From mailman-admin@ietf.org Sat Mar 1 11:21:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10577 for ; Sat, 1 Mar 2003 11:21:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21GUWp15643 for ; Sat, 1 Mar 2003 11:30:32 -0500 Date: Sat, 01 Mar 2003 11:30:32 -0500 Message-ID: <20030301163032.26394.1503.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: seamoby-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, seamoby-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for seamoby-archive@lists.ietf.org: List Password // URL ---- -------- seamoby@ietf.org Zzch https://www1.ietf.org/mailman/options/seamoby/seamoby-archive%40lists.ietf.org From mailnull@www1.ietf.org Sat Mar 1 23:43:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24461 for ; Sat, 1 Mar 2003 23:43:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h224qbi27211 for seamoby-archive@odin.ietf.org; Sat, 1 Mar 2003 23:52:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224qbp27208 for ; Sat, 1 Mar 2003 23:52:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24451 for ; Sat, 1 Mar 2003 23:42:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224qLp27178; Sat, 1 Mar 2003 23:52:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224isp26967 for ; Sat, 1 Mar 2003 23:44:54 -0500 Received: from fep01-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24397 for ; Sat, 1 Mar 2003 23:35:03 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030302043648.ZYNQ4812.fep01-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Sat, 1 Mar 2003 23:36:48 -0500 Message-ID: <3E618A3C.5060708@ee.ryerson.ca> Date: Sat, 01 Mar 2003 23:36:12 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Sat, 1 Mar 2003 23:36:48 -0500 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 10 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 1 23:43:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24488 for ; Sat, 1 Mar 2003 23:43:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224qLp27178; Sat, 1 Mar 2003 23:52:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224isp26967 for ; Sat, 1 Mar 2003 23:44:54 -0500 Received: from fep01-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24397 for ; Sat, 1 Mar 2003 23:35:03 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030302043648.ZYNQ4812.fep01-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Sat, 1 Mar 2003 23:36:48 -0500 Message-ID: <3E618A3C.5060708@ee.ryerson.ca> Date: Sat, 01 Mar 2003 23:36:12 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Sat, 1 Mar 2003 23:36:48 -0500 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 10 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 3 09:49:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27375 for ; Mon, 3 Mar 2003 09:49:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23ExFW23014 for seamoby-archive@odin.ietf.org; Mon, 3 Mar 2003 09:59:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23ExEp23011 for ; Mon, 3 Mar 2003 09:59:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27338 for ; Mon, 3 Mar 2003 09:48:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Ewip22970; Mon, 3 Mar 2003 09:58:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Evfp22917 for ; Mon, 3 Mar 2003 09:57:41 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27292 for ; Mon, 3 Mar 2003 09:47:08 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h23En9v07595 for ; Mon, 3 Mar 2003 15:49:09 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6318541F0C for ; Mon, 3 Mar 2003 14:33:27 +0100 (CET) Message-ID: <3E635A9E.5040305@ccrle.nec.de> Date: Mon, 03 Mar 2003 14:37:34 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] update of the CARD design team's protocol proposal submitted Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, an updated version of the CARD design team's draft on a Candidate Access Router Discovery protocol (version 01) has been just submitted to the IETF secretariat. After the draft's availability has been announced, feedback and comments on this updated version are highly appreciated. Regards, marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 3 09:49:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27389 for ; Mon, 3 Mar 2003 09:49:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Ewip22970; Mon, 3 Mar 2003 09:58:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Evfp22917 for ; Mon, 3 Mar 2003 09:57:41 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27292 for ; Mon, 3 Mar 2003 09:47:08 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h23En9v07595 for ; Mon, 3 Mar 2003 15:49:09 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6318541F0C for ; Mon, 3 Mar 2003 14:33:27 +0100 (CET) Message-ID: <3E635A9E.5040305@ccrle.nec.de> Date: Mon, 03 Mar 2003 14:37:34 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] update of the CARD design team's protocol proposal submitted Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, an updated version of the CARD design team's draft on a Candidate Access Router Discovery protocol (version 01) has been just submitted to the IETF secretariat. After the draft's availability has been announced, feedback and comments on this updated version are highly appreciated. Regards, marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 4 11:42:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29910 for ; Tue, 4 Mar 2003 11:42:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GqkP19439 for seamoby-archive@odin.ietf.org; Tue, 4 Mar 2003 11:52:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Gqkp19436 for ; Tue, 4 Mar 2003 11:52:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29876 for ; Tue, 4 Mar 2003 11:41:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GqPp19415; Tue, 4 Mar 2003 11:52:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GhIp18977 for ; Tue, 4 Mar 2003 11:43:18 -0500 Received: from send.nc.u-tokyo.ac.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29492 for ; Tue, 4 Mar 2003 11:32:12 -0500 (EST) Received: from arten12.nc.u-tokyo.ac.jp (arten12.nc.u-tokyo.ac.jp [133.11.119.42]) by send.nc.u-tokyo.ac.jp (8.12.8/3.7W) with SMTP id BAA20970 for ; Wed, 5 Mar 2003 01:34:54 +0900 (JST) Received: from chamomile.mlab.t.u-tokyo.ac.jp ([133.11.236.1]) by arten12.nc.u-tokyo.ac.jp (NAVGW 2.5.1.18) with SMTP id M2003030501341421826 for ; Wed, 05 Mar 2003 01:34:14 +0900 Received: (qmail 4859 invoked from network); 4 Mar 2003 16:34:14 -0000 Received: from unknown (HELO sunflower.mlab.t.u-tokyo.ac.jp) (192.168.1.1) by 133.11.236.1 with SMTP; 4 Mar 2003 16:34:14 -0000 Received: (qmail 15539 invoked by alias); 4 Mar 2003 16:34:13 -0000 Received: (qmail 15532 invoked from network); 4 Mar 2003 16:34:13 -0000 Received: from unknown (HELO MORI-T30.mlab.t.u-tokyo.ac.jp) (192.168.1.104) by sunflower.mlab.t.u-tokyo.ac.jp with SMTP; 4 Mar 2003 16:34:13 -0000 Message-Id: <5.0.2.7.2.20030305013337.06f19de0@pop.mlab.t.u-tokyo.ac.jp> X-Sender: mori@pop.mlab.t.u-tokyo.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Wed, 05 Mar 2003 01:33:46 +0900 To: seamoby@ietf.org From: Hiroyuki Morikawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Seamoby] Reminder -- MobiCom 2003 paper registration deadline March 5 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is just a reminder that the deadline for registering papers for submission to MobiCom 2003, Ninth Annual International Conference on Mobile Computing and Networking, is this Wednesday, March 5, 2003. All papers must be registered by 11:59 PM PST (US Pacific timezone) on March 5. Registering a paper involves entering the paper's - title, - abstract, - author information, and - topic areas into the MobiCom 2003 EDAS web-based paper submission system. For more information on paper registration and submission for MobiCom 2003, please see the Call for Papers at http://www.sigmobile.org/mobicom/2003/cfp.html and the detailed submission instructions at http://www.sigmobile.org/mobicom/2003/submit.html Once you have registered your paper in this way by the March 5 deadline above, the deadline for then actually submitting the paper is Wednesday, March 12, at 11:59 PM PST (US Pacific timezone). Hiro _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 4 11:42:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29956 for ; Tue, 4 Mar 2003 11:42:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GqPp19415; Tue, 4 Mar 2003 11:52:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GhIp18977 for ; Tue, 4 Mar 2003 11:43:18 -0500 Received: from send.nc.u-tokyo.ac.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29492 for ; Tue, 4 Mar 2003 11:32:12 -0500 (EST) Received: from arten12.nc.u-tokyo.ac.jp (arten12.nc.u-tokyo.ac.jp [133.11.119.42]) by send.nc.u-tokyo.ac.jp (8.12.8/3.7W) with SMTP id BAA20970 for ; Wed, 5 Mar 2003 01:34:54 +0900 (JST) Received: from chamomile.mlab.t.u-tokyo.ac.jp ([133.11.236.1]) by arten12.nc.u-tokyo.ac.jp (NAVGW 2.5.1.18) with SMTP id M2003030501341421826 for ; Wed, 05 Mar 2003 01:34:14 +0900 Received: (qmail 4859 invoked from network); 4 Mar 2003 16:34:14 -0000 Received: from unknown (HELO sunflower.mlab.t.u-tokyo.ac.jp) (192.168.1.1) by 133.11.236.1 with SMTP; 4 Mar 2003 16:34:14 -0000 Received: (qmail 15539 invoked by alias); 4 Mar 2003 16:34:13 -0000 Received: (qmail 15532 invoked from network); 4 Mar 2003 16:34:13 -0000 Received: from unknown (HELO MORI-T30.mlab.t.u-tokyo.ac.jp) (192.168.1.104) by sunflower.mlab.t.u-tokyo.ac.jp with SMTP; 4 Mar 2003 16:34:13 -0000 Message-Id: <5.0.2.7.2.20030305013337.06f19de0@pop.mlab.t.u-tokyo.ac.jp> X-Sender: mori@pop.mlab.t.u-tokyo.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Wed, 05 Mar 2003 01:33:46 +0900 To: seamoby@ietf.org From: Hiroyuki Morikawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Seamoby] Reminder -- MobiCom 2003 paper registration deadline March 5 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is just a reminder that the deadline for registering papers for submission to MobiCom 2003, Ninth Annual International Conference on Mobile Computing and Networking, is this Wednesday, March 5, 2003. All papers must be registered by 11:59 PM PST (US Pacific timezone) on March 5. Registering a paper involves entering the paper's - title, - abstract, - author information, and - topic areas into the MobiCom 2003 EDAS web-based paper submission system. For more information on paper registration and submission for MobiCom 2003, please see the Call for Papers at http://www.sigmobile.org/mobicom/2003/cfp.html and the detailed submission instructions at http://www.sigmobile.org/mobicom/2003/submit.html Once you have registered your paper in this way by the March 5 deadline above, the deadline for then actually submitting the paper is Wednesday, March 12, at 11:59 PM PST (US Pacific timezone). Hiro _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 4 14:19:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06265 for ; Tue, 4 Mar 2003 14:19:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24JUYj06103 for seamoby-archive@odin.ietf.org; Tue, 4 Mar 2003 14:30:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JUY506100 for ; Tue, 4 Mar 2003 14:30:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06245 for ; Tue, 4 Mar 2003 14:19:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JUA506088; Tue, 4 Mar 2003 14:30:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JSL506026 for ; Tue, 4 Mar 2003 14:28:21 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06147 for ; Tue, 4 Mar 2003 14:17:14 -0500 (EST) Message-ID: <01d401c2e282$bbf1b140$636015ac@T23KEMPF> From: "James Kempf" To: Date: Tue, 4 Mar 2003 11:17:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD Draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, The CARD draft got hung up on an SMTP server and missed the deadline, but Marco posted a public copy to the URL below. Please read and send comments to the list. http://www.ccrle.nec.de/I-D/draft-ietf-seamoby-card-protocol-01.txt jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 4 14:20:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06284 for ; Tue, 4 Mar 2003 14:20:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JUA506088; Tue, 4 Mar 2003 14:30:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JSL506026 for ; Tue, 4 Mar 2003 14:28:21 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06147 for ; Tue, 4 Mar 2003 14:17:14 -0500 (EST) Message-ID: <01d401c2e282$bbf1b140$636015ac@T23KEMPF> From: "James Kempf" To: Date: Tue, 4 Mar 2003 11:17:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD Draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, The CARD draft got hung up on an SMTP server and missed the deadline, but Marco posted a public copy to the URL below. Please read and send comments to the list. http://www.ccrle.nec.de/I-D/draft-ietf-seamoby-card-protocol-01.txt jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 4 18:27:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15177 for ; Tue, 4 Mar 2003 18:27:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24NcDk24202 for seamoby-archive@odin.ietf.org; Tue, 4 Mar 2003 18:38:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24NcD524199 for ; Tue, 4 Mar 2003 18:38:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15112 for ; Tue, 4 Mar 2003 18:27:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Nbv524158; Tue, 4 Mar 2003 18:37:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24NaT523225 for ; Tue, 4 Mar 2003 18:36:29 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15039 for ; Tue, 4 Mar 2003 18:25:16 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24NRWi05703 for ; Tue, 4 Mar 2003 17:27:32 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Mar 2003 17:27:18 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Mar 2003 15:26:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Mar 2003 18:26:51 -0500 Message-ID: Thread-Topic: Comments on DT CARD draft Thread-Index: AcLipYj3fwziV8hMQou6982/YtZiJQ== To: X-OriginalArrivalTime: 04 Mar 2003 23:26:52.0536 (UTC) FILETIME=[89928F80:01C2E2A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h24NaT523226 Subject: [Seamoby] Comments on DT CARD draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi guys, I glanced through the CARD draft and I have some preliminary comments. Here they are: 1. Violation of Requirement 3.8 The draft violates Requirement 3.8, by introducing a new network element specifically intended for CARD. 2. Need for CARD server. The CARD server will never be used once the network reaches steady state. So we are talking about introducing a network element for the sake of CARD discovery that will be never used probably after one handover between ARs. Once a handover happens between CARs, you can push all the AP information as capabilities to the CARs. So why do we need this server again? Apart from this, the DT draft has acknowledged the fact that there is no guarantee that the response from the CARD server will get to the MN in time for the handover. So even when the server is present, at least the first handover is a seamless in a probabilistic sense. The CARD server is a single point of failure. To avoid this we may introduce some kind of redundancy here. But then we are talking about making the architecture even more complicated, along with associated baggage, for a functionality that will probably be never used after sometime. There is some discussion in the draft that we can add this server functionality to AAA and RADIUS servers. But can this be such an unilateral decision that doesn't really need discussion with the AAA WG? I therefore think this is not quite a feasible solution right now. Please correct me if I'm wrong about this. 3. Security section I think "Scope ID" is a complicated solution, whose cost of usage far out weighs the benefit. Even here we are limiting the granularity of error to that decided by Scope IDs. Therefore if there are n ARs with the same scope ID then we allow n invalid entries in the cache. Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. 4. Some random observations.... The difference between this draft and dycard is that the AP-AR for the first handover between any two CARs is got from the server. That's it. After this once the cache is created, inter CAR communication takes care of capability transfer and maintenance. Security wise, I don't think dycard is any way more susceptible to attacks than the DT draft. This is fundamentally because the MN's are involved in populating the cache. In the current version of dycard, the first handover between CARs is a bootstrap handover and hence the MN is not provided the mapping between AP and AR. However, we have shown (albeit in an earlier version of our protocol) that we can lower the probability of this too. Even in the DT's CARD approach this is not deterministic process (as acknowledged in the draft) and if the entry is not in cache the response from the CARD server may not get to the MN in time. So I think we should look hard into the cost vs. benefit ratio of introducing a new element in the network for CARD. IMHO, it is not worth it. Thanks for your time, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 4 18:27:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15190 for ; Tue, 4 Mar 2003 18:27:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Nbv524158; Tue, 4 Mar 2003 18:37:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24NaT523225 for ; Tue, 4 Mar 2003 18:36:29 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15039 for ; Tue, 4 Mar 2003 18:25:16 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24NRWi05703 for ; Tue, 4 Mar 2003 17:27:32 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Mar 2003 17:27:18 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Mar 2003 15:26:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Mar 2003 18:26:51 -0500 Message-ID: Thread-Topic: Comments on DT CARD draft Thread-Index: AcLipYj3fwziV8hMQou6982/YtZiJQ== To: X-OriginalArrivalTime: 04 Mar 2003 23:26:52.0536 (UTC) FILETIME=[89928F80:01C2E2A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h24NaT523226 Subject: [Seamoby] Comments on DT CARD draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi guys, I glanced through the CARD draft and I have some preliminary comments. Here they are: 1. Violation of Requirement 3.8 The draft violates Requirement 3.8, by introducing a new network element specifically intended for CARD. 2. Need for CARD server. The CARD server will never be used once the network reaches steady state. So we are talking about introducing a network element for the sake of CARD discovery that will be never used probably after one handover between ARs. Once a handover happens between CARs, you can push all the AP information as capabilities to the CARs. So why do we need this server again? Apart from this, the DT draft has acknowledged the fact that there is no guarantee that the response from the CARD server will get to the MN in time for the handover. So even when the server is present, at least the first handover is a seamless in a probabilistic sense. The CARD server is a single point of failure. To avoid this we may introduce some kind of redundancy here. But then we are talking about making the architecture even more complicated, along with associated baggage, for a functionality that will probably be never used after sometime. There is some discussion in the draft that we can add this server functionality to AAA and RADIUS servers. But can this be such an unilateral decision that doesn't really need discussion with the AAA WG? I therefore think this is not quite a feasible solution right now. Please correct me if I'm wrong about this. 3. Security section I think "Scope ID" is a complicated solution, whose cost of usage far out weighs the benefit. Even here we are limiting the granularity of error to that decided by Scope IDs. Therefore if there are n ARs with the same scope ID then we allow n invalid entries in the cache. Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. 4. Some random observations.... The difference between this draft and dycard is that the AP-AR for the first handover between any two CARs is got from the server. That's it. After this once the cache is created, inter CAR communication takes care of capability transfer and maintenance. Security wise, I don't think dycard is any way more susceptible to attacks than the DT draft. This is fundamentally because the MN's are involved in populating the cache. In the current version of dycard, the first handover between CARs is a bootstrap handover and hence the MN is not provided the mapping between AP and AR. However, we have shown (albeit in an earlier version of our protocol) that we can lower the probability of this too. Even in the DT's CARD approach this is not deterministic process (as acknowledged in the draft) and if the entry is not in cache the response from the CARD server may not get to the MN in time. So I think we should look hard into the cost vs. benefit ratio of introducing a new element in the network for CARD. IMHO, it is not worth it. Thanks for your time, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 12:08:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13507 for ; Wed, 5 Mar 2003 12:08:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25HJkD16695 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 12:19:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25HJk516692 for ; Wed, 5 Mar 2003 12:19:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13463 for ; Wed, 5 Mar 2003 12:08:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25HJR516465; Wed, 5 Mar 2003 12:19:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25HBj515793 for ; Wed, 5 Mar 2003 12:11:45 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12933 for ; Wed, 5 Mar 2003 12:00:10 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h25H35T9024175 for ; Wed, 5 Mar 2003 10:03:05 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA26164 for ; Wed, 5 Mar 2003 10:00:20 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Mar 2003 11:02:11 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE2C@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 11:02:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Govind, Thanks for your initial feedback. Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, March 04, 2003 5:27 PM To: seamoby@ietf.org Subject: [Seamoby] Comments on DT CARD draft Hi guys, I glanced through the CARD draft and I have some preliminary comments. Here they are: 1. Violation of Requirement 3.8 The draft violates Requirement 3.8, by introducing a new network element specifically intended for CARD. AJOY-> We are aware of this. What is the status of requirement draft? Is it approved by IESG yet. Probably we need to change this requirement in case WG likes to go with server based approach. 2. Need for CARD server. The CARD server will never be used once the network reaches steady state. So we are talking about introducing a network element for the sake of CARD discovery that will be never used probably after one handover between ARs. AJOY-> This depends upon the cache timeout as well as handoff traffic. BTW, the server based approach is easier to manage as well it provides extra security. If we deploy scope-id with serve based approach, then it is very much possible to reduce or even eliminate the problem of cache contamination. This also minimizes the affect DoS attack. Once a handover happens between CARs, you can push all the AP information as capabilities to the CARs. So why do we need this server again? AJOY-> These entries may not be cached for ever. Smaller the cache timeout, the earlier you will be able to detect any change of capability or L2->L3 mapping information. Apart from this, the DT draft has acknowledged the fact that there is no guarantee that the response from the CARD server will get to the MN in time for the handover. So even when the server is present, at least the first handover is a seamless in a probabilistic sense. AJOY-> I think this will be better than the case where cache entries are solely propagated by the mobile node. I think in the later case, the first handoff will always be the slower. Moreover the later approach is very difficult to manage and is even less secure. The CARD server is a single point of failure. To avoid this we may introduce some kind of redundancy here. But then we are talking about making the architecture even more complicated, along with associated baggage, for a functionality that will probably be never used after sometime. BTW-> The IP packets are not routed via CARD server so I am not sure if it a big drawback. I will be more concerned about the single point of failure where IP packets are routed through it. CARD server will provide a similar function as DNS server So, probably it is not a big drawback in my understanding. On the other handoff, server based approach provides better manageability as well control. As I mentioned above, with clever use of scope-id, it is possible to reduce the affect of DoS attack as well as cache contamination problem. There is some discussion in the draft that we can add this server functionality to AAA and RADIUS servers. But can this be such an unilateral decision that doesn't really need discussion with the AAA WG? I therefore think this is not quite a feasible solution right now. Please correct me if I'm wrong about this. AJOY-> Probably you are right. We do need to get consensus from AAA group for doing this. BTW, If we use AAA server, then it is also possible to use AAA server for the purpose of key distribution. I would like to receive feedback from other members of WG about the potential use of AAA server as CARD server. 3. Security section I think "Scope ID" is a complicated solution, whose cost of usage far out weighs the benefit. Even here we are limiting the granularity of error to that decided by Scope IDs. Therefore if there are n ARs with the same scope ID then we allow n invalid entries in the cache. AJOY-> I am not sure I agree with you here. Could you provide some additional detail why you think scope id is complicated? Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. AJOY-> Let be focused now. 4. Some random observations.... The difference between this draft and dycard is that the AP-AR for the first handover between any two CARs is got from the server. That's it. After this once the cache is created, inter CAR communication takes care of capability transfer and maintenance. Security wise, I don't think dycard is any way more susceptible to attacks than the DT draft. This is fundamentally because the MN's are involved in populating the cache. In the current version of dycard, the first handover between CARs is a bootstrap handover and hence the MN is not provided the mapping between AP and AR. However, we have shown (albeit in an earlier version of our protocol) that we can lower the probability of this too. Even in the DT's CARD approach this is not deterministic process (as acknowledged in the draft) and if the entry is not in cache the response from the CARD server may not get to the MN in time. So I think we should look hard into the cost vs. benefit ratio of introducing a new element in the network for CARD. IMHO, it is not worth it. Thanks for your time, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 12:09:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13534 for ; Wed, 5 Mar 2003 12:09:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25HJR516465; Wed, 5 Mar 2003 12:19:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25HBj515793 for ; Wed, 5 Mar 2003 12:11:45 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12933 for ; Wed, 5 Mar 2003 12:00:10 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h25H35T9024175 for ; Wed, 5 Mar 2003 10:03:05 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA26164 for ; Wed, 5 Mar 2003 10:00:20 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Mar 2003 11:02:11 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE2C@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 11:02:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Govind, Thanks for your initial feedback. Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, March 04, 2003 5:27 PM To: seamoby@ietf.org Subject: [Seamoby] Comments on DT CARD draft Hi guys, I glanced through the CARD draft and I have some preliminary comments. Here they are: 1. Violation of Requirement 3.8 The draft violates Requirement 3.8, by introducing a new network element specifically intended for CARD. AJOY-> We are aware of this. What is the status of requirement draft? Is it approved by IESG yet. Probably we need to change this requirement in case WG likes to go with server based approach. 2. Need for CARD server. The CARD server will never be used once the network reaches steady state. So we are talking about introducing a network element for the sake of CARD discovery that will be never used probably after one handover between ARs. AJOY-> This depends upon the cache timeout as well as handoff traffic. BTW, the server based approach is easier to manage as well it provides extra security. If we deploy scope-id with serve based approach, then it is very much possible to reduce or even eliminate the problem of cache contamination. This also minimizes the affect DoS attack. Once a handover happens between CARs, you can push all the AP information as capabilities to the CARs. So why do we need this server again? AJOY-> These entries may not be cached for ever. Smaller the cache timeout, the earlier you will be able to detect any change of capability or L2->L3 mapping information. Apart from this, the DT draft has acknowledged the fact that there is no guarantee that the response from the CARD server will get to the MN in time for the handover. So even when the server is present, at least the first handover is a seamless in a probabilistic sense. AJOY-> I think this will be better than the case where cache entries are solely propagated by the mobile node. I think in the later case, the first handoff will always be the slower. Moreover the later approach is very difficult to manage and is even less secure. The CARD server is a single point of failure. To avoid this we may introduce some kind of redundancy here. But then we are talking about making the architecture even more complicated, along with associated baggage, for a functionality that will probably be never used after sometime. BTW-> The IP packets are not routed via CARD server so I am not sure if it a big drawback. I will be more concerned about the single point of failure where IP packets are routed through it. CARD server will provide a similar function as DNS server So, probably it is not a big drawback in my understanding. On the other handoff, server based approach provides better manageability as well control. As I mentioned above, with clever use of scope-id, it is possible to reduce the affect of DoS attack as well as cache contamination problem. There is some discussion in the draft that we can add this server functionality to AAA and RADIUS servers. But can this be such an unilateral decision that doesn't really need discussion with the AAA WG? I therefore think this is not quite a feasible solution right now. Please correct me if I'm wrong about this. AJOY-> Probably you are right. We do need to get consensus from AAA group for doing this. BTW, If we use AAA server, then it is also possible to use AAA server for the purpose of key distribution. I would like to receive feedback from other members of WG about the potential use of AAA server as CARD server. 3. Security section I think "Scope ID" is a complicated solution, whose cost of usage far out weighs the benefit. Even here we are limiting the granularity of error to that decided by Scope IDs. Therefore if there are n ARs with the same scope ID then we allow n invalid entries in the cache. AJOY-> I am not sure I agree with you here. Could you provide some additional detail why you think scope id is complicated? Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. AJOY-> Let be focused now. 4. Some random observations.... The difference between this draft and dycard is that the AP-AR for the first handover between any two CARs is got from the server. That's it. After this once the cache is created, inter CAR communication takes care of capability transfer and maintenance. Security wise, I don't think dycard is any way more susceptible to attacks than the DT draft. This is fundamentally because the MN's are involved in populating the cache. In the current version of dycard, the first handover between CARs is a bootstrap handover and hence the MN is not provided the mapping between AP and AR. However, we have shown (albeit in an earlier version of our protocol) that we can lower the probability of this too. Even in the DT's CARD approach this is not deterministic process (as acknowledged in the draft) and if the entry is not in cache the response from the CARD server may not get to the MN in time. So I think we should look hard into the cost vs. benefit ratio of introducing a new element in the network for CARD. IMHO, it is not worth it. Thanks for your time, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 14:23:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23255 for ; Wed, 5 Mar 2003 14:23:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25JXd311222 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 14:33:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JXdO11219 for ; Wed, 5 Mar 2003 14:33:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23203 for ; Wed, 5 Mar 2003 14:22:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JXFO11170; Wed, 5 Mar 2003 14:33:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25J7XO09061 for ; Wed, 5 Mar 2003 14:07:33 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21732 for ; Wed, 5 Mar 2003 13:56:21 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25IwRa01086 for ; Wed, 5 Mar 2003 12:58:27 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 12:58:24 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 10:58:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 13:58:23 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjORcHjeuwYBRmRTaDHCoSMPpE5gACpZPQ To: , X-OriginalArrivalTime: 05 Mar 2003 18:58:24.0537 (UTC) FILETIME=[32DEB890:01C2E349] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25J7XO09065 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy, Comments inline. Thanks for your reply. -Govind. AJOY-> We are aware of this. What is the status of requirement draft? Is it approved by IESG yet. Probably we need to change this requirement in case WG likes to go with server based approach. [Govind] The requirements document has passed last WG last call. The IESG did come back with one set of comments, but I don't think they had any problems with this particular requirement in those comments. [snip] AJOY-> This depends upon the cache timeout as well as handoff traffic. BTW, the server based approach is easier to manage as well it provides extra security. If we deploy scope-id with serve based approach, then it is very much possible to reduce or even eliminate the problem of cache contamination. This also minimizes the affect DoS attack. [Govind] The cache timeout can be handled quite easily. Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entries that are not CARs in the cache. In fact, the DT draft acknowledges that the CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a CARD server. [snip] AJOY-> These entries may not be cached for ever. Smaller the cache timeout, the earlier you will be able to detect any change of capability or L2->L3 mapping information. [Govind] So we need to choose a timeout that is appropriate, why do we need a server for this? I still don't understand that. [snip] AJOY-> I think this will be better than the case where cache entries are solely propagated by the mobile node. I think in the later case, the first handoff will always be the slower. Moreover the later approach is very difficult to manage and is even less secure. [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? Lastly, as I pointed out in my earlier mail, we have provided a method, in an earlier version of the draft, that makes the first handover also seamless in a probabilistic sense. I don't think DT draft can promise better than that too. We omitted this, because we felt that it doesn't make much sense in the steady state of the system. Basically a cost vs. benefit analysis. ----------* [snip] BTW-> The IP packets are not routed via CARD server so I am not sure if it a big drawback. [Govind] You need the CARD server for any translation on a cache miss. So what is this that you bring about routing packets via CARD server? I'm completely missing your point here. -----------------------* I will be more concerned about the single point of failure where IP packets are routed through it. CARD server will provide a similar function as DNS server So, probably it is not a big drawback in my understanding. [Govind] Does this imply that the functionality of the CARD server is minimal? We are talking about the "central" point of control here that determines the cache entries. I think it a very important point to consider. ---------------------------* On the other handoff, server based approach provides better manageability as well control. [Govind] What manageability are you talking about? You assume that each AR knows what APs it has. Why should it be conveyed to the CARD server? Why can't it be conveyed directly to its CARs? Also, what lack of manageability that you perceive in dycard? Can we talk quantitatively rather qualitatively here? As I mentioned above, with clever use of scope-id, it is possible to reduce the affect of DoS attack as well as cache contamination problem. [Govind] Could you define "clever" use of scope-id? Quoting from the draft "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. [snip] AJOY-> Probably you are right. We do need to get consensus from AAA group for doing this. BTW, If we use AAA server, then it is also possible to use AAA server for the purpose of key distribution. I would like to receive feedback from other members of WG about the potential use of AAA server as CARD server. [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? [snip] AJOY-> I am not sure I agree with you here. Could you provide some additional detail why you think scope id is complicated? [Govind]I'll let you know if I come up with something more, than what I've provided in my previous email. Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. AJOY-> Let be focused now. [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with a solution that works well now, and also has a good chance of being accepted later. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 14:23:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23308 for ; Wed, 5 Mar 2003 14:23:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JXFO11170; Wed, 5 Mar 2003 14:33:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25J7XO09061 for ; Wed, 5 Mar 2003 14:07:33 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21732 for ; Wed, 5 Mar 2003 13:56:21 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25IwRa01086 for ; Wed, 5 Mar 2003 12:58:27 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 12:58:24 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 10:58:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 13:58:23 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjORcHjeuwYBRmRTaDHCoSMPpE5gACpZPQ To: , X-OriginalArrivalTime: 05 Mar 2003 18:58:24.0537 (UTC) FILETIME=[32DEB890:01C2E349] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25J7XO09065 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy, Comments inline. Thanks for your reply. -Govind. AJOY-> We are aware of this. What is the status of requirement draft? Is it approved by IESG yet. Probably we need to change this requirement in case WG likes to go with server based approach. [Govind] The requirements document has passed last WG last call. The IESG did come back with one set of comments, but I don't think they had any problems with this particular requirement in those comments. [snip] AJOY-> This depends upon the cache timeout as well as handoff traffic. BTW, the server based approach is easier to manage as well it provides extra security. If we deploy scope-id with serve based approach, then it is very much possible to reduce or even eliminate the problem of cache contamination. This also minimizes the affect DoS attack. [Govind] The cache timeout can be handled quite easily. Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entries that are not CARs in the cache. In fact, the DT draft acknowledges that the CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a CARD server. [snip] AJOY-> These entries may not be cached for ever. Smaller the cache timeout, the earlier you will be able to detect any change of capability or L2->L3 mapping information. [Govind] So we need to choose a timeout that is appropriate, why do we need a server for this? I still don't understand that. [snip] AJOY-> I think this will be better than the case where cache entries are solely propagated by the mobile node. I think in the later case, the first handoff will always be the slower. Moreover the later approach is very difficult to manage and is even less secure. [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? Lastly, as I pointed out in my earlier mail, we have provided a method, in an earlier version of the draft, that makes the first handover also seamless in a probabilistic sense. I don't think DT draft can promise better than that too. We omitted this, because we felt that it doesn't make much sense in the steady state of the system. Basically a cost vs. benefit analysis. ----------* [snip] BTW-> The IP packets are not routed via CARD server so I am not sure if it a big drawback. [Govind] You need the CARD server for any translation on a cache miss. So what is this that you bring about routing packets via CARD server? I'm completely missing your point here. -----------------------* I will be more concerned about the single point of failure where IP packets are routed through it. CARD server will provide a similar function as DNS server So, probably it is not a big drawback in my understanding. [Govind] Does this imply that the functionality of the CARD server is minimal? We are talking about the "central" point of control here that determines the cache entries. I think it a very important point to consider. ---------------------------* On the other handoff, server based approach provides better manageability as well control. [Govind] What manageability are you talking about? You assume that each AR knows what APs it has. Why should it be conveyed to the CARD server? Why can't it be conveyed directly to its CARs? Also, what lack of manageability that you perceive in dycard? Can we talk quantitatively rather qualitatively here? As I mentioned above, with clever use of scope-id, it is possible to reduce the affect of DoS attack as well as cache contamination problem. [Govind] Could you define "clever" use of scope-id? Quoting from the draft "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. [snip] AJOY-> Probably you are right. We do need to get consensus from AAA group for doing this. BTW, If we use AAA server, then it is also possible to use AAA server for the purpose of key distribution. I would like to receive feedback from other members of WG about the potential use of AAA server as CARD server. [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? [snip] AJOY-> I am not sure I agree with you here. Could you provide some additional detail why you think scope id is complicated? [Govind]I'll let you know if I come up with something more, than what I've provided in my previous email. Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. AJOY-> Let be focused now. [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with a solution that works well now, and also has a good chance of being accepted later. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 14:36:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24199 for ; Wed, 5 Mar 2003 14:36:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25JlNv13559 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 14:47:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JlNO13556 for ; Wed, 5 Mar 2003 14:47:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24172 for ; Wed, 5 Mar 2003 14:36:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JlBO13545; Wed, 5 Mar 2003 14:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JkLO13469 for ; Wed, 5 Mar 2003 14:46:21 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24110 for ; Wed, 5 Mar 2003 14:35:10 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25JbC818063 for ; Wed, 5 Mar 2003 13:37:12 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Mar 2003 13:37:12 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 13:37:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 14:37:10 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjORcHjeuwYBRmRTaDHCoSMPpE5gAEdeHAAAAPf/A= To: X-OriginalArrivalTime: 05 Mar 2003 19:37:11.0890 (UTC) FILETIME=[9E149B20:01C2E34E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25JkLO13470 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 14:37:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24236 for ; Wed, 5 Mar 2003 14:37:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JlBO13545; Wed, 5 Mar 2003 14:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JkLO13469 for ; Wed, 5 Mar 2003 14:46:21 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24110 for ; Wed, 5 Mar 2003 14:35:10 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25JbC818063 for ; Wed, 5 Mar 2003 13:37:12 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Mar 2003 13:37:12 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 13:37:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 14:37:10 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjORcHjeuwYBRmRTaDHCoSMPpE5gAEdeHAAAAPf/A= To: X-OriginalArrivalTime: 05 Mar 2003 19:37:11.0890 (UTC) FILETIME=[9E149B20:01C2E34E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25JkLO13470 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 15:15:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26914 for ; Wed, 5 Mar 2003 15:15:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25KPiW16853 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 15:25:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KPiO16850 for ; Wed, 5 Mar 2003 15:25:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26894 for ; Wed, 5 Mar 2003 15:14:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KPCO16818; Wed, 5 Mar 2003 15:25:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KOrO16776 for ; Wed, 5 Mar 2003 15:24:53 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26871 for ; Wed, 5 Mar 2003 15:13:35 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h25KGIc1009023 for ; Thu, 6 Mar 2003 04:16:18 +0800 (SGT) Received: from bkdom-MTA by mailer.icr.a-star.edu.sg with Novell_GroupWise; Thu, 06 Mar 2003 04:08:55 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Thu, 06 Mar 2003 04:08:26 +0800 From: "Paul Tan Hock Lai" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_2E717B47.09680289" Subject: [Seamoby] [ID Announce] Recommendations for Achieving Seameless IPv6 Handover in 802.11 Networks Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_2E717B47.09680289 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I have recently submitted an individual draft which entails recommendations= on achieving seamless IPv6 handover in 802.11 networks and also dynamic = candidate access routers discovery. You are most welcome to read this draft from the following link: http://www.ietf.org/internet-drafts/draft-paultan-seamless-ipv6-handoff-802= -00.txt I sincerely look forward to your valuable feedback concerning this draft. = All comments and inputs are welcomed and greatly appreciated. Yours Sincerely, Paul Tan " .... success is never guarantee but failure is, if you don't even try ... " --=_2E717B47.09680289 Content-Type: text/plain Content-Disposition: attachment; filename="draft-paultan-seamless-ipv6-handoff-802-00.txt" Content-Transfer-Encoding: 7bit Internet Draft Paul Tan draft-paultan-seamless-ipv6-handoff-802-00.txt ICR Expires: Aug 2003 Feb 2003 Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract To achieve seamless layer 3 handover, mobile nodes must be able to perform movement detection and neighborhood candidate access routers discovery quickly and efficiently. In this document, we present a conceptual overview on how to extend the IEEE 802.11 Management frames to carry extensible application- specific Information Element, which allow access points to advertise the capabilities information of its associated network/provider and to improve movement detection. We believe that mobile nodes can thus dynamically discover neighboring candidate access routers or networks more quickly and efficiently, and also to obtain valuable capabilities information so as to select the 'best' target access router to initiate seamless handover. Paul Tan Expires - August 2003 [Page 1] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in RFC 2119. This document uses the terminology defined in [2] and [3]. The following terminology and abbreviations are used in this document. Mobile Node (MN) A Mobile IPv6 host Access Router (AR) An Access Network Router residing on the edge of an Access Network and offers IP connectivity to mobile nodes New Access Router (NAR) The MN's anticipated default router subsequent to its handover Candidate AR (CAR) An AR to which a MN has a choice of performing IP-level handover. This implies that the MN has the right radio interface to connect to an AP that is served by this AR, as well as the coverage of this AR overlaps with that of the AR to which the MN is currently attached to. Target AR (TAR) An AR with which the procedures for the MN's IP-level handover are initiated. The TAR is selected after running a TAR Selection algorithm that takes into account the capabilities of CARs, preferences of the MN and any other local policies. New CoA (NCoA) The MN's Care of Address valid on NAR Handover A process of terminating existing connectivity and obtaining new IP connectivity. Router Solicitation for Proxy (RtSolPr) A message from the MN to the PAR requesting information for a potential handover Proxy Router Advertisement (PrRtAdv) A message from the PAR indicating a MN to undergo handover Paul Tan Expires - August 2003 [Page 2] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 Access Point (AP) An L2 entity that has station functionality and provides access to the distribution services, via the wireless medium for associated stations. Association The service used to establish access point/station (AP/STA) mapping and enable STA access to the Distribution System. Basic Service Set (BSS) A set of stations controlled by a single coordination function, where the coordination function may be centralized (e.g., in a single AP) or distributed (e.g., for an ad-hoc network). The BSS can be thought of as the coverage area of a single AP. Distribution System (DS) A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set(ESS). Extended Service Set (ESS) A set of one or more interconnected basic service sets (BSSs) and integrated local area networks (LANs) that appears as a single BSS to the logical link control layer at any station associated with one of those BSSs. The ESS can be thought of as the coverage area provided by a collection of APs all interconnected by the Distribution System. It may consist of one or more IP subnets. Paul Tan Expires - August 2003 [Page 3] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 2. Introduction In Mobile IPv6 [1], a mobile node can effectively maintain its connectivity to the Internet when it changes its point-of-attachment to the Internet. During the handover, the mobile node is unable to send/receive IPv6 packets both due to its L2/L3 handover operations. This handover latency is unacceptable to real-time or delay sensitive traffic/applications. 2.1 Movement Detection based on Router Advertisements Whenever a mobile node moves, it is required to perform movement detection by discovering (sending Router Solicitation) its current environment. In Mobile IPv6 [1], the movement detection algorithm relies on the periodic Router Advertisements to enable the mobile node to determine their current location. To achieve optimum detection performance, Router Advertisements can be broadcast at a faster rate, which eventually results in poor link utilization. The algorithm can be triggered through the indication from the underlying L2 driver. However, we noted that not all L2 mobility indication from the L2 driver indicates movement of the mobile node to a new subnet (i.e. L3 movement). Movement detection, which is achieved through the use of Neighbour Discovery [4] requires routers to send unsolicited Router Advertisement at a minimum interval of 3 seconds [section 6.2.4 of [4]]. Upon receipt of a Router Solicitation message, the router MUST delay its response (i.e. Router Advertisement) by a random time. Lastly, the protocol also requires the mobile node to delay its transmission of the initial solicitation for a random amount of time. Such delay is simply not desirable in achieving seamless handover. However, mobile IPv6 [1] relaxes such limit to allow mobile nodes to quickly detect their movement by listening to Router Advertisements, which are sent at a much faster rate. 2.2 Fast-Handoff Protocol The fast handover protocol [2] is designed to achieve seamless handoff of mobile nodes between the access routers. In a mobile-initiated anticipated fast-handover described in [2], the mobile node first sends a Router Solicitation for Proxy(RtSolPr) to the current access router containing the link-layer address of the new access point. The current access router replies with RtrAdvPr, which contains the [AP-ID, AR-MAC, AR-IP] tuple. These message exchanges allows a mobile node to obtain the new access Paul Tan Expires - August 2003 [Page 4] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 router's MAC address, which is needed to send packets once the mobile node attaches to the new access router, and also to perform 'anticipative' configuration of the new IP address on the new subnet using the New Router Prefix Information option carried in the RtrAdvPr message. However, the above protocol assumes that the L2 protocol is capable of delivering the L2 identifier of the new access point to the mobile node. More important, to initiate seamless handover, the current AR must be capable of mapping this new L2 identifier into the IP address of the new AR [6]. Lastly, it assumes that the mobile node or the current access router have a priori knowledge (e.g. capabilities) of the target of the handover (i.e. target access router). 3. Proposal Overview One of the challenges in achieving seamless L3 handover is the ability of MN to perform movement detection and to discover and select its new neighboring candidate access router quickly and efficiently that matches closely to the mobile node preferences or requirements. In this document, we present an overview on how to extend the IEEE 802.11 Management frames to carry extensible application-specific Information Element, which allow access points to advertise the capabilities information of its associated network/provider. The recommendation also improves in the movement detection mechanism by avoiding unnecessary L3 messaging over the wireless link. More importantly, we believe that mobile nodes can dynamically discover neighboring candidate access routers or networks more quickly and efficiently, and also to obtain valuable capabilities information so as to select the 'best' target access router to initiate seamless handover. The recommendation also allows new/removed access routers and access points to be discovered without much human interventions. 3.1 Instantaneous/Faster Movement Detection In this section, we describe how to configure the Extended Service Set Identifier (ESSID) of an infrastructure 802.11 network such that it includes the L3 identifier/Information of its associated AR or network. With this embedded identifier (e.g. IP address or prefix information), MN can quickly detect movement to a new L3 subnet, thus avoiding transmitting unnecessary L3 messages (i.e. Router Solicitation/Advertisement) and delays. Paul Tan Expires - August 2003 [Page 5] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 To perform instantaneous movement detection, we recommend that APs to include the subnet prefix information for their associated AR (Subnet-Router-Anycast-Address) into the ESSID. This recommendation allows MN to discover new network when it established a L2 connection with the new AP in an instantaneous manner. +---...--+ | | +-----+ +-----+ +-----+ | AR1 | | AR1 | | AR2 | +-----+ +-----+ +-----+ | | | +---+---+ | | | | | | +-----+ +-----+ +-----+ +-----+ | AP1 | | AP2 | | AP1 | | AP2 | +-----+ +-----+ +-----+ +-----+ /\ /\ /\ /\ / \ / \ / \ / \ / \ / \ / \ / \ / \/ \ / \/ \ / /\ \ / /\ \ / / \ \ / / \ \ re-assoc (mn) -----> |----- essid_1 -----| |---- essid_1 ----| Figure 1: Typical/Possible 802.11 Network Deployment However, to improve the inter-cell (802.11) handoff performance, several APs belonging to different administrative domains (different subnets) may choose to share similar ESSID. Therefore, as MN moves across these cells, it only needs to initiate re-association instead of the plain association process, which can take significantly longer. In this case, instead of embedding network prefix information into the ESSID, which is specific to each subnet, AP can include Network-Prefix-Information (section 5.1.1) object using the Application-Specific Information Element (section 5.1) into the beacon frames. Paul Tan Expires - August 2003 [Page 6] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 The table below shows an example of a list of beacon information advertised by the neighboring APs received by the MN on a specific wireless interface with an identifier, mniid. +-------------+---------------+--------+------+-----------------+------+ |Subnet-prefix| ESSID | AP-MAC | RSSI | Care-of-Address |Status| +-------------+---------------+--------+------+-----------------+------+ | prefix1 | essid1 | MAC1 |x dbm | prefix1:mniid | - | +-------------+---------------+--------+------+-----------------+------+ | prefix2 | essid1 | MAC2 |x dbm | prefix2:mniid |active| +-------------+---------------+--------+------+-----------------+------+ | prefix3 | essid2 | MAC3 |x dbm | prefix3:mniid | - | +-------------+---------------+--------+------+-----------------+------+ | prefix4 | essid3 | MAC4 |x dbm | prefix4:mniid | - | +-------------+---------------+--------+------+-----------------+------+ Table 1: Beacon Lists When MN moves, the underlying driver can indicate such movement using triggers (e.g. onL2Up during the 802.11 Assoc/Re-Assoc events) to the mobile IP stack. Based on the earlier cached configuration of the new subnet, MN can immediately perform mobile IP operations without performing movement detection using Router Solicitation and Advertisement. 4. Dynamic Candidate Access Router Discovery MN constantly listens for any beacons frame advertised by the neighboring APs. When MN discovers a new AP/Advertisement, it stores the advertised capabilities information, which is encapsulated inside the Network-Capabilities-Information Object (section 5.1) into its Neighborhood CAR list. +---------------+---------------+---------+---------+-----+--------+ | Subnet-prefix | ESSID | Cost | Fast-HO | QoS |Security| +---------------+---------------+---------+---------+-----+--------+ | prefix1 | essid1 | 0 units | n | n | n | +------------------------------------------------------------------+ | prefix2 | essid1 | 1 units | n | n | y | +------------------------------------------------------------------+ | prefix3 | essid2 | 2 units | n | y | n | +------------------------------------------------------------------+ | prefix4 | essid3 | 3 units | y | y | y | +------------------------------------------------------------------+ Table 2: Neighborhood CAR list Paul Tan Expires - August 2003 [Page 7] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 MN can store these discovered information ordered by either the signal strength or other parameters (e.g. Pricing). To achieve/assist fast handoff operation, information such as L2/L3 address mapping of the AR can be obtained from the Access-Router- Information Object (section 5.1.3). Therefore, the ability to dynamically discover neighboring CAR's capabilities allows the MN to perform the selection of TAR based on the mobile node's preference or requirements [6]. 4.1 Operations In this section, we will briefly describe the operation on the MN. MN AP1 AP2 AP3 AR3 - | advertisement | | | | | | <------------ | | | | | | advertisement | | | | | <--------------------------- | | | NDP | | | | | . . . . . | . . . . . . advertisement . . - | <---------------------------------------- | | | | | | | - | assoc/re-assoc | | | | ----------------------------------------> | | PP | L3 HO | | | | --------------------------------------------> | - | | | | | - Neighborhood Discovery Phase (NDP) - MN discovers neighboring APs or networks and creates a list of CARs with their advertised information (Table 2) - Optionally, during the neighborhood discovery phase, MN can configure in advance new CoA for each discovered APs on various different subnets. - 'Panic' Phase (PP) - If the current associated AP's signal strength drops or if the MN discovers a new AP, which offers 'better' service/pricing, MN can immediately perform a handover to this new AP/AR. - MN decides to perform association/re-association with a new AP (e.g. AP3) based on MN's preference/requirements - We assumed here that AP3 is associated with a different subnet; MN will know that it has moved to a new network using the cached information. - Assuming MN is still attached to AP1, it quickly initiates fast-handoff using the cached information of AP3(AR3-L2-ID, Paul Tan Expires - August 2003 [Page 8] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 AR3-L3-ID). - Or if the MN has already obtain a valid CoA for which the new AR has reserved/defended, it can quickly initiate a 'lightweight-FHO' (a trigger to indicate movement confirmation) 5. Extensible Application-Specific Information Elements We proposed to extend the current IEEE 802.11 Management frames to carry extensible application-specific information elements. For example, the IEEE 802.11 Beacon frame with the newly proposed IE is shown in the figure 2. The Extensible Application-specific IE allows future applications/protocols to encapsulate their information into the IEEE 802.11 frame easily, hopefully without much software modification. With the new IE, we believe that valuable information can then be easily included in the IEEE 802.11 Management frames and discovered by roaming MN. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Control | Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Basic Service Set ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Sequence Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability Information | Beacon Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | SSID (2-34 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported Rates (3-7 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . | Extensible-Application-Specific IE | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Check Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. 802.11 Beacon Frame with new Ext-Application-Specific IE Paul Tan Expires - August 2003 [Page 9] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 The above application-specific IE consists of the following fields: Element ID, Length, and Extensible-Application-Specific Information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Length | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + Application-Specific Object + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Extensible-Application-Specific Information Element As defined in [3], the element ID field is 1 octet long and specifies the type of IE. The length field is 1 octet long and specifies the length (number of octets) of the application-specific Information field. Lastly, the application-specific object field carries the specific application object using the following structure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | App ID | Length | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + Application-Specific Information + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. Generic Application-Specific Object Structure 5.1 Application-Specific Information Objects In this conceptual document, we have proposed several application- specific objects to achieve our intended objective. We believed that future application objects could be easily defined and carried through the Extensible-Application Information Element without defining new IEEE 802.11 information elements. Paul Tan Expires - August 2003 [Page 10] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 5.1.1 Network-Prefix-Information Object The format of the Network-Prefix-Information object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | App_NwPrfInfo | Length | Prefix-Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ App-ID App_NwPrfInfo (1) Length 1 + Length of the prefix value in octets Prefix-Value An IPv6 address or its prefix. The Prefix Length field contains the number of valid leading bits in the prefix. 5.1.2 Network-Capabilities-Information Object The format of the Network-Capabilities-Information object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | App_NwCapInfo | Length | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Capabilities-Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ App-ID App_NwCapInfo (2) Length 1 Capabilities-Info TBD 5.1.3 Access-Router-Information Object The format of the Access-Router-Information object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | App_ARInfo | Length | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . | IPv6 Address | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Paul Tan Expires - August 2003 [Page 11] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 App-ID App_ARInfo (3) Length 22 MAC Address A MAC address for the access router IPv6 Address An IPv6 address for the access router 6. Requirements MN should be capable of receiving and passing the new Extensible Application information up from the 802.11 driver to IP layer. The IEEE 802.11 AP should be configurable such that new Application- specific information can be carried in the 802.11 frames without much hassle. The AP should also be able to include this new IE into the beacon or even the association/re-association frames. References [1] D.Johnson, C.Perkins and J.Arkko, Mobility Support in Ipv6, draft-ietf-mobileip-ipv6-18.txt, May 2002 [2] Dommety, G., et. al., Fast Handovers for Mobile Ipv6, draft- ietf-mobileip-fast-mipv6-05.txt [3] IEEE, "Part II: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 1999 [4] T.Narten, E. Nordmark and W.Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, December 1998 [5] Alper E. Yegin, Daichi Funato, Karim El Malki, Youngjune Gwon, James Kempf, Mattias Pettersson, Phil Roberts, Hesham Soliman, Atushi Takeshita, Supporting Optimisation Handover for IP Mobility - Requirement for Underlying Systems, draft- manyfolks-l2-mobilereq-02.txt [6] Trossen, D., Krisharmurthi, G. Chaskar, H., Kempf, J, Issues in Candidate Access Router Discovery for seamless IP-level handoffs, draft-ietf-seamoby-cardiscovery-issues-04.txt, work in progress, October 2002 Paul Tan Expires - August 2003 [Page 12] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 Acknowledgments The author would like to thank James Kempf and Parijat (I2R) for their review and suggestions. Author's Addresses Paul Tan Institute of Communications Research (ICR) 20, TeleTech Park, #02-34/37, Singapore Science Park II, Singapore 117674 Phone: +65 68709324 Email: tanpaul@i2r.a-star.edu.sg Paul Tan Expires - August 2003 [Page 13] --=_2E717B47.09680289-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 15:15:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26936 for ; Wed, 5 Mar 2003 15:15:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KPCO16818; Wed, 5 Mar 2003 15:25:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KOrO16776 for ; Wed, 5 Mar 2003 15:24:53 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26871 for ; Wed, 5 Mar 2003 15:13:35 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h25KGIc1009023 for ; Thu, 6 Mar 2003 04:16:18 +0800 (SGT) Received: from bkdom-MTA by mailer.icr.a-star.edu.sg with Novell_GroupWise; Thu, 06 Mar 2003 04:08:55 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Thu, 06 Mar 2003 04:08:26 +0800 From: "Paul Tan Hock Lai" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_2E717B47.09680289" Subject: [Seamoby] [ID Announce] Recommendations for Achieving Seameless IPv6 Handover in 802.11 Networks Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_2E717B47.09680289 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I have recently submitted an individual draft which entails recommendations= on achieving seamless IPv6 handover in 802.11 networks and also dynamic = candidate access routers discovery. You are most welcome to read this draft from the following link: http://www.ietf.org/internet-drafts/draft-paultan-seamless-ipv6-handoff-802= -00.txt I sincerely look forward to your valuable feedback concerning this draft. = All comments and inputs are welcomed and greatly appreciated. Yours Sincerely, Paul Tan " .... success is never guarantee but failure is, if you don't even try ... " --=_2E717B47.09680289 Content-Type: text/plain Content-Disposition: attachment; filename="draft-paultan-seamless-ipv6-handoff-802-00.txt" Content-Transfer-Encoding: 7bit Internet Draft Paul Tan draft-paultan-seamless-ipv6-handoff-802-00.txt ICR Expires: Aug 2003 Feb 2003 Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract To achieve seamless layer 3 handover, mobile nodes must be able to perform movement detection and neighborhood candidate access routers discovery quickly and efficiently. In this document, we present a conceptual overview on how to extend the IEEE 802.11 Management frames to carry extensible application- specific Information Element, which allow access points to advertise the capabilities information of its associated network/provider and to improve movement detection. We believe that mobile nodes can thus dynamically discover neighboring candidate access routers or networks more quickly and efficiently, and also to obtain valuable capabilities information so as to select the 'best' target access router to initiate seamless handover. Paul Tan Expires - August 2003 [Page 1] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in RFC 2119. This document uses the terminology defined in [2] and [3]. The following terminology and abbreviations are used in this document. Mobile Node (MN) A Mobile IPv6 host Access Router (AR) An Access Network Router residing on the edge of an Access Network and offers IP connectivity to mobile nodes New Access Router (NAR) The MN's anticipated default router subsequent to its handover Candidate AR (CAR) An AR to which a MN has a choice of performing IP-level handover. This implies that the MN has the right radio interface to connect to an AP that is served by this AR, as well as the coverage of this AR overlaps with that of the AR to which the MN is currently attached to. Target AR (TAR) An AR with which the procedures for the MN's IP-level handover are initiated. The TAR is selected after running a TAR Selection algorithm that takes into account the capabilities of CARs, preferences of the MN and any other local policies. New CoA (NCoA) The MN's Care of Address valid on NAR Handover A process of terminating existing connectivity and obtaining new IP connectivity. Router Solicitation for Proxy (RtSolPr) A message from the MN to the PAR requesting information for a potential handover Proxy Router Advertisement (PrRtAdv) A message from the PAR indicating a MN to undergo handover Paul Tan Expires - August 2003 [Page 2] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 Access Point (AP) An L2 entity that has station functionality and provides access to the distribution services, via the wireless medium for associated stations. Association The service used to establish access point/station (AP/STA) mapping and enable STA access to the Distribution System. Basic Service Set (BSS) A set of stations controlled by a single coordination function, where the coordination function may be centralized (e.g., in a single AP) or distributed (e.g., for an ad-hoc network). The BSS can be thought of as the coverage area of a single AP. Distribution System (DS) A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set(ESS). Extended Service Set (ESS) A set of one or more interconnected basic service sets (BSSs) and integrated local area networks (LANs) that appears as a single BSS to the logical link control layer at any station associated with one of those BSSs. The ESS can be thought of as the coverage area provided by a collection of APs all interconnected by the Distribution System. It may consist of one or more IP subnets. Paul Tan Expires - August 2003 [Page 3] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 2. Introduction In Mobile IPv6 [1], a mobile node can effectively maintain its connectivity to the Internet when it changes its point-of-attachment to the Internet. During the handover, the mobile node is unable to send/receive IPv6 packets both due to its L2/L3 handover operations. This handover latency is unacceptable to real-time or delay sensitive traffic/applications. 2.1 Movement Detection based on Router Advertisements Whenever a mobile node moves, it is required to perform movement detection by discovering (sending Router Solicitation) its current environment. In Mobile IPv6 [1], the movement detection algorithm relies on the periodic Router Advertisements to enable the mobile node to determine their current location. To achieve optimum detection performance, Router Advertisements can be broadcast at a faster rate, which eventually results in poor link utilization. The algorithm can be triggered through the indication from the underlying L2 driver. However, we noted that not all L2 mobility indication from the L2 driver indicates movement of the mobile node to a new subnet (i.e. L3 movement). Movement detection, which is achieved through the use of Neighbour Discovery [4] requires routers to send unsolicited Router Advertisement at a minimum interval of 3 seconds [section 6.2.4 of [4]]. Upon receipt of a Router Solicitation message, the router MUST delay its response (i.e. Router Advertisement) by a random time. Lastly, the protocol also requires the mobile node to delay its transmission of the initial solicitation for a random amount of time. Such delay is simply not desirable in achieving seamless handover. However, mobile IPv6 [1] relaxes such limit to allow mobile nodes to quickly detect their movement by listening to Router Advertisements, which are sent at a much faster rate. 2.2 Fast-Handoff Protocol The fast handover protocol [2] is designed to achieve seamless handoff of mobile nodes between the access routers. In a mobile-initiated anticipated fast-handover described in [2], the mobile node first sends a Router Solicitation for Proxy(RtSolPr) to the current access router containing the link-layer address of the new access point. The current access router replies with RtrAdvPr, which contains the [AP-ID, AR-MAC, AR-IP] tuple. These message exchanges allows a mobile node to obtain the new access Paul Tan Expires - August 2003 [Page 4] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 router's MAC address, which is needed to send packets once the mobile node attaches to the new access router, and also to perform 'anticipative' configuration of the new IP address on the new subnet using the New Router Prefix Information option carried in the RtrAdvPr message. However, the above protocol assumes that the L2 protocol is capable of delivering the L2 identifier of the new access point to the mobile node. More important, to initiate seamless handover, the current AR must be capable of mapping this new L2 identifier into the IP address of the new AR [6]. Lastly, it assumes that the mobile node or the current access router have a priori knowledge (e.g. capabilities) of the target of the handover (i.e. target access router). 3. Proposal Overview One of the challenges in achieving seamless L3 handover is the ability of MN to perform movement detection and to discover and select its new neighboring candidate access router quickly and efficiently that matches closely to the mobile node preferences or requirements. In this document, we present an overview on how to extend the IEEE 802.11 Management frames to carry extensible application-specific Information Element, which allow access points to advertise the capabilities information of its associated network/provider. The recommendation also improves in the movement detection mechanism by avoiding unnecessary L3 messaging over the wireless link. More importantly, we believe that mobile nodes can dynamically discover neighboring candidate access routers or networks more quickly and efficiently, and also to obtain valuable capabilities information so as to select the 'best' target access router to initiate seamless handover. The recommendation also allows new/removed access routers and access points to be discovered without much human interventions. 3.1 Instantaneous/Faster Movement Detection In this section, we describe how to configure the Extended Service Set Identifier (ESSID) of an infrastructure 802.11 network such that it includes the L3 identifier/Information of its associated AR or network. With this embedded identifier (e.g. IP address or prefix information), MN can quickly detect movement to a new L3 subnet, thus avoiding transmitting unnecessary L3 messages (i.e. Router Solicitation/Advertisement) and delays. Paul Tan Expires - August 2003 [Page 5] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 To perform instantaneous movement detection, we recommend that APs to include the subnet prefix information for their associated AR (Subnet-Router-Anycast-Address) into the ESSID. This recommendation allows MN to discover new network when it established a L2 connection with the new AP in an instantaneous manner. +---...--+ | | +-----+ +-----+ +-----+ | AR1 | | AR1 | | AR2 | +-----+ +-----+ +-----+ | | | +---+---+ | | | | | | +-----+ +-----+ +-----+ +-----+ | AP1 | | AP2 | | AP1 | | AP2 | +-----+ +-----+ +-----+ +-----+ /\ /\ /\ /\ / \ / \ / \ / \ / \ / \ / \ / \ / \/ \ / \/ \ / /\ \ / /\ \ / / \ \ / / \ \ re-assoc (mn) -----> |----- essid_1 -----| |---- essid_1 ----| Figure 1: Typical/Possible 802.11 Network Deployment However, to improve the inter-cell (802.11) handoff performance, several APs belonging to different administrative domains (different subnets) may choose to share similar ESSID. Therefore, as MN moves across these cells, it only needs to initiate re-association instead of the plain association process, which can take significantly longer. In this case, instead of embedding network prefix information into the ESSID, which is specific to each subnet, AP can include Network-Prefix-Information (section 5.1.1) object using the Application-Specific Information Element (section 5.1) into the beacon frames. Paul Tan Expires - August 2003 [Page 6] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 The table below shows an example of a list of beacon information advertised by the neighboring APs received by the MN on a specific wireless interface with an identifier, mniid. +-------------+---------------+--------+------+-----------------+------+ |Subnet-prefix| ESSID | AP-MAC | RSSI | Care-of-Address |Status| +-------------+---------------+--------+------+-----------------+------+ | prefix1 | essid1 | MAC1 |x dbm | prefix1:mniid | - | +-------------+---------------+--------+------+-----------------+------+ | prefix2 | essid1 | MAC2 |x dbm | prefix2:mniid |active| +-------------+---------------+--------+------+-----------------+------+ | prefix3 | essid2 | MAC3 |x dbm | prefix3:mniid | - | +-------------+---------------+--------+------+-----------------+------+ | prefix4 | essid3 | MAC4 |x dbm | prefix4:mniid | - | +-------------+---------------+--------+------+-----------------+------+ Table 1: Beacon Lists When MN moves, the underlying driver can indicate such movement using triggers (e.g. onL2Up during the 802.11 Assoc/Re-Assoc events) to the mobile IP stack. Based on the earlier cached configuration of the new subnet, MN can immediately perform mobile IP operations without performing movement detection using Router Solicitation and Advertisement. 4. Dynamic Candidate Access Router Discovery MN constantly listens for any beacons frame advertised by the neighboring APs. When MN discovers a new AP/Advertisement, it stores the advertised capabilities information, which is encapsulated inside the Network-Capabilities-Information Object (section 5.1) into its Neighborhood CAR list. +---------------+---------------+---------+---------+-----+--------+ | Subnet-prefix | ESSID | Cost | Fast-HO | QoS |Security| +---------------+---------------+---------+---------+-----+--------+ | prefix1 | essid1 | 0 units | n | n | n | +------------------------------------------------------------------+ | prefix2 | essid1 | 1 units | n | n | y | +------------------------------------------------------------------+ | prefix3 | essid2 | 2 units | n | y | n | +------------------------------------------------------------------+ | prefix4 | essid3 | 3 units | y | y | y | +------------------------------------------------------------------+ Table 2: Neighborhood CAR list Paul Tan Expires - August 2003 [Page 7] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 MN can store these discovered information ordered by either the signal strength or other parameters (e.g. Pricing). To achieve/assist fast handoff operation, information such as L2/L3 address mapping of the AR can be obtained from the Access-Router- Information Object (section 5.1.3). Therefore, the ability to dynamically discover neighboring CAR's capabilities allows the MN to perform the selection of TAR based on the mobile node's preference or requirements [6]. 4.1 Operations In this section, we will briefly describe the operation on the MN. MN AP1 AP2 AP3 AR3 - | advertisement | | | | | | <------------ | | | | | | advertisement | | | | | <--------------------------- | | | NDP | | | | | . . . . . | . . . . . . advertisement . . - | <---------------------------------------- | | | | | | | - | assoc/re-assoc | | | | ----------------------------------------> | | PP | L3 HO | | | | --------------------------------------------> | - | | | | | - Neighborhood Discovery Phase (NDP) - MN discovers neighboring APs or networks and creates a list of CARs with their advertised information (Table 2) - Optionally, during the neighborhood discovery phase, MN can configure in advance new CoA for each discovered APs on various different subnets. - 'Panic' Phase (PP) - If the current associated AP's signal strength drops or if the MN discovers a new AP, which offers 'better' service/pricing, MN can immediately perform a handover to this new AP/AR. - MN decides to perform association/re-association with a new AP (e.g. AP3) based on MN's preference/requirements - We assumed here that AP3 is associated with a different subnet; MN will know that it has moved to a new network using the cached information. - Assuming MN is still attached to AP1, it quickly initiates fast-handoff using the cached information of AP3(AR3-L2-ID, Paul Tan Expires - August 2003 [Page 8] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 AR3-L3-ID). - Or if the MN has already obtain a valid CoA for which the new AR has reserved/defended, it can quickly initiate a 'lightweight-FHO' (a trigger to indicate movement confirmation) 5. Extensible Application-Specific Information Elements We proposed to extend the current IEEE 802.11 Management frames to carry extensible application-specific information elements. For example, the IEEE 802.11 Beacon frame with the newly proposed IE is shown in the figure 2. The Extensible Application-specific IE allows future applications/protocols to encapsulate their information into the IEEE 802.11 frame easily, hopefully without much software modification. With the new IE, we believe that valuable information can then be easily included in the IEEE 802.11 Management frames and discovered by roaming MN. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Control | Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Basic Service Set ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Sequence Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability Information | Beacon Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | SSID (2-34 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported Rates (3-7 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . | Extensible-Application-Specific IE | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Check Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. 802.11 Beacon Frame with new Ext-Application-Specific IE Paul Tan Expires - August 2003 [Page 9] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 The above application-specific IE consists of the following fields: Element ID, Length, and Extensible-Application-Specific Information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Length | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + Application-Specific Object + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Extensible-Application-Specific Information Element As defined in [3], the element ID field is 1 octet long and specifies the type of IE. The length field is 1 octet long and specifies the length (number of octets) of the application-specific Information field. Lastly, the application-specific object field carries the specific application object using the following structure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | App ID | Length | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + Application-Specific Information + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. Generic Application-Specific Object Structure 5.1 Application-Specific Information Objects In this conceptual document, we have proposed several application- specific objects to achieve our intended objective. We believed that future application objects could be easily defined and carried through the Extensible-Application Information Element without defining new IEEE 802.11 information elements. Paul Tan Expires - August 2003 [Page 10] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 5.1.1 Network-Prefix-Information Object The format of the Network-Prefix-Information object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | App_NwPrfInfo | Length | Prefix-Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ App-ID App_NwPrfInfo (1) Length 1 + Length of the prefix value in octets Prefix-Value An IPv6 address or its prefix. The Prefix Length field contains the number of valid leading bits in the prefix. 5.1.2 Network-Capabilities-Information Object The format of the Network-Capabilities-Information object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | App_NwCapInfo | Length | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Capabilities-Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ App-ID App_NwCapInfo (2) Length 1 Capabilities-Info TBD 5.1.3 Access-Router-Information Object The format of the Access-Router-Information object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | App_ARInfo | Length | .. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . | IPv6 Address | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Paul Tan Expires - August 2003 [Page 11] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 App-ID App_ARInfo (3) Length 22 MAC Address A MAC address for the access router IPv6 Address An IPv6 address for the access router 6. Requirements MN should be capable of receiving and passing the new Extensible Application information up from the 802.11 driver to IP layer. The IEEE 802.11 AP should be configurable such that new Application- specific information can be carried in the 802.11 frames without much hassle. The AP should also be able to include this new IE into the beacon or even the association/re-association frames. References [1] D.Johnson, C.Perkins and J.Arkko, Mobility Support in Ipv6, draft-ietf-mobileip-ipv6-18.txt, May 2002 [2] Dommety, G., et. al., Fast Handovers for Mobile Ipv6, draft- ietf-mobileip-fast-mipv6-05.txt [3] IEEE, "Part II: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 1999 [4] T.Narten, E. Nordmark and W.Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, December 1998 [5] Alper E. Yegin, Daichi Funato, Karim El Malki, Youngjune Gwon, James Kempf, Mattias Pettersson, Phil Roberts, Hesham Soliman, Atushi Takeshita, Supporting Optimisation Handover for IP Mobility - Requirement for Underlying Systems, draft- manyfolks-l2-mobilereq-02.txt [6] Trossen, D., Krisharmurthi, G. Chaskar, H., Kempf, J, Issues in Candidate Access Router Discovery for seamless IP-level handoffs, draft-ietf-seamoby-cardiscovery-issues-04.txt, work in progress, October 2002 Paul Tan Expires - August 2003 [Page 12] Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks February 2003 Acknowledgments The author would like to thank James Kempf and Parijat (I2R) for their review and suggestions. Author's Addresses Paul Tan Institute of Communications Research (ICR) 20, TeleTech Park, #02-34/37, Singapore Science Park II, Singapore 117674 Phone: +65 68709324 Email: tanpaul@i2r.a-star.edu.sg Paul Tan Expires - August 2003 [Page 13] --=_2E717B47.09680289-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 16:18:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29192 for ; Wed, 5 Mar 2003 16:18:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25LTN521785 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 16:29:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LTNO21782 for ; Wed, 5 Mar 2003 16:29:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29166 for ; Wed, 5 Mar 2003 16:18:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LT8O21755; Wed, 5 Mar 2003 16:29:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LS8O21663 for ; Wed, 5 Mar 2003 16:28:08 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29090 for ; Wed, 5 Mar 2003 16:16:55 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25LIxa18697 for ; Wed, 5 Mar 2003 15:18:59 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Mar 2003 15:18:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 15:18:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 16:18:43 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjORcHjeuwYBRmRTaDHCoSMPpE5gAEdeHAAAAPf/AABEaQkA== To: , X-OriginalArrivalTime: 05 Mar 2003 21:18:44.0335 (UTC) FILETIME=[CD75EFF0:01C2E35C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25LS8O21664 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 16:18:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29216 for ; Wed, 5 Mar 2003 16:18:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LT8O21755; Wed, 5 Mar 2003 16:29:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LS8O21663 for ; Wed, 5 Mar 2003 16:28:08 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29090 for ; Wed, 5 Mar 2003 16:16:55 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25LIxa18697 for ; Wed, 5 Mar 2003 15:18:59 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Mar 2003 15:18:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 15:18:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 16:18:43 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjORcHjeuwYBRmRTaDHCoSMPpE5gAEdeHAAAAPf/AABEaQkA== To: , X-OriginalArrivalTime: 05 Mar 2003 21:18:44.0335 (UTC) FILETIME=[CD75EFF0:01C2E35C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25LS8O21664 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 16:36:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00546 for ; Wed, 5 Mar 2003 16:36:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25LlLM24421 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 16:47:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LlLO24418 for ; Wed, 5 Mar 2003 16:47:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00504 for ; Wed, 5 Mar 2003 16:36:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Ll8O24368; Wed, 5 Mar 2003 16:47:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LkOO24291 for ; Wed, 5 Mar 2003 16:46:24 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00440 for ; Wed, 5 Mar 2003 16:35:10 -0500 (EST) Message-ID: <020e01c2e35f$2b433be0$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 13:35:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Govind, I don't agree that the server specified in the draft is a new element. The specification is for a configuration server, AAA or LDAP or something like that. This is a common way of configuring routers, I believe it is used for IPsec configuration information. I haven't finished reading the draft yet so I can't comment on the rest of your points. jak ----- Original Message ----- From: To: ; Sent: Wednesday, March 05, 2003 10:58 AM Subject: RE: [Seamoby] Comments on DT CARD draft > Hi Ajoy, > Comments inline. Thanks for your reply. > > -Govind. > > > > AJOY-> We are aware of this. What is the status of > requirement draft? Is it approved by IESG yet. Probably > we need to change this requirement in case WG likes > to go with server based approach. > > [Govind] The requirements document has passed last WG last call. The IESG did come back with one set of comments, but I don't think they had > any problems with this particular requirement in those comments. > > [snip] > > AJOY-> This depends upon the cache timeout as well as handoff traffic. > BTW, the server based approach is easier to manage as well > it provides extra security. If we deploy scope-id with serve based approach, then > it is very much possible to reduce or even eliminate the problem of cache contamination. > This also minimizes the affect DoS attack. > > [Govind] The cache timeout can be handled quite easily. Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entries > that are not CARs in the cache. In fact, the DT draft acknowledges that the > CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a > CARD server. > > [snip] > > AJOY-> These entries may not be cached for ever. Smaller the cache timeout, > the earlier you will be able to detect any change of capability > or L2->L3 mapping information. > > [Govind] So we need to choose a timeout that is appropriate, why do we need a server for this? I still don't understand that. > > [snip] > > AJOY-> I think this will be better than the case where cache entries are solely > propagated by the mobile node. I think in the later case, the first handoff > will always be the slower. Moreover the later approach is very > difficult to manage and is even less secure. > > [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? > Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. > > Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? > > Lastly, as I pointed out in my earlier mail, we have provided a method, in an earlier version of the draft, that makes the first handover also seamless in a probabilistic sense. I don't think DT draft can promise better than that too. We omitted this, because we felt that it doesn't make much sense in the steady state of the system. Basically a cost vs. benefit analysis. > > ----------* > [snip] > > BTW-> The IP packets are not routed via CARD server so I am not sure if it a big > drawback. > [Govind] You need the CARD server for any translation on a cache miss. > So what is this that you bring about routing packets via CARD server? I'm completely missing your point here. > -----------------------* > I will be more concerned about the single point of failure where IP packets are > routed through it. CARD server will provide a similar function as DNS server > So, probably it is not a big drawback in my understanding. > > [Govind] Does this imply that the functionality of the CARD server is minimal? We are talking about the "central" point of control here that determines the cache entries. I think it a very important point to consider. > ---------------------------* > On the other handoff, > server based approach provides better manageability as well control. > > [Govind] What manageability are you talking about? You assume that each AR knows what APs it has. Why should it be conveyed to the CARD server? Why can't it be conveyed directly to its CARs? Also, what lack of manageability that you perceive in dycard? Can we talk quantitatively rather qualitatively here? > > As I mentioned above, > with clever use of scope-id, it is possible to reduce the affect of DoS attack as > well as cache contamination problem. > > [Govind] Could you define "clever" use of scope-id? Quoting from the draft > "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. > > > [snip] > AJOY-> Probably you are right. We do need to get consensus from AAA group for doing this. > BTW, If we use AAA server, then it is also possible to use AAA server for the > purpose of key distribution. I would like to receive feedback from other members of > WG about the potential use of AAA server as CARD server. > [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? > > > [snip] > AJOY-> I am not sure I agree with you here. Could you provide some additional > detail why you think scope id is complicated? > > [Govind]I'll let you know if I come up with something more, than what I've provided in my previous email. > > Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. > > AJOY-> Let be focused now. > > [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with > a solution that works well now, and also has a good chance of being accepted later. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 16:36:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00562 for ; Wed, 5 Mar 2003 16:36:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Ll8O24368; Wed, 5 Mar 2003 16:47:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LkOO24291 for ; Wed, 5 Mar 2003 16:46:24 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00440 for ; Wed, 5 Mar 2003 16:35:10 -0500 (EST) Message-ID: <020e01c2e35f$2b433be0$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 13:35:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Govind, I don't agree that the server specified in the draft is a new element. The specification is for a configuration server, AAA or LDAP or something like that. This is a common way of configuring routers, I believe it is used for IPsec configuration information. I haven't finished reading the draft yet so I can't comment on the rest of your points. jak ----- Original Message ----- From: To: ; Sent: Wednesday, March 05, 2003 10:58 AM Subject: RE: [Seamoby] Comments on DT CARD draft > Hi Ajoy, > Comments inline. Thanks for your reply. > > -Govind. > > > > AJOY-> We are aware of this. What is the status of > requirement draft? Is it approved by IESG yet. Probably > we need to change this requirement in case WG likes > to go with server based approach. > > [Govind] The requirements document has passed last WG last call. The IESG did come back with one set of comments, but I don't think they had > any problems with this particular requirement in those comments. > > [snip] > > AJOY-> This depends upon the cache timeout as well as handoff traffic. > BTW, the server based approach is easier to manage as well > it provides extra security. If we deploy scope-id with serve based approach, then > it is very much possible to reduce or even eliminate the problem of cache contamination. > This also minimizes the affect DoS attack. > > [Govind] The cache timeout can be handled quite easily. Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entries > that are not CARs in the cache. In fact, the DT draft acknowledges that the > CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a > CARD server. > > [snip] > > AJOY-> These entries may not be cached for ever. Smaller the cache timeout, > the earlier you will be able to detect any change of capability > or L2->L3 mapping information. > > [Govind] So we need to choose a timeout that is appropriate, why do we need a server for this? I still don't understand that. > > [snip] > > AJOY-> I think this will be better than the case where cache entries are solely > propagated by the mobile node. I think in the later case, the first handoff > will always be the slower. Moreover the later approach is very > difficult to manage and is even less secure. > > [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? > Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. > > Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? > > Lastly, as I pointed out in my earlier mail, we have provided a method, in an earlier version of the draft, that makes the first handover also seamless in a probabilistic sense. I don't think DT draft can promise better than that too. We omitted this, because we felt that it doesn't make much sense in the steady state of the system. Basically a cost vs. benefit analysis. > > ----------* > [snip] > > BTW-> The IP packets are not routed via CARD server so I am not sure if it a big > drawback. > [Govind] You need the CARD server for any translation on a cache miss. > So what is this that you bring about routing packets via CARD server? I'm completely missing your point here. > -----------------------* > I will be more concerned about the single point of failure where IP packets are > routed through it. CARD server will provide a similar function as DNS server > So, probably it is not a big drawback in my understanding. > > [Govind] Does this imply that the functionality of the CARD server is minimal? We are talking about the "central" point of control here that determines the cache entries. I think it a very important point to consider. > ---------------------------* > On the other handoff, > server based approach provides better manageability as well control. > > [Govind] What manageability are you talking about? You assume that each AR knows what APs it has. Why should it be conveyed to the CARD server? Why can't it be conveyed directly to its CARs? Also, what lack of manageability that you perceive in dycard? Can we talk quantitatively rather qualitatively here? > > As I mentioned above, > with clever use of scope-id, it is possible to reduce the affect of DoS attack as > well as cache contamination problem. > > [Govind] Could you define "clever" use of scope-id? Quoting from the draft > "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. > > > [snip] > AJOY-> Probably you are right. We do need to get consensus from AAA group for doing this. > BTW, If we use AAA server, then it is also possible to use AAA server for the > purpose of key distribution. I would like to receive feedback from other members of > WG about the potential use of AAA server as CARD server. > [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? > > > [snip] > AJOY-> I am not sure I agree with you here. Could you provide some additional > detail why you think scope id is complicated? > > [Govind]I'll let you know if I come up with something more, than what I've provided in my previous email. > > Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. > > AJOY-> Let be focused now. > > [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with > a solution that works well now, and also has a good chance of being accepted later. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 16:57:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01808 for ; Wed, 5 Mar 2003 16:57:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25M8Md27146 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 17:08:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25M8MO27143 for ; Wed, 5 Mar 2003 17:08:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01801 for ; Wed, 5 Mar 2003 16:57:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25M89O27119; Wed, 5 Mar 2003 17:08:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25M7JO26764 for ; Wed, 5 Mar 2003 17:07:19 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01639 for ; Wed, 5 Mar 2003 16:56:05 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Mar 2003 16:58:07 -0500 Message-ID: <010001c2e37b$9f453270$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <020e01c2e35f$2b433be0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 16:59:20 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 05 Mar 2003 21:58:07.0991 (UTC) FILETIME=[4E4F3870:01C2E362] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't understand James' comment. Certainly it is a new element introduced for CARD. Let's say I have WLAN without any server you listed in the below. Then to run CARD, I need to install the server introduced by the draft, don't I? Regards, Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Wednesday, March 05, 2003 1:35 PM Subject: Re: [Seamoby] Comments on DT CARD draft > Govind, > > I don't agree that the server specified in the draft is a new element. The > specification is for a configuration server, AAA or LDAP or something like that. > This is a common way of configuring routers, I believe it is used for IPsec > configuration information. > > I haven't finished reading the draft yet so I can't comment on the rest of your > points. > > jak > > ----- Original Message ----- > From: > To: ; > Sent: Wednesday, March 05, 2003 10:58 AM > Subject: RE: [Seamoby] Comments on DT CARD draft > > > > Hi Ajoy, > > Comments inline. Thanks for your reply. > > > > -Govind. > > > > > > > > AJOY-> We are aware of this. What is the status of > > requirement draft? Is it approved by IESG yet. Probably > > we need to change this requirement in case WG likes > > to go with server based approach. > > > > [Govind] The requirements document has passed last WG last call. The IESG did > come back with one set of comments, but I don't think they had > > any problems with this particular requirement in those comments. > > > > [snip] > > > > AJOY-> This depends upon the cache timeout as well as handoff traffic. > > BTW, the server based approach is easier to manage as well > > it provides extra security. If we deploy scope-id with serve based approach, > then > > it is very much possible to reduce or even eliminate the problem of cache > contamination. > > This also minimizes the affect DoS attack. > > > > [Govind] The cache timeout can be handled quite easily. Regarding, the server > based approach being more secure, this is quite unclear from the document. I > don't think you can eleminate the cache contamination problem from any of the > schemes that you have described. I have explained in my email how using the > scope ID approach still allows you to keep "n" entries > > that are not CARs in the cache. In fact, the DT draft acknowledges that the > > CARD server can still be subjected to a DoS attack. I don't really agree with > your premise that you alleviate the security problems just by having a > > CARD server. > > > > [snip] > > > > AJOY-> These entries may not be cached for ever. Smaller the cache timeout, > > the earlier you will be able to detect any change of capability > > or L2->L3 mapping information. > > > > [Govind] So we need to choose a timeout that is appropriate, why do we need a > server for this? I still don't understand that. > > > > [snip] > > > > AJOY-> I think this will be better than the case where cache entries are > solely > > propagated by the mobile node. I think in the later case, the first handoff > > will always be the slower. Moreover the later approach is very > > difficult to manage and is even less secure. > > > > [Govind] Yes, the first handover case. So are you saying the cost of the first > handover being not seamless is worth introducing a new element in the network? > > Could you explain why the latter approach is less secure? Once you have a > cache at the AR that is populated with MN input, like what you are doing in the > DT draft and we do in dycard, the level of security of the protocols is pretty > comparable. Please note, any of the security checks that you have introduced > including scope ID, which I still think is not the best way to go, can be used > without the server being present at all. > > > > Also, you could you list out the security holes that you perceive in the > dycard draft. Also, could you look at the way we have handled it and see whether > we have presented solutions tackled the issues? > > > > Lastly, as I pointed out in my earlier mail, we have provided a method, in an > earlier version of the draft, that makes the first handover also seamless in a > probabilistic sense. I don't think DT draft can promise better than that too. We > omitted this, because we felt that it doesn't make much sense in the steady > state of the system. Basically a cost vs. benefit analysis. > > > > ----------* > > [snip] > > > > BTW-> The IP packets are not routed via CARD server so I am not sure if it a > big > > drawback. > > [Govind] You need the CARD server for any translation on a cache miss. > > So what is this that you bring about routing packets via CARD server? I'm > completely missing your point here. > > -----------------------* > > I will be more concerned about the single point of failure where IP packets > are > > routed through it. CARD server will provide a similar function as DNS server > > So, probably it is not a big drawback in my understanding. > > > > [Govind] Does this imply that the functionality of the CARD server is minimal? > We are talking about the "central" point of control here that determines the > cache entries. I think it a very important point to consider. > > ---------------------------* > > On the other handoff, > > server based approach provides better manageability as well control. > > > > [Govind] What manageability are you talking about? You assume that each AR > knows what APs it has. Why should it be conveyed to the CARD server? Why can't > it be conveyed directly to its CARs? Also, what lack of manageability that you > perceive in dycard? Can we talk quantitatively rather qualitatively here? > > > > As I mentioned above, > > with clever use of scope-id, it is possible to reduce the affect of DoS attack > as > > well as cache contamination problem. > > > > [Govind] Could you define "clever" use of scope-id? Quoting from the draft > > "operators may set their ARs' scope id to a server. When a current AR requests > the L2-L3 mapping from the server, the server returns the mapping with the > scope-id". From the above reasoning, there is an close correlation assumed with > the ARs and APs. That might not be true first. Second if the approximate > locations of APs and ARs are known and they are in the same domain, why not have > these scope-IDs directly stored at the ARs in the cache rather than pushing them > to the CARD server then getting them down to the ARs. > > > > > > [snip] > > AJOY-> Probably you are right. We do need to get consensus from AAA group for > doing this. > > BTW, If we use AAA server, then it is also possible to use AAA server for the > > purpose of key distribution. I would like to receive feedback from other > members of > > WG about the potential use of AAA server as CARD server. > > [Govind] I don't think we need to do this at all. Key distribution, that too > for ARs in the same domain, is not at all CARD problem at all. There are other > ways to do it, and I don't think we need to re-invent the wheel. Routers within > a domain are trusting each other right now too, is it not? > > > > > > [snip] > > AJOY-> I am not sure I agree with you here. Could you provide some additional > > detail why you think scope id is complicated? > > > > [Govind]I'll let you know if I come up with something more, than what I've > provided in my previous email. > > > > Also, when we talk about inter-domain handovers this may be quite difficult to > achieve. I know that we are not talking about inter-domain handovers at this > point, but coming up with a solution that does not work very well in the future > is not the correct way to go, IMHO. > > > > AJOY-> Let be focused now. > > > > [Govind] Focusing on a solution that doesn't work very well even now is not > the best way to go either. Instead, it will be more prudent to come up with > > a solution that works well now, and also has a good chance of being accepted > later. > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 16:57:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01821 for ; Wed, 5 Mar 2003 16:57:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25M89O27119; Wed, 5 Mar 2003 17:08:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25M7JO26764 for ; Wed, 5 Mar 2003 17:07:19 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01639 for ; Wed, 5 Mar 2003 16:56:05 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Mar 2003 16:58:07 -0500 Message-ID: <010001c2e37b$9f453270$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <020e01c2e35f$2b433be0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 16:59:20 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 05 Mar 2003 21:58:07.0991 (UTC) FILETIME=[4E4F3870:01C2E362] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't understand James' comment. Certainly it is a new element introduced for CARD. Let's say I have WLAN without any server you listed in the below. Then to run CARD, I need to install the server introduced by the draft, don't I? Regards, Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Wednesday, March 05, 2003 1:35 PM Subject: Re: [Seamoby] Comments on DT CARD draft > Govind, > > I don't agree that the server specified in the draft is a new element. The > specification is for a configuration server, AAA or LDAP or something like that. > This is a common way of configuring routers, I believe it is used for IPsec > configuration information. > > I haven't finished reading the draft yet so I can't comment on the rest of your > points. > > jak > > ----- Original Message ----- > From: > To: ; > Sent: Wednesday, March 05, 2003 10:58 AM > Subject: RE: [Seamoby] Comments on DT CARD draft > > > > Hi Ajoy, > > Comments inline. Thanks for your reply. > > > > -Govind. > > > > > > > > AJOY-> We are aware of this. What is the status of > > requirement draft? Is it approved by IESG yet. Probably > > we need to change this requirement in case WG likes > > to go with server based approach. > > > > [Govind] The requirements document has passed last WG last call. The IESG did > come back with one set of comments, but I don't think they had > > any problems with this particular requirement in those comments. > > > > [snip] > > > > AJOY-> This depends upon the cache timeout as well as handoff traffic. > > BTW, the server based approach is easier to manage as well > > it provides extra security. If we deploy scope-id with serve based approach, > then > > it is very much possible to reduce or even eliminate the problem of cache > contamination. > > This also minimizes the affect DoS attack. > > > > [Govind] The cache timeout can be handled quite easily. Regarding, the server > based approach being more secure, this is quite unclear from the document. I > don't think you can eleminate the cache contamination problem from any of the > schemes that you have described. I have explained in my email how using the > scope ID approach still allows you to keep "n" entries > > that are not CARs in the cache. In fact, the DT draft acknowledges that the > > CARD server can still be subjected to a DoS attack. I don't really agree with > your premise that you alleviate the security problems just by having a > > CARD server. > > > > [snip] > > > > AJOY-> These entries may not be cached for ever. Smaller the cache timeout, > > the earlier you will be able to detect any change of capability > > or L2->L3 mapping information. > > > > [Govind] So we need to choose a timeout that is appropriate, why do we need a > server for this? I still don't understand that. > > > > [snip] > > > > AJOY-> I think this will be better than the case where cache entries are > solely > > propagated by the mobile node. I think in the later case, the first handoff > > will always be the slower. Moreover the later approach is very > > difficult to manage and is even less secure. > > > > [Govind] Yes, the first handover case. So are you saying the cost of the first > handover being not seamless is worth introducing a new element in the network? > > Could you explain why the latter approach is less secure? Once you have a > cache at the AR that is populated with MN input, like what you are doing in the > DT draft and we do in dycard, the level of security of the protocols is pretty > comparable. Please note, any of the security checks that you have introduced > including scope ID, which I still think is not the best way to go, can be used > without the server being present at all. > > > > Also, you could you list out the security holes that you perceive in the > dycard draft. Also, could you look at the way we have handled it and see whether > we have presented solutions tackled the issues? > > > > Lastly, as I pointed out in my earlier mail, we have provided a method, in an > earlier version of the draft, that makes the first handover also seamless in a > probabilistic sense. I don't think DT draft can promise better than that too. We > omitted this, because we felt that it doesn't make much sense in the steady > state of the system. Basically a cost vs. benefit analysis. > > > > ----------* > > [snip] > > > > BTW-> The IP packets are not routed via CARD server so I am not sure if it a > big > > drawback. > > [Govind] You need the CARD server for any translation on a cache miss. > > So what is this that you bring about routing packets via CARD server? I'm > completely missing your point here. > > -----------------------* > > I will be more concerned about the single point of failure where IP packets > are > > routed through it. CARD server will provide a similar function as DNS server > > So, probably it is not a big drawback in my understanding. > > > > [Govind] Does this imply that the functionality of the CARD server is minimal? > We are talking about the "central" point of control here that determines the > cache entries. I think it a very important point to consider. > > ---------------------------* > > On the other handoff, > > server based approach provides better manageability as well control. > > > > [Govind] What manageability are you talking about? You assume that each AR > knows what APs it has. Why should it be conveyed to the CARD server? Why can't > it be conveyed directly to its CARs? Also, what lack of manageability that you > perceive in dycard? Can we talk quantitatively rather qualitatively here? > > > > As I mentioned above, > > with clever use of scope-id, it is possible to reduce the affect of DoS attack > as > > well as cache contamination problem. > > > > [Govind] Could you define "clever" use of scope-id? Quoting from the draft > > "operators may set their ARs' scope id to a server. When a current AR requests > the L2-L3 mapping from the server, the server returns the mapping with the > scope-id". From the above reasoning, there is an close correlation assumed with > the ARs and APs. That might not be true first. Second if the approximate > locations of APs and ARs are known and they are in the same domain, why not have > these scope-IDs directly stored at the ARs in the cache rather than pushing them > to the CARD server then getting them down to the ARs. > > > > > > [snip] > > AJOY-> Probably you are right. We do need to get consensus from AAA group for > doing this. > > BTW, If we use AAA server, then it is also possible to use AAA server for the > > purpose of key distribution. I would like to receive feedback from other > members of > > WG about the potential use of AAA server as CARD server. > > [Govind] I don't think we need to do this at all. Key distribution, that too > for ARs in the same domain, is not at all CARD problem at all. There are other > ways to do it, and I don't think we need to re-invent the wheel. Routers within > a domain are trusting each other right now too, is it not? > > > > > > [snip] > > AJOY-> I am not sure I agree with you here. Could you provide some additional > > detail why you think scope id is complicated? > > > > [Govind]I'll let you know if I come up with something more, than what I've > provided in my previous email. > > > > Also, when we talk about inter-domain handovers this may be quite difficult to > achieve. I know that we are not talking about inter-domain handovers at this > point, but coming up with a solution that does not work very well in the future > is not the correct way to go, IMHO. > > > > AJOY-> Let be focused now. > > > > [Govind] Focusing on a solution that doesn't work very well even now is not > the best way to go either. Instead, it will be more prudent to come up with > > a solution that works well now, and also has a good chance of being accepted > later. > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 16:59:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01911 for ; Wed, 5 Mar 2003 16:59:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25MAK427260 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 17:10:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MAKO27257 for ; Wed, 5 Mar 2003 17:10:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01869 for ; Wed, 5 Mar 2003 16:59:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MA2O27247; Wed, 5 Mar 2003 17:10:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25M9oO27219 for ; Wed, 5 Mar 2003 17:09:50 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01849 for ; Wed, 5 Mar 2003 16:58:35 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25M0c821984 for ; Wed, 5 Mar 2003 16:00:38 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 16:00:37 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 15:59:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 16:59:40 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjX/OzIvrn39N7SVy1HW2HE+MkowAAA9bg To: , , X-OriginalArrivalTime: 05 Mar 2003 21:59:41.0539 (UTC) FILETIME=[86118330:01C2E362] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25M9oO27220 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, First, I think the DT has a different view from you about the server not being a new element :). Essentially what saying is that you are adding a new functionality on some other existing element in the network. There is an inherent assumption that this can be added to such servers. For example, this may not be possible in AAA servers given the present charter of AAA WG. The DT members also seem to accept this may be the case. The main point I was trying to make is having an extra server (or functionality) whereever it may reside is not worth it at all. Could you elaborate more on the IPSec configuration that you mention. Just to understand you better. I look forward to your comments. -Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 05, 2003 4:36 PM To: Krishnamurthi Govind (NRC/Boston); ASINGH1@motorola.com; seamoby@ietf.org Subject: Re: [Seamoby] Comments on DT CARD draft Govind, I don't agree that the server specified in the draft is a new element. The specification is for a configuration server, AAA or LDAP or something like that. This is a common way of configuring routers, I believe it is used for IPsec configuration information. I haven't finished reading the draft yet so I can't comment on the rest of your points. jak ----- Original Message ----- From: To: ; Sent: Wednesday, March 05, 2003 10:58 AM Subject: RE: [Seamoby] Comments on DT CARD draft > Hi Ajoy, > Comments inline. Thanks for your reply. > > -Govind. > > > > AJOY-> We are aware of this. What is the status of > requirement draft? Is it approved by IESG yet. Probably > we need to change this requirement in case WG likes > to go with server based approach. > > [Govind] The requirements document has passed last WG last call. The IESG did come back with one set of comments, but I don't think they had > any problems with this particular requirement in those comments. > > [snip] > > AJOY-> This depends upon the cache timeout as well as handoff traffic. > BTW, the server based approach is easier to manage as well > it provides extra security. If we deploy scope-id with serve based approach, then > it is very much possible to reduce or even eliminate the problem of cache contamination. > This also minimizes the affect DoS attack. > > [Govind] The cache timeout can be handled quite easily. Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entries > that are not CARs in the cache. In fact, the DT draft acknowledges that the > CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a > CARD server. > > [snip] > > AJOY-> These entries may not be cached for ever. Smaller the cache timeout, > the earlier you will be able to detect any change of capability > or L2->L3 mapping information. > > [Govind] So we need to choose a timeout that is appropriate, why do we need a server for this? I still don't understand that. > > [snip] > > AJOY-> I think this will be better than the case where cache entries are solely > propagated by the mobile node. I think in the later case, the first handoff > will always be the slower. Moreover the later approach is very > difficult to manage and is even less secure. > > [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? > Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. > > Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? > > Lastly, as I pointed out in my earlier mail, we have provided a method, in an earlier version of the draft, that makes the first handover also seamless in a probabilistic sense. I don't think DT draft can promise better than that too. We omitted this, because we felt that it doesn't make much sense in the steady state of the system. Basically a cost vs. benefit analysis. > > ----------* > [snip] > > BTW-> The IP packets are not routed via CARD server so I am not sure if it a big > drawback. > [Govind] You need the CARD server for any translation on a cache miss. > So what is this that you bring about routing packets via CARD server? I'm completely missing your point here. > -----------------------* > I will be more concerned about the single point of failure where IP packets are > routed through it. CARD server will provide a similar function as DNS server > So, probably it is not a big drawback in my understanding. > > [Govind] Does this imply that the functionality of the CARD server is minimal? We are talking about the "central" point of control here that determines the cache entries. I think it a very important point to consider. > ---------------------------* > On the other handoff, > server based approach provides better manageability as well control. > > [Govind] What manageability are you talking about? You assume that each AR knows what APs it has. Why should it be conveyed to the CARD server? Why can't it be conveyed directly to its CARs? Also, what lack of manageability that you perceive in dycard? Can we talk quantitatively rather qualitatively here? > > As I mentioned above, > with clever use of scope-id, it is possible to reduce the affect of DoS attack as > well as cache contamination problem. > > [Govind] Could you define "clever" use of scope-id? Quoting from the draft > "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. > > > [snip] > AJOY-> Probably you are right. We do need to get consensus from AAA group for doing this. > BTW, If we use AAA server, then it is also possible to use AAA server for the > purpose of key distribution. I would like to receive feedback from other members of > WG about the potential use of AAA server as CARD server. > [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? > > > [snip] > AJOY-> I am not sure I agree with you here. Could you provide some additional > detail why you think scope id is complicated? > > [Govind]I'll let you know if I come up with something more, than what I've provided in my previous email. > > Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. > > AJOY-> Let be focused now. > > [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with > a solution that works well now, and also has a good chance of being accepted later. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 17:00:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01979 for ; Wed, 5 Mar 2003 17:00:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MA2O27247; Wed, 5 Mar 2003 17:10:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25M9oO27219 for ; Wed, 5 Mar 2003 17:09:50 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01849 for ; Wed, 5 Mar 2003 16:58:35 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25M0c821984 for ; Wed, 5 Mar 2003 16:00:38 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 16:00:37 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 15:59:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 16:59:40 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjX/OzIvrn39N7SVy1HW2HE+MkowAAA9bg To: , , X-OriginalArrivalTime: 05 Mar 2003 21:59:41.0539 (UTC) FILETIME=[86118330:01C2E362] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25M9oO27220 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, First, I think the DT has a different view from you about the server not being a new element :). Essentially what saying is that you are adding a new functionality on some other existing element in the network. There is an inherent assumption that this can be added to such servers. For example, this may not be possible in AAA servers given the present charter of AAA WG. The DT members also seem to accept this may be the case. The main point I was trying to make is having an extra server (or functionality) whereever it may reside is not worth it at all. Could you elaborate more on the IPSec configuration that you mention. Just to understand you better. I look forward to your comments. -Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 05, 2003 4:36 PM To: Krishnamurthi Govind (NRC/Boston); ASINGH1@motorola.com; seamoby@ietf.org Subject: Re: [Seamoby] Comments on DT CARD draft Govind, I don't agree that the server specified in the draft is a new element. The specification is for a configuration server, AAA or LDAP or something like that. This is a common way of configuring routers, I believe it is used for IPsec configuration information. I haven't finished reading the draft yet so I can't comment on the rest of your points. jak ----- Original Message ----- From: To: ; Sent: Wednesday, March 05, 2003 10:58 AM Subject: RE: [Seamoby] Comments on DT CARD draft > Hi Ajoy, > Comments inline. Thanks for your reply. > > -Govind. > > > > AJOY-> We are aware of this. What is the status of > requirement draft? Is it approved by IESG yet. Probably > we need to change this requirement in case WG likes > to go with server based approach. > > [Govind] The requirements document has passed last WG last call. The IESG did come back with one set of comments, but I don't think they had > any problems with this particular requirement in those comments. > > [snip] > > AJOY-> This depends upon the cache timeout as well as handoff traffic. > BTW, the server based approach is easier to manage as well > it provides extra security. If we deploy scope-id with serve based approach, then > it is very much possible to reduce or even eliminate the problem of cache contamination. > This also minimizes the affect DoS attack. > > [Govind] The cache timeout can be handled quite easily. Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entries > that are not CARs in the cache. In fact, the DT draft acknowledges that the > CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a > CARD server. > > [snip] > > AJOY-> These entries may not be cached for ever. Smaller the cache timeout, > the earlier you will be able to detect any change of capability > or L2->L3 mapping information. > > [Govind] So we need to choose a timeout that is appropriate, why do we need a server for this? I still don't understand that. > > [snip] > > AJOY-> I think this will be better than the case where cache entries are solely > propagated by the mobile node. I think in the later case, the first handoff > will always be the slower. Moreover the later approach is very > difficult to manage and is even less secure. > > [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? > Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. > > Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? > > Lastly, as I pointed out in my earlier mail, we have provided a method, in an earlier version of the draft, that makes the first handover also seamless in a probabilistic sense. I don't think DT draft can promise better than that too. We omitted this, because we felt that it doesn't make much sense in the steady state of the system. Basically a cost vs. benefit analysis. > > ----------* > [snip] > > BTW-> The IP packets are not routed via CARD server so I am not sure if it a big > drawback. > [Govind] You need the CARD server for any translation on a cache miss. > So what is this that you bring about routing packets via CARD server? I'm completely missing your point here. > -----------------------* > I will be more concerned about the single point of failure where IP packets are > routed through it. CARD server will provide a similar function as DNS server > So, probably it is not a big drawback in my understanding. > > [Govind] Does this imply that the functionality of the CARD server is minimal? We are talking about the "central" point of control here that determines the cache entries. I think it a very important point to consider. > ---------------------------* > On the other handoff, > server based approach provides better manageability as well control. > > [Govind] What manageability are you talking about? You assume that each AR knows what APs it has. Why should it be conveyed to the CARD server? Why can't it be conveyed directly to its CARs? Also, what lack of manageability that you perceive in dycard? Can we talk quantitatively rather qualitatively here? > > As I mentioned above, > with clever use of scope-id, it is possible to reduce the affect of DoS attack as > well as cache contamination problem. > > [Govind] Could you define "clever" use of scope-id? Quoting from the draft > "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. > > > [snip] > AJOY-> Probably you are right. We do need to get consensus from AAA group for doing this. > BTW, If we use AAA server, then it is also possible to use AAA server for the > purpose of key distribution. I would like to receive feedback from other members of > WG about the potential use of AAA server as CARD server. > [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? > > > [snip] > AJOY-> I am not sure I agree with you here. Could you provide some additional > detail why you think scope id is complicated? > > [Govind]I'll let you know if I come up with something more, than what I've provided in my previous email. > > Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. > > AJOY-> Let be focused now. > > [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with > a solution that works well now, and also has a good chance of being accepted later. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 17:44:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03711 for ; Wed, 5 Mar 2003 17:44:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Mthd30895 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 17:55:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MtgO30892 for ; Wed, 5 Mar 2003 17:55:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03688 for ; Wed, 5 Mar 2003 17:44:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MtDO30860; Wed, 5 Mar 2003 17:55:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MrgO30743 for ; Wed, 5 Mar 2003 17:53:42 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03582 for ; Wed, 5 Mar 2003 17:42:27 -0500 (EST) Message-ID: <027a01c2e368$9218adb0$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 14:42:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > First, I think the DT has a different view from you about the server not being a new element :). > Like I said, I haven't finished reading the draft yet. Too much email to read. :-) > Essentially what saying is that you are adding a new functionality on some other > existing element in the network. > There is an inherent assumption that this can be added to such servers. For example, this may > not be possible in AAA servers given the present charter of AAA WG. The DT members also > seem to accept this may be the case. > It could be an LDAP server. > The main point I was trying to make is > having an extra server (or functionality) whereever it may reside is not worth it at all. > Depends. There are other things in this draft (TAR calculation, for example) that one could argue shouldn't be there. > Could you elaborate more on the IPSec configuration that you mention. Just to > understand you better. > My understanding is VPN gateways and routers often store SPD entries in LDAP servers. Having the configuration information centralized makes it easier for sysadmins to maintain. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 17:45:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03728 for ; Wed, 5 Mar 2003 17:45:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MtDO30860; Wed, 5 Mar 2003 17:55:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MrgO30743 for ; Wed, 5 Mar 2003 17:53:42 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03582 for ; Wed, 5 Mar 2003 17:42:27 -0500 (EST) Message-ID: <027a01c2e368$9218adb0$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 14:42:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > First, I think the DT has a different view from you about the server not being a new element :). > Like I said, I haven't finished reading the draft yet. Too much email to read. :-) > Essentially what saying is that you are adding a new functionality on some other > existing element in the network. > There is an inherent assumption that this can be added to such servers. For example, this may > not be possible in AAA servers given the present charter of AAA WG. The DT members also > seem to accept this may be the case. > It could be an LDAP server. > The main point I was trying to make is > having an extra server (or functionality) whereever it may reside is not worth it at all. > Depends. There are other things in this draft (TAR calculation, for example) that one could argue shouldn't be there. > Could you elaborate more on the IPSec configuration that you mention. Just to > understand you better. > My understanding is VPN gateways and routers often store SPD entries in LDAP servers. Having the configuration information centralized makes it easier for sysadmins to maintain. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 18:58:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07176 for ; Wed, 5 Mar 2003 18:58:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2609dL04296 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 19:09:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2609dO04293 for ; Wed, 5 Mar 2003 19:09:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07167 for ; Wed, 5 Mar 2003 18:58:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2609SO04285; Wed, 5 Mar 2003 19:09:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2608sO04237 for ; Wed, 5 Mar 2003 19:08:54 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07094 for ; Wed, 5 Mar 2003 18:57:37 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25Nxga06333 for ; Wed, 5 Mar 2003 17:59:42 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 17:59:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 15:58:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 18:58:46 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjaNHOW6bAYgTCR2iHHDyGHdf4egACYnFw To: , , X-OriginalArrivalTime: 05 Mar 2003 23:58:47.0956 (UTC) FILETIME=[29AA3540:01C2E373] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2608sO04238 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, > Essentially what saying is that you are adding a new functionality on some other > existing element in the network. > There is an inherent assumption that this can be added to such servers. For example, this may > not be possible in AAA servers given the present charter of AAA WG. The DT members also > seem to accept this may be the case. > It could be an LDAP server. [Govind] Are you sure LDAP servers exist everywhere? Plus, you might have similar issues as with AAA WG. > The main point I was trying to make is > having an extra server (or functionality) whereever it may reside is not worth it at all. > Depends. There are other things in this draft (TAR calculation, for example) that one could argue shouldn't be there. [Govind] AFAIK, the DT draft does not talk about TAR selection. But I might have missed it. It just mentions that the CARD output is fed to TARS. But I agree with you in the sense that what is not essentially relevant to CARD shouldn't be there. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 18:59:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07197 for ; Wed, 5 Mar 2003 18:59:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2609SO04285; Wed, 5 Mar 2003 19:09:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2608sO04237 for ; Wed, 5 Mar 2003 19:08:54 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07094 for ; Wed, 5 Mar 2003 18:57:37 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25Nxga06333 for ; Wed, 5 Mar 2003 17:59:42 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 17:59:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 15:58:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Wed, 5 Mar 2003 18:58:46 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLjaNHOW6bAYgTCR2iHHDyGHdf4egACYnFw To: , , X-OriginalArrivalTime: 05 Mar 2003 23:58:47.0956 (UTC) FILETIME=[29AA3540:01C2E373] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2608sO04238 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, > Essentially what saying is that you are adding a new functionality on some other > existing element in the network. > There is an inherent assumption that this can be added to such servers. For example, this may > not be possible in AAA servers given the present charter of AAA WG. The DT members also > seem to accept this may be the case. > It could be an LDAP server. [Govind] Are you sure LDAP servers exist everywhere? Plus, you might have similar issues as with AAA WG. > The main point I was trying to make is > having an extra server (or functionality) whereever it may reside is not worth it at all. > Depends. There are other things in this draft (TAR calculation, for example) that one could argue shouldn't be there. [Govind] AFAIK, the DT draft does not talk about TAR selection. But I might have missed it. It just mentions that the CARD output is fed to TARS. But I agree with you in the sense that what is not essentially relevant to CARD shouldn't be there. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 5 20:01:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08848 for ; Wed, 5 Mar 2003 20:01:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h261CXK08600 for seamoby-archive@odin.ietf.org; Wed, 5 Mar 2003 20:12:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h261CXO08597 for ; Wed, 5 Mar 2003 20:12:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08833 for ; Wed, 5 Mar 2003 20:01:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h261CKO08589; Wed, 5 Mar 2003 20:12:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h261BnO08564 for ; Wed, 5 Mar 2003 20:11:49 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08816 for ; Wed, 5 Mar 2003 20:00:29 -0500 (EST) Message-ID: <033901c2e37b$db27b3d0$156015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 5 Mar 2003 17:01:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Finally had time to complete a review of the latest CARD draft. In general, the design team seems to be making good progress on getting the details of the protocol design filled in. My comments break down into 3 areas: meta-issues involving contents of the draft, specific technical issues with the contents, and editorial comments. Meta-issues ------------ I found the draft somewhat confusing as there seem to be really four protocols defined here. They are: 1) A collection of options for RFC 2461 and FMIP to provide a mobile node with information about wireless handover connectivity to different subnets. 2) An RFC 2461 extension message for transmitting 1) between a mobile node and access router in the absence of FMIP. 3) An interrouter protocol that uses 1) to exchange the same sort of information between routers instead of between the mobile node and its access router. 4) An (underspecified) protocol between an access router and a server that lets the access router authenticate CARD information and, optionally, pre-populate its cache so that there is no learning period involved before the access router can provide CARD information to the mobile node. I think it would be really helpful to separate out these four areas and drill down on them to get the details. Specifically, I would like to suggest the following: 1) &2) As some of you may know, the Mobile IP group is currently undergoing rechartering and there will be a BOF in SFO to discuss this. I have proposed as part of the recharter that parts of the CARD work that have overlap with or have relevance to FMIP be moved into a separate, spinoff MIP group. In the latest FMIP draft, the proxy router advertisement signaling has been moved away from handover and now has no function other than to inform the mobile node about wireless subnet connectivity. Since that is also what 1) and 2) are doing, I would propose that the good work done in this document be sectioned off into a separate document and introduced into the spinoff WG, should the IESG agree to form such a group. If the ISEG doesn't, then I think the design team should section the document and put this protocol into a separate document, dropping 2) and making this signaling a collection of options on FMIP. In addition, I would suggest that the CARD design team co-ordinate this with the current editor of the FMIP draft. There is no point in having 2) if FMIP provides the functionality. 3) I can't really see the point of introducing a new inter-router protocol of this sort. I believe this would be better handled by defining some kind of OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a proposal, however. In any case, it needs investigation and should be moved into a separate document if it proves to be of interest. 4) I disagree with the contention of some that this protocol is introducing a new network element. Any large scale enterprise or ISP network is going to have configuration in it, and this protocol is essentially defining a way to do configuration. For small, home networks, this might not be required, because it might be done using a Web interface to the firewall/access point. The proposed solution in this draft is fairly vague, but I can see a couple of possible dispositions: a) Define a RADIUS extension like that used by IAPP. b) Define an LDAP schema for access point configuration information. c) Define an SNMP MIB that allows a router to obtain this information from another router. I believe 802.11 has its own MIB, but we are talking about something that is more generic. I've got no opinion about which of these would be better, and there could be other possibilities. We should decide fairly quickly which we want to pursue. Technical Comments --------------------- Section 3.2: Highly dynamic capabilites should be out of scope. Also, in paragraph 2, what are downlink channels? Not all wireless protocols will have these. Section 4.1: I can't see how an MN could possibly perform CARD with an AR that is not currently on its subnet. How does the MN discover such an AR in the first place except by performing CARD with its exisitng AR (in which case, it doesn't need to perform it with the other one)? If you assume that the MN has brought up a separate interface with the other AR, then the other AR is on a subnet that the MN is using on that interface. RA/RS can't be sent to any off link node, as they are limited by the security measures in RFC 2461. Also, I don't think that we should be considering L2 specific measures here (like including the other router's IP address in the L2 beacon). Throughout the draft, the notes on TAR selection and prefiltering should be moved to an appendix. This includes the part in Section 4.2. The discussion of TAR in the Requirements suboption and the node types in the Address suboption need to be removed. From the MN's point of view, it doesn't matter whether the returned address was prefiltered by the router or not. TAR selection on the router should be completely invisible as far at the MN is concerned, and selection on the MN is out of scope for this draft. Section 5.1.3 Option formats need to be aligned with FMIP to avoid duplication. For example, the MN may want to know the subnet prefix on the new subnet, but that is not defined here. Section 5.1.3.4 Why is the 'P' flag necessary? I think we need to align with FMIP and remove this. Section 5.1.4: What function does the lifetime flag perform? Either the returned information is valid or not. If there's a lifetime associated with it, that should be in the returned information. Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, itself, subject to DOS attacks. The solutions presented in Section 6.3 for handling these problems are much more streamlined and align with IP network softstate approach: 1) The protocol specifies a minimum interarrival time for sending requests. 2) The protocol specifies a minimum reply time for routers replying. If too many requests arrive, the router begins to selectively drop so hosts have to retransmit. 3) A default cache lifetime is defined. After this time, the router times out the cache entry. 4) An entry presented by the MN gets a preference level. The more times it is reported by another MN, the less likely it is to time out. This needs to be quantified and described as an algorthm. These elements need to be added to the protocol draft for 1) in the meta-issues section. Editorial Comments ------------------- Abbreviations that are defined in Section 2 should not be used until after they are defined. Section 2, CAR definition: the wording here is awkward. It needs clarification. Section 3.1, paragraph 1, line 2: CAR that connects -> CAR that is connected Section 3.1, paragraph 3, line 5: reverse address translation before -> reverse address translation Section 3.1, paragraph 4: These comments seem somewhat out of place. The new AR isn't of interest to the MN for mobility purposes unless it is in a new subnet, and, anyway, ARs in the current subnet will be obtained by RFC 2461 router discovery. I also don't understand what the last sentence has to do with anything. Section 4.2 paragraph 9: the link layer ID of nearby AP -> the link layer ID of a new AP. There are also a couple of other awkwardly phrased places in this paragraph. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 5 20:03:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08872 for ; Wed, 5 Mar 2003 20:03:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h261CKO08589; Wed, 5 Mar 2003 20:12:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h261BnO08564 for ; Wed, 5 Mar 2003 20:11:49 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08816 for ; Wed, 5 Mar 2003 20:00:29 -0500 (EST) Message-ID: <033901c2e37b$db27b3d0$156015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 5 Mar 2003 17:01:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Finally had time to complete a review of the latest CARD draft. In general, the design team seems to be making good progress on getting the details of the protocol design filled in. My comments break down into 3 areas: meta-issues involving contents of the draft, specific technical issues with the contents, and editorial comments. Meta-issues ------------ I found the draft somewhat confusing as there seem to be really four protocols defined here. They are: 1) A collection of options for RFC 2461 and FMIP to provide a mobile node with information about wireless handover connectivity to different subnets. 2) An RFC 2461 extension message for transmitting 1) between a mobile node and access router in the absence of FMIP. 3) An interrouter protocol that uses 1) to exchange the same sort of information between routers instead of between the mobile node and its access router. 4) An (underspecified) protocol between an access router and a server that lets the access router authenticate CARD information and, optionally, pre-populate its cache so that there is no learning period involved before the access router can provide CARD information to the mobile node. I think it would be really helpful to separate out these four areas and drill down on them to get the details. Specifically, I would like to suggest the following: 1) &2) As some of you may know, the Mobile IP group is currently undergoing rechartering and there will be a BOF in SFO to discuss this. I have proposed as part of the recharter that parts of the CARD work that have overlap with or have relevance to FMIP be moved into a separate, spinoff MIP group. In the latest FMIP draft, the proxy router advertisement signaling has been moved away from handover and now has no function other than to inform the mobile node about wireless subnet connectivity. Since that is also what 1) and 2) are doing, I would propose that the good work done in this document be sectioned off into a separate document and introduced into the spinoff WG, should the IESG agree to form such a group. If the ISEG doesn't, then I think the design team should section the document and put this protocol into a separate document, dropping 2) and making this signaling a collection of options on FMIP. In addition, I would suggest that the CARD design team co-ordinate this with the current editor of the FMIP draft. There is no point in having 2) if FMIP provides the functionality. 3) I can't really see the point of introducing a new inter-router protocol of this sort. I believe this would be better handled by defining some kind of OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a proposal, however. In any case, it needs investigation and should be moved into a separate document if it proves to be of interest. 4) I disagree with the contention of some that this protocol is introducing a new network element. Any large scale enterprise or ISP network is going to have configuration in it, and this protocol is essentially defining a way to do configuration. For small, home networks, this might not be required, because it might be done using a Web interface to the firewall/access point. The proposed solution in this draft is fairly vague, but I can see a couple of possible dispositions: a) Define a RADIUS extension like that used by IAPP. b) Define an LDAP schema for access point configuration information. c) Define an SNMP MIB that allows a router to obtain this information from another router. I believe 802.11 has its own MIB, but we are talking about something that is more generic. I've got no opinion about which of these would be better, and there could be other possibilities. We should decide fairly quickly which we want to pursue. Technical Comments --------------------- Section 3.2: Highly dynamic capabilites should be out of scope. Also, in paragraph 2, what are downlink channels? Not all wireless protocols will have these. Section 4.1: I can't see how an MN could possibly perform CARD with an AR that is not currently on its subnet. How does the MN discover such an AR in the first place except by performing CARD with its exisitng AR (in which case, it doesn't need to perform it with the other one)? If you assume that the MN has brought up a separate interface with the other AR, then the other AR is on a subnet that the MN is using on that interface. RA/RS can't be sent to any off link node, as they are limited by the security measures in RFC 2461. Also, I don't think that we should be considering L2 specific measures here (like including the other router's IP address in the L2 beacon). Throughout the draft, the notes on TAR selection and prefiltering should be moved to an appendix. This includes the part in Section 4.2. The discussion of TAR in the Requirements suboption and the node types in the Address suboption need to be removed. From the MN's point of view, it doesn't matter whether the returned address was prefiltered by the router or not. TAR selection on the router should be completely invisible as far at the MN is concerned, and selection on the MN is out of scope for this draft. Section 5.1.3 Option formats need to be aligned with FMIP to avoid duplication. For example, the MN may want to know the subnet prefix on the new subnet, but that is not defined here. Section 5.1.3.4 Why is the 'P' flag necessary? I think we need to align with FMIP and remove this. Section 5.1.4: What function does the lifetime flag perform? Either the returned information is valid or not. If there's a lifetime associated with it, that should be in the returned information. Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, itself, subject to DOS attacks. The solutions presented in Section 6.3 for handling these problems are much more streamlined and align with IP network softstate approach: 1) The protocol specifies a minimum interarrival time for sending requests. 2) The protocol specifies a minimum reply time for routers replying. If too many requests arrive, the router begins to selectively drop so hosts have to retransmit. 3) A default cache lifetime is defined. After this time, the router times out the cache entry. 4) An entry presented by the MN gets a preference level. The more times it is reported by another MN, the less likely it is to time out. This needs to be quantified and described as an algorthm. These elements need to be added to the protocol draft for 1) in the meta-issues section. Editorial Comments ------------------- Abbreviations that are defined in Section 2 should not be used until after they are defined. Section 2, CAR definition: the wording here is awkward. It needs clarification. Section 3.1, paragraph 1, line 2: CAR that connects -> CAR that is connected Section 3.1, paragraph 3, line 5: reverse address translation before -> reverse address translation Section 3.1, paragraph 4: These comments seem somewhat out of place. The new AR isn't of interest to the MN for mobility purposes unless it is in a new subnet, and, anyway, ARs in the current subnet will be obtained by RFC 2461 router discovery. I also don't understand what the last sentence has to do with anything. Section 4.2 paragraph 9: the link layer ID of nearby AP -> the link layer ID of a new AP. There are also a couple of other awkwardly phrased places in this paragraph. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 12:13:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29447 for ; Thu, 6 Mar 2003 12:13:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HOLF25401 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 12:24:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HOLO25395 for ; Thu, 6 Mar 2003 12:24:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29402 for ; Thu, 6 Mar 2003 12:12:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HO8O25321; Thu, 6 Mar 2003 12:24:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HDLO24156 for ; Thu, 6 Mar 2003 12:13:21 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28631 for ; Thu, 6 Mar 2003 12:01:45 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 12:03:49 -0500 Message-ID: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: , , , References: Subject: Re: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 12:05:02 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 06 Mar 2003 17:03:49.0199 (UTC) FILETIME=[5B4325F0:01C2E402] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Regarding the CARD server, I have a few comments. 1) First of all, the dycard draft shows that CARD works without any central server. That is, we don't need the server for CARD. 2) The DT draft also mentions that the server + beacon approach has a security hole that allows so easy contamination of the table at the AR. In comparison to this, the dycard draft proposes an approach that can be designed to make such contamination very difficult. It is the discovery approach where the mobile host delivers the IP address of the previous AR to the current AR. 3) Certainly the CARD server, which is a central server, causes concern about single point of failure and scalability. So I don't quite understand why the CARD server approach was taken while it has such disadvantages compared to an alternative approach. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 12:13:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29462 for ; Thu, 6 Mar 2003 12:13:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HO8O25321; Thu, 6 Mar 2003 12:24:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HDLO24156 for ; Thu, 6 Mar 2003 12:13:21 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28631 for ; Thu, 6 Mar 2003 12:01:45 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 12:03:49 -0500 Message-ID: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: , , , References: Subject: Re: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 12:05:02 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 06 Mar 2003 17:03:49.0199 (UTC) FILETIME=[5B4325F0:01C2E402] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Regarding the CARD server, I have a few comments. 1) First of all, the dycard draft shows that CARD works without any central server. That is, we don't need the server for CARD. 2) The DT draft also mentions that the server + beacon approach has a security hole that allows so easy contamination of the table at the AR. In comparison to this, the dycard draft proposes an approach that can be designed to make such contamination very difficult. It is the discovery approach where the mobile host delivers the IP address of the previous AR to the current AR. 3) Certainly the CARD server, which is a central server, causes concern about single point of failure and scalability. So I don't quite understand why the CARD server approach was taken while it has such disadvantages compared to an alternative approach. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 12:15:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29715 for ; Thu, 6 Mar 2003 12:15:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HQCX25956 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 12:26:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HQCO25953 for ; Thu, 6 Mar 2003 12:26:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29616 for ; Thu, 6 Mar 2003 12:14:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HPYO25653; Thu, 6 Mar 2003 12:25:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HJKO24689 for ; Thu, 6 Mar 2003 12:19:20 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29016 for ; Thu, 6 Mar 2003 12:07:41 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26H9la05644 for ; Thu, 6 Mar 2003 11:09:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 11:09:44 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 09:09:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 12:09:43 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLjfDxvkIENi3bnTO2+D+396PVpHAAdN47A To: , X-OriginalArrivalTime: 06 Mar 2003 17:09:44.0458 (UTC) FILETIME=[2F035EA0:01C2E403] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26HJKO24690 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jim, Some comments embedded inline. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 05, 2003 8:01 PM To: seamoby@ietf.org Subject: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt [snip] dropping 2) and making this signaling a collection of options on FMIP. In addition, I would suggest that the CARD design team co-ordinate this with the current editor of the FMIP draft. There is no point in having 2) if FMIP provides the functionality. [Govind] I do agree that we can optimize CARD if we know FMIP (I think you mean v6) is going to be available in the subnet. However, CARD is needed to operate in domains that are not IPv6. I would think the better way to go is FMIP and other seamless mobility protocols were to use CARD messages for this purpose. I think this was pointed out in an email on the mobile-ip working group. 3) I can't really see the point of introducing a new inter-router protocol of this sort. I believe this would be better handled by defining some kind of OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a proposal, however. In any case, it needs investigation and should be moved into a separate document if it proves to be of interest. [Govind] Could you explain why you would think it should be an OSPF extension? Do we have to bring OSPF/IS-IS into this? The routers are sending packets to each other like any other packets,just like FMIPv6 or CT has messages between ARs, to enable protocol functionality. Why is this any different? I think this is very important and helps provide a major functionality and it does belong in this document. Maybe I'm missing something. 4) I disagree with the contention of some that this protocol is introducing a new network element. Any large scale enterprise or ISP network is going to have configuration in it, and this protocol is essentially defining a way to do configuration. For small, home networks, this might not be required, because it might be done using a Web interface to the firewall/access point. The proposed solution in this draft is fairly vague, but I can see a couple of possible dispositions: a) Define a RADIUS extension like that used by IAPP. b) Define an LDAP schema for access point configuration information. c) Define an SNMP MIB that allows a router to obtain this information from another router. I believe 802.11 has its own MIB, but we are talking about something that is more generic. I've got no opinion about which of these would be better, and there could be other possibilities. We should decide fairly quickly which we want to pursue. [Govind] Do you think any of the methods that you suggest are worth the effort for the purpose the CARD server is designated to do? Plus, using a CARD server introduces the possibility of DoS on the CARD server itself. I think this is one direction that we do not need to go, the cost heavily outweighs the benefit, IMO. Technical Comments --------------------- Section 3.2: Highly dynamic capabilites should be out of scope. Also, in paragraph 2, what are downlink channels? Not all wireless protocols will have these. [Govind] First, I don't know what you mean by highly dynamic capabilities. Can you give some examples? I think the Issues draft does make the distinction between capabilities as dynamic and static but not on the level of dynamicity in the capabilities. So why bring a new level of distinction now? Second, regardless of the level of dyamicity of the capabilities in question, the basic capability transfer remains the same. The state times out and it is refreshed. Third, the draft does not go into saying what capabilities are going to be put in. All it defines is the framework for capability transfer. So what are you trying to remove here? Are you saying that you want to remove the function of the protocol that deals with dynamic capabilities? This I disagree with. [snip] Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, itself, subject to DOS attacks. The solutions presented in Section 6.3 for handling these problems are much more streamlined and align with IP network softstate approach: 1) The protocol specifies a minimum interarrival time for sending requests. 2) The protocol specifies a minimum reply time for routers replying. If too many requests arrive, the router begins to selectively drop so hosts have to retransmit. 3) A default cache lifetime is defined. After this time, the router times out the cache entry. 4) An entry presented by the MN gets a preference level. The more times it is reported by another MN, the less likely it is to time out. This needs to be quantified and described as an algorthm. These elements need to be added to the protocol draft for 1) in the meta-issues section. [Govind] The scope-id solution has several questions regarding effectiveness and I have pointed them out in my earlier email. Having said that, none of the methodologies that you suggest above really help that much in alleviating DoS attacks either. IP spoofing will counter all of the checks is it not? One more thing that is missing in the DT draft is providing CARD services to ARs that have private addresses, i.e. Requirement 3.3. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 12:15:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29763 for ; Thu, 6 Mar 2003 12:15:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HPYO25653; Thu, 6 Mar 2003 12:25:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HJKO24689 for ; Thu, 6 Mar 2003 12:19:20 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29016 for ; Thu, 6 Mar 2003 12:07:41 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26H9la05644 for ; Thu, 6 Mar 2003 11:09:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 11:09:44 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 09:09:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 12:09:43 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLjfDxvkIENi3bnTO2+D+396PVpHAAdN47A To: , X-OriginalArrivalTime: 06 Mar 2003 17:09:44.0458 (UTC) FILETIME=[2F035EA0:01C2E403] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26HJKO24690 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Jim, Some comments embedded inline. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 05, 2003 8:01 PM To: seamoby@ietf.org Subject: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt [snip] dropping 2) and making this signaling a collection of options on FMIP. In addition, I would suggest that the CARD design team co-ordinate this with the current editor of the FMIP draft. There is no point in having 2) if FMIP provides the functionality. [Govind] I do agree that we can optimize CARD if we know FMIP (I think you mean v6) is going to be available in the subnet. However, CARD is needed to operate in domains that are not IPv6. I would think the better way to go is FMIP and other seamless mobility protocols were to use CARD messages for this purpose. I think this was pointed out in an email on the mobile-ip working group. 3) I can't really see the point of introducing a new inter-router protocol of this sort. I believe this would be better handled by defining some kind of OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a proposal, however. In any case, it needs investigation and should be moved into a separate document if it proves to be of interest. [Govind] Could you explain why you would think it should be an OSPF extension? Do we have to bring OSPF/IS-IS into this? The routers are sending packets to each other like any other packets,just like FMIPv6 or CT has messages between ARs, to enable protocol functionality. Why is this any different? I think this is very important and helps provide a major functionality and it does belong in this document. Maybe I'm missing something. 4) I disagree with the contention of some that this protocol is introducing a new network element. Any large scale enterprise or ISP network is going to have configuration in it, and this protocol is essentially defining a way to do configuration. For small, home networks, this might not be required, because it might be done using a Web interface to the firewall/access point. The proposed solution in this draft is fairly vague, but I can see a couple of possible dispositions: a) Define a RADIUS extension like that used by IAPP. b) Define an LDAP schema for access point configuration information. c) Define an SNMP MIB that allows a router to obtain this information from another router. I believe 802.11 has its own MIB, but we are talking about something that is more generic. I've got no opinion about which of these would be better, and there could be other possibilities. We should decide fairly quickly which we want to pursue. [Govind] Do you think any of the methods that you suggest are worth the effort for the purpose the CARD server is designated to do? Plus, using a CARD server introduces the possibility of DoS on the CARD server itself. I think this is one direction that we do not need to go, the cost heavily outweighs the benefit, IMO. Technical Comments --------------------- Section 3.2: Highly dynamic capabilites should be out of scope. Also, in paragraph 2, what are downlink channels? Not all wireless protocols will have these. [Govind] First, I don't know what you mean by highly dynamic capabilities. Can you give some examples? I think the Issues draft does make the distinction between capabilities as dynamic and static but not on the level of dynamicity in the capabilities. So why bring a new level of distinction now? Second, regardless of the level of dyamicity of the capabilities in question, the basic capability transfer remains the same. The state times out and it is refreshed. Third, the draft does not go into saying what capabilities are going to be put in. All it defines is the framework for capability transfer. So what are you trying to remove here? Are you saying that you want to remove the function of the protocol that deals with dynamic capabilities? This I disagree with. [snip] Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, itself, subject to DOS attacks. The solutions presented in Section 6.3 for handling these problems are much more streamlined and align with IP network softstate approach: 1) The protocol specifies a minimum interarrival time for sending requests. 2) The protocol specifies a minimum reply time for routers replying. If too many requests arrive, the router begins to selectively drop so hosts have to retransmit. 3) A default cache lifetime is defined. After this time, the router times out the cache entry. 4) An entry presented by the MN gets a preference level. The more times it is reported by another MN, the less likely it is to time out. This needs to be quantified and described as an algorthm. These elements need to be added to the protocol draft for 1) in the meta-issues section. [Govind] The scope-id solution has several questions regarding effectiveness and I have pointed them out in my earlier email. Having said that, none of the methodologies that you suggest above really help that much in alleviating DoS attacks either. IP spoofing will counter all of the checks is it not? One more thing that is missing in the DT draft is providing CARD services to ARs that have private addresses, i.e. Requirement 3.3. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 12:58:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03230 for ; Thu, 6 Mar 2003 12:58:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26I9dY31250 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 13:09:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26I9dO31247 for ; Thu, 6 Mar 2003 13:09:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03217 for ; Thu, 6 Mar 2003 12:58:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26I9NO31231; Thu, 6 Mar 2003 13:09:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26I83O31185 for ; Thu, 6 Mar 2003 13:08:03 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03190 for ; Thu, 6 Mar 2003 12:56:24 -0500 (EST) Message-ID: <014701c2e409$c7938e50$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 09:56:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > dropping 2) > and making this signaling a collection of options on FMIP. In addition, I would > suggest that the CARD design team co-ordinate this with the current editor of > the FMIP draft. There is no point in having 2) if FMIP provides the > functionality. > > [Govind] > I do agree that we can optimize CARD if we know FMIP (I think you mean v6) > is going to be available in the subnet. However, CARD is needed to operate in domains > that are not IPv6. I would think the better way to go is FMIP and other seamless > mobility protocols were to use CARD messages for this purpose. I think this was > pointed out in an email on the mobile-ip working group. > I would argue that events have overtaken us and CARD is no longer relevant for IPv4 from a market perspective. Certainly, this is the case with other advanced IP mobility technologies, like the fast handover technologies CARD was supposed to support. I believe it makes more sense to have CARD be a well-integrated part of the local link movement protocols for IPv6, where there is still some interest in technology development on advanced IP mobility technologies. > > 3) I can't really see the point of introducing a new inter-router protocol of > this sort. I believe this would be better handled by defining some kind of > OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a > proposal, however. In any case, it needs investigation and should be moved into > a separate document if it proves to be of interest. > > [Govind] Could you explain why you would think it should be an OSPF extension? > Do we have to bring OSPF/IS-IS into this? The routers are sending packets to each > other like any other packets,just like FMIPv6 or CT has messages between ARs, to enable > protocol functionality. Why is this any different? I think this is very important > and helps provide a major functionality and it does belong in this document. Maybe > I'm missing something. > First off, I'm not convinced even an OSPF extension would be the right approach. Like I said, we need to talk with the Routing Area Directors to see what they say. However, what suggests that it is a better approach is that the information being conveyed is not real time, that is, it is not connected to handover. It will vary slowly as access points are introduced or brought down. Thus, it is in the same category as standard routing reachability information distributed by the IGPs, and not like CT or handover. > 4) I disagree with the contention of some that this protocol is introducing a > new network element. Any large scale enterprise or ISP network is going to have > configuration in it, and this protocol is essentially defining a way to do > configuration. For small, home networks, this might not be required, because it > might be done using a Web interface to the firewall/access point. The proposed > solution in this draft is fairly vague, but I can see a couple of possible > dispositions: > a) Define a RADIUS extension like that used by IAPP. > b) Define an LDAP schema for access point configuration information. > c) Define an SNMP MIB that allows a router to obtain this information from > another router. > I believe 802.11 has its own MIB, but we are talking about something that is > more generic. I've got no opinion about which of these would be better, and > there could be other possibilities. We should decide fairly quickly which we > want to pursue. > > [Govind] Do you think any of the methods that you suggest are > worth the effort for the purpose the CARD server is designated to do? Plus, > using a CARD server introduces the possibility of DoS on the CARD server itself. > I think this is one direction that we do not need to go, the cost heavily outweighs > the benefit, IMO. > Servers are used all the time for PKI. There is an article in this month's ACM Communications about how servers are used for PKI. They are used to configure routers, IPsec gateways, etc. Typically, LDAP is the protocol. A DoS attack is easy to foil: put a rule in the firewall that disallows any external traffic to the server. Also, don't advertise the address of the server outside the access router. From an enterprise/ISP standpoint, tying CARD configuration to a server in a standardized way might help to speed deployment. This component should not be a required part of the router to host protocol, though, because the router to host protocol could also be deployed in a small office or home environment with a Web configuration. That's why I think it should be in a separate document. > > Technical Comments > --------------------- > > Section 3.2: Highly dynamic capabilites should be out of scope. Also, in > paragraph 2, what are downlink channels? Not all wireless protocols will have > these. > > [Govind] First, I don't know what you mean by highly dynamic capabilities. Can > you give some examples? I think the Issues draft does make the distinction between capabilities > as dynamic and static but not on the level of dynamicity in the capabilities. So why bring a new > level of distinction now? I didn't make the distinction, it was in the draft. I think it should be removed. > Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, > itself, subject to DOS attacks. The solutions presented in Section 6.3 for > handling these problems are much more streamlined and align with IP network > softstate approach: > 1) The protocol specifies a minimum interarrival time for sending requests. > 2) The protocol specifies a minimum reply time for routers replying. If too > many requests arrive, the router begins to selectively drop so hosts have to > retransmit. > 3) A default cache lifetime is defined. After this time, the router times > out the cache entry. > 4) An entry presented by the MN gets a preference level. The more times it is > reported by another MN, the less likely it is to time out. This needs to be > quantified and described as an algorthm. > These elements need to be added to the protocol draft for 1) in the meta-issues > section. > > [Govind] > The scope-id solution has several questions regarding effectiveness and > I have pointed them out in my earlier email. Having said that, none of the methodologies > that you suggest above really help that much > in alleviating DoS attacks either. IP spoofing will counter all of the checks is it not? > If the router starts dropping requests when they come in too quickly, then it will look to clients like it is responding more slowly, but the attacker will not succeed in completely disrupting service. That is what is meant by 2). In addition to these measures, I think the draft should specify that standard ND security including SEND is used on the protocol. This should completely eliminate the possibility of IP spoofing. > > One more thing that is missing in the DT draft is providing CARD services to ARs that > have private addresses, i.e. Requirement 3.3. > > > If the IPv4 requirement is dropped, I don't think this is necessary. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 12:59:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03265 for ; Thu, 6 Mar 2003 12:59:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26I9NO31231; Thu, 6 Mar 2003 13:09:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26I83O31185 for ; Thu, 6 Mar 2003 13:08:03 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03190 for ; Thu, 6 Mar 2003 12:56:24 -0500 (EST) Message-ID: <014701c2e409$c7938e50$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 09:56:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > dropping 2) > and making this signaling a collection of options on FMIP. In addition, I would > suggest that the CARD design team co-ordinate this with the current editor of > the FMIP draft. There is no point in having 2) if FMIP provides the > functionality. > > [Govind] > I do agree that we can optimize CARD if we know FMIP (I think you mean v6) > is going to be available in the subnet. However, CARD is needed to operate in domains > that are not IPv6. I would think the better way to go is FMIP and other seamless > mobility protocols were to use CARD messages for this purpose. I think this was > pointed out in an email on the mobile-ip working group. > I would argue that events have overtaken us and CARD is no longer relevant for IPv4 from a market perspective. Certainly, this is the case with other advanced IP mobility technologies, like the fast handover technologies CARD was supposed to support. I believe it makes more sense to have CARD be a well-integrated part of the local link movement protocols for IPv6, where there is still some interest in technology development on advanced IP mobility technologies. > > 3) I can't really see the point of introducing a new inter-router protocol of > this sort. I believe this would be better handled by defining some kind of > OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a > proposal, however. In any case, it needs investigation and should be moved into > a separate document if it proves to be of interest. > > [Govind] Could you explain why you would think it should be an OSPF extension? > Do we have to bring OSPF/IS-IS into this? The routers are sending packets to each > other like any other packets,just like FMIPv6 or CT has messages between ARs, to enable > protocol functionality. Why is this any different? I think this is very important > and helps provide a major functionality and it does belong in this document. Maybe > I'm missing something. > First off, I'm not convinced even an OSPF extension would be the right approach. Like I said, we need to talk with the Routing Area Directors to see what they say. However, what suggests that it is a better approach is that the information being conveyed is not real time, that is, it is not connected to handover. It will vary slowly as access points are introduced or brought down. Thus, it is in the same category as standard routing reachability information distributed by the IGPs, and not like CT or handover. > 4) I disagree with the contention of some that this protocol is introducing a > new network element. Any large scale enterprise or ISP network is going to have > configuration in it, and this protocol is essentially defining a way to do > configuration. For small, home networks, this might not be required, because it > might be done using a Web interface to the firewall/access point. The proposed > solution in this draft is fairly vague, but I can see a couple of possible > dispositions: > a) Define a RADIUS extension like that used by IAPP. > b) Define an LDAP schema for access point configuration information. > c) Define an SNMP MIB that allows a router to obtain this information from > another router. > I believe 802.11 has its own MIB, but we are talking about something that is > more generic. I've got no opinion about which of these would be better, and > there could be other possibilities. We should decide fairly quickly which we > want to pursue. > > [Govind] Do you think any of the methods that you suggest are > worth the effort for the purpose the CARD server is designated to do? Plus, > using a CARD server introduces the possibility of DoS on the CARD server itself. > I think this is one direction that we do not need to go, the cost heavily outweighs > the benefit, IMO. > Servers are used all the time for PKI. There is an article in this month's ACM Communications about how servers are used for PKI. They are used to configure routers, IPsec gateways, etc. Typically, LDAP is the protocol. A DoS attack is easy to foil: put a rule in the firewall that disallows any external traffic to the server. Also, don't advertise the address of the server outside the access router. From an enterprise/ISP standpoint, tying CARD configuration to a server in a standardized way might help to speed deployment. This component should not be a required part of the router to host protocol, though, because the router to host protocol could also be deployed in a small office or home environment with a Web configuration. That's why I think it should be in a separate document. > > Technical Comments > --------------------- > > Section 3.2: Highly dynamic capabilites should be out of scope. Also, in > paragraph 2, what are downlink channels? Not all wireless protocols will have > these. > > [Govind] First, I don't know what you mean by highly dynamic capabilities. Can > you give some examples? I think the Issues draft does make the distinction between capabilities > as dynamic and static but not on the level of dynamicity in the capabilities. So why bring a new > level of distinction now? I didn't make the distinction, it was in the draft. I think it should be removed. > Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, > itself, subject to DOS attacks. The solutions presented in Section 6.3 for > handling these problems are much more streamlined and align with IP network > softstate approach: > 1) The protocol specifies a minimum interarrival time for sending requests. > 2) The protocol specifies a minimum reply time for routers replying. If too > many requests arrive, the router begins to selectively drop so hosts have to > retransmit. > 3) A default cache lifetime is defined. After this time, the router times > out the cache entry. > 4) An entry presented by the MN gets a preference level. The more times it is > reported by another MN, the less likely it is to time out. This needs to be > quantified and described as an algorthm. > These elements need to be added to the protocol draft for 1) in the meta-issues > section. > > [Govind] > The scope-id solution has several questions regarding effectiveness and > I have pointed them out in my earlier email. Having said that, none of the methodologies > that you suggest above really help that much > in alleviating DoS attacks either. IP spoofing will counter all of the checks is it not? > If the router starts dropping requests when they come in too quickly, then it will look to clients like it is responding more slowly, but the attacker will not succeed in completely disrupting service. That is what is meant by 2). In addition to these measures, I think the draft should specify that standard ND security including SEND is used on the protocol. This should completely eliminate the possibility of IP spoofing. > > One more thing that is missing in the DT draft is providing CARD services to ARs that > have private addresses, i.e. Requirement 3.3. > > > If the IPv4 requirement is dropped, I don't think this is necessary. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 13:08:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03937 for ; Thu, 6 Mar 2003 13:08:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26IJJe31967 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 13:19:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IJJO31964 for ; Thu, 6 Mar 2003 13:19:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03917 for ; Thu, 6 Mar 2003 13:07:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IJ5O31951; Thu, 6 Mar 2003 13:19:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IIvO31919 for ; Thu, 6 Mar 2003 13:18:57 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03852 for ; Thu, 6 Mar 2003 13:07:18 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26I9M825196 for ; Thu, 6 Mar 2003 12:09:22 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 12:09:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 10:09:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 13:09:21 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkCj1Y5+Cj6CpZSxmsRUpGe6xnXQAADd3Q To: , , X-OriginalArrivalTime: 06 Mar 2003 18:09:22.0402 (UTC) FILETIME=[83A24C20:01C2E40B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26IIvO31920 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, >Servers are used all the time for PKI. There is an article in >this month's ACM >Communications about how servers are used for PKI. They are >used to configure >routers, IPsec gateways, etc. Typically, LDAP is the protocol. >A DoS attack is >easy to foil: put a rule in the firewall that disallows any >external traffic to >the server. Also, don't advertise the address of the server >outside the access >router. In the context of the DT document, a possible DoS attack does not even consider attacks from outside of the domain directed towards the server as such, but inherently through the protocol operation involving the server. Namely, a malicious MN is contaminating the cache entries of the AP through falsified L2-L3 mapping requests, i.e., through the cache population mechanism that is the basis of the server approach. Firewalls won't help here! > >From an enterprise/ISP standpoint, tying CARD configuration to >a server in a >standardized way might help to speed deployment. Hmm, wouldn't deployment even more speed up if we didn't have a server at all?? The question is not whether or not a server would hinder deployment but whether or not a server is necessary at all. I still don't see a convincing argument for this. The DT draft does not give one, and the current discussion hasn't either. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 13:08:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03985 for ; Thu, 6 Mar 2003 13:08:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IJ5O31951; Thu, 6 Mar 2003 13:19:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IIvO31919 for ; Thu, 6 Mar 2003 13:18:57 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03852 for ; Thu, 6 Mar 2003 13:07:18 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26I9M825196 for ; Thu, 6 Mar 2003 12:09:22 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 12:09:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 10:09:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 13:09:21 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkCj1Y5+Cj6CpZSxmsRUpGe6xnXQAADd3Q To: , , X-OriginalArrivalTime: 06 Mar 2003 18:09:22.0402 (UTC) FILETIME=[83A24C20:01C2E40B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26IIvO31920 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, >Servers are used all the time for PKI. There is an article in >this month's ACM >Communications about how servers are used for PKI. They are >used to configure >routers, IPsec gateways, etc. Typically, LDAP is the protocol. >A DoS attack is >easy to foil: put a rule in the firewall that disallows any >external traffic to >the server. Also, don't advertise the address of the server >outside the access >router. In the context of the DT document, a possible DoS attack does not even consider attacks from outside of the domain directed towards the server as such, but inherently through the protocol operation involving the server. Namely, a malicious MN is contaminating the cache entries of the AP through falsified L2-L3 mapping requests, i.e., through the cache population mechanism that is the basis of the server approach. Firewalls won't help here! > >From an enterprise/ISP standpoint, tying CARD configuration to >a server in a >standardized way might help to speed deployment. Hmm, wouldn't deployment even more speed up if we didn't have a server at all?? The question is not whether or not a server would hinder deployment but whether or not a server is necessary at all. I still don't see a convincing argument for this. The DT draft does not give one, and the current discussion hasn't either. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 13:18:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04468 for ; Thu, 6 Mar 2003 13:18:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26ITWT32698 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 13:29:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ITWO32695 for ; Thu, 6 Mar 2003 13:29:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04436 for ; Thu, 6 Mar 2003 13:17:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ITBO32650; Thu, 6 Mar 2003 13:29:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ISCO32592 for ; Thu, 6 Mar 2003 13:28:12 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04354 for ; Thu, 6 Mar 2003 13:16:32 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h26IIa6N014294 for ; Thu, 6 Mar 2003 11:18:36 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA02687 for ; Thu, 6 Mar 2003 11:18:36 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 12:18:36 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE32@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 12:18:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Wednesday, March 05, 2003 12:58 PM To: Ajoy Singh; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Ajoy, Comments inline. Thanks for your reply. -Govind. AJOY-> We are aware of this. What is the status of requirement draft? Is it approved by IESG yet. Probably we need to change this requirement in case WG likes to go with server based approach. [Govind] The requirements document has passed last WG last call. The IESG did come back with one set of comments, but I don't think they had any problems with this particular requirement in those comments. [snip] This depends upon the cache timeout as well as handoff traffic. BTW, the server based approach is easier to manage as well it provides extra security. If we deploy scope-id with serve based approach, then it is very much possible to reduce or even eliminate the problem of cache contamination. This also minimizes the affect DoS attack. [Govind] The cache timeout can be handled quite easily. AJOY-> I meant every time cache times out, your proposed scheme (dycard) will perform slow handoff. But in case of server based approach this may not be the case. In server based approach, AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the current AR may not be required to query AR server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entriesthat are not CARs in the cache. In fact, the DT draft acknowledges that the CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a CARD server. AJOY-> The scope-id reduces the cache contamination problem, the potential growth of AR cache is bounded. This will eliminate the problem introduced due to unbounded cache growth. For example, in case of dycard, you might have a situation where the AR cache will overflow if a mobile node keeps injecting wrong information to the AR. This will cause AR to either crash or remove the old useful cache entries. Potentially this will create a situation where AR will loose valid cache entries to populate invalid entries. Is it not correct? [snip] These entries may not be cached for ever. Smaller the cache timeout, the earlier you will be able to detect any change of capability or L2->L3 mapping information. [Govind] So we need to choose a timeout that is appropriate, why do we need a server for this? I still don't understand that. AJOY-> Won't next handoff performed by dycard will be slow after cache timeout? BTW, this is necessarily not a problem with server based approach. The AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the AR may not be required to query CARD server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [snip] I think this will be better than the case where cache entries are solely propagated by the mobile node. I think in the later case, the first handoff will always be the slower. Moreover the later approach is very difficult to manage and is even less secure. [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? AJOY-> This is not the only reason. The server based approach provides centralized configuration. It is also easier to manage. Also, you can deploy scope-id to eliminate the harmful aspect of cache contamination. In this you can eliminate the cache overflow by properly configuring the size of AR cache. Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. AJOY-> The scope-id enables you to avoid cache overflow problem. If you do not have scope-id defined, some malicious MN will able to inject the fake messages to AR that would increase the size of cache to unexpectedly large value. Depending upon the caching policy, AR may either discard the useful cache information to store fake entries. Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? AJOY-> Could you please explain how dycard plans to avoid the problem of cache overflow? Lastly, as I pointed out in my earlier mail, we have provided a method, in an earlier version of the draft, that makes the first handover also seamless in a probabilistic sense. I don't think DT draft can promise better than that too. We omitted this, because we felt that it doesn't make much sense in the steady state of the system. Basically a cost vs. benefit analysis. ----------* [snip] BTW-> The IP packets are not routed via CARD server so I am not sure if it a big drawback. [Govind] You need the CARD server for any translation on a cache miss. So what is this that you bring about routing packets via CARD server? I'm completely missing your point here. AJOY-> It is relatively inexpensive to provide redundancy of a server that only does L2->L3 mapping. This function can be easily piggybacked upon existing high availability server platform. -----------------------* I will be more concerned about the single point of failure where IP packets are routed through it. CARD server will provide a similar function as DNS server So, probably it is not a big drawback in my understanding. [Govind] Does this imply that the functionality of the CARD server is minimal? We are talking about the "central" point of control here that determines the cache entries. I think it a very important point to consider. AJOY-> See previous reply. ---------------------------* On the other handoff, server based approach provides better manageability as well control. [Govind] What manageability are you talking about? You assume that each AR knows what APs it has. Why should it be conveyed to the CARD server? Why can't it be conveyed directly to its CARs? Also, what lack of manageability that you perceive in dycard? Can we talk quantitatively rather qualitatively here? AJOY-> The server based approach also allows the server to store L2->L3 mapping, scope-id and static capabilities. It is very easy to manage these information if it stored at single point. Managing such information in distributed case is difficult. As I mentioned above, with clever use of scope-id, it is possible to reduce the affect of DoS attack as well as cache contamination problem. [Govind] Could you define "clever" use of scope-id? Quoting from the draft "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". AJOY-> The scope-id can also be manually configured at server. In this case if any AR tries to resolve the link layer id belonging to AR whose scope-id does not match the requester's scope-id, server can simply reject the request. Also, you can properly configure the size of AR cache if you know how many AR's are covered by the given scope-id. BTW, I do admit we need to clarify the proper use of scope-id in the draft From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. [snip] Probably you are right. We do need to get consensus from AAA group for doing this. BTW, If we use AAA server, then it is also possible to use AAA server for the purpose of key distribution. I would like to receive feedback from other members of WG about the potential use of AAA server as CARD server. [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? AJOY-> BTW, the AAA server is widely used in access network. So, I do not see why are you so much opposed to this? I think the AAA server based key distribution may be useful in inter-domain case. BTW, I am flexible in this and NOT proposing that key distribution MUST be done through AAA server. I am just looking for others' opinion about it. [snip] I am not sure I agree with you here. Could you provide some additional detail why you think scope id is complicated? [Govind]I'll let you know if I come up with something more, than what I've provided in my previous email. AJOY-> Ok, it will be helpful. Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. Let be focused now. [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with a solution that works well now, and also has a good chance of being accepted later. AJOY-> I do not agree with your conclusion. The server based approach (DNS) has been widely deployed in Internet name->address resolution. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 13:18:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04479 for ; Thu, 6 Mar 2003 13:18:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26ITXg32715 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 13:29:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ITWO32712 for ; Thu, 6 Mar 2003 13:29:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04438 for ; Thu, 6 Mar 2003 13:17:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ITEO32668; Thu, 6 Mar 2003 13:29:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ISjO32628 for ; Thu, 6 Mar 2003 13:28:45 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04393 for ; Thu, 6 Mar 2003 13:17:05 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26IJ9827306 for ; Thu, 6 Mar 2003 12:19:09 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 12:19:05 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 10:18:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 13:18:26 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkCgqD5WCCiRVkSSeLWUEWpdQVkgAACBJA To: , X-OriginalArrivalTime: 06 Mar 2003 18:18:27.0206 (UTC) FILETIME=[C85CCA60:01C2E40C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26ISjO32629 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, I would argue that events have overtaken us and CARD is no longer relevant for IPv4 from a market perspective. Certainly, this is the case with other advanced IP mobility technologies, like the fast handover technologies CARD was supposed to support. I believe it makes more sense to have CARD be a well-integrated part of the local link movement protocols for IPv6, where there is still some interest in technology development on advanced IP mobility technologies. [Govind] GPRS, for example is still a technology for the near future. I think GPRS is based on IPv4 at least now. I agree that CARD should be IPv6 amenable but neglecting IPv4 is not correct. I disagree. > > 3) I can't really see the point of introducing a new inter-router protocol of > this sort. I believe this would be better handled by defining some kind of > OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a > proposal, however. In any case, it needs investigation and should be moved into > a separate document if it proves to be of interest. > > [Govind] Could you explain why you would think it should be an OSPF extension? > Do we have to bring OSPF/IS-IS into this? The routers are sending packets to each > other like any other packets,just like FMIPv6 or CT has messages between ARs, to enable > protocol functionality. Why is this any different? I think this is very important > and helps provide a major functionality and it does belong in this document. Maybe > I'm missing something. > First off, I'm not convinced even an OSPF extension would be the right approach. Like I said, we need to talk with the Routing Area Directors to see what they say. However, what suggests that it is a better approach is that the information being conveyed is not real time, that is, it is not connected to handover. It will vary slowly as access points are introduced or brought down. Thus, it is in the same category as standard routing reachability information distributed by the IGPs, and not like CT or handover. [Govind] First, I don't think this a real time. Information transferred between does not comprise only of the example that you talk about network topology change. Hence I don't think we can tie everything to routing reachability information like you say above. > 4) I disagree with the contention of some that this protocol is introducing a > new network element. Any large scale enterprise or ISP network is going to have > configuration in it, and this protocol is essentially defining a way to do > configuration. For small, home networks, this might not be required, because it > might be done using a Web interface to the firewall/access point. The proposed > solution in this draft is fairly vague, but I can see a couple of possible > dispositions: > a) Define a RADIUS extension like that used by IAPP. > b) Define an LDAP schema for access point configuration information. > c) Define an SNMP MIB that allows a router to obtain this information from > another router. > I believe 802.11 has its own MIB, but we are talking about something that is > more generic. I've got no opinion about which of these would be better, and > there could be other possibilities. We should decide fairly quickly which we > want to pursue. > > [Govind] Do you think any of the methods that you suggest are > worth the effort for the purpose the CARD server is designated to do? Plus, > using a CARD server introduces the possibility of DoS on the CARD server itself. > I think this is one direction that we do not need to go, the cost heavily outweighs > the benefit, IMO. > Servers are used all the time for PKI. There is an article in this month's ACM Communications about how servers are used for PKI. They are used to configure routers, IPsec gateways, etc. Typically, LDAP is the protocol. A DoS attack is easy to foil: put a rule in the firewall that disallows any external traffic to the server. Also, don't advertise the address of the server outside the access router. [Govind]Even though is also manual configuration possible for PKI, I don't disagree with PKI using servers (LDAP is just one way of doing it). What I disagree is with your notion that just because PKI uses it, CARD should use it too. There is no need to do this. [Govind] DoS attack is possible because, the traffic is not coming from the external source, it is coming from an authenticated access router because it is not able to translate a particular AP to an AR. From an enterprise/ISP standpoint, tying CARD configuration to a server in a standardized way might help to speed deployment. This component should not be a required part of the router to host protocol, though, because the router to host protocol could also be deployed in a small office or home environment with a Web configuration. That's why I think it should be in a separate document. [Govind] This is not true. The server approach needs a cache at ARs anyways. So what ease are you talking about. By removing the server how does the protocol become easier to deploy? This seems counter intutive to me. Are you saying that ISPs will allow caches to be present at ARs only they have a server too? > > Technical Comments > --------------------- > > Section 3.2: Highly dynamic capabilites should be out of scope. Also, in > paragraph 2, what are downlink channels? Not all wireless protocols will have > these. > > [Govind] First, I don't know what you mean by highly dynamic capabilities. Can > you give some examples? I think the Issues draft does make the distinction between capabilities > as dynamic and static but not on the level of dynamicity in the capabilities. So why bring a new > level of distinction now? I didn't make the distinction, it was in the draft. I think it should be removed. [Govind] ok. > Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, > itself, subject to DOS attacks. The solutions presented in Section 6.3 for > handling these problems are much more streamlined and align with IP network > softstate approach: > 1) The protocol specifies a minimum interarrival time for sending requests. > 2) The protocol specifies a minimum reply time for routers replying. If too > many requests arrive, the router begins to selectively drop so hosts have to > retransmit. > 3) A default cache lifetime is defined. After this time, the router times > out the cache entry. > 4) An entry presented by the MN gets a preference level. The more times it is > reported by another MN, the less likely it is to time out. This needs to be > quantified and described as an algorthm. > These elements need to be added to the protocol draft for 1) in the meta-issues > section. > > [Govind] > The scope-id solution has several questions regarding effectiveness and > I have pointed them out in my earlier email. Having said that, none of the methodologies > that you suggest above really help that much > in alleviating DoS attacks either. IP spoofing will counter all of the checks is it not? > If the router starts dropping requests when they come in too quickly, then it will look to clients like it is responding more slowly, but the attacker will not succeed in completely disrupting service. That is what is meant by 2). [Govind] I feel that there are better, possibly not difficult, ways to make any DoS attack really hard to materialize. In addition to these measures, I think the draft should specify that standard ND security including SEND is used on the protocol. This should completely eliminate the possibility of IP spoofing. [Govind] I have to read up on this before I can respond to you. > > One more thing that is missing in the DT draft is providing CARD services to ARs that > have private addresses, i.e. Requirement 3.3. > > > If the IPv4 requirement is dropped, I don't think this is necessary. [Govind] First, I don't think the IPv4 should be dropped. Secondly, I think site-local addresses in IPv6 is also covered by this requirement. Third, I think non global routeability may not be just for the sake of lack of addresses, it may be for other reasons too, like security, as you probably know. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 13:18:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04510 for ; Thu, 6 Mar 2003 13:18:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ITEO32668; Thu, 6 Mar 2003 13:29:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ISjO32628 for ; Thu, 6 Mar 2003 13:28:45 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04393 for ; Thu, 6 Mar 2003 13:17:05 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26IJ9827306 for ; Thu, 6 Mar 2003 12:19:09 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 12:19:05 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 10:18:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 13:18:26 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkCgqD5WCCiRVkSSeLWUEWpdQVkgAACBJA To: , X-OriginalArrivalTime: 06 Mar 2003 18:18:27.0206 (UTC) FILETIME=[C85CCA60:01C2E40C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26ISjO32629 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, I would argue that events have overtaken us and CARD is no longer relevant for IPv4 from a market perspective. Certainly, this is the case with other advanced IP mobility technologies, like the fast handover technologies CARD was supposed to support. I believe it makes more sense to have CARD be a well-integrated part of the local link movement protocols for IPv6, where there is still some interest in technology development on advanced IP mobility technologies. [Govind] GPRS, for example is still a technology for the near future. I think GPRS is based on IPv4 at least now. I agree that CARD should be IPv6 amenable but neglecting IPv4 is not correct. I disagree. > > 3) I can't really see the point of introducing a new inter-router protocol of > this sort. I believe this would be better handled by defining some kind of > OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a > proposal, however. In any case, it needs investigation and should be moved into > a separate document if it proves to be of interest. > > [Govind] Could you explain why you would think it should be an OSPF extension? > Do we have to bring OSPF/IS-IS into this? The routers are sending packets to each > other like any other packets,just like FMIPv6 or CT has messages between ARs, to enable > protocol functionality. Why is this any different? I think this is very important > and helps provide a major functionality and it does belong in this document. Maybe > I'm missing something. > First off, I'm not convinced even an OSPF extension would be the right approach. Like I said, we need to talk with the Routing Area Directors to see what they say. However, what suggests that it is a better approach is that the information being conveyed is not real time, that is, it is not connected to handover. It will vary slowly as access points are introduced or brought down. Thus, it is in the same category as standard routing reachability information distributed by the IGPs, and not like CT or handover. [Govind] First, I don't think this a real time. Information transferred between does not comprise only of the example that you talk about network topology change. Hence I don't think we can tie everything to routing reachability information like you say above. > 4) I disagree with the contention of some that this protocol is introducing a > new network element. Any large scale enterprise or ISP network is going to have > configuration in it, and this protocol is essentially defining a way to do > configuration. For small, home networks, this might not be required, because it > might be done using a Web interface to the firewall/access point. The proposed > solution in this draft is fairly vague, but I can see a couple of possible > dispositions: > a) Define a RADIUS extension like that used by IAPP. > b) Define an LDAP schema for access point configuration information. > c) Define an SNMP MIB that allows a router to obtain this information from > another router. > I believe 802.11 has its own MIB, but we are talking about something that is > more generic. I've got no opinion about which of these would be better, and > there could be other possibilities. We should decide fairly quickly which we > want to pursue. > > [Govind] Do you think any of the methods that you suggest are > worth the effort for the purpose the CARD server is designated to do? Plus, > using a CARD server introduces the possibility of DoS on the CARD server itself. > I think this is one direction that we do not need to go, the cost heavily outweighs > the benefit, IMO. > Servers are used all the time for PKI. There is an article in this month's ACM Communications about how servers are used for PKI. They are used to configure routers, IPsec gateways, etc. Typically, LDAP is the protocol. A DoS attack is easy to foil: put a rule in the firewall that disallows any external traffic to the server. Also, don't advertise the address of the server outside the access router. [Govind]Even though is also manual configuration possible for PKI, I don't disagree with PKI using servers (LDAP is just one way of doing it). What I disagree is with your notion that just because PKI uses it, CARD should use it too. There is no need to do this. [Govind] DoS attack is possible because, the traffic is not coming from the external source, it is coming from an authenticated access router because it is not able to translate a particular AP to an AR. From an enterprise/ISP standpoint, tying CARD configuration to a server in a standardized way might help to speed deployment. This component should not be a required part of the router to host protocol, though, because the router to host protocol could also be deployed in a small office or home environment with a Web configuration. That's why I think it should be in a separate document. [Govind] This is not true. The server approach needs a cache at ARs anyways. So what ease are you talking about. By removing the server how does the protocol become easier to deploy? This seems counter intutive to me. Are you saying that ISPs will allow caches to be present at ARs only they have a server too? > > Technical Comments > --------------------- > > Section 3.2: Highly dynamic capabilites should be out of scope. Also, in > paragraph 2, what are downlink channels? Not all wireless protocols will have > these. > > [Govind] First, I don't know what you mean by highly dynamic capabilities. Can > you give some examples? I think the Issues draft does make the distinction between capabilities > as dynamic and static but not on the level of dynamicity in the capabilities. So why bring a new > level of distinction now? I didn't make the distinction, it was in the draft. I think it should be removed. [Govind] ok. > Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, > itself, subject to DOS attacks. The solutions presented in Section 6.3 for > handling these problems are much more streamlined and align with IP network > softstate approach: > 1) The protocol specifies a minimum interarrival time for sending requests. > 2) The protocol specifies a minimum reply time for routers replying. If too > many requests arrive, the router begins to selectively drop so hosts have to > retransmit. > 3) A default cache lifetime is defined. After this time, the router times > out the cache entry. > 4) An entry presented by the MN gets a preference level. The more times it is > reported by another MN, the less likely it is to time out. This needs to be > quantified and described as an algorthm. > These elements need to be added to the protocol draft for 1) in the meta-issues > section. > > [Govind] > The scope-id solution has several questions regarding effectiveness and > I have pointed them out in my earlier email. Having said that, none of the methodologies > that you suggest above really help that much > in alleviating DoS attacks either. IP spoofing will counter all of the checks is it not? > If the router starts dropping requests when they come in too quickly, then it will look to clients like it is responding more slowly, but the attacker will not succeed in completely disrupting service. That is what is meant by 2). [Govind] I feel that there are better, possibly not difficult, ways to make any DoS attack really hard to materialize. In addition to these measures, I think the draft should specify that standard ND security including SEND is used on the protocol. This should completely eliminate the possibility of IP spoofing. [Govind] I have to read up on this before I can respond to you. > > One more thing that is missing in the DT draft is providing CARD services to ARs that > have private addresses, i.e. Requirement 3.3. > > > If the IPv4 requirement is dropped, I don't think this is necessary. [Govind] First, I don't think the IPv4 should be dropped. Secondly, I think site-local addresses in IPv6 is also covered by this requirement. Third, I think non global routeability may not be just for the sake of lack of addresses, it may be for other reasons too, like security, as you probably know. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 13:19:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04534 for ; Thu, 6 Mar 2003 13:19:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ITBO32650; Thu, 6 Mar 2003 13:29:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ISCO32592 for ; Thu, 6 Mar 2003 13:28:12 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04354 for ; Thu, 6 Mar 2003 13:16:32 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h26IIa6N014294 for ; Thu, 6 Mar 2003 11:18:36 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA02687 for ; Thu, 6 Mar 2003 11:18:36 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 12:18:36 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE32@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 12:18:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Wednesday, March 05, 2003 12:58 PM To: Ajoy Singh; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Ajoy, Comments inline. Thanks for your reply. -Govind. AJOY-> We are aware of this. What is the status of requirement draft? Is it approved by IESG yet. Probably we need to change this requirement in case WG likes to go with server based approach. [Govind] The requirements document has passed last WG last call. The IESG did come back with one set of comments, but I don't think they had any problems with this particular requirement in those comments. [snip] This depends upon the cache timeout as well as handoff traffic. BTW, the server based approach is easier to manage as well it provides extra security. If we deploy scope-id with serve based approach, then it is very much possible to reduce or even eliminate the problem of cache contamination. This also minimizes the affect DoS attack. [Govind] The cache timeout can be handled quite easily. AJOY-> I meant every time cache times out, your proposed scheme (dycard) will perform slow handoff. But in case of server based approach this may not be the case. In server based approach, AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the current AR may not be required to query AR server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entriesthat are not CARs in the cache. In fact, the DT draft acknowledges that the CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a CARD server. AJOY-> The scope-id reduces the cache contamination problem, the potential growth of AR cache is bounded. This will eliminate the problem introduced due to unbounded cache growth. For example, in case of dycard, you might have a situation where the AR cache will overflow if a mobile node keeps injecting wrong information to the AR. This will cause AR to either crash or remove the old useful cache entries. Potentially this will create a situation where AR will loose valid cache entries to populate invalid entries. Is it not correct? [snip] These entries may not be cached for ever. Smaller the cache timeout, the earlier you will be able to detect any change of capability or L2->L3 mapping information. [Govind] So we need to choose a timeout that is appropriate, why do we need a server for this? I still don't understand that. AJOY-> Won't next handoff performed by dycard will be slow after cache timeout? BTW, this is necessarily not a problem with server based approach. The AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the AR may not be required to query CARD server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [snip] I think this will be better than the case where cache entries are solely propagated by the mobile node. I think in the later case, the first handoff will always be the slower. Moreover the later approach is very difficult to manage and is even less secure. [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? AJOY-> This is not the only reason. The server based approach provides centralized configuration. It is also easier to manage. Also, you can deploy scope-id to eliminate the harmful aspect of cache contamination. In this you can eliminate the cache overflow by properly configuring the size of AR cache. Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. AJOY-> The scope-id enables you to avoid cache overflow problem. If you do not have scope-id defined, some malicious MN will able to inject the fake messages to AR that would increase the size of cache to unexpectedly large value. Depending upon the caching policy, AR may either discard the useful cache information to store fake entries. Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? AJOY-> Could you please explain how dycard plans to avoid the problem of cache overflow? Lastly, as I pointed out in my earlier mail, we have provided a method, in an earlier version of the draft, that makes the first handover also seamless in a probabilistic sense. I don't think DT draft can promise better than that too. We omitted this, because we felt that it doesn't make much sense in the steady state of the system. Basically a cost vs. benefit analysis. ----------* [snip] BTW-> The IP packets are not routed via CARD server so I am not sure if it a big drawback. [Govind] You need the CARD server for any translation on a cache miss. So what is this that you bring about routing packets via CARD server? I'm completely missing your point here. AJOY-> It is relatively inexpensive to provide redundancy of a server that only does L2->L3 mapping. This function can be easily piggybacked upon existing high availability server platform. -----------------------* I will be more concerned about the single point of failure where IP packets are routed through it. CARD server will provide a similar function as DNS server So, probably it is not a big drawback in my understanding. [Govind] Does this imply that the functionality of the CARD server is minimal? We are talking about the "central" point of control here that determines the cache entries. I think it a very important point to consider. AJOY-> See previous reply. ---------------------------* On the other handoff, server based approach provides better manageability as well control. [Govind] What manageability are you talking about? You assume that each AR knows what APs it has. Why should it be conveyed to the CARD server? Why can't it be conveyed directly to its CARs? Also, what lack of manageability that you perceive in dycard? Can we talk quantitatively rather qualitatively here? AJOY-> The server based approach also allows the server to store L2->L3 mapping, scope-id and static capabilities. It is very easy to manage these information if it stored at single point. Managing such information in distributed case is difficult. As I mentioned above, with clever use of scope-id, it is possible to reduce the affect of DoS attack as well as cache contamination problem. [Govind] Could you define "clever" use of scope-id? Quoting from the draft "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". AJOY-> The scope-id can also be manually configured at server. In this case if any AR tries to resolve the link layer id belonging to AR whose scope-id does not match the requester's scope-id, server can simply reject the request. Also, you can properly configure the size of AR cache if you know how many AR's are covered by the given scope-id. BTW, I do admit we need to clarify the proper use of scope-id in the draft From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. [snip] Probably you are right. We do need to get consensus from AAA group for doing this. BTW, If we use AAA server, then it is also possible to use AAA server for the purpose of key distribution. I would like to receive feedback from other members of WG about the potential use of AAA server as CARD server. [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? AJOY-> BTW, the AAA server is widely used in access network. So, I do not see why are you so much opposed to this? I think the AAA server based key distribution may be useful in inter-domain case. BTW, I am flexible in this and NOT proposing that key distribution MUST be done through AAA server. I am just looking for others' opinion about it. [snip] I am not sure I agree with you here. Could you provide some additional detail why you think scope id is complicated? [Govind]I'll let you know if I come up with something more, than what I've provided in my previous email. AJOY-> Ok, it will be helpful. Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. Let be focused now. [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with a solution that works well now, and also has a good chance of being accepted later. AJOY-> I do not agree with your conclusion. The server based approach (DNS) has been widely deployed in Internet name->address resolution. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 13:34:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05078 for ; Thu, 6 Mar 2003 13:34:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26IjWI01966 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 13:45:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IjWO01963 for ; Thu, 6 Mar 2003 13:45:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05068 for ; Thu, 6 Mar 2003 13:33:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IjDO01927; Thu, 6 Mar 2003 13:45:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Ib5O00846 for ; Thu, 6 Mar 2003 13:37:05 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04818 for ; Thu, 6 Mar 2003 13:25:25 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h26IRTdG021365 for ; Thu, 6 Mar 2003 11:27:29 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA23670 for ; Thu, 6 Mar 2003 11:27:29 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 12:26:41 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE33@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Dirk.Trossen@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 12:26:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> You please see my reply to Govind. OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 13:34:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05139 for ; Thu, 6 Mar 2003 13:34:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IjDO01927; Thu, 6 Mar 2003 13:45:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Ib5O00846 for ; Thu, 6 Mar 2003 13:37:05 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04818 for ; Thu, 6 Mar 2003 13:25:25 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h26IRTdG021365 for ; Thu, 6 Mar 2003 11:27:29 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA23670 for ; Thu, 6 Mar 2003 11:27:29 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 12:26:41 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE33@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Dirk.Trossen@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 12:26:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> You please see my reply to Govind. OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 13:45:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05693 for ; Thu, 6 Mar 2003 13:45:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26IuOp02822 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 13:56:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IuOO02819 for ; Thu, 6 Mar 2003 13:56:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05669 for ; Thu, 6 Mar 2003 13:44:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IuDO02805; Thu, 6 Mar 2003 13:56:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ItxO02780 for ; Thu, 6 Mar 2003 13:55:59 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05638 for ; Thu, 6 Mar 2003 13:44:19 -0500 (EST) Message-ID: <017801c2e410$799cbd00$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 10:44:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > In the context of the DT document, a possible DoS attack does not > even consider attacks from outside of the domain directed towards the > server as such, but inherently through the protocol operation involving the > server. Namely, a malicious MN is contaminating the cache entries of the AP > through falsified L2-L3 mapping requests, i.e., through the cache population > mechanism that is the basis of the server approach. Firewalls won't help here! > The AR should *never* propagate any MN supplied information back to the server. The server should contain a map of what are the valid, authorized AP to AR mappings, as installed by the sysadmin. The rest of my note describes how to deal with weeding out bogus MN supplied information (timeouts, weighting information supplied by multiple MNs more highly than by a single one, etc). > Hmm, wouldn't deployment even more speed up if we didn't have a server > at all?? The question is not whether or not a server would hinder deployment > but whether or not a server is necessary at all. I still don't see a convincing > argument for this. The DT draft does not give one, and the current discussion > hasn't either. > Nope. If I am a sysadmin, I want my routers to know they can trust the information supplied by an MN. I, as a sysadmin, know what APs I've installed. The router should not trust any information provided by the MN unless it is validated by the map in the server. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 13:45:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05755 for ; Thu, 6 Mar 2003 13:45:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IuDO02805; Thu, 6 Mar 2003 13:56:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ItxO02780 for ; Thu, 6 Mar 2003 13:55:59 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05638 for ; Thu, 6 Mar 2003 13:44:19 -0500 (EST) Message-ID: <017801c2e410$799cbd00$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 10:44:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In the context of the DT document, a possible DoS attack does not > even consider attacks from outside of the domain directed towards the > server as such, but inherently through the protocol operation involving the > server. Namely, a malicious MN is contaminating the cache entries of the AP > through falsified L2-L3 mapping requests, i.e., through the cache population > mechanism that is the basis of the server approach. Firewalls won't help here! > The AR should *never* propagate any MN supplied information back to the server. The server should contain a map of what are the valid, authorized AP to AR mappings, as installed by the sysadmin. The rest of my note describes how to deal with weeding out bogus MN supplied information (timeouts, weighting information supplied by multiple MNs more highly than by a single one, etc). > Hmm, wouldn't deployment even more speed up if we didn't have a server > at all?? The question is not whether or not a server would hinder deployment > but whether or not a server is necessary at all. I still don't see a convincing > argument for this. The DT draft does not give one, and the current discussion > hasn't either. > Nope. If I am a sysadmin, I want my routers to know they can trust the information supplied by an MN. I, as a sysadmin, know what APs I've installed. The router should not trust any information provided by the MN unless it is validated by the map in the server. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 13:47:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05851 for ; Thu, 6 Mar 2003 13:47:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26IwFW03006 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 13:58:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IwFO03003 for ; Thu, 6 Mar 2003 13:58:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05820 for ; Thu, 6 Mar 2003 13:46:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Iw1O02980; Thu, 6 Mar 2003 13:58:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IvvO02966 for ; Thu, 6 Mar 2003 13:57:57 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05814 for ; Thu, 6 Mar 2003 13:46:16 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h26ImHBY018259 for ; Thu, 6 Mar 2003 11:48:17 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA07269 for ; Thu, 6 Mar 2003 11:46:28 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 12:48:20 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE34@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 12:48:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Dirk, See my reply to Govind's email for answers for most of your questions. Please also see the inline reply. Regards, Ajoy -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 1:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? AJOY-> This requirements are not yet approved. BTW, we are open to re-use the existing server to provide CARD functionality. > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? AJOY-> Why not? see my reply to Govind's email. > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. AJOY-> This is not a technical reason for not pursuing this. BTW, what is your opion about the time frame when the vendors will deploy CARD? > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. AJOY-> Please see the my reply to Govind's email. BTW, I do agree that we need to clarify the use of scope-id in the next revision of the draft. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 13:49:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05966 for ; Thu, 6 Mar 2003 13:49:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Iw1O02980; Thu, 6 Mar 2003 13:58:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IvvO02966 for ; Thu, 6 Mar 2003 13:57:57 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05814 for ; Thu, 6 Mar 2003 13:46:16 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h26ImHBY018259 for ; Thu, 6 Mar 2003 11:48:17 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA07269 for ; Thu, 6 Mar 2003 11:46:28 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 12:48:20 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE34@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 12:48:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Dirk, See my reply to Govind's email for answers for most of your questions. Please also see the inline reply. Regards, Ajoy -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 1:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? AJOY-> This requirements are not yet approved. BTW, we are open to re-use the existing server to provide CARD functionality. > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? AJOY-> Why not? see my reply to Govind's email. > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. AJOY-> This is not a technical reason for not pursuing this. BTW, what is your opion about the time frame when the vendors will deploy CARD? > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. AJOY-> Please see the my reply to Govind's email. BTW, I do agree that we need to clarify the use of scope-id in the next revision of the draft. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 13:51:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06108 for ; Thu, 6 Mar 2003 13:51:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26J2u603271 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 14:02:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J2uO03266 for ; Thu, 6 Mar 2003 14:02:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06089 for ; Thu, 6 Mar 2003 13:51:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J2hO03254; Thu, 6 Mar 2003 14:02:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J0sO03150 for ; Thu, 6 Mar 2003 14:00:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05985 for ; Thu, 6 Mar 2003 13:49:13 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26IpH804943 for ; Thu, 6 Mar 2003 12:51:17 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 12:51:17 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 12:51:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 13:51:16 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkDO8bqVGuSuwTQX+kf9FQu7Fe+wAAFiaQ To: , X-OriginalArrivalTime: 06 Mar 2003 18:51:17.0297 (UTC) FILETIME=[5EA0D210:01C2E411] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26J0sO03151 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy, My replies are embedded. -Govind. AJOY-> I meant every time cache times out, your proposed scheme (dycard) will perform slow handoff. But in case of server based approach this may not be the case. In server based approach, AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the current AR may not be required to query AR server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [Govind] Why will cache time out if there are frequent handovers. Plus once two ARs have recognized each other as CARs, why can't we setup a refresh procedure. Doesn't that take care of it? Secondly, what do you mean "properly placing the server with respect to the AR, we minimize the round trip delay". You have one server per domain right? How are you going to optimize w.r.t each AR. Are you suggesting now an server per AR? AJOY-> The scope-id reduces the cache contamination problem, the potential growth of AR cache is bounded. This will eliminate the problem introduced due to unbounded cache growth. For example, in case of dycard, you might have a situation where the AR cache will overflow if a mobile node keeps injecting wrong information to the AR. This will cause AR to either crash or remove the old useful cache entries. Potentially this will create a situation where AR will loose valid cache entries to populate invalid entries. Is it not correct? [Govind] First, if you read dycard you will see that the "overflow" problem that you talk about is almost impossible. We do this by a scheme wherein we restrict the number of entries that can be created by each MN. Also, I don't think your scope-id solution anyway reduces the problem. You are saying that if we have "n" incorrect entries in the cache it is not a problem, where n can be arbitrarily large right (atleast w.r.t the cache size) ? I don't quite agree with that. [snip] AJOY-> Won't next handoff performed by dycard will be slow after cache timeout? BTW, this is necessarily not a problem with server based approach. The AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the AR may not be required to query CARD server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [Govind] I disagree with your premise that dycard introduces frequent cache misses. This statement is terribly flawed. Rather, I think in the steady state the server is useless. If you have a proper cache update policy and make sure DoS is hard, we are through. [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? AJOY-> This is not the only reason. The server based approach provides centralized configuration. It is also easier to manage. Also, you can deploy scope-id to eliminate the harmful aspect of cache contamination. In this you can eliminate the cache overflow by properly configuring the size of AR cache. [Govind] Again, what management are you talking about? When CARs talk to each other why not store all the information required in each other's caches? You are doing that anyway in the DT draft. What you are advocating is a cache + server. What I am saying that cache is enough. Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. AJOY-> The scope-id enables you to avoid cache overflow problem. If you do not have scope-id defined, some malicious MN will able to inject the fake messages to AR that would increase the size of cache to unexpectedly large value. Depending upon the caching policy, AR may either discard the useful cache information to store fake entries. [Govind] Yes while I agree we have to protect against DoS, scope-id is not the way to handle this, IMO. Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? AJOY-> Could you please explain how dycard plans to avoid the problem of cache overflow? [Govind] Sure, we restrict the number of entries that each MN can create in the server. The number of entries is configurable. We make sure that the MN was actually present in the previous ARs domain in the "recent" past. Where "recent" is a variable that can be configured. AJOY-> It is relatively inexpensive to provide redundancy of a server that only does L2->L3 mapping. This function can be easily piggybacked upon existing high availability server platform. [Govind] I don't disagree with the fact that it might be relatively inexpensive to provide reliability. But look at the cost in terms of any benefit you receive from the server. It doesn't add up. Plus, you have consistency issues to take care of when you have redundancy. Instead, why not have a server at each AR then? AJOY-> The server based approach also allows the server to store L2->L3 mapping, scope-id and static capabilities. It is very easy to manage these information if it stored at single point. Managing such information in distributed case is difficult. [Govind]Why are you introducing a new element or functionality instead of dealing with routers themselves. CARs can contact each other just fine once they know about each other. They can talk to each other and manage capabilities. They don't need talk to a server to get updates. [Govind] Could you define "clever" use of scope-id? Quoting from the draft "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". AJOY-> The scope-id can also be manually configured at server. In this case if any AR tries to resolve the link layer id belonging to AR whose scope-id does not match the requester's scope-id, server can simply reject the request. Also, you can properly configure the size of AR cache if you know how many AR's are covered by the given scope-id. BTW, I do admit we need to clarify the proper use of scope-id in the draft [Govind] What advantage do you have by manually configuring scope-ids? If that is the case, why don't you program it in routers themselves and make themselves aware of their scope-id? [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? AJOY-> BTW, the AAA server is widely used in access network. So, I do not see why are you so much opposed to this? I think the AAA server based key distribution may be useful in inter-domain case. BTW, I am flexible in this and NOT proposing that key distribution MUST be done through AAA server. I am just looking for others' opinion about it. [Govind] Why don't we use already existing SAs (trust relationships) between routers in the same domain. Why do we have to invent a new scheme altogether? [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with a solution that works well now, and also has a good chance of being accepted later. AJOY-> I do not agree with your conclusion. The server based approach (DNS) has been widely deployed in Internet name->address resolution. [Govind] Just because something works someplace, you don't need to use it everywhere when there is no need for it. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 13:52:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06161 for ; Thu, 6 Mar 2003 13:52:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J2hO03254; Thu, 6 Mar 2003 14:02:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J0sO03150 for ; Thu, 6 Mar 2003 14:00:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05985 for ; Thu, 6 Mar 2003 13:49:13 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26IpH804943 for ; Thu, 6 Mar 2003 12:51:17 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 12:51:17 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 12:51:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 13:51:16 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkDO8bqVGuSuwTQX+kf9FQu7Fe+wAAFiaQ To: , X-OriginalArrivalTime: 06 Mar 2003 18:51:17.0297 (UTC) FILETIME=[5EA0D210:01C2E411] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26J0sO03151 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy, My replies are embedded. -Govind. AJOY-> I meant every time cache times out, your proposed scheme (dycard) will perform slow handoff. But in case of server based approach this may not be the case. In server based approach, AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the current AR may not be required to query AR server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [Govind] Why will cache time out if there are frequent handovers. Plus once two ARs have recognized each other as CARs, why can't we setup a refresh procedure. Doesn't that take care of it? Secondly, what do you mean "properly placing the server with respect to the AR, we minimize the round trip delay". You have one server per domain right? How are you going to optimize w.r.t each AR. Are you suggesting now an server per AR? AJOY-> The scope-id reduces the cache contamination problem, the potential growth of AR cache is bounded. This will eliminate the problem introduced due to unbounded cache growth. For example, in case of dycard, you might have a situation where the AR cache will overflow if a mobile node keeps injecting wrong information to the AR. This will cause AR to either crash or remove the old useful cache entries. Potentially this will create a situation where AR will loose valid cache entries to populate invalid entries. Is it not correct? [Govind] First, if you read dycard you will see that the "overflow" problem that you talk about is almost impossible. We do this by a scheme wherein we restrict the number of entries that can be created by each MN. Also, I don't think your scope-id solution anyway reduces the problem. You are saying that if we have "n" incorrect entries in the cache it is not a problem, where n can be arbitrarily large right (atleast w.r.t the cache size) ? I don't quite agree with that. [snip] AJOY-> Won't next handoff performed by dycard will be slow after cache timeout? BTW, this is necessarily not a problem with server based approach. The AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the AR may not be required to query CARD server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [Govind] I disagree with your premise that dycard introduces frequent cache misses. This statement is terribly flawed. Rather, I think in the steady state the server is useless. If you have a proper cache update policy and make sure DoS is hard, we are through. [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? AJOY-> This is not the only reason. The server based approach provides centralized configuration. It is also easier to manage. Also, you can deploy scope-id to eliminate the harmful aspect of cache contamination. In this you can eliminate the cache overflow by properly configuring the size of AR cache. [Govind] Again, what management are you talking about? When CARs talk to each other why not store all the information required in each other's caches? You are doing that anyway in the DT draft. What you are advocating is a cache + server. What I am saying that cache is enough. Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all. AJOY-> The scope-id enables you to avoid cache overflow problem. If you do not have scope-id defined, some malicious MN will able to inject the fake messages to AR that would increase the size of cache to unexpectedly large value. Depending upon the caching policy, AR may either discard the useful cache information to store fake entries. [Govind] Yes while I agree we have to protect against DoS, scope-id is not the way to handle this, IMO. Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? AJOY-> Could you please explain how dycard plans to avoid the problem of cache overflow? [Govind] Sure, we restrict the number of entries that each MN can create in the server. The number of entries is configurable. We make sure that the MN was actually present in the previous ARs domain in the "recent" past. Where "recent" is a variable that can be configured. AJOY-> It is relatively inexpensive to provide redundancy of a server that only does L2->L3 mapping. This function can be easily piggybacked upon existing high availability server platform. [Govind] I don't disagree with the fact that it might be relatively inexpensive to provide reliability. But look at the cost in terms of any benefit you receive from the server. It doesn't add up. Plus, you have consistency issues to take care of when you have redundancy. Instead, why not have a server at each AR then? AJOY-> The server based approach also allows the server to store L2->L3 mapping, scope-id and static capabilities. It is very easy to manage these information if it stored at single point. Managing such information in distributed case is difficult. [Govind]Why are you introducing a new element or functionality instead of dealing with routers themselves. CARs can contact each other just fine once they know about each other. They can talk to each other and manage capabilities. They don't need talk to a server to get updates. [Govind] Could you define "clever" use of scope-id? Quoting from the draft "operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". AJOY-> The scope-id can also be manually configured at server. In this case if any AR tries to resolve the link layer id belonging to AR whose scope-id does not match the requester's scope-id, server can simply reject the request. Also, you can properly configure the size of AR cache if you know how many AR's are covered by the given scope-id. BTW, I do admit we need to clarify the proper use of scope-id in the draft [Govind] What advantage do you have by manually configuring scope-ids? If that is the case, why don't you program it in routers themselves and make themselves aware of their scope-id? [Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? AJOY-> BTW, the AAA server is widely used in access network. So, I do not see why are you so much opposed to this? I think the AAA server based key distribution may be useful in inter-domain case. BTW, I am flexible in this and NOT proposing that key distribution MUST be done through AAA server. I am just looking for others' opinion about it. [Govind] Why don't we use already existing SAs (trust relationships) between routers in the same domain. Why do we have to invent a new scheme altogether? [Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with a solution that works well now, and also has a good chance of being accepted later. AJOY-> I do not agree with your conclusion. The server based approach (DNS) has been widely deployed in Internet name->address resolution. [Govind] Just because something works someplace, you don't need to use it everywhere when there is no need for it. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 13:53:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06204 for ; Thu, 6 Mar 2003 13:53:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26J4Hl03419 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 14:04:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J4GO03416 for ; Thu, 6 Mar 2003 14:04:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06184 for ; Thu, 6 Mar 2003 13:52:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J42O03375; Thu, 6 Mar 2003 14:04:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J3YO03325 for ; Thu, 6 Mar 2003 14:03:34 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06129 for ; Thu, 6 Mar 2003 13:51:54 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26Irw805437 for ; Thu, 6 Mar 2003 12:53:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 12:53:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 10:52:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 13:52:48 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkDQp1OiZsC+QhRQyPJfQvT2xlJwAADLvA To: , , X-OriginalArrivalTime: 06 Mar 2003 18:52:49.0076 (UTC) FILETIME=[95552F40:01C2E411] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26J3ZO03326 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy, see inline. >[snip] > >This depends upon the cache timeout as well as handoff traffic. >BTW, the server based approach is easier to manage as well >it provides extra security. If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. >This also minimizes the affect DoS attack. > >[Govind] The cache timeout can be handled quite easily. > >AJOY-> I meant every time cache times out, your proposed >scheme (dycard) >will perform slow handoff. But in case of server based >approach this may >not be the case. In server based approach, AR cache is updated >when a mobile >node scans the neighboring channel and detects a new link >layer id. In this it is likely >that the server cache will be updated prior to layer 3 handoff. >Hence, the current AR may not be required to query AR server >during critical >path of handoff. Also, by properly placing the server with >respect to AR, you can minimize the round trip delay with server. It still boils down to the same question: In case there is no entry in the AR cache (either due to very first handoff or due to cache timeout), is it worth to deploy a server to catch the first handoff in order to populate the cache? In the server-based approach this will happen with a certain probability only, and it is hard to get real numbers on this probability since it depends on delay for the query compared to the time the mobile resides in the overlapping region of coverage. Guessing that "it will probably be there in time" is not a quantitive measure that helps, since it is a highly physical topology and mobility pattern dependent problem. But even so, is it worth the effort, in particular if we consider conservative cache timeout settings or even dynamic cache timeout mechanisms in the AR based on the handoff traffic? > >Regarding, the server based approach being more secure, this >is quite unclear from the document. I don't think you can >eleminate the cache contamination problem from any of the >schemes that you have described. I have explained in my email >how using the scope ID approach still allows you to keep "n" >entriesthat are not CARs in the cache. In fact, the DT draft >acknowledges that the >CARD server can still be subjected to a DoS attack. I don't >really agree with your premise that you alleviate the security >problems just by having a >CARD server. > >AJOY-> The scope-id reduces the cache contamination problem, the >potential growth of AR cache is bounded. This will eliminate >the problem >introduced due to unbounded cache growth. For example, in case >of dycard, >you might have a situation where the AR cache will overflow if >a mobile node >keeps injecting wrong information to the AR. This will cause >AR to either crash or remove the old useful cache entries. >Potentially >this will create a situation where AR will loose valid cache entries >to populate invalid entries. Is it not correct? Why can't I do the same bound operation in dycard? If an MN is injecting wrong information to the AR, I can start rejecting the entries after n ARs. I have to do the same thing for the server. Nothing crashes here. Further, you have to keep in mind that it is probably easier to inject wrong L2-L3 mapping requests (as for the server approach) than to forge your L2 identifier (which you have to provide in the dycard approach) when injecting the old AR's address. >[snip] > >I think this will be better than the case where cache entries >are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Moreover the later approach is very >difficult to manage and is even less secure. > >[Govind] Yes, the first handover case. So are you saying the >cost of the first handover being not seamless is worth >introducing a new element in the network? > >AJOY-> This is not the only reason. The server based approach provides >centralized configuration. It is also easier to manage. Also, >you can deploy scope-id to eliminate the harmful aspect of cache >contamination. In this you can eliminate the cache overflow by >properly configuring the size of AR cache. We're turning in circles here. The question is not whether or not the server is managable and nice to configure, the question is whether we need the server at all. Having nothing to be configured and managed is better than any other solution that requires management and configuration, right? Regarding the scope-id, it is not yet clear (also James indicated this) how the scope-id would work. Eliminating cache overflow is always possible by simply rejecting entries after a certain cache size. > >Also, you could you list out the security holes that you >perceive in the dycard draft. Also, could you look at the way >we have handled it and see whether we have presented solutions >tackled the issues? > >AJOY-> Could you please explain how dycard plans to avoid the >problem of >cache overflow? Please take a look at the draft since it is explained in there. >[Govind] What manageability are you talking about? You assume >that each AR knows what APs it has. Why should it be conveyed >to the CARD server? Why can't it be conveyed directly to its >CARs? Also, what lack of manageability that you perceive in >dycard? Can we talk quantitatively rather qualitatively here? > >AJOY-> The server based approach also allows the server to store >L2->L3 mapping, scope-id and static capabilities. It is >very easy to manage these information if it stored at >single point. Managing such information in >distributed case is difficult. It would be helpful if you would point out the difficulties in managing a distributed approach such as dycard. > >As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. > >[Govind] Could you define "clever" use of scope-id? Quoting >from the draft >"operators may set their ARs' scope id to a server. When a >current AR requests the L2-L3 mapping from the server, the >server returns the mapping with the scope-id". > >AJOY-> The scope-id can also be manually configured at server. >In this case if any AR tries to resolve the link layer >id belonging to AR whose scope-id does not match the >requester's scope-id, server can simply reject the >request. Also, you can properly configure the size of AR cache if >you know how many AR's are covered by the >given scope-id. BTW, I do admit we need to clarify the >proper use of scope-id in the draft How would this work in an environment with a certain dynamic? Would you have to reconfigure the id? The problem right now is mostly that we are relying on a mechanism when it comes to security, which is not at all clear with respect to its usage. "Proper" and "clever" as design guidelines are not helpful to resolve these concerns. >[snip] >Probably you are right. We do need to get consensus from AAA >group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. > >[Govind] I don't think we need to do this at all. Key >distribution, that too for ARs in the same domain, is not at >all CARD problem at all. There are other ways to do it, and I >don't think we need to re-invent the wheel. Routers within a >domain are trusting each other right now too, is it not? > >AJOY-> BTW, the AAA server is widely used in access network. So, >I do not see why are you so much opposed to this? I think >the AAA server based key distribution may be useful in >inter-domain case. BTW, I am flexible in this and >NOT proposing that key distribution MUST be done >through AAA server. I am just looking for >others' opinion about it. The main opposition comes from the question whether we're tackling a problem here that we shouldn't. > >[snip] >I am not sure I agree with you here. Could you provide some additional >detail why you think scope id is complicated? > >[Govind]I'll let you know if I come up with something more, >than what I've provided in my previous email. > >AJOY-> Ok, it will be helpful. It is not about complicated or not. It is simply not clear how to use the parameter, in particular since it is proposed to cope with DoS attacks. Again, clarifying "clever" and "proper" from your side would be helpful to give everybody a picture of the usefulness of the parameter and the ability to do what it is supposed to do. > >Also, when we talk about inter-domain handovers this may be >quite difficult to achieve. I know that we are not talking >about inter-domain handovers at this point, but coming up with >a solution that does not work very well in the future is not >the correct way to go, IMHO. > >Let be focused now. > >[Govind] Focusing on a solution that doesn't work very well >even now is not the best way to go either. Instead, it will be >more prudent to come up with >a solution that works well now, and also has a good chance of >being accepted later. > >AJOY-> I do not agree with your conclusion. The server based >approach (DNS) >has been widely deployed in Internet name->address resolution. You're simply not comparing the right things. DNS isn't a widely deployed and accepted solution because everybody loves servers for the sake of their existence. The problem of name resolution (with its existing naming structure) points towards a server solution. At least, I can hardly imagine a fully server-less solution for DNS (apart from shouting into the network). However, this does not give sufficient reason to use servers for another problem, in particular not if a server-less solution is available. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 13:53:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06238 for ; Thu, 6 Mar 2003 13:53:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J42O03375; Thu, 6 Mar 2003 14:04:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J3YO03325 for ; Thu, 6 Mar 2003 14:03:34 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06129 for ; Thu, 6 Mar 2003 13:51:54 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26Irw805437 for ; Thu, 6 Mar 2003 12:53:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 12:53:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 10:52:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 13:52:48 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkDQp1OiZsC+QhRQyPJfQvT2xlJwAADLvA To: , , X-OriginalArrivalTime: 06 Mar 2003 18:52:49.0076 (UTC) FILETIME=[95552F40:01C2E411] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26J3ZO03326 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy, see inline. >[snip] > >This depends upon the cache timeout as well as handoff traffic. >BTW, the server based approach is easier to manage as well >it provides extra security. If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. >This also minimizes the affect DoS attack. > >[Govind] The cache timeout can be handled quite easily. > >AJOY-> I meant every time cache times out, your proposed >scheme (dycard) >will perform slow handoff. But in case of server based >approach this may >not be the case. In server based approach, AR cache is updated >when a mobile >node scans the neighboring channel and detects a new link >layer id. In this it is likely >that the server cache will be updated prior to layer 3 handoff. >Hence, the current AR may not be required to query AR server >during critical >path of handoff. Also, by properly placing the server with >respect to AR, you can minimize the round trip delay with server. It still boils down to the same question: In case there is no entry in the AR cache (either due to very first handoff or due to cache timeout), is it worth to deploy a server to catch the first handoff in order to populate the cache? In the server-based approach this will happen with a certain probability only, and it is hard to get real numbers on this probability since it depends on delay for the query compared to the time the mobile resides in the overlapping region of coverage. Guessing that "it will probably be there in time" is not a quantitive measure that helps, since it is a highly physical topology and mobility pattern dependent problem. But even so, is it worth the effort, in particular if we consider conservative cache timeout settings or even dynamic cache timeout mechanisms in the AR based on the handoff traffic? > >Regarding, the server based approach being more secure, this >is quite unclear from the document. I don't think you can >eleminate the cache contamination problem from any of the >schemes that you have described. I have explained in my email >how using the scope ID approach still allows you to keep "n" >entriesthat are not CARs in the cache. In fact, the DT draft >acknowledges that the >CARD server can still be subjected to a DoS attack. I don't >really agree with your premise that you alleviate the security >problems just by having a >CARD server. > >AJOY-> The scope-id reduces the cache contamination problem, the >potential growth of AR cache is bounded. This will eliminate >the problem >introduced due to unbounded cache growth. For example, in case >of dycard, >you might have a situation where the AR cache will overflow if >a mobile node >keeps injecting wrong information to the AR. This will cause >AR to either crash or remove the old useful cache entries. >Potentially >this will create a situation where AR will loose valid cache entries >to populate invalid entries. Is it not correct? Why can't I do the same bound operation in dycard? If an MN is injecting wrong information to the AR, I can start rejecting the entries after n ARs. I have to do the same thing for the server. Nothing crashes here. Further, you have to keep in mind that it is probably easier to inject wrong L2-L3 mapping requests (as for the server approach) than to forge your L2 identifier (which you have to provide in the dycard approach) when injecting the old AR's address. >[snip] > >I think this will be better than the case where cache entries >are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Moreover the later approach is very >difficult to manage and is even less secure. > >[Govind] Yes, the first handover case. So are you saying the >cost of the first handover being not seamless is worth >introducing a new element in the network? > >AJOY-> This is not the only reason. The server based approach provides >centralized configuration. It is also easier to manage. Also, >you can deploy scope-id to eliminate the harmful aspect of cache >contamination. In this you can eliminate the cache overflow by >properly configuring the size of AR cache. We're turning in circles here. The question is not whether or not the server is managable and nice to configure, the question is whether we need the server at all. Having nothing to be configured and managed is better than any other solution that requires management and configuration, right? Regarding the scope-id, it is not yet clear (also James indicated this) how the scope-id would work. Eliminating cache overflow is always possible by simply rejecting entries after a certain cache size. > >Also, you could you list out the security holes that you >perceive in the dycard draft. Also, could you look at the way >we have handled it and see whether we have presented solutions >tackled the issues? > >AJOY-> Could you please explain how dycard plans to avoid the >problem of >cache overflow? Please take a look at the draft since it is explained in there. >[Govind] What manageability are you talking about? You assume >that each AR knows what APs it has. Why should it be conveyed >to the CARD server? Why can't it be conveyed directly to its >CARs? Also, what lack of manageability that you perceive in >dycard? Can we talk quantitatively rather qualitatively here? > >AJOY-> The server based approach also allows the server to store >L2->L3 mapping, scope-id and static capabilities. It is >very easy to manage these information if it stored at >single point. Managing such information in >distributed case is difficult. It would be helpful if you would point out the difficulties in managing a distributed approach such as dycard. > >As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. > >[Govind] Could you define "clever" use of scope-id? Quoting >from the draft >"operators may set their ARs' scope id to a server. When a >current AR requests the L2-L3 mapping from the server, the >server returns the mapping with the scope-id". > >AJOY-> The scope-id can also be manually configured at server. >In this case if any AR tries to resolve the link layer >id belonging to AR whose scope-id does not match the >requester's scope-id, server can simply reject the >request. Also, you can properly configure the size of AR cache if >you know how many AR's are covered by the >given scope-id. BTW, I do admit we need to clarify the >proper use of scope-id in the draft How would this work in an environment with a certain dynamic? Would you have to reconfigure the id? The problem right now is mostly that we are relying on a mechanism when it comes to security, which is not at all clear with respect to its usage. "Proper" and "clever" as design guidelines are not helpful to resolve these concerns. >[snip] >Probably you are right. We do need to get consensus from AAA >group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. > >[Govind] I don't think we need to do this at all. Key >distribution, that too for ARs in the same domain, is not at >all CARD problem at all. There are other ways to do it, and I >don't think we need to re-invent the wheel. Routers within a >domain are trusting each other right now too, is it not? > >AJOY-> BTW, the AAA server is widely used in access network. So, >I do not see why are you so much opposed to this? I think >the AAA server based key distribution may be useful in >inter-domain case. BTW, I am flexible in this and >NOT proposing that key distribution MUST be done >through AAA server. I am just looking for >others' opinion about it. The main opposition comes from the question whether we're tackling a problem here that we shouldn't. > >[snip] >I am not sure I agree with you here. Could you provide some additional >detail why you think scope id is complicated? > >[Govind]I'll let you know if I come up with something more, >than what I've provided in my previous email. > >AJOY-> Ok, it will be helpful. It is not about complicated or not. It is simply not clear how to use the parameter, in particular since it is proposed to cope with DoS attacks. Again, clarifying "clever" and "proper" from your side would be helpful to give everybody a picture of the usefulness of the parameter and the ability to do what it is supposed to do. > >Also, when we talk about inter-domain handovers this may be >quite difficult to achieve. I know that we are not talking >about inter-domain handovers at this point, but coming up with >a solution that does not work very well in the future is not >the correct way to go, IMHO. > >Let be focused now. > >[Govind] Focusing on a solution that doesn't work very well >even now is not the best way to go either. Instead, it will be >more prudent to come up with >a solution that works well now, and also has a good chance of >being accepted later. > >AJOY-> I do not agree with your conclusion. The server based >approach (DNS) >has been widely deployed in Internet name->address resolution. You're simply not comparing the right things. DNS isn't a widely deployed and accepted solution because everybody loves servers for the sake of their existence. The problem of name resolution (with its existing naming structure) points towards a server solution. At least, I can hardly imagine a fully server-less solution for DNS (apart from shouting into the network). However, this does not give sufficient reason to use servers for another problem, in particular not if a server-less solution is available. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 13:57:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06359 for ; Thu, 6 Mar 2003 13:57:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26J8H204480 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 14:08:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J8HO04477 for ; Thu, 6 Mar 2003 14:08:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06346 for ; Thu, 6 Mar 2003 13:56:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J86O04453; Thu, 6 Mar 2003 14:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J7wO04424 for ; Thu, 6 Mar 2003 14:07:58 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06332 for ; Thu, 6 Mar 2003 13:56:17 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26J1fF01662 for ; Thu, 6 Mar 2003 21:01:41 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 20:58:21 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 20:58:21 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 10:58:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 13:58:12 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkELXzZjjc78IARdCo65RTh+5spgAAS9Hg To: , , X-OriginalArrivalTime: 06 Mar 2003 18:58:13.0815 (UTC) FILETIME=[56E46C70:01C2E412] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26J7wO04425 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jim, The AR should *never* propagate any MN supplied information back to the server. The server should contain a map of what are the valid, authorized AP to AR mappings, as installed by the sysadmin. [Govind] From what I understand, the DT draft does exactly this. If the L2-L3 mapping for a MN supplied L2 is not available in the cache it is fetched from the server. The rest of my note describes how to deal with weeding out bogus MN supplied information (timeouts, weighting information supplied by multiple MNs more highly than by a single one, etc). [Govind]The point is this all these schemes work on the cache. They don't need a server to exist, which is exactly my point. If you have a scheme where in we can avoid DoS, why do we need a server? > Hmm, wouldn't deployment even more speed up if we didn't have a server > at all?? The question is not whether or not a server would hinder deployment > but whether or not a server is necessary at all. I still don't see a convincing > argument for this. The DT draft does not give one, and the current discussion > hasn't either. > Nope. If I am a sysadmin, I want my routers to know they can trust the information supplied by an MN. I, as a sysadmin, know what APs I've installed. The router should not trust any information provided by the MN unless it is validated by the map in the server. [Govind] I agree that any MN supplied information should be validated. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 13:57:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06390 for ; Thu, 6 Mar 2003 13:57:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J86O04453; Thu, 6 Mar 2003 14:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J7wO04424 for ; Thu, 6 Mar 2003 14:07:58 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06332 for ; Thu, 6 Mar 2003 13:56:17 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26J1fF01662 for ; Thu, 6 Mar 2003 21:01:41 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 20:58:21 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 20:58:21 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 10:58:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 13:58:12 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkELXzZjjc78IARdCo65RTh+5spgAAS9Hg To: , , X-OriginalArrivalTime: 06 Mar 2003 18:58:13.0815 (UTC) FILETIME=[56E46C70:01C2E412] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26J7wO04425 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Jim, The AR should *never* propagate any MN supplied information back to the server. The server should contain a map of what are the valid, authorized AP to AR mappings, as installed by the sysadmin. [Govind] From what I understand, the DT draft does exactly this. If the L2-L3 mapping for a MN supplied L2 is not available in the cache it is fetched from the server. The rest of my note describes how to deal with weeding out bogus MN supplied information (timeouts, weighting information supplied by multiple MNs more highly than by a single one, etc). [Govind]The point is this all these schemes work on the cache. They don't need a server to exist, which is exactly my point. If you have a scheme where in we can avoid DoS, why do we need a server? > Hmm, wouldn't deployment even more speed up if we didn't have a server > at all?? The question is not whether or not a server would hinder deployment > but whether or not a server is necessary at all. I still don't see a convincing > argument for this. The DT draft does not give one, and the current discussion > hasn't either. > Nope. If I am a sysadmin, I want my routers to know they can trust the information supplied by an MN. I, as a sysadmin, know what APs I've installed. The router should not trust any information provided by the MN unless it is validated by the map in the server. [Govind] I agree that any MN supplied information should be validated. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 14:03:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06675 for ; Thu, 6 Mar 2003 14:03:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26JEZS04922 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 14:14:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JEZO04919 for ; Thu, 6 Mar 2003 14:14:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06645 for ; Thu, 6 Mar 2003 14:02:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JELO04887; Thu, 6 Mar 2003 14:14:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JDOO04756 for ; Thu, 6 Mar 2003 14:13:24 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06572 for ; Thu, 6 Mar 2003 14:01:43 -0500 (EST) Message-ID: <019001c2e412$e7b7ec90$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 11:02:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [Govind] GPRS, for example is still a technology for the near future. > I think GPRS is based on IPv4 at least now. I agree that CARD should be IPv6 amenable > but neglecting IPv4 is not correct. I disagree. > I don't see what GPRS has to do with CARD. I think I would have to see a higher level of implementation and deployment interest before I would be willing to change my opinion, but the trend in Mobile IP is towards stopping any technology development in MIPv4 unless it is directly related to deployment concerns. As a way to focus the design and reduce people's work load, I think that would be a prudent course for Seamoby to follow as well. > > [Govind] Could you explain why you would think it should be an OSPF extension? > > Do we have to bring OSPF/IS-IS into this? The routers are sending packets to > each > > other like any other packets,just like FMIPv6 or CT has messages between ARs, > to enable > > protocol functionality. Why is this any different? I think this is very > important > > and helps provide a major functionality and it does belong in this document. > Maybe > > I'm missing something. > > > (for the second and last time) Like I said, I did not say it should be an OSPF extension. I said that we need to talk with the Routing Area Directors about whether it is an appropriate kind of information to distribute using the IGP. It is different from CT in that it is not tied to handover. There are no timing constraints on whether this information gets between routers within a particular time window. The information is not tied to a specific mobile node. It is orthogonal to the router to host protocol for CARD. The information is tied to a topology change, an AP going up or down, which is like a router going up or down, suggesting an IGP extension. Therefore I believe it should be in a separate document. Whether or not an IGP extension is the right approach is TBD. > [Govind]Even though is also manual configuration possible for PKI, I don't disagree > with PKI using servers (LDAP is just one way of doing it). > What I disagree is with your notion that just because PKI uses it, > CARD should use it too. There is no need to do this. > Govind, if I am a sysadmin, I don't want 50 different ways to configure my network, I want one. Its as simple as that. Ask the sysadmin in your office if he likes having multiple ways of doing things if you don't believe me. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 14:03:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06688 for ; Thu, 6 Mar 2003 14:03:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26JEc804943 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 14:14:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JEcO04940 for ; Thu, 6 Mar 2003 14:14:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06652 for ; Thu, 6 Mar 2003 14:02:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JERO04909; Thu, 6 Mar 2003 14:14:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JDYO04773 for ; Thu, 6 Mar 2003 14:13:34 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06577 for ; Thu, 6 Mar 2003 14:01:54 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26J3w808407 for ; Thu, 6 Mar 2003 13:03:59 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 13:03:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 13:02:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 14:02:41 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkELXf8fEOBg3PQrG2WKsc0ynr+wAAPDMg To: , , X-OriginalArrivalTime: 06 Mar 2003 19:02:42.0337 (UTC) FILETIME=[F6F1A110:01C2E412] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26JDYO04774 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, >> In the context of the DT document, a possible DoS attack does not >> even consider attacks from outside of the domain directed towards the >> server as such, but inherently through the protocol >operation involving the >> server. Namely, a malicious MN is contaminating the cache >entries of the AP >> through falsified L2-L3 mapping requests, i.e., through the >cache population >> mechanism that is the basis of the server approach. >Firewalls won't help here! >> > >The AR should *never* propagate any MN supplied information >back to the server. If the (MN-)requested L2-L3 mapping does not exist in the AR cache, a request is sent to the server to obtain this information (maybe I missed something in the draft). If the MN does the request for all n ARs in the scope, the cache will soon be filled up with all possible ARs in the scope region. But even more, the MN can also explicitly request L2-L3 mappings of ARs that are not within the region (the AR does not know about the region, and it does not know whether or not the supplied information is correct, so it has to ask the server). The mapping is requested from the server by the AR, the server rejects the request (reason "out of scope region"). Result of this would be server and AR load, i.e., DoS attack. Another thought: Since eventually, the AR might get the L2-L3 mappings of all scope region ARs anyway (assuming such malicious MN above), why don't we simply push the L2-L3 mappings right from the beginning to the AR instead of requesting it on time???? This would bring us very close to a static configuration approach though. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 14:03:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06713 for ; Thu, 6 Mar 2003 14:03:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JELO04887; Thu, 6 Mar 2003 14:14:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JDOO04756 for ; Thu, 6 Mar 2003 14:13:24 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06572 for ; Thu, 6 Mar 2003 14:01:43 -0500 (EST) Message-ID: <019001c2e412$e7b7ec90$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 11:02:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [Govind] GPRS, for example is still a technology for the near future. > I think GPRS is based on IPv4 at least now. I agree that CARD should be IPv6 amenable > but neglecting IPv4 is not correct. I disagree. > I don't see what GPRS has to do with CARD. I think I would have to see a higher level of implementation and deployment interest before I would be willing to change my opinion, but the trend in Mobile IP is towards stopping any technology development in MIPv4 unless it is directly related to deployment concerns. As a way to focus the design and reduce people's work load, I think that would be a prudent course for Seamoby to follow as well. > > [Govind] Could you explain why you would think it should be an OSPF extension? > > Do we have to bring OSPF/IS-IS into this? The routers are sending packets to > each > > other like any other packets,just like FMIPv6 or CT has messages between ARs, > to enable > > protocol functionality. Why is this any different? I think this is very > important > > and helps provide a major functionality and it does belong in this document. > Maybe > > I'm missing something. > > > (for the second and last time) Like I said, I did not say it should be an OSPF extension. I said that we need to talk with the Routing Area Directors about whether it is an appropriate kind of information to distribute using the IGP. It is different from CT in that it is not tied to handover. There are no timing constraints on whether this information gets between routers within a particular time window. The information is not tied to a specific mobile node. It is orthogonal to the router to host protocol for CARD. The information is tied to a topology change, an AP going up or down, which is like a router going up or down, suggesting an IGP extension. Therefore I believe it should be in a separate document. Whether or not an IGP extension is the right approach is TBD. > [Govind]Even though is also manual configuration possible for PKI, I don't disagree > with PKI using servers (LDAP is just one way of doing it). > What I disagree is with your notion that just because PKI uses it, > CARD should use it too. There is no need to do this. > Govind, if I am a sysadmin, I don't want 50 different ways to configure my network, I want one. Its as simple as that. Ask the sysadmin in your office if he likes having multiple ways of doing things if you don't believe me. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 14:03:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06729 for ; Thu, 6 Mar 2003 14:03:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JERO04909; Thu, 6 Mar 2003 14:14:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JDYO04773 for ; Thu, 6 Mar 2003 14:13:34 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06577 for ; Thu, 6 Mar 2003 14:01:54 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26J3w808407 for ; Thu, 6 Mar 2003 13:03:59 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 13:03:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 13:02:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 14:02:41 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkELXf8fEOBg3PQrG2WKsc0ynr+wAAPDMg To: , , X-OriginalArrivalTime: 06 Mar 2003 19:02:42.0337 (UTC) FILETIME=[F6F1A110:01C2E412] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26JDYO04774 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, >> In the context of the DT document, a possible DoS attack does not >> even consider attacks from outside of the domain directed towards the >> server as such, but inherently through the protocol >operation involving the >> server. Namely, a malicious MN is contaminating the cache >entries of the AP >> through falsified L2-L3 mapping requests, i.e., through the >cache population >> mechanism that is the basis of the server approach. >Firewalls won't help here! >> > >The AR should *never* propagate any MN supplied information >back to the server. If the (MN-)requested L2-L3 mapping does not exist in the AR cache, a request is sent to the server to obtain this information (maybe I missed something in the draft). If the MN does the request for all n ARs in the scope, the cache will soon be filled up with all possible ARs in the scope region. But even more, the MN can also explicitly request L2-L3 mappings of ARs that are not within the region (the AR does not know about the region, and it does not know whether or not the supplied information is correct, so it has to ask the server). The mapping is requested from the server by the AR, the server rejects the request (reason "out of scope region"). Result of this would be server and AR load, i.e., DoS attack. Another thought: Since eventually, the AR might get the L2-L3 mappings of all scope region ARs anyway (assuming such malicious MN above), why don't we simply push the L2-L3 mappings right from the beginning to the AR instead of requesting it on time???? This would bring us very close to a static configuration approach though. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 14:24:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07636 for ; Thu, 6 Mar 2003 14:24:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26JZif06012 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 14:35:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JZiO06009 for ; Thu, 6 Mar 2003 14:35:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07598 for ; Thu, 6 Mar 2003 14:24:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JZPO05958; Thu, 6 Mar 2003 14:35:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JPhO05482 for ; Thu, 6 Mar 2003 14:25:43 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07155 for ; Thu, 6 Mar 2003 14:14:03 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26JG3811363 for ; Thu, 6 Mar 2003 13:16:03 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 13:16:03 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 13:15:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 14:15:06 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkEyM/XIMUZw2gQ/23HaG1+c83QgAAB7aw To: , X-OriginalArrivalTime: 06 Mar 2003 19:15:07.0535 (UTC) FILETIME=[B31DD1F0:01C2E414] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26JPhO05483 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I don't see what GPRS has to do with CARD. [Govind] Well, GPRS uses IPv4 addresses as I explained. CARD is an useful tool to support inter-technology handovers. I hope my point is clear now. Infact so is CDMA2000 based networks also use IPv4 based networks. Hence IPv4 is relevant. I think I would have to see a higher level of implementation and deployment interest before I would be willing to change my opinion, but the trend in Mobile IP is towards stopping any technology development in MIPv4 unless it is directly related to deployment concerns. As a way to focus the design and reduce people's work load, I think that would be a prudent course for Seamoby to follow as well. [Govind] same reply as above. (for the second and last time) Like I said, I did not say it should be an OSPF extension. I said that we need to talk with the Routing Area Directors about whether it is an appropriate kind of information to distribute using the IGP. It is different from CT in that it is not tied to handover. There are no timing constraints on whether this information gets between routers within a particular time window. The information is not tied to a specific mobile node. [Govind] Ofcourse this is tied to handovers. This information helps best choose the ARs, isn't it? Also, if AP information is sent as capabilities, it is the very necessary mapping, needed for handovers. It is orthogonal to the router to host protocol for CARD. The information is tied to a topology change, an AP going up or down, which is like a router going up or down, suggesting an IGP extension. Therefore I believe it should be in a separate document. Whether or not an IGP extension is the right approach is TBD. [Govind] Well lets discuss this at a later stage.. we have too much on the plate already :) > [Govind]Even though is also manual configuration possible for PKI, I don't disagree > with PKI using servers (LDAP is just one way of doing it). > What I disagree is with your notion that just because PKI uses it, > CARD should use it too. There is no need to do this. > Govind, if I am a sysadmin, I don't want 50 different ways to configure my network, I want one. Its as simple as that. Ask the sysadmin in your office if he likes having multiple ways of doing things if you don't believe me. [Govind] Sure, I hear you. But, I don't agree that you would need a server based approach for your objective. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 14:24:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07668 for ; Thu, 6 Mar 2003 14:24:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JZPO05958; Thu, 6 Mar 2003 14:35:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JPhO05482 for ; Thu, 6 Mar 2003 14:25:43 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07155 for ; Thu, 6 Mar 2003 14:14:03 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26JG3811363 for ; Thu, 6 Mar 2003 13:16:03 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 13:16:03 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 13:15:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 14:15:06 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkEyM/XIMUZw2gQ/23HaG1+c83QgAAB7aw To: , X-OriginalArrivalTime: 06 Mar 2003 19:15:07.0535 (UTC) FILETIME=[B31DD1F0:01C2E414] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26JPhO05483 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I don't see what GPRS has to do with CARD. [Govind] Well, GPRS uses IPv4 addresses as I explained. CARD is an useful tool to support inter-technology handovers. I hope my point is clear now. Infact so is CDMA2000 based networks also use IPv4 based networks. Hence IPv4 is relevant. I think I would have to see a higher level of implementation and deployment interest before I would be willing to change my opinion, but the trend in Mobile IP is towards stopping any technology development in MIPv4 unless it is directly related to deployment concerns. As a way to focus the design and reduce people's work load, I think that would be a prudent course for Seamoby to follow as well. [Govind] same reply as above. (for the second and last time) Like I said, I did not say it should be an OSPF extension. I said that we need to talk with the Routing Area Directors about whether it is an appropriate kind of information to distribute using the IGP. It is different from CT in that it is not tied to handover. There are no timing constraints on whether this information gets between routers within a particular time window. The information is not tied to a specific mobile node. [Govind] Ofcourse this is tied to handovers. This information helps best choose the ARs, isn't it? Also, if AP information is sent as capabilities, it is the very necessary mapping, needed for handovers. It is orthogonal to the router to host protocol for CARD. The information is tied to a topology change, an AP going up or down, which is like a router going up or down, suggesting an IGP extension. Therefore I believe it should be in a separate document. Whether or not an IGP extension is the right approach is TBD. [Govind] Well lets discuss this at a later stage.. we have too much on the plate already :) > [Govind]Even though is also manual configuration possible for PKI, I don't disagree > with PKI using servers (LDAP is just one way of doing it). > What I disagree is with your notion that just because PKI uses it, > CARD should use it too. There is no need to do this. > Govind, if I am a sysadmin, I don't want 50 different ways to configure my network, I want one. Its as simple as that. Ask the sysadmin in your office if he likes having multiple ways of doing things if you don't believe me. [Govind] Sure, I hear you. But, I don't agree that you would need a server based approach for your objective. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 14:55:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08944 for ; Thu, 6 Mar 2003 14:55:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26K6U508706 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 15:06:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26K6UO08703 for ; Thu, 6 Mar 2003 15:06:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08931 for ; Thu, 6 Mar 2003 14:54:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26K6JO08688; Thu, 6 Mar 2003 15:06:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JxGO08250 for ; Thu, 6 Mar 2003 14:59:16 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08659 for ; Thu, 6 Mar 2003 14:47:34 -0500 (EST) Message-ID: <01e201c2e419$4fd9e2f0$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 11:48:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Dirk, > If the (MN-)requested L2-L3 mapping does not exist in the AR cache, > a request is sent to the server to obtain this information (maybe I missed > something in the draft). If the MN does the request for all n ARs in the scope, > the cache will soon be filled up with all possible ARs in the scope region. But even > more, the MN can also explicitly request L2-L3 mappings of ARs that are not within the region > (the AR does not know about the region, and it does not know whether or not the supplied > information is correct, so it has to ask the server). The mapping is requested from the server > by the AR, the server rejects the request (reason "out of scope region"). Result of this would be > server and AR load, i.e., DoS attack. > Where's the denial of service? All you've described above is how the router cache gets populated by all the APs in the region. Properly sizing the router cache is required, of course. thought: Since eventually, the AR might get the L2-L3 mappings of all scope region ARs anyway > (assuming such malicious MN above), why don't we simply push the L2-L3 mappings right from the beginning > to the AR instead of requesting it on time???? This would bring us very close to a static configuration > approach though. > It is static as far as the router is concerned, but not as far as the MN is concerned. The MN can still dynamically do the CARD. Frankly, I think this might be necessary anyway to avoid the startup transient. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 14:55:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08960 for ; Thu, 6 Mar 2003 14:55:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26K6JO08688; Thu, 6 Mar 2003 15:06:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JxGO08250 for ; Thu, 6 Mar 2003 14:59:16 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08659 for ; Thu, 6 Mar 2003 14:47:34 -0500 (EST) Message-ID: <01e201c2e419$4fd9e2f0$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 11:48:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Dirk, > If the (MN-)requested L2-L3 mapping does not exist in the AR cache, > a request is sent to the server to obtain this information (maybe I missed > something in the draft). If the MN does the request for all n ARs in the scope, > the cache will soon be filled up with all possible ARs in the scope region. But even > more, the MN can also explicitly request L2-L3 mappings of ARs that are not within the region > (the AR does not know about the region, and it does not know whether or not the supplied > information is correct, so it has to ask the server). The mapping is requested from the server > by the AR, the server rejects the request (reason "out of scope region"). Result of this would be > server and AR load, i.e., DoS attack. > Where's the denial of service? All you've described above is how the router cache gets populated by all the APs in the region. Properly sizing the router cache is required, of course. thought: Since eventually, the AR might get the L2-L3 mappings of all scope region ARs anyway > (assuming such malicious MN above), why don't we simply push the L2-L3 mappings right from the beginning > to the AR instead of requesting it on time???? This would bring us very close to a static configuration > approach though. > It is static as far as the router is concerned, but not as far as the MN is concerned. The MN can still dynamically do the CARD. Frankly, I think this might be necessary anyway to avoid the startup transient. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 15:13:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10816 for ; Thu, 6 Mar 2003 15:13:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26KP7o10608 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 15:25:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KP7O10605 for ; Thu, 6 Mar 2003 15:25:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10771 for ; Thu, 6 Mar 2003 15:13:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KOvO10566; Thu, 6 Mar 2003 15:24:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KB4O09687 for ; Thu, 6 Mar 2003 15:11:04 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09096 for ; Thu, 6 Mar 2003 14:59:23 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26K4lF29265 for ; Thu, 6 Mar 2003 22:04:47 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 22:01:27 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 22:01:27 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 14:00:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 15:00:49 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkGLTSGEFVx6ilTnWZuQv3WFEHbwAAVRig To: Cc: , X-OriginalArrivalTime: 06 Mar 2003 20:00:50.0163 (UTC) FILETIME=[15D9A430:01C2E41B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26KB5O09688 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, Please read what I wrote again. "Should not propagate *from* the MN *to* the server." Please point out to me where in the draft it says that. Fetching *from* the server is the other way around. [Govind] The MN sends an L2 id. It is not there in the cache. Note the AR has no way of determining whether this is a genuine AP. If the entry to the AP is not in the cache it is sent over to the server. Server responds with the mapping or probably a error based. Doesn't the MN have direct control of what goes to the server? Thats what I meant. Hope it is clear now. This is what I understood. The DT draft has acknowledged that this is a problem and proposes the scope-id as one solution for this. Look at section 6.2. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 15:14:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10844 for ; Thu, 6 Mar 2003 15:14:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KOvO10566; Thu, 6 Mar 2003 15:24:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KB4O09687 for ; Thu, 6 Mar 2003 15:11:04 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09096 for ; Thu, 6 Mar 2003 14:59:23 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26K4lF29265 for ; Thu, 6 Mar 2003 22:04:47 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 22:01:27 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 22:01:27 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 14:00:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 15:00:49 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkGLTSGEFVx6ilTnWZuQv3WFEHbwAAVRig To: Cc: , X-OriginalArrivalTime: 06 Mar 2003 20:00:50.0163 (UTC) FILETIME=[15D9A430:01C2E41B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26KB5O09688 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, Please read what I wrote again. "Should not propagate *from* the MN *to* the server." Please point out to me where in the draft it says that. Fetching *from* the server is the other way around. [Govind] The MN sends an L2 id. It is not there in the cache. Note the AR has no way of determining whether this is a genuine AP. If the entry to the AP is not in the cache it is sent over to the server. Server responds with the mapping or probably a error based. Doesn't the MN have direct control of what goes to the server? Thats what I meant. Hope it is clear now. This is what I understood. The DT draft has acknowledged that this is a problem and proposes the scope-id as one solution for this. Look at section 6.2. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 15:19:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11101 for ; Thu, 6 Mar 2003 15:19:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26KUO110885 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 15:30:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KUOO10882 for ; Thu, 6 Mar 2003 15:30:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11013 for ; Thu, 6 Mar 2003 15:18:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KU5O10855; Thu, 6 Mar 2003 15:30:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KENO09845 for ; Thu, 6 Mar 2003 15:14:23 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09230 for ; Thu, 6 Mar 2003 15:02:41 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Mar 2003 12:04:46 -0800 Received: from 138.15.98.115 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 06 Mar 2003 20:04:46 GMT X-Originating-IP: [138.15.98.115] From: "Eunsoo Shim" To: ASINGH1@motorola.com, Hemant.Chaskar@nokia.com, Dirk.Trossen@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 06 Mar 2003 15:04:46 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Mar 2003 20:04:46.0383 (UTC) FILETIME=[A2A5F3F0:01C2E41B] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > > >If we deploy scope-id with serve > >based approach, then > >it is very much possible to reduce or even eliminate the > >problem of cache contamination. > >How would this happen? If I have n ARs in the scope of one scope-id, I >still >have the possibility of n false cache entries. Could you give some details >on how >such elimination would happen? > (eunsoo) I don't understand either how scope-id prevents cache contamination. Please provide us a scenario of it. To assign scope id, you should know what base stations are in the adjacent region and to which AR those APs are associated. Also you need to assign multiple scope-ids to each AR. We started CARD work to find a solution for dynamic discovery while we knew that static configuration of L2-L3 mapping at each AR was always a possibility. Now the server approach requires static configuration of L2-L3 mapping in a server and also requires knowledge of which base stations are close to each other. If a new base station is deployed, a new mapping entry should be typed in and also the admin should figure out right scope-ids for the AR associated to the base station. If the system admin does not mind keeping track of coverage areas of all the base stations or changing the static configuration in the server at every change (even just IP address change of an AR), why should she/he open the door for cache contamination? It seems to me that the server approach is getting quite close to static configuration solution of L2-L3 mapping at each AR. Regards, Eunsoo _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 15:19:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11139 for ; Thu, 6 Mar 2003 15:19:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KU5O10855; Thu, 6 Mar 2003 15:30:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KENO09845 for ; Thu, 6 Mar 2003 15:14:23 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09230 for ; Thu, 6 Mar 2003 15:02:41 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Mar 2003 12:04:46 -0800 Received: from 138.15.98.115 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 06 Mar 2003 20:04:46 GMT X-Originating-IP: [138.15.98.115] From: "Eunsoo Shim" To: ASINGH1@motorola.com, Hemant.Chaskar@nokia.com, Dirk.Trossen@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 06 Mar 2003 15:04:46 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Mar 2003 20:04:46.0383 (UTC) FILETIME=[A2A5F3F0:01C2E41B] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > > >If we deploy scope-id with serve > >based approach, then > >it is very much possible to reduce or even eliminate the > >problem of cache contamination. > >How would this happen? If I have n ARs in the scope of one scope-id, I >still >have the possibility of n false cache entries. Could you give some details >on how >such elimination would happen? > (eunsoo) I don't understand either how scope-id prevents cache contamination. Please provide us a scenario of it. To assign scope id, you should know what base stations are in the adjacent region and to which AR those APs are associated. Also you need to assign multiple scope-ids to each AR. We started CARD work to find a solution for dynamic discovery while we knew that static configuration of L2-L3 mapping at each AR was always a possibility. Now the server approach requires static configuration of L2-L3 mapping in a server and also requires knowledge of which base stations are close to each other. If a new base station is deployed, a new mapping entry should be typed in and also the admin should figure out right scope-ids for the AR associated to the base station. If the system admin does not mind keeping track of coverage areas of all the base stations or changing the static configuration in the server at every change (even just IP address change of an AR), why should she/he open the door for cache contamination? It seems to me that the server approach is getting quite close to static configuration solution of L2-L3 mapping at each AR. Regards, Eunsoo _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 16:38:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14011 for ; Thu, 6 Mar 2003 16:38:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Lo8f18166 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 16:50:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Lo8O18163 for ; Thu, 6 Mar 2003 16:50:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13997 for ; Thu, 6 Mar 2003 16:38:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26LnoO18111; Thu, 6 Mar 2003 16:49:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26LmGO18002 for ; Thu, 6 Mar 2003 16:48:16 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13886 for ; Thu, 6 Mar 2003 16:36:31 -0500 (EST) Message-ID: <022a01c2e428$86e1b980$156015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 6 Mar 2003 13:37:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Review of draft-ietf-seamoby-ctp-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat has been following CT more closely than I, so some of my comments may be due to unfamiliarity with the topic, but unfortunately he hasn't had much time recently to spend on CT. I have a few general comments, including editorial comments, then some more detailed comments. jak -------------------------------------------- General Comments -------------------- 1) The draft begins rather abruptly. I think there is a need for some, shall we say, context transfer :-) from the problem statement and requirements draft at the very beginning to ease the transition. There should be a section with goals and nongoals, so people have an overall impression about what the protocol is trying to do. In addition, the ladder diagrams in Section 5 would probably be better at the beginning so that people have some idea about how the protocol works before diving into detials. For example, when I read through Section 2, it was unclear to me whether pAR could send context to nAR in response to a link trigger, which seems clearly needed for certain time critical handovers. 2) I was quite disappointed to see that the transport issue has still not been resolved. This was certainly at the top of my list for topics that should be complete by this stage. If I recall correctly, I asked the DT about this in Atlanta and was assured that the issue would be resolved quickly, yet it has not been. My technical opinion is that the ladder diagrams in Section 5 suggest two transport modes: one between the MN and AR and another between ARs. More detailed consideration of this might help sort out some aspects of transport. 3) The security model in this draft is extremely vague. An "authorization token" from the MN is specified, but the construction of the token, its security properties, and the provisioning of the participants in the trust relationships involved in CT are left as an exercise to the reader. My opinion is that the DT and WG should revisit this decision and consider whether using more standardized security mechanisms, such as IPsec or TLS, might make more sense. New security algorithms a very hard to design, it took over a year for the MIP group to design the RR security algorithm, for example. I frankly don't think that the security problems of CT are so different that they need a new algorithm. In addition, there was nothing said about security on individual feature contexts. I don't know if the topic was discussed in the DT, but it certainly is something that needs consideration. Detailed Comments -------------------- I've included actual text from the draft, with comments: Seamoby WG J. Loughney (editor) Internet Draft M. Nakhjiri Category: Standards Track C. Perkins R. Koodli Expires: September 2003 March 2003 Context Transfer Protocol jak> Why not "Context Transfer Protocol (CTxP)"? Abstract This document presents a context transfer protocol that enables authorized context transfers. Context transfers allows better ^^^^ allow support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reducing latency, packet losses and avoid re-initiation of signaling to and from the mobile node. jak> The abstract is not very descriptive of what the draft is about. What is a context? What is node based mobility? 1.0 Introduction jak> Terms are used here before being defined. What is a context? What is a feature? These need to be defined in the text or in a terminology section, and should in any event be defined before being used. Access Routers typically establish state in order to effect certain forwarding treatments to packet streams belonging to nodes sharing the access router. For instance, an access router may establish an ^^ remove AAA session state and a QoS state for a node's packet streams. When ^^ remove * Bandwidth savings. Re-establishing multiple contexts over an expensive, low-speed link can be avoided by relocating contexts ^ wireless over a potentially higher-speed wire. * Either nAR or pAR may request or start (respectively) context transfer based on internal or network triggers (see Appendix B). ^^^^^^^ don't you mean link triggers? I don't think you are talking about ICMP Host Unreachable or anything like that. Typically, the source node is a MN's Previous Access Router (pAR) and the target node is MN's New Access Router (nAR). We assume that pAR and nAR share an appropriate security association, set up ^^^^^^^^^^^^^^^ is IPsec meant here or something different? independently and prior to context transfer. Any appropriate mechanism may be used in setting up this security association; it enables the CT peers to utilize a secure channel for transferring contexts, providing authentication, integrity, and (if needed) confidentiality. Context Transfer takes place when an event, such as a handover, takes place. We call such an event as a Context Transfer Trigger. In ^^ remove response to such a trigger, the pAR may transfer the contexts; the NAR may request contexts and the MN may send a message to the PAR to transfer contexts. Such a trigger must be capable of providing the necessary information, such as the MN's IP address with which the contexts are associated, the IP addresses of the access routers, and authorization to transfer context. Context transfer protocol messages use Context Types that identify the way that data is organized for the particular feature contexts. The Context Types (CPTs) are registered in a number space (with IANA Type Numbers) that allows a node to unambiguously determine the type of context and the context parameters present in the protocol messages. Contexts are transferred by laying out the appropriate feature data within Context Data Blocks according to the format in section 2.3, as well as any IP addresses necessary to associate the contexts to a particular MN. The context transfer initiation messages contain parameters that identify the source and target nodes, the desired list of feature contexts and IP addresses to ^^^^^^^^^^^ What IP addresses? At this point in the document, it is not clear how the IP address would work. If you mean a care of address, is it the address on the old link or new? If a home address, how does the AR associate that with a particular host? The Previous Access Router transfers feature contexts under two general scenarios. First, it may receive a Context Transfer Start ^^^ A quick summary of the scenarios with reference to the ladder diagrams would help the reader. Request (CTSR) message from the MN whose feature contexts are to be transferred, or it receives an internally generated trigger (e.g., a link-layer trigger on the interface to which the MN is connected). Loughney et al. expires August 2003 [Page 5] Internet-Draft February 2003 The CTSR message, described in Section 2.4.1, provides the IP address of NAR, the IP address of MN on PAR, the list of feature contexts to be transferred (by default requesting all contexts to be transferred), and a token authorizing the transfer. It also includes the MN's new IP address (valid on NAR) whenever it is known. In response to a CT-Start Request message or to the CT trigger, PAR predictively transmits a Context Transfer Data (CTD) message that contains feature contexts. This message, described in Section 2.4.2, contains the MN's previous IP address and its new IP address ^^^^^^^^^^^ How can the MN know this prior to getting on the new link and doing DAD? If there are specific dependencies on other protocols, for example FMIP, then that needs to be called out. (whenever known). It also includes a key, and an indication to use a particular algorithm to assist NAR in computing a token that it could use to check authorization prior to making the contexts available to the MN. In the second scenario, pAR receives a Context Transfer Request (CT Request) described in Section 2.4.5, message from nAR. The nAR itself generates the CT Request message either as a result of receiving the CTSR message or as a response to an internal trigger (that indicates the MN's attachment). In the CT-Req message, nAR supplies the MN's previous IP address, the feature contexts to be transferred, and a token (typically generated by the MN) authorizing context transfer. In response to CT Request message, pAR transmits a Context Transfer Data (CTD) message that includes the MN's previous IP address and feature contexts. When it receives a corresponding CTD message, nAR may generate a CTD Reply message (See Section 2.4.3) to report the status of processing the received contexts. In this "reactive" transfer of contexts, PAR verifies authorization token before transmitting the contexts, and hence does not include the key and the name of algorithm in the CTD message. jak> I'm having trouble understanding how the authentication token would work if the AR sends the context in response to a link trigger. Must the MN negotiate with the AR first to provide it with the token, at some point prior to the handover? Or does the AR ask the MN for the token? What is the basic motivation for having a token anyway? If the routers have a trust relationship, verified via the (presumably IPsec) security relationship cited previously in the draft and a (presumably AH) MAC or digital signature on the CT signaling, shouldn't they trust each other to not send deceptive information? If the MN has negotiated an AAA exchange to get into the network, then shouldn't the MN trust the provider's network to handle its routing and handover information expeditiously and with discretion? Otherwise, wouldn't the MN put source routing headers on all its packets because it wouldn't trust the provider's IGP to set up routing tables correctly? There is an issue with MN to router signaling being trusted, but, again, shouldn't that be handled by a standard IPsec security relationship, or, alternatively, TLS if TCP is used? Performing context transfer in advance of the MN attaching to NAR clearly has potential for better performance. For this to take place, certain conditions must be met. For example, PAR must have sufficient time and knowledge about the impending handover. This is feasible for instance in Mobile IP fast handovers. However, when the advance knowledge of impending handover is not available, or if a mechanism such as fast handover fails, retrieving feature contexts after the MN attaches to NAR is the only available means for context transfer. Performing context transfer after handover might still be better than having to re-establish all the contexts from scratch. Finally, some contexts may simply need to be transferred during handover signaling. For instance, any context that gets updated on a per-packet basis must clearly be transferred only after packet forwarding to the MN on its previous link is terminated. Transfer of such contexts must be properly synchronized with appropriate handover messages, such as Mobile IP (Fast) Binding Update. ^^^^^^^^^^^^^^^^^^^^^^^^^^ This is an assumption of a particular (version of) a particular handover protocol. 2.2 Context Types Contexts are identified by context type, which is a 32-bit number. The meaning of each context type is determined by a specification document and the context type numbers are to be tabulated in a registry maintained by IANA, and handled according to the message specifications in this document. The instantiation of each context jak> The above isn't enough to tie down how CT feature contexts are standardized. Is the method of IETF concensus used, or can anybody just submit an individual contribution to the IESG? Please see RFC 2608 for an example of text that precisely specifies the steps needed to standardize different extensions to a protocol. 2.3 Context Data Block jak> I'm sorry, but this went completely over my head. What is the purpose of the presence vector? I can't see what this is trying to achieve. Why not use a simple TLV format? 2.4 Messages In this section, a list of the available context transfer message types is given, along with a brief description of their functions. Generally, messages use the following generic message header format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |reserve| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / message data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ jak> Why is the length 12 bits? Why not byte align it? Actually, I think in IPv6 it must be byte aligned. 2.4.1 Context Transfer Start Request (CTSR) Message Sent by MN to nAR to request start of context transfer. It is for jak> Must the MN be on link when this is sent, or can it be sent from the old link? ICMP and UDP do not provide congestion control, while TCP/SCTP do provide congestion control. The connection setup for those congestion control transport protocols may introduce delays in start of data transfer, but do protect the network from becoming jak> There are well-known ways to handle start up delays: cache the connections. This should be especially possible with the interrouter CT since the topology won't change often. It is assumed that intra-domain time-critical context transfer should take no more than one kilobyte, based on existing implementation of jak> Where did this number come from? If you have some experimental data to support this, then why not present a table in the draft, or a reference to a paper where the experiment is discussed in detail. As it currently stands, it looks as if the number was picked out of the air. some context transfer solutions. Contexts that are significantly larger are assumed not so time critical. For a larger number of users, say one thousand users requesting a smooth handover all in the same second, the total bandwidth needed is still a small fraction of a typical Ethernet or frame relay or ATM link between access routers. So even bursty traffic is unlikely to introduce local congestion. Furthermore, physically adjacent access routers should be within one or two IP hops of each other, so the effects of context transfer should be localized. If transferring real-time contexts triggers congestive errors, the access network may be seriously under- provisioned. jak> The discussion above assumes that intra-provider CT won't go over the Internet. This isn't clear to me. Suppose I have a hotspot network in which I can move from Starbucks across the street to The Lunchtime Cafe on this side, and both are handled by T-Mobile. Both sides are in the same ISPs network, but the wired traffic may have to go over the Internet if there is no direct connnection. Since the wireless cells may overlap, a mobile could move between the two wirelessly, and it would not involve an inter-domain move, because both hotspots are managed by T-Mobile. 4.3 Failure Handling Failure of Context Transfer should at least cause no harm to the network or to the user session. Failure reporting to the mobile node may be needed. The details about how failure can be reported for some individual contexts but not requiring retransmission of all contexts should be straightforward but remain to be worked out. ^^^^^^^^^^^^^^^^^^^^^ Another big, unresolved issue. :-( 4.4 Zone of Operation Currently, the authors are restricting discussion of CTP to intra- domain signaling. Discussion of inter-domain signaling left for later discussions. jak> This should be stated at the beginning in a section called "Goals and Nongoals" or something like that. Is a new message CT request needed? ^^^^^^^^^^^^^^^ Sure seems that way to me from your diagram. 5.3 Mobile controlled, Predictive New L2 up/old L2 down jak> If this is predictive, then why is the CTSR being sent to nAR? Predictive means the MN or pAR has information prior to the handover that could be used to optimize. The CTSR relay is the CTSR message that is destined to pAR and is routed through nAR (routing details later). In case CT cannot be supported, a CTSR reject maybe sent to the MN through nAR. jak> I don't understand the CTSR relay. Why is this needed? It was not introduced in the draft until this point. Furthermore, either one or both of the pAR and nAR need to be able authenticate the mobile and authorize mobile's credential before jak> Why is this necessary? It sounds like you are saying that prior to every handover, this must be done. If the MN is authenticated to use the router, then why must it be authenticated again for the handover? Isn't it enough to have signaling triggering CT from the MN that can be authentically tied the the MN? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 16:39:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14039 for ; Thu, 6 Mar 2003 16:39:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26LnoO18111; Thu, 6 Mar 2003 16:49:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26LmGO18002 for ; Thu, 6 Mar 2003 16:48:16 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13886 for ; Thu, 6 Mar 2003 16:36:31 -0500 (EST) Message-ID: <022a01c2e428$86e1b980$156015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 6 Mar 2003 13:37:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Review of draft-ietf-seamoby-ctp-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pat has been following CT more closely than I, so some of my comments may be due to unfamiliarity with the topic, but unfortunately he hasn't had much time recently to spend on CT. I have a few general comments, including editorial comments, then some more detailed comments. jak -------------------------------------------- General Comments -------------------- 1) The draft begins rather abruptly. I think there is a need for some, shall we say, context transfer :-) from the problem statement and requirements draft at the very beginning to ease the transition. There should be a section with goals and nongoals, so people have an overall impression about what the protocol is trying to do. In addition, the ladder diagrams in Section 5 would probably be better at the beginning so that people have some idea about how the protocol works before diving into detials. For example, when I read through Section 2, it was unclear to me whether pAR could send context to nAR in response to a link trigger, which seems clearly needed for certain time critical handovers. 2) I was quite disappointed to see that the transport issue has still not been resolved. This was certainly at the top of my list for topics that should be complete by this stage. If I recall correctly, I asked the DT about this in Atlanta and was assured that the issue would be resolved quickly, yet it has not been. My technical opinion is that the ladder diagrams in Section 5 suggest two transport modes: one between the MN and AR and another between ARs. More detailed consideration of this might help sort out some aspects of transport. 3) The security model in this draft is extremely vague. An "authorization token" from the MN is specified, but the construction of the token, its security properties, and the provisioning of the participants in the trust relationships involved in CT are left as an exercise to the reader. My opinion is that the DT and WG should revisit this decision and consider whether using more standardized security mechanisms, such as IPsec or TLS, might make more sense. New security algorithms a very hard to design, it took over a year for the MIP group to design the RR security algorithm, for example. I frankly don't think that the security problems of CT are so different that they need a new algorithm. In addition, there was nothing said about security on individual feature contexts. I don't know if the topic was discussed in the DT, but it certainly is something that needs consideration. Detailed Comments -------------------- I've included actual text from the draft, with comments: Seamoby WG J. Loughney (editor) Internet Draft M. Nakhjiri Category: Standards Track C. Perkins R. Koodli Expires: September 2003 March 2003 Context Transfer Protocol jak> Why not "Context Transfer Protocol (CTxP)"? Abstract This document presents a context transfer protocol that enables authorized context transfers. Context transfers allows better ^^^^ allow support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reducing latency, packet losses and avoid re-initiation of signaling to and from the mobile node. jak> The abstract is not very descriptive of what the draft is about. What is a context? What is node based mobility? 1.0 Introduction jak> Terms are used here before being defined. What is a context? What is a feature? These need to be defined in the text or in a terminology section, and should in any event be defined before being used. Access Routers typically establish state in order to effect certain forwarding treatments to packet streams belonging to nodes sharing the access router. For instance, an access router may establish an ^^ remove AAA session state and a QoS state for a node's packet streams. When ^^ remove * Bandwidth savings. Re-establishing multiple contexts over an expensive, low-speed link can be avoided by relocating contexts ^ wireless over a potentially higher-speed wire. * Either nAR or pAR may request or start (respectively) context transfer based on internal or network triggers (see Appendix B). ^^^^^^^ don't you mean link triggers? I don't think you are talking about ICMP Host Unreachable or anything like that. Typically, the source node is a MN's Previous Access Router (pAR) and the target node is MN's New Access Router (nAR). We assume that pAR and nAR share an appropriate security association, set up ^^^^^^^^^^^^^^^ is IPsec meant here or something different? independently and prior to context transfer. Any appropriate mechanism may be used in setting up this security association; it enables the CT peers to utilize a secure channel for transferring contexts, providing authentication, integrity, and (if needed) confidentiality. Context Transfer takes place when an event, such as a handover, takes place. We call such an event as a Context Transfer Trigger. In ^^ remove response to such a trigger, the pAR may transfer the contexts; the NAR may request contexts and the MN may send a message to the PAR to transfer contexts. Such a trigger must be capable of providing the necessary information, such as the MN's IP address with which the contexts are associated, the IP addresses of the access routers, and authorization to transfer context. Context transfer protocol messages use Context Types that identify the way that data is organized for the particular feature contexts. The Context Types (CPTs) are registered in a number space (with IANA Type Numbers) that allows a node to unambiguously determine the type of context and the context parameters present in the protocol messages. Contexts are transferred by laying out the appropriate feature data within Context Data Blocks according to the format in section 2.3, as well as any IP addresses necessary to associate the contexts to a particular MN. The context transfer initiation messages contain parameters that identify the source and target nodes, the desired list of feature contexts and IP addresses to ^^^^^^^^^^^ What IP addresses? At this point in the document, it is not clear how the IP address would work. If you mean a care of address, is it the address on the old link or new? If a home address, how does the AR associate that with a particular host? The Previous Access Router transfers feature contexts under two general scenarios. First, it may receive a Context Transfer Start ^^^ A quick summary of the scenarios with reference to the ladder diagrams would help the reader. Request (CTSR) message from the MN whose feature contexts are to be transferred, or it receives an internally generated trigger (e.g., a link-layer trigger on the interface to which the MN is connected). Loughney et al. expires August 2003 [Page 5] Internet-Draft February 2003 The CTSR message, described in Section 2.4.1, provides the IP address of NAR, the IP address of MN on PAR, the list of feature contexts to be transferred (by default requesting all contexts to be transferred), and a token authorizing the transfer. It also includes the MN's new IP address (valid on NAR) whenever it is known. In response to a CT-Start Request message or to the CT trigger, PAR predictively transmits a Context Transfer Data (CTD) message that contains feature contexts. This message, described in Section 2.4.2, contains the MN's previous IP address and its new IP address ^^^^^^^^^^^ How can the MN know this prior to getting on the new link and doing DAD? If there are specific dependencies on other protocols, for example FMIP, then that needs to be called out. (whenever known). It also includes a key, and an indication to use a particular algorithm to assist NAR in computing a token that it could use to check authorization prior to making the contexts available to the MN. In the second scenario, pAR receives a Context Transfer Request (CT Request) described in Section 2.4.5, message from nAR. The nAR itself generates the CT Request message either as a result of receiving the CTSR message or as a response to an internal trigger (that indicates the MN's attachment). In the CT-Req message, nAR supplies the MN's previous IP address, the feature contexts to be transferred, and a token (typically generated by the MN) authorizing context transfer. In response to CT Request message, pAR transmits a Context Transfer Data (CTD) message that includes the MN's previous IP address and feature contexts. When it receives a corresponding CTD message, nAR may generate a CTD Reply message (See Section 2.4.3) to report the status of processing the received contexts. In this "reactive" transfer of contexts, PAR verifies authorization token before transmitting the contexts, and hence does not include the key and the name of algorithm in the CTD message. jak> I'm having trouble understanding how the authentication token would work if the AR sends the context in response to a link trigger. Must the MN negotiate with the AR first to provide it with the token, at some point prior to the handover? Or does the AR ask the MN for the token? What is the basic motivation for having a token anyway? If the routers have a trust relationship, verified via the (presumably IPsec) security relationship cited previously in the draft and a (presumably AH) MAC or digital signature on the CT signaling, shouldn't they trust each other to not send deceptive information? If the MN has negotiated an AAA exchange to get into the network, then shouldn't the MN trust the provider's network to handle its routing and handover information expeditiously and with discretion? Otherwise, wouldn't the MN put source routing headers on all its packets because it wouldn't trust the provider's IGP to set up routing tables correctly? There is an issue with MN to router signaling being trusted, but, again, shouldn't that be handled by a standard IPsec security relationship, or, alternatively, TLS if TCP is used? Performing context transfer in advance of the MN attaching to NAR clearly has potential for better performance. For this to take place, certain conditions must be met. For example, PAR must have sufficient time and knowledge about the impending handover. This is feasible for instance in Mobile IP fast handovers. However, when the advance knowledge of impending handover is not available, or if a mechanism such as fast handover fails, retrieving feature contexts after the MN attaches to NAR is the only available means for context transfer. Performing context transfer after handover might still be better than having to re-establish all the contexts from scratch. Finally, some contexts may simply need to be transferred during handover signaling. For instance, any context that gets updated on a per-packet basis must clearly be transferred only after packet forwarding to the MN on its previous link is terminated. Transfer of such contexts must be properly synchronized with appropriate handover messages, such as Mobile IP (Fast) Binding Update. ^^^^^^^^^^^^^^^^^^^^^^^^^^ This is an assumption of a particular (version of) a particular handover protocol. 2.2 Context Types Contexts are identified by context type, which is a 32-bit number. The meaning of each context type is determined by a specification document and the context type numbers are to be tabulated in a registry maintained by IANA, and handled according to the message specifications in this document. The instantiation of each context jak> The above isn't enough to tie down how CT feature contexts are standardized. Is the method of IETF concensus used, or can anybody just submit an individual contribution to the IESG? Please see RFC 2608 for an example of text that precisely specifies the steps needed to standardize different extensions to a protocol. 2.3 Context Data Block jak> I'm sorry, but this went completely over my head. What is the purpose of the presence vector? I can't see what this is trying to achieve. Why not use a simple TLV format? 2.4 Messages In this section, a list of the available context transfer message types is given, along with a brief description of their functions. Generally, messages use the following generic message header format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |reserve| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / message data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ jak> Why is the length 12 bits? Why not byte align it? Actually, I think in IPv6 it must be byte aligned. 2.4.1 Context Transfer Start Request (CTSR) Message Sent by MN to nAR to request start of context transfer. It is for jak> Must the MN be on link when this is sent, or can it be sent from the old link? ICMP and UDP do not provide congestion control, while TCP/SCTP do provide congestion control. The connection setup for those congestion control transport protocols may introduce delays in start of data transfer, but do protect the network from becoming jak> There are well-known ways to handle start up delays: cache the connections. This should be especially possible with the interrouter CT since the topology won't change often. It is assumed that intra-domain time-critical context transfer should take no more than one kilobyte, based on existing implementation of jak> Where did this number come from? If you have some experimental data to support this, then why not present a table in the draft, or a reference to a paper where the experiment is discussed in detail. As it currently stands, it looks as if the number was picked out of the air. some context transfer solutions. Contexts that are significantly larger are assumed not so time critical. For a larger number of users, say one thousand users requesting a smooth handover all in the same second, the total bandwidth needed is still a small fraction of a typical Ethernet or frame relay or ATM link between access routers. So even bursty traffic is unlikely to introduce local congestion. Furthermore, physically adjacent access routers should be within one or two IP hops of each other, so the effects of context transfer should be localized. If transferring real-time contexts triggers congestive errors, the access network may be seriously under- provisioned. jak> The discussion above assumes that intra-provider CT won't go over the Internet. This isn't clear to me. Suppose I have a hotspot network in which I can move from Starbucks across the street to The Lunchtime Cafe on this side, and both are handled by T-Mobile. Both sides are in the same ISPs network, but the wired traffic may have to go over the Internet if there is no direct connnection. Since the wireless cells may overlap, a mobile could move between the two wirelessly, and it would not involve an inter-domain move, because both hotspots are managed by T-Mobile. 4.3 Failure Handling Failure of Context Transfer should at least cause no harm to the network or to the user session. Failure reporting to the mobile node may be needed. The details about how failure can be reported for some individual contexts but not requiring retransmission of all contexts should be straightforward but remain to be worked out. ^^^^^^^^^^^^^^^^^^^^^ Another big, unresolved issue. :-( 4.4 Zone of Operation Currently, the authors are restricting discussion of CTP to intra- domain signaling. Discussion of inter-domain signaling left for later discussions. jak> This should be stated at the beginning in a section called "Goals and Nongoals" or something like that. Is a new message CT request needed? ^^^^^^^^^^^^^^^ Sure seems that way to me from your diagram. 5.3 Mobile controlled, Predictive New L2 up/old L2 down jak> If this is predictive, then why is the CTSR being sent to nAR? Predictive means the MN or pAR has information prior to the handover that could be used to optimize. The CTSR relay is the CTSR message that is destined to pAR and is routed through nAR (routing details later). In case CT cannot be supported, a CTSR reject maybe sent to the MN through nAR. jak> I don't understand the CTSR relay. Why is this needed? It was not introduced in the draft until this point. Furthermore, either one or both of the pAR and nAR need to be able authenticate the mobile and authorize mobile's credential before jak> Why is this necessary? It sounds like you are saying that prior to every handover, this must be done. If the MN is authenticated to use the router, then why must it be authenticated again for the handover? Isn't it enough to have signaling triggering CT from the MN that can be authentically tied the the MN? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 16:57:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14860 for ; Thu, 6 Mar 2003 16:57:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26M8QW20668 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 17:08:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26M8QO20665 for ; Thu, 6 Mar 2003 17:08:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14852 for ; Thu, 6 Mar 2003 16:56:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26M8AO20651; Thu, 6 Mar 2003 17:08:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26M73O19924 for ; Thu, 6 Mar 2003 17:07:03 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14821 for ; Thu, 6 Mar 2003 16:55:20 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h26LwGI5009376 for ; Thu, 6 Mar 2003 14:58:16 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA28033 for ; Thu, 6 Mar 2003 14:57:24 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 15:57:23 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE38@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 15:57:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 06, 2003 12:51 PM To: Ajoy Singh; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Ajoy, My replies are embedded. -Govind. I meant every time cache times out, your proposed scheme (dycard) will perform slow handoff. But in case of server based approach this may not be the case. In server based approach, AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the current AR may not be required to query AR server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [Govind] Why will cache time out if there are frequent handovers. Plus once two ARs have recognized each other as CARs, why can't we setup a refresh procedure. Doesn't that take care of it? AJOY-> Sure you can but I think you are complicating the protocol. The L2-> L3 mapping is a simple problem and we should keep it simple. Secondly, what do you mean "properly placing the server with respect to the AR, we minimize the round trip delay". AJOY-> BTW, you do not need do this because L2->L3 mapping is initiated by link layer trigger that happens prior to L2 handoff. Hence, I do not see any reason to optimize this RTT. This is probably noto relevant in this context. The scope-id reduces the cache contamination problem, the potential growth of AR cache is bounded. This will eliminate the problem introduced due to unbounded cache growth. For example, in case of dycard, you might have a situation where the AR cache will overflow if a mobile node keeps injecting wrong information to the AR. This will cause AR to either crash or remove the old useful cache entries. Potentially this will create a situation where AR will loose valid cache entries to populate invalid entries. Is it not correct? [Govind] First, if you read dycard you will see that the "overflow" problem that you talk about is almost impossible. We do this by a scheme wherein we restrict the number of entries that can be created by each MN. AJOY-> I am not sure just limiting the number of entries created by single MN will fix this problem. The attacker can use multiple MN to launch such attack. Whereas this type of attack is not possible when scope-id is used? Also, I don't think your scope-id solution anyway reduces the problem. You are saying that if we have "n" incorrect entries in the cache it is not a problem, where n can be arbitrarily large right (atleast w.r.t the cache size) ? I don't quite agree with that. AJOY-> You can configure the appropriately sized cache at AR if you know the number of ARs being covered by a given scope-id. This will also ensure that cache overflow would never happen. Hence, it will be impossible for an attacker to inject fake message to remove the useful entries from the AR. I do not see how will you achieve this in dycard? [snip] Won't next handoff performed by dycard will be slow after cache timeout? BTW, this is necessarily not a problem with server based approach. The AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the AR may not be required to query CARD server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [Govind] I disagree with your premise that dycard introduces frequent cache misses. This statement is terribly flawed. Rather, I think in the steady state the server is useless. If you have a proper cache update policy and make sure DoS is hard, we are through. AJOY-> This is difficult to justify without proper data from real deployment or simulation. Do have any real data to prove me otherwise? [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? Could you please explain how dycard plans to avoid the problem of cache overflow? [Govind] Sure, we restrict the number of entries that each MN can create in the server. The number of entries is configurable. We make sure that the MN was actually present in the previous ARs domain in the "recent" past. Where "recent" is a variable that can be configured. AJOY-> This does not fix the problem. The attacker can use multiple MN to launch such attack. Do you believe that service provider would deploy an such network that can be disabled by few malicious attackers? It is relatively inexpensive to provide redundancy of a server that only does L2->L3 mapping. This function can be easily piggybacked upon existing high availability server platform. [Govind] I don't disagree with the fact that it might be relatively inexpensive to provide reliability. AJOY-> OK But look at the cost in terms of any benefit you receive from the server. It doesn't add up. Plus, you have consistency issues to take care of when you have redundancy. Instead, why not have a server at each AR then? AJOY-> What is the cost? You can deploy the CARD server on existing server platform for example AAA platform. I do not see any extra cost of doing this. [Govind] What advantage do you have by manually configuring scope-ids? If that is the case, why don't you program it in routers themselves and make themselves aware of their scope-id? AJOY-> Well you can. This means that every time you configure a router, you have to configure its scope-id. Whereas in former case, you can do it at once? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 16:57:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14885 for ; Thu, 6 Mar 2003 16:57:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26M8AO20651; Thu, 6 Mar 2003 17:08:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26M73O19924 for ; Thu, 6 Mar 2003 17:07:03 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14821 for ; Thu, 6 Mar 2003 16:55:20 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h26LwGI5009376 for ; Thu, 6 Mar 2003 14:58:16 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA28033 for ; Thu, 6 Mar 2003 14:57:24 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 15:57:23 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE38@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 15:57:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 06, 2003 12:51 PM To: Ajoy Singh; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Ajoy, My replies are embedded. -Govind. I meant every time cache times out, your proposed scheme (dycard) will perform slow handoff. But in case of server based approach this may not be the case. In server based approach, AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the current AR may not be required to query AR server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [Govind] Why will cache time out if there are frequent handovers. Plus once two ARs have recognized each other as CARs, why can't we setup a refresh procedure. Doesn't that take care of it? AJOY-> Sure you can but I think you are complicating the protocol. The L2-> L3 mapping is a simple problem and we should keep it simple. Secondly, what do you mean "properly placing the server with respect to the AR, we minimize the round trip delay". AJOY-> BTW, you do not need do this because L2->L3 mapping is initiated by link layer trigger that happens prior to L2 handoff. Hence, I do not see any reason to optimize this RTT. This is probably noto relevant in this context. The scope-id reduces the cache contamination problem, the potential growth of AR cache is bounded. This will eliminate the problem introduced due to unbounded cache growth. For example, in case of dycard, you might have a situation where the AR cache will overflow if a mobile node keeps injecting wrong information to the AR. This will cause AR to either crash or remove the old useful cache entries. Potentially this will create a situation where AR will loose valid cache entries to populate invalid entries. Is it not correct? [Govind] First, if you read dycard you will see that the "overflow" problem that you talk about is almost impossible. We do this by a scheme wherein we restrict the number of entries that can be created by each MN. AJOY-> I am not sure just limiting the number of entries created by single MN will fix this problem. The attacker can use multiple MN to launch such attack. Whereas this type of attack is not possible when scope-id is used? Also, I don't think your scope-id solution anyway reduces the problem. You are saying that if we have "n" incorrect entries in the cache it is not a problem, where n can be arbitrarily large right (atleast w.r.t the cache size) ? I don't quite agree with that. AJOY-> You can configure the appropriately sized cache at AR if you know the number of ARs being covered by a given scope-id. This will also ensure that cache overflow would never happen. Hence, it will be impossible for an attacker to inject fake message to remove the useful entries from the AR. I do not see how will you achieve this in dycard? [snip] Won't next handoff performed by dycard will be slow after cache timeout? BTW, this is necessarily not a problem with server based approach. The AR cache is updated when a mobile node scans the neighboring channel and detects a new link layer id. In this it is likely that the server cache will be updated prior to layer 3 handoff. Hence, the AR may not be required to query CARD server during critical path of handoff. Also, by properly placing the server with respect to AR, you can minimize the round trip delay with server. [Govind] I disagree with your premise that dycard introduces frequent cache misses. This statement is terribly flawed. Rather, I think in the steady state the server is useless. If you have a proper cache update policy and make sure DoS is hard, we are through. AJOY-> This is difficult to justify without proper data from real deployment or simulation. Do have any real data to prove me otherwise? [Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? Could you please explain how dycard plans to avoid the problem of cache overflow? [Govind] Sure, we restrict the number of entries that each MN can create in the server. The number of entries is configurable. We make sure that the MN was actually present in the previous ARs domain in the "recent" past. Where "recent" is a variable that can be configured. AJOY-> This does not fix the problem. The attacker can use multiple MN to launch such attack. Do you believe that service provider would deploy an such network that can be disabled by few malicious attackers? It is relatively inexpensive to provide redundancy of a server that only does L2->L3 mapping. This function can be easily piggybacked upon existing high availability server platform. [Govind] I don't disagree with the fact that it might be relatively inexpensive to provide reliability. AJOY-> OK But look at the cost in terms of any benefit you receive from the server. It doesn't add up. Plus, you have consistency issues to take care of when you have redundancy. Instead, why not have a server at each AR then? AJOY-> What is the cost? You can deploy the CARD server on existing server platform for example AAA platform. I do not see any extra cost of doing this. [Govind] What advantage do you have by manually configuring scope-ids? If that is the case, why don't you program it in routers themselves and make themselves aware of their scope-id? AJOY-> Well you can. This means that every time you configure a router, you have to configure its scope-id. Whereas in former case, you can do it at once? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 17:07:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15260 for ; Thu, 6 Mar 2003 17:07:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26MIDF21157 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 17:18:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MIDO21154 for ; Thu, 6 Mar 2003 17:18:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15249 for ; Thu, 6 Mar 2003 17:06:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MI4O21133; Thu, 6 Mar 2003 17:18:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MHEO21099 for ; Thu, 6 Mar 2003 17:17:14 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15238 for ; Thu, 6 Mar 2003 17:05:31 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 17:07:35 -0500 Message-ID: <031b01c2e446$1b7e4960$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <014701c2e409$c7938e50$156015ac@T23KEMPF> Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 17:08:47 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 06 Mar 2003 22:07:35.0549 (UTC) FILETIME=[CB0372D0:01C2E42C] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Kempf" To: ; Sent: Thursday, March 06, 2003 9:56 AM Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > dropping 2) > > and making this signaling a collection of options on FMIP. In addition, I > would > > suggest that the CARD design team co-ordinate this with the current editor of > > the FMIP draft. There is no point in having 2) if FMIP provides the > > functionality. > > > > [Govind] > > I do agree that we can optimize CARD if we know FMIP (I think you mean v6) > > is going to be available in the subnet. However, CARD is needed to operate in > domains > > that are not IPv6. I would think the better way to go is FMIP and other > seamless > > mobility protocols were to use CARD messages for this purpose. I think this > was > > pointed out in an email on the mobile-ip working group. > > > > I would argue that events have overtaken us and CARD is no longer relevant for > IPv4 from a market perspective. Certainly, this is the case with other advanced > IP mobility technologies, like the fast handover technologies CARD was supposed > to support. I believe it makes more sense to have CARD be a well-integrated part > of the local link movement protocols for IPv6, where there is still some > interest in technology development on advanced IP mobility technologies. > (eunsoo) Well, I have been seeing commercial products with Mobile IPv4. I don't think we should forget about IPv4 yet. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 17:07:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15279 for ; Thu, 6 Mar 2003 17:07:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MI4O21133; Thu, 6 Mar 2003 17:18:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MHEO21099 for ; Thu, 6 Mar 2003 17:17:14 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15238 for ; Thu, 6 Mar 2003 17:05:31 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 17:07:35 -0500 Message-ID: <031b01c2e446$1b7e4960$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <014701c2e409$c7938e50$156015ac@T23KEMPF> Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 17:08:47 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 06 Mar 2003 22:07:35.0549 (UTC) FILETIME=[CB0372D0:01C2E42C] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Kempf" To: ; Sent: Thursday, March 06, 2003 9:56 AM Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > dropping 2) > > and making this signaling a collection of options on FMIP. In addition, I > would > > suggest that the CARD design team co-ordinate this with the current editor of > > the FMIP draft. There is no point in having 2) if FMIP provides the > > functionality. > > > > [Govind] > > I do agree that we can optimize CARD if we know FMIP (I think you mean v6) > > is going to be available in the subnet. However, CARD is needed to operate in > domains > > that are not IPv6. I would think the better way to go is FMIP and other > seamless > > mobility protocols were to use CARD messages for this purpose. I think this > was > > pointed out in an email on the mobile-ip working group. > > > > I would argue that events have overtaken us and CARD is no longer relevant for > IPv4 from a market perspective. Certainly, this is the case with other advanced > IP mobility technologies, like the fast handover technologies CARD was supposed > to support. I believe it makes more sense to have CARD be a well-integrated part > of the local link movement protocols for IPv6, where there is still some > interest in technology development on advanced IP mobility technologies. > (eunsoo) Well, I have been seeing commercial products with Mobile IPv4. I don't think we should forget about IPv4 yet. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 17:17:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15583 for ; Thu, 6 Mar 2003 17:17:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26MSLJ21680 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 17:28:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MSLO21677 for ; Thu, 6 Mar 2003 17:28:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15575 for ; Thu, 6 Mar 2003 17:16:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MS9O21658; Thu, 6 Mar 2003 17:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MRWO21642 for ; Thu, 6 Mar 2003 17:27:32 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15544 for ; Thu, 6 Mar 2003 17:15:49 -0500 (EST) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h26MHq112075 for ; Thu, 6 Mar 2003 14:17:52 -0800 (PST) Message-ID: <3E67C910.9060200@cs.ucsb.edu> Date: Thu, 06 Mar 2003 14:17:52 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] CARD Draft References: <01d401c2e282$bbf1b140$636015ac@T23KEMPF> In-Reply-To: <01d401c2e282$bbf1b140$636015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For my own sanity as well as for some others on the mailing list, let me try to summarize some of the key points concerning the DT draft as it compares to a serverless, learning-based approach (dyCARD). I'll try to be fair, but I should note that I'm in favor of the latter approach. 1. What are the advantages of a server-based approach? 1.a. AR-AP mappings are known to be valid. However, in a learning-based approach, each AR knows about its own AP mappings. So, why can't I ask the AR in question rather than the server. Won't the validity of the answer be equivalent? 1.b. AR-AP mappings are more convenient to manage. Actually, the way I read the DT draft, the ARs register their AP mappings with the server. This implies that the management is not done centrally at the server. In any case, using a centralized server to manage the valid AP-AR mappings is a fine idea, but doesn't imply that the server must be part of the resolution process. Rather, it seems like a completely separate issue: how to manage configuration data (AR-AP mappings) for a large number of routers. There are a number of existing techniques for doing that, and they are orthogonal to how the mappings are used at the AR. 1.c. Populating the cache with an initial entry does not require handover. This is the strongest argument for the server-based approach, but there are a number of issues that must be addressed to understand the true benefit available. First, the expectation of both techniques, server-based and learning-based, is that the cache is fully populated during steady-state operation. For the learning-based approach, if a AP-AR mapping does not exist, no help is available. In the server-based approach, the time to resolve the mapping with the server, as well as gather any necessary capabilities from the neighboring AR cannot be expected to complete prior to the information being needed for TAR selection. Consider a MN moving through an AP's coverage area. Let's say from left to right for simplicity. Performing resolution early will most likely provide mappings and capabilities for the APs on the left of the coverage area, thus behind the mobile node. The APs to the right won't become "visible" until the MN approaches the righthand border (unless there is extreme overlap). At this point, the time necessary to resolve the new APs as well as decide to handover may be short. In short, early resolution won't gain you much in way of eventual targets, and late resolution requires cache hits. So for both techniques, proper configuration of lifetimes (or even dynamic lifetimes as Dirk? suggested) are necessary to ensure viable response times. So, the real question is whether both techniques can maintain satisfactory cache fill ratios. This needs some experimentation to confirm, but I think that the server-based approach may have a slight advantage here, and I do mean slight. Just for note, there are techniques that can be used to improve the cache fill ratio of the learning-based technique. In particular, once one handover between two ARs occurs, they can exchange a list of attached APs as a special form of capabilities. This means that as long as handovers continue between the two ARs, no matter which APs are involved, all AR-AP mappings are maintained for the two neighbors. 2. What are the advantages of a learning-based approach. 2.a. No single point of failure. 2.b. No extra entity in the network necessary for the protocol to operate. 2.c. Cache entries actually represent neighboring AR/APs rather than simply valid AR-AP mappings. This could be beneficial if we later wanted to allow a MN to query it's current router with a wildcard. The entries in the cache are known to be neighbors, and thus provide valuable information. This of course ignores the fact of malicious entries, etc. I'll address that in a bit. 2.d. The same protocol scales to the inter-domain case without change. 3. How secure are the two techniques. 3.a. Both techniques rely on an authoritative mapping between and AR and its APs. For the server-based approach this is the server. For the learning-based approach the authority lies at the individual ARs. 3.b. Both techniques rely on a cache to operate without unacceptable delay. Both techniques rely on MN reports to populate the cache. If we accept the fact that MNs may be malicious, the cache must be limited in size to eliminate the chance of exhausting AR memory. Once the cache is limited in size, malicious entries could replace valid entries thus causing a cache-miss. So, the only way to overcome this problem is to validate the cache entries prior to creation, or employ a very clever cache replacement policy. 3.c. The server-based approach cannot adequately validate MN reports prior to creating cache entries. Since the reports are simply MN requests for information, there is little to use for verification. The scope ID concept doesn't seem very applicable. It seems like the network admin would have to very carefully layout these scope IDs to match the overlapping coverage areas, which could change without having to change the network topoloogy (a big building is erected near a base station). Moreover, each AP may be part of many scopes, yes. 3.d. The learning-based approach validates the MN report. Since the report is based on a handover between two APs, the current AR checks whether the current AP is locally attached, the previous AR checks whether the previous AP is locally attached (AR-AP map validation), and the previous AR checks whether the MN was recently present (neighbor validation). 3.e. Other techniques, common to both CARD approaches, exist to limit the impact that a malicious MN can have on the contents of an ARs cache. In particular, an AR can limit the number of entries that any given MN can indirectly create. 3.f. Smart cache replacement policies should be implemented at the AR, no matter which CARD approach you choose. Cache entries derived from local information (learning-based) should be favored over remote info. Entries that are accessed more often for resolution should also be favored. In the end, I don't think that the server is really necessary. It may provide a small benefit for keeping the cache full, but this is completely dependant upon the properties of the network and the dynamics of the MNs. Moreover, I think that the server-based approach is harder to secure against malicious mobiles. For the learning-based approach, an attack requires a large number of mobiles spread across numerous networks working in tight synchronization. For the server-based approach, a few local malicious mobiles could fill the current AR's cache with little effort. enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 17:17:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15604 for ; Thu, 6 Mar 2003 17:17:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MS9O21658; Thu, 6 Mar 2003 17:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MRWO21642 for ; Thu, 6 Mar 2003 17:27:32 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15544 for ; Thu, 6 Mar 2003 17:15:49 -0500 (EST) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h26MHq112075 for ; Thu, 6 Mar 2003 14:17:52 -0800 (PST) Message-ID: <3E67C910.9060200@cs.ucsb.edu> Date: Thu, 06 Mar 2003 14:17:52 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] CARD Draft References: <01d401c2e282$bbf1b140$636015ac@T23KEMPF> In-Reply-To: <01d401c2e282$bbf1b140$636015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit For my own sanity as well as for some others on the mailing list, let me try to summarize some of the key points concerning the DT draft as it compares to a serverless, learning-based approach (dyCARD). I'll try to be fair, but I should note that I'm in favor of the latter approach. 1. What are the advantages of a server-based approach? 1.a. AR-AP mappings are known to be valid. However, in a learning-based approach, each AR knows about its own AP mappings. So, why can't I ask the AR in question rather than the server. Won't the validity of the answer be equivalent? 1.b. AR-AP mappings are more convenient to manage. Actually, the way I read the DT draft, the ARs register their AP mappings with the server. This implies that the management is not done centrally at the server. In any case, using a centralized server to manage the valid AP-AR mappings is a fine idea, but doesn't imply that the server must be part of the resolution process. Rather, it seems like a completely separate issue: how to manage configuration data (AR-AP mappings) for a large number of routers. There are a number of existing techniques for doing that, and they are orthogonal to how the mappings are used at the AR. 1.c. Populating the cache with an initial entry does not require handover. This is the strongest argument for the server-based approach, but there are a number of issues that must be addressed to understand the true benefit available. First, the expectation of both techniques, server-based and learning-based, is that the cache is fully populated during steady-state operation. For the learning-based approach, if a AP-AR mapping does not exist, no help is available. In the server-based approach, the time to resolve the mapping with the server, as well as gather any necessary capabilities from the neighboring AR cannot be expected to complete prior to the information being needed for TAR selection. Consider a MN moving through an AP's coverage area. Let's say from left to right for simplicity. Performing resolution early will most likely provide mappings and capabilities for the APs on the left of the coverage area, thus behind the mobile node. The APs to the right won't become "visible" until the MN approaches the righthand border (unless there is extreme overlap). At this point, the time necessary to resolve the new APs as well as decide to handover may be short. In short, early resolution won't gain you much in way of eventual targets, and late resolution requires cache hits. So for both techniques, proper configuration of lifetimes (or even dynamic lifetimes as Dirk? suggested) are necessary to ensure viable response times. So, the real question is whether both techniques can maintain satisfactory cache fill ratios. This needs some experimentation to confirm, but I think that the server-based approach may have a slight advantage here, and I do mean slight. Just for note, there are techniques that can be used to improve the cache fill ratio of the learning-based technique. In particular, once one handover between two ARs occurs, they can exchange a list of attached APs as a special form of capabilities. This means that as long as handovers continue between the two ARs, no matter which APs are involved, all AR-AP mappings are maintained for the two neighbors. 2. What are the advantages of a learning-based approach. 2.a. No single point of failure. 2.b. No extra entity in the network necessary for the protocol to operate. 2.c. Cache entries actually represent neighboring AR/APs rather than simply valid AR-AP mappings. This could be beneficial if we later wanted to allow a MN to query it's current router with a wildcard. The entries in the cache are known to be neighbors, and thus provide valuable information. This of course ignores the fact of malicious entries, etc. I'll address that in a bit. 2.d. The same protocol scales to the inter-domain case without change. 3. How secure are the two techniques. 3.a. Both techniques rely on an authoritative mapping between and AR and its APs. For the server-based approach this is the server. For the learning-based approach the authority lies at the individual ARs. 3.b. Both techniques rely on a cache to operate without unacceptable delay. Both techniques rely on MN reports to populate the cache. If we accept the fact that MNs may be malicious, the cache must be limited in size to eliminate the chance of exhausting AR memory. Once the cache is limited in size, malicious entries could replace valid entries thus causing a cache-miss. So, the only way to overcome this problem is to validate the cache entries prior to creation, or employ a very clever cache replacement policy. 3.c. The server-based approach cannot adequately validate MN reports prior to creating cache entries. Since the reports are simply MN requests for information, there is little to use for verification. The scope ID concept doesn't seem very applicable. It seems like the network admin would have to very carefully layout these scope IDs to match the overlapping coverage areas, which could change without having to change the network topoloogy (a big building is erected near a base station). Moreover, each AP may be part of many scopes, yes. 3.d. The learning-based approach validates the MN report. Since the report is based on a handover between two APs, the current AR checks whether the current AP is locally attached, the previous AR checks whether the previous AP is locally attached (AR-AP map validation), and the previous AR checks whether the MN was recently present (neighbor validation). 3.e. Other techniques, common to both CARD approaches, exist to limit the impact that a malicious MN can have on the contents of an ARs cache. In particular, an AR can limit the number of entries that any given MN can indirectly create. 3.f. Smart cache replacement policies should be implemented at the AR, no matter which CARD approach you choose. Cache entries derived from local information (learning-based) should be favored over remote info. Entries that are accessed more often for resolution should also be favored. In the end, I don't think that the server is really necessary. It may provide a small benefit for keeping the cache full, but this is completely dependant upon the properties of the network and the dynamics of the MNs. Moreover, I think that the server-based approach is harder to secure against malicious mobiles. For the learning-based approach, an attack requires a large number of mobiles spread across numerous networks working in tight synchronization. For the server-based approach, a few local malicious mobiles could fill the current AR's cache with little effort. enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 17:19:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15649 for ; Thu, 6 Mar 2003 17:19:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26MUjf21843 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 17:30:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MUjO21840 for ; Thu, 6 Mar 2003 17:30:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15643 for ; Thu, 6 Mar 2003 17:19:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MUQO21816; Thu, 6 Mar 2003 17:30:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MTsO21751 for ; Thu, 6 Mar 2003 17:29:54 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15628 for ; Thu, 6 Mar 2003 17:18:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Mar 2003 14:20:14 -0800 X-Originating-IP: [138.15.107.226] From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE38@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 17:21:25 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 06 Mar 2003 22:20:14.0383 (UTC) FILETIME=[8F5053F0:01C2E42E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > The scope-id reduces the cache contamination problem, the > potential growth of AR cache is bounded. This will eliminate the problem > introduced due to unbounded cache growth. For example, in case of dycard, > you might have a situation where the AR cache will overflow if a mobile node > keeps injecting wrong information to the AR. This will cause > AR to either crash or remove the old useful cache entries. Potentially > this will create a situation where AR will loose valid cache entries > to populate invalid entries. Is it not correct? > > [Govind] First, if you read dycard you will see that the "overflow" problem > that you talk about is almost impossible. We do this by a scheme wherein > we restrict the number of entries that can be created by each MN. > > AJOY-> I am not sure just limiting the number of entries created by > single MN will fix this problem. The attacker can use multiple MN to > launch such attack. Whereas this type of attack is not possible > when scope-id is used? > (eunsoo) Ajoy, can you please provide a scenario of how scope id prevents cache contamination? > Also, I don't think your scope-id solution anyway reduces the problem. You > are saying that if we have "n" incorrect entries in the cache it is not > a problem, where n can be arbitrarily large right (atleast w.r.t the cache size) > ? I don't quite agree with that. > > AJOY-> You can configure the appropriately sized > cache at AR if you know the number of ARs being covered > by a given scope-id. This will also ensure that cache > overflow would never happen. Hence, > it will be impossible for an attacker to inject > fake message to remove the useful entries from the > AR. I do not see how will you achieve this in > dycard? > (eunsoo) Now you are proposing the network admin should configure each AR with knowledge of the number of ARs covered by scope id. I am not sure how much the work load is different from configuring each AR with the whole L2-L3 mapping table from the first place. Whenever you reconfigure scope id, you may have to do this for lots of ARs. In the case of dycard, it will make it very difficult to cheat the AR because two cooperating ARs (previous AR and current AR) will verify the information provided by the MN. Also it allows only one report from each MN per handoff. You said an attacker could use multiple MNs. Certainly it requires lots of effort even after assuming the attacker can cheat the two cooperating ARs. Please be aware that you would need multiple scope id per AR. For you don't want to limit the CARD operation into separate scopes. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 17:20:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15682 for ; Thu, 6 Mar 2003 17:20:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MUQO21816; Thu, 6 Mar 2003 17:30:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MTsO21751 for ; Thu, 6 Mar 2003 17:29:54 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15628 for ; Thu, 6 Mar 2003 17:18:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Mar 2003 14:20:14 -0800 X-Originating-IP: [138.15.107.226] From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE38@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 17:21:25 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 06 Mar 2003 22:20:14.0383 (UTC) FILETIME=[8F5053F0:01C2E42E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > The scope-id reduces the cache contamination problem, the > potential growth of AR cache is bounded. This will eliminate the problem > introduced due to unbounded cache growth. For example, in case of dycard, > you might have a situation where the AR cache will overflow if a mobile node > keeps injecting wrong information to the AR. This will cause > AR to either crash or remove the old useful cache entries. Potentially > this will create a situation where AR will loose valid cache entries > to populate invalid entries. Is it not correct? > > [Govind] First, if you read dycard you will see that the "overflow" problem > that you talk about is almost impossible. We do this by a scheme wherein > we restrict the number of entries that can be created by each MN. > > AJOY-> I am not sure just limiting the number of entries created by > single MN will fix this problem. The attacker can use multiple MN to > launch such attack. Whereas this type of attack is not possible > when scope-id is used? > (eunsoo) Ajoy, can you please provide a scenario of how scope id prevents cache contamination? > Also, I don't think your scope-id solution anyway reduces the problem. You > are saying that if we have "n" incorrect entries in the cache it is not > a problem, where n can be arbitrarily large right (atleast w.r.t the cache size) > ? I don't quite agree with that. > > AJOY-> You can configure the appropriately sized > cache at AR if you know the number of ARs being covered > by a given scope-id. This will also ensure that cache > overflow would never happen. Hence, > it will be impossible for an attacker to inject > fake message to remove the useful entries from the > AR. I do not see how will you achieve this in > dycard? > (eunsoo) Now you are proposing the network admin should configure each AR with knowledge of the number of ARs covered by scope id. I am not sure how much the work load is different from configuring each AR with the whole L2-L3 mapping table from the first place. Whenever you reconfigure scope id, you may have to do this for lots of ARs. In the case of dycard, it will make it very difficult to cheat the AR because two cooperating ARs (previous AR and current AR) will verify the information provided by the MN. Also it allows only one report from each MN per handoff. You said an attacker could use multiple MNs. Certainly it requires lots of effort even after assuming the attacker can cheat the two cooperating ARs. Please be aware that you would need multiple scope id per AR. For you don't want to limit the CARD operation into separate scopes. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 17:55:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16588 for ; Thu, 6 Mar 2003 17:55:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26N6Pv24267 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 18:06:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26N6PO24264 for ; Thu, 6 Mar 2003 18:06:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16568 for ; Thu, 6 Mar 2003 17:54:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26N6BO24251; Thu, 6 Mar 2003 18:06:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26N5NO24225 for ; Thu, 6 Mar 2003 18:05:23 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16512 for ; Thu, 6 Mar 2003 17:53:33 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26MtG809060 for ; Thu, 6 Mar 2003 16:55:26 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 16:55:15 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 14:55:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 17:55:14 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkK2m8bzDKnoioTfWBlVdQGMe67gAADgPg To: , X-OriginalArrivalTime: 06 Mar 2003 22:55:15.0825 (UTC) FILETIME=[73DEEE10:01C2E433] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26N5NO24226 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy, Comments embedded. Regards, -Govind. [Govind] Why will cache time out if there are frequent handovers. Plus once two ARs have recognized each other as CARs, why can't we setup a refresh procedure. Doesn't that take care of it? AJOY-> Sure you can but I think you are complicating the protocol. The L2-> L3 mapping is a simple problem and we should keep it simple. [Govind] I don't think so at all. We need refreshing clearly to take care of dyanmic capabilities. So why is it complicated? Ofcourse, you will have handovers happening between them anyways which will also refresh state. So the main thing would be to choose a lifetime that makes sure that at least one handover happens (if you use soft state at ARs).. For example, if you keep the lifetime is 1 day. You would hope that at least one handover (after the first ever handover) happens between the ARs in 1 day to refresh state. Which I think is pretty reasonable. In a real systems, handovers will always happen so why not let the system learn from that? I agree that the lifetime is something we need to think about and we have done some simulations to study the effect of lifetimes on the cache hit ratio. AJOY-> BTW, you do not need do this because L2->L3 mapping is initiated by link layer trigger that happens prior to L2 handoff. Hence, I do not see any reason to optimize this RTT. This is probably noto relevant in this context. [Govind] Well this comment was to answer your earlier statement where you said that you can optimize this round trip time like you said above. Now you say it is not necessary. However, I think this minimization of round trip is needed for the very reason that is mentioned in the DT draft. AJOY-> I am not sure just limiting the number of entries created by single MN will fix this problem. The attacker can use multiple MN to launch such attack. Whereas this type of attack is not possible when scope-id is used? [Govind] Consider that we limit one entry per MN. How many colluding MNs would you need? We have done simulations on this and have seen that the performance is not very much affected even when we limit the number of entries per MN, in a steady state system. The colluding attack is even possible in the DT draft. Consider this. A malicious MN keeps changing its identity and keeps sending up "incorrect" L2 ids. The AR keeps asking the server for translation. Isn't this a DoS attack waiting to happen. I think you have acknowledged this in the DT draft too. How does the scope-id prevent this? AJOY-> You can configure the appropriately sized cache at AR if you know the number of ARs being covered by a given scope-id. This will also ensure that cache overflow would never happen. Hence, it will be impossible for an attacker to inject fake message to remove the useful entries from the AR. I do not see how will you achieve this in dycard? [Govind] A similar argument can hold good also in a server free approach. Clearly my point is, if you have no problems with DoS attacks why will you ever contact the server again? Regarding dycard, I have explained how it is done in the earlier part of this email and other emaisl. However, whatever the DoS prevention mechanism, you wouldn't need servers. [snip] AJOY-> This is difficult to justify without proper data from real deployment or simulation. Do have any real data to prove me otherwise? [Govind] We have implemented dycard and we have gotten it to work with FMIPv6 in our local test-bed. We have demonstrated dycard at Mobicom2002. We have done simulations and a performance analysis on dycard. My observations are based on that. I hope you consider this "real data". Now on the flip side, do you have any "real data", as you put it, to quantify your statements that you would need servers and a serverless approach will not work? Or the server based approach is better? [snip] AJOY-> This does not fix the problem. The attacker can use multiple MN to launch such attack. Do you believe that service provider would deploy an such network that can be disabled by few malicious attackers? [Govind] Can you define "few". I don't clearly think it is few. I would urge you read our draft to see whether you can do it with a few malicious MNs. We will be updating our draft in the next couple of days. But the basic idea is what I have explained. [snip] AJOY-> What is the cost? You can deploy the CARD server on existing server platform for example AAA platform. I do not see any extra cost of doing this. [Govind] Why should you add a server at all? DT approach is server + cache. Dycard is cache alone. We have shown that it works fine. You agreed yesterday about the task (w.r.t to convincing the AAA WG) involved in putting it in a AAA platform. At least thats the opinion I got from the WG mails. But the previous one is just a minor point, even if it were easy why have a server at all when it is not going to be used after sometime, if you have taken care of DoS attacks, and the network is in steady state. AJOY-> Well you can. This means that every time you configure a router, you have to configure its scope-id. Whereas in former case, you can do it at once? [Govind] I don't think you would need to. But I think you are missing the point. My main point is severs are unnecessary in a steady state and as long as you take care of ensuring that DoS is difficult. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 17:55:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16610 for ; Thu, 6 Mar 2003 17:55:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26N6BO24251; Thu, 6 Mar 2003 18:06:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26N5NO24225 for ; Thu, 6 Mar 2003 18:05:23 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16512 for ; Thu, 6 Mar 2003 17:53:33 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26MtG809060 for ; Thu, 6 Mar 2003 16:55:26 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 16:55:15 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 14:55:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 17:55:14 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkK2m8bzDKnoioTfWBlVdQGMe67gAADgPg To: , X-OriginalArrivalTime: 06 Mar 2003 22:55:15.0825 (UTC) FILETIME=[73DEEE10:01C2E433] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26N5NO24226 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy, Comments embedded. Regards, -Govind. [Govind] Why will cache time out if there are frequent handovers. Plus once two ARs have recognized each other as CARs, why can't we setup a refresh procedure. Doesn't that take care of it? AJOY-> Sure you can but I think you are complicating the protocol. The L2-> L3 mapping is a simple problem and we should keep it simple. [Govind] I don't think so at all. We need refreshing clearly to take care of dyanmic capabilities. So why is it complicated? Ofcourse, you will have handovers happening between them anyways which will also refresh state. So the main thing would be to choose a lifetime that makes sure that at least one handover happens (if you use soft state at ARs).. For example, if you keep the lifetime is 1 day. You would hope that at least one handover (after the first ever handover) happens between the ARs in 1 day to refresh state. Which I think is pretty reasonable. In a real systems, handovers will always happen so why not let the system learn from that? I agree that the lifetime is something we need to think about and we have done some simulations to study the effect of lifetimes on the cache hit ratio. AJOY-> BTW, you do not need do this because L2->L3 mapping is initiated by link layer trigger that happens prior to L2 handoff. Hence, I do not see any reason to optimize this RTT. This is probably noto relevant in this context. [Govind] Well this comment was to answer your earlier statement where you said that you can optimize this round trip time like you said above. Now you say it is not necessary. However, I think this minimization of round trip is needed for the very reason that is mentioned in the DT draft. AJOY-> I am not sure just limiting the number of entries created by single MN will fix this problem. The attacker can use multiple MN to launch such attack. Whereas this type of attack is not possible when scope-id is used? [Govind] Consider that we limit one entry per MN. How many colluding MNs would you need? We have done simulations on this and have seen that the performance is not very much affected even when we limit the number of entries per MN, in a steady state system. The colluding attack is even possible in the DT draft. Consider this. A malicious MN keeps changing its identity and keeps sending up "incorrect" L2 ids. The AR keeps asking the server for translation. Isn't this a DoS attack waiting to happen. I think you have acknowledged this in the DT draft too. How does the scope-id prevent this? AJOY-> You can configure the appropriately sized cache at AR if you know the number of ARs being covered by a given scope-id. This will also ensure that cache overflow would never happen. Hence, it will be impossible for an attacker to inject fake message to remove the useful entries from the AR. I do not see how will you achieve this in dycard? [Govind] A similar argument can hold good also in a server free approach. Clearly my point is, if you have no problems with DoS attacks why will you ever contact the server again? Regarding dycard, I have explained how it is done in the earlier part of this email and other emaisl. However, whatever the DoS prevention mechanism, you wouldn't need servers. [snip] AJOY-> This is difficult to justify without proper data from real deployment or simulation. Do have any real data to prove me otherwise? [Govind] We have implemented dycard and we have gotten it to work with FMIPv6 in our local test-bed. We have demonstrated dycard at Mobicom2002. We have done simulations and a performance analysis on dycard. My observations are based on that. I hope you consider this "real data". Now on the flip side, do you have any "real data", as you put it, to quantify your statements that you would need servers and a serverless approach will not work? Or the server based approach is better? [snip] AJOY-> This does not fix the problem. The attacker can use multiple MN to launch such attack. Do you believe that service provider would deploy an such network that can be disabled by few malicious attackers? [Govind] Can you define "few". I don't clearly think it is few. I would urge you read our draft to see whether you can do it with a few malicious MNs. We will be updating our draft in the next couple of days. But the basic idea is what I have explained. [snip] AJOY-> What is the cost? You can deploy the CARD server on existing server platform for example AAA platform. I do not see any extra cost of doing this. [Govind] Why should you add a server at all? DT approach is server + cache. Dycard is cache alone. We have shown that it works fine. You agreed yesterday about the task (w.r.t to convincing the AAA WG) involved in putting it in a AAA platform. At least thats the opinion I got from the WG mails. But the previous one is just a minor point, even if it were easy why have a server at all when it is not going to be used after sometime, if you have taken care of DoS attacks, and the network is in steady state. AJOY-> Well you can. This means that every time you configure a router, you have to configure its scope-id. Whereas in former case, you can do it at once? [Govind] I don't think you would need to. But I think you are missing the point. My main point is severs are unnecessary in a steady state and as long as you take care of ensuring that DoS is difficult. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 18:19:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18064 for ; Thu, 6 Mar 2003 18:19:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26NUR925850 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 18:30:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NURO25847 for ; Thu, 6 Mar 2003 18:30:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18060 for ; Thu, 6 Mar 2003 18:18:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NUFO25829; Thu, 6 Mar 2003 18:30:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NQ6O25671 for ; Thu, 6 Mar 2003 18:26:06 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17906 for ; Thu, 6 Mar 2003 18:14:21 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26NJiF19919 for ; Fri, 7 Mar 2003 01:19:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 01:16:24 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 01:16:23 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 17:15:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 18:15:55 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkGLTSGEFVx6ilTnWZuQv3WFEHbwAAVRigAAazKXA= To: , Cc: , X-OriginalArrivalTime: 06 Mar 2003 23:15:56.0657 (UTC) FILETIME=[5776DE10:01C2E436] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26NQ7O25672 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Guys: Some clarification on possibility of DoS in current DT draft. The following DoS attacks are possible in the current protocol: + MN sending bogus L2 ids to current AR. This in turn means that current AR makes request to CARD server to resolve it. Server returns error condition (no such mapping or mapping out of scope ID). + Limiting requests per MN is not possible to avoid the above. MN may keep disconnecting and connecting back frequently, each time sending a set of bogus L2 IDs. In each reconnection, MN may acquire a different CoA, and hence, current AR cannot keep track of which MN is sending how many L2 IDs over a period of time. + Scope ID is simple mechanism to limit cache contamination from domain scale to region scale. However, it is easily possible that malicious node would make the cache at current AR always filled up will all ARs in scope ID. + If additional mechanisms are introduced such as tagging cache entries with MN identifier (as asserted by AAA when access was granted), DoS can be managed however. Then scope ID wont be necessary, IMHO. Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 06, 2003 3:01 PM To: kempf@docomolabs-usa.com Cc: pcalhoun@airespace.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Jim, Please read what I wrote again. "Should not propagate *from* the MN *to* the server." Please point out to me where in the draft it says that. Fetching *from* the server is the other way around. [Govind] The MN sends an L2 id. It is not there in the cache. Note the AR has no way of determining whether this is a genuine AP. If the entry to the AP is not in the cache it is sent over to the server. Server responds with the mapping or probably a error based. Doesn't the MN have direct control of what goes to the server? Thats what I meant. Hope it is clear now. This is what I understood. The DT draft has acknowledged that this is a problem and proposes the scope-id as one solution for this. Look at section 6.2. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 18:19:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18090 for ; Thu, 6 Mar 2003 18:19:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NUFO25829; Thu, 6 Mar 2003 18:30:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NQ6O25671 for ; Thu, 6 Mar 2003 18:26:06 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17906 for ; Thu, 6 Mar 2003 18:14:21 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26NJiF19919 for ; Fri, 7 Mar 2003 01:19:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 01:16:24 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 01:16:23 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 17:15:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 18:15:55 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkGLTSGEFVx6ilTnWZuQv3WFEHbwAAVRigAAazKXA= To: , Cc: , X-OriginalArrivalTime: 06 Mar 2003 23:15:56.0657 (UTC) FILETIME=[5776DE10:01C2E436] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26NQ7O25672 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Guys: Some clarification on possibility of DoS in current DT draft. The following DoS attacks are possible in the current protocol: + MN sending bogus L2 ids to current AR. This in turn means that current AR makes request to CARD server to resolve it. Server returns error condition (no such mapping or mapping out of scope ID). + Limiting requests per MN is not possible to avoid the above. MN may keep disconnecting and connecting back frequently, each time sending a set of bogus L2 IDs. In each reconnection, MN may acquire a different CoA, and hence, current AR cannot keep track of which MN is sending how many L2 IDs over a period of time. + Scope ID is simple mechanism to limit cache contamination from domain scale to region scale. However, it is easily possible that malicious node would make the cache at current AR always filled up will all ARs in scope ID. + If additional mechanisms are introduced such as tagging cache entries with MN identifier (as asserted by AAA when access was granted), DoS can be managed however. Then scope ID wont be necessary, IMHO. Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 06, 2003 3:01 PM To: kempf@docomolabs-usa.com Cc: pcalhoun@airespace.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Jim, Please read what I wrote again. "Should not propagate *from* the MN *to* the server." Please point out to me where in the draft it says that. Fetching *from* the server is the other way around. [Govind] The MN sends an L2 id. It is not there in the cache. Note the AR has no way of determining whether this is a genuine AP. If the entry to the AP is not in the cache it is sent over to the server. Server responds with the mapping or probably a error based. Doesn't the MN have direct control of what goes to the server? Thats what I meant. Hope it is clear now. This is what I understood. The DT draft has acknowledged that this is a problem and proposes the scope-id as one solution for this. Look at section 6.2. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 18:33:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18509 for ; Thu, 6 Mar 2003 18:33:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26NiNu27188 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 18:44:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NiMO27185 for ; Thu, 6 Mar 2003 18:44:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18473 for ; Thu, 6 Mar 2003 18:32:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Ni5O27161; Thu, 6 Mar 2003 18:44:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NfXO27074 for ; Thu, 6 Mar 2003 18:41:33 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18418 for ; Thu, 6 Mar 2003 18:29:48 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26NVsa27771 for ; Thu, 6 Mar 2003 17:31:54 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 17:31:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 15:30:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 18:30:51 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLjfDxajZZk8ZJKT2qqjpqvlOe3uwAulgrw To: , X-OriginalArrivalTime: 06 Mar 2003 23:30:52.0290 (UTC) FILETIME=[6D4D9E20:01C2E438] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26NfXO27075 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: Please see some comments below: ----------snip------------- 3) I can't really see the point of introducing a new inter-router protocol of this sort. I believe this would be better handled by defining some kind of OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a proposal, however. In any case, it needs investigation and should be moved into a separate document if it proves to be of interest. Hemant -> I do not see any point in bothering all routers in domain (as OSPF updates will do) for the sake of exchanging a piece of message between two ARs. ------------------snip----------------------------------------- Section 4.1: I can't see how an MN could possibly perform CARD with an AR that is not currently on its subnet. How does the MN discover such an AR in the first place except by performing CARD with its exisitng AR (in which case, it doesn't need to perform it with the other one)? If you assume that the MN has brought up a separate interface with the other AR, then the other AR is on a subnet that the MN is using on that interface. RA/RS can't be sent to any off link node, as they are limited by the security measures in RFC 2461. Hemant -> I have not read RFC 2461 recently. But, I was curious about this. We talked a lot about this on mailing list after Steve Deering's presentation in Minneapolis. Steve advocated this as the primary way of doing CARD when there are multiple interfaces available on MN. You also quite strongly supported this view. And then, IMHO this is the most natural way to do CARD when there are multiple interfaces available. This is also ideal for inter-domain handoffs such as handoff from cellular to my home WLAN. All decisions and security issues are anchored at MN and can be easily addressed for this case. I am wondering as to what has changed between then and now. -------------------snip----------------------------- Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, itself, subject to DOS attacks. The solutions presented in Section 6.3 for handling these problems are much more streamlined and align with IP network softstate approach: 1) The protocol specifies a minimum interarrival time for sending requests. 2) The protocol specifies a minimum reply time for routers replying. If too many requests arrive, the router begins to selectively drop so hosts have to retransmit. 3) A default cache lifetime is defined. After this time, the router times out the cache entry. 4) An entry presented by the MN gets a preference level. The more times it is reported by another MN, the less likely it is to time out. This needs to be quantified and described as an algorthm. These elements need to be added to the protocol draft for 1) in the meta-issues section. Hemant -> 4) can be fooled as follows: MN can disconnect and reconnect each time sending the same bogus entry. This increases the preference of that entry. At each reconnection, MN may get different CoA. So current AR cannot identify bogus requests coming from same MN (unless other mechanisms as I pointed out in my other email are introduced). Hemant --------------snip------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 18:33:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18547 for ; Thu, 6 Mar 2003 18:33:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Ni5O27161; Thu, 6 Mar 2003 18:44:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NfXO27074 for ; Thu, 6 Mar 2003 18:41:33 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18418 for ; Thu, 6 Mar 2003 18:29:48 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26NVsa27771 for ; Thu, 6 Mar 2003 17:31:54 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 17:31:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 15:30:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 18:30:51 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLjfDxajZZk8ZJKT2qqjpqvlOe3uwAulgrw To: , X-OriginalArrivalTime: 06 Mar 2003 23:30:52.0290 (UTC) FILETIME=[6D4D9E20:01C2E438] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26NfXO27075 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: Please see some comments below: ----------snip------------- 3) I can't really see the point of introducing a new inter-router protocol of this sort. I believe this would be better handled by defining some kind of OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a proposal, however. In any case, it needs investigation and should be moved into a separate document if it proves to be of interest. Hemant -> I do not see any point in bothering all routers in domain (as OSPF updates will do) for the sake of exchanging a piece of message between two ARs. ------------------snip----------------------------------------- Section 4.1: I can't see how an MN could possibly perform CARD with an AR that is not currently on its subnet. How does the MN discover such an AR in the first place except by performing CARD with its exisitng AR (in which case, it doesn't need to perform it with the other one)? If you assume that the MN has brought up a separate interface with the other AR, then the other AR is on a subnet that the MN is using on that interface. RA/RS can't be sent to any off link node, as they are limited by the security measures in RFC 2461. Hemant -> I have not read RFC 2461 recently. But, I was curious about this. We talked a lot about this on mailing list after Steve Deering's presentation in Minneapolis. Steve advocated this as the primary way of doing CARD when there are multiple interfaces available on MN. You also quite strongly supported this view. And then, IMHO this is the most natural way to do CARD when there are multiple interfaces available. This is also ideal for inter-domain handoffs such as handoff from cellular to my home WLAN. All decisions and security issues are anchored at MN and can be easily addressed for this case. I am wondering as to what has changed between then and now. -------------------snip----------------------------- Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is, itself, subject to DOS attacks. The solutions presented in Section 6.3 for handling these problems are much more streamlined and align with IP network softstate approach: 1) The protocol specifies a minimum interarrival time for sending requests. 2) The protocol specifies a minimum reply time for routers replying. If too many requests arrive, the router begins to selectively drop so hosts have to retransmit. 3) A default cache lifetime is defined. After this time, the router times out the cache entry. 4) An entry presented by the MN gets a preference level. The more times it is reported by another MN, the less likely it is to time out. This needs to be quantified and described as an algorthm. These elements need to be added to the protocol draft for 1) in the meta-issues section. Hemant -> 4) can be fooled as follows: MN can disconnect and reconnect each time sending the same bogus entry. This increases the preference of that entry. At each reconnection, MN may get different CoA. So current AR cannot identify bogus requests coming from same MN (unless other mechanisms as I pointed out in my other email are introduced). Hemant --------------snip------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 18:47:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19697 for ; Thu, 6 Mar 2003 18:47:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26NwGv29138 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 18:58:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NwGO29135 for ; Thu, 6 Mar 2003 18:58:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19686 for ; Thu, 6 Mar 2003 18:46:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Nw7O29110; Thu, 6 Mar 2003 18:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NvBO29064 for ; Thu, 6 Mar 2003 18:57:11 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19675 for ; Thu, 6 Mar 2003 18:45:25 -0500 (EST) Date: Thu, 06 Mar 2003 15:45:28 -0800 From: Daichi Funato To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on DT CARD draft In-Reply-To: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> References: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> Message-Id: <20030306150029.89BE.FUNATO@docomolabs-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Eunsoo, > 1) First of all, the dycard draft shows that CARD works without any central > server. That is, we don't need the server for CARD. In dycard, ARs need to be stateful for every MN just for CARD. Most of the MN states in ARs would be useless since we just need one MN report to build one CAR entry. Only a few MN may discover new CARs. After CAR cache comes to an stable condition, the MN state maintenance is in vain. Unfortunately, an AR never knows whether it is in the stable condition or not. So, the AR needs to continue to maintain every MN's state. I think this is waste of the resources and not worth doing such a useless MN state maintenance in every AR. If we take the server approach, we can keep ARs stateless. This is much simpler than the dycard approach. (ARs may have some states to avoid cache contamination, as James proposed before. But, it is not like the dycard MN states, which are not to be used in most cases.) So, I believe the server approach keeps the system simple and avoids wasting the AR's resources for the useless MN state maintenance. Regards, Daichi _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 18:47:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19737 for ; Thu, 6 Mar 2003 18:47:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Nw7O29110; Thu, 6 Mar 2003 18:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NvBO29064 for ; Thu, 6 Mar 2003 18:57:11 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19675 for ; Thu, 6 Mar 2003 18:45:25 -0500 (EST) Date: Thu, 06 Mar 2003 15:45:28 -0800 From: Daichi Funato To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on DT CARD draft In-Reply-To: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> References: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> Message-Id: <20030306150029.89BE.FUNATO@docomolabs-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Eunsoo, > 1) First of all, the dycard draft shows that CARD works without any central > server. That is, we don't need the server for CARD. In dycard, ARs need to be stateful for every MN just for CARD. Most of the MN states in ARs would be useless since we just need one MN report to build one CAR entry. Only a few MN may discover new CARs. After CAR cache comes to an stable condition, the MN state maintenance is in vain. Unfortunately, an AR never knows whether it is in the stable condition or not. So, the AR needs to continue to maintain every MN's state. I think this is waste of the resources and not worth doing such a useless MN state maintenance in every AR. If we take the server approach, we can keep ARs stateless. This is much simpler than the dycard approach. (ARs may have some states to avoid cache contamination, as James proposed before. But, it is not like the dycard MN states, which are not to be used in most cases.) So, I believe the server approach keeps the system simple and avoids wasting the AR's resources for the useless MN state maintenance. Regards, Daichi _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 18:51:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19873 for ; Thu, 6 Mar 2003 18:51:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2702Fp29385 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 19:02:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2702EO29382 for ; Thu, 6 Mar 2003 19:02:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19853 for ; Thu, 6 Mar 2003 18:50:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27023O29363; Thu, 6 Mar 2003 19:02:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2701iO29344 for ; Thu, 6 Mar 2003 19:01:44 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19822 for ; Thu, 6 Mar 2003 18:49:52 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26Npc821471 for ; Thu, 6 Mar 2003 17:51:49 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 17:51:38 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 15:50:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 18:50:26 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkK2m8bzDKnoioTfWBlVdQGMe67gAADgPgAAODsuA= To: , , X-OriginalArrivalTime: 06 Mar 2003 23:50:27.0118 (UTC) FILETIME=[298E24E0:01C2E43B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2701iO29345 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi guys: DT hat off> My "own analysis" shows that the only drawbacks of dyCard and DT protocol respectively, while using scope ID, are: + In dyCard, the first handoff is slow + In DT protocol, CARD server is needed The DoS vulnerabilities are same for both approaches, i.e. same kind of DoS cache attack can be launched in both methods using slightly different techniques. This amounts to filling cache entries with all ARs in scope ID. However, in both approaches, this can be managed without scope ID if AAA asserted MN identity is used at AR to tag cache entries, e.g. by snooping on NAI that is being passed between MN and AAA. DT hat on> DT does not have cost-benefit analysis for above tradeoff between dyCARD and DT protocol. So, in the interest of having at least one concrete protocol in 01 version, we decided to go for one approach. Now WG should provide input on this. Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 06, 2003 5:55 PM To: ASINGH1@motorola.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Ajoy, Comments embedded. Regards, -Govind. [Govind] Why will cache time out if there are frequent handovers. Plus once two ARs have recognized each other as CARs, why can't we setup a refresh procedure. Doesn't that take care of it? AJOY-> Sure you can but I think you are complicating the protocol. The L2-> L3 mapping is a simple problem and we should keep it simple. [Govind] I don't think so at all. We need refreshing clearly to take care of dyanmic capabilities. So why is it complicated? Ofcourse, you will have handovers happening between them anyways which will also refresh state. So the main thing would be to choose a lifetime that makes sure that at least one handover happens (if you use soft state at ARs).. For example, if you keep the lifetime is 1 day. You would hope that at least one handover (after the first ever handover) happens between the ARs in 1 day to refresh state. Which I think is pretty reasonable. In a real systems, handovers will always happen so why not let the system learn from that? I agree that the lifetime is something we need to think about and we have done some simulations to study the effect of lifetimes on the cache hit ratio. AJOY-> BTW, you do not need do this because L2->L3 mapping is initiated by link layer trigger that happens prior to L2 handoff. Hence, I do not see any reason to optimize this RTT. This is probably noto relevant in this context. [Govind] Well this comment was to answer your earlier statement where you said that you can optimize this round trip time like you said above. Now you say it is not necessary. However, I think this minimization of round trip is needed for the very reason that is mentioned in the DT draft. AJOY-> I am not sure just limiting the number of entries created by single MN will fix this problem. The attacker can use multiple MN to launch such attack. Whereas this type of attack is not possible when scope-id is used? [Govind] Consider that we limit one entry per MN. How many colluding MNs would you need? We have done simulations on this and have seen that the performance is not very much affected even when we limit the number of entries per MN, in a steady state system. The colluding attack is even possible in the DT draft. Consider this. A malicious MN keeps changing its identity and keeps sending up "incorrect" L2 ids. The AR keeps asking the server for translation. Isn't this a DoS attack waiting to happen. I think you have acknowledged this in the DT draft too. How does the scope-id prevent this? AJOY-> You can configure the appropriately sized cache at AR if you know the number of ARs being covered by a given scope-id. This will also ensure that cache overflow would never happen. Hence, it will be impossible for an attacker to inject fake message to remove the useful entries from the AR. I do not see how will you achieve this in dycard? [Govind] A similar argument can hold good also in a server free approach. Clearly my point is, if you have no problems with DoS attacks why will you ever contact the server again? Regarding dycard, I have explained how it is done in the earlier part of this email and other emaisl. However, whatever the DoS prevention mechanism, you wouldn't need servers. [snip] AJOY-> This is difficult to justify without proper data from real deployment or simulation. Do have any real data to prove me otherwise? [Govind] We have implemented dycard and we have gotten it to work with FMIPv6 in our local test-bed. We have demonstrated dycard at Mobicom2002. We have done simulations and a performance analysis on dycard. My observations are based on that. I hope you consider this "real data". Now on the flip side, do you have any "real data", as you put it, to quantify your statements that you would need servers and a serverless approach will not work? Or the server based approach is better? [snip] AJOY-> This does not fix the problem. The attacker can use multiple MN to launch such attack. Do you believe that service provider would deploy an such network that can be disabled by few malicious attackers? [Govind] Can you define "few". I don't clearly think it is few. I would urge you read our draft to see whether you can do it with a few malicious MNs. We will be updating our draft in the next couple of days. But the basic idea is what I have explained. [snip] AJOY-> What is the cost? You can deploy the CARD server on existing server platform for example AAA platform. I do not see any extra cost of doing this. [Govind] Why should you add a server at all? DT approach is server + cache. Dycard is cache alone. We have shown that it works fine. You agreed yesterday about the task (w.r.t to convincing the AAA WG) involved in putting it in a AAA platform. At least thats the opinion I got from the WG mails. But the previous one is just a minor point, even if it were easy why have a server at all when it is not going to be used after sometime, if you have taken care of DoS attacks, and the network is in steady state. AJOY-> Well you can. This means that every time you configure a router, you have to configure its scope-id. Whereas in former case, you can do it at once? [Govind] I don't think you would need to. But I think you are missing the point. My main point is severs are unnecessary in a steady state and as long as you take care of ensuring that DoS is difficult. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 18:51:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19888 for ; Thu, 6 Mar 2003 18:51:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27023O29363; Thu, 6 Mar 2003 19:02:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2701iO29344 for ; Thu, 6 Mar 2003 19:01:44 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19822 for ; Thu, 6 Mar 2003 18:49:52 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26Npc821471 for ; Thu, 6 Mar 2003 17:51:49 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 17:51:38 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 15:50:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 18:50:26 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkK2m8bzDKnoioTfWBlVdQGMe67gAADgPgAAODsuA= To: , , X-OriginalArrivalTime: 06 Mar 2003 23:50:27.0118 (UTC) FILETIME=[298E24E0:01C2E43B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2701iO29345 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi guys: DT hat off> My "own analysis" shows that the only drawbacks of dyCard and DT protocol respectively, while using scope ID, are: + In dyCard, the first handoff is slow + In DT protocol, CARD server is needed The DoS vulnerabilities are same for both approaches, i.e. same kind of DoS cache attack can be launched in both methods using slightly different techniques. This amounts to filling cache entries with all ARs in scope ID. However, in both approaches, this can be managed without scope ID if AAA asserted MN identity is used at AR to tag cache entries, e.g. by snooping on NAI that is being passed between MN and AAA. DT hat on> DT does not have cost-benefit analysis for above tradeoff between dyCARD and DT protocol. So, in the interest of having at least one concrete protocol in 01 version, we decided to go for one approach. Now WG should provide input on this. Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 06, 2003 5:55 PM To: ASINGH1@motorola.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Ajoy, Comments embedded. Regards, -Govind. [Govind] Why will cache time out if there are frequent handovers. Plus once two ARs have recognized each other as CARs, why can't we setup a refresh procedure. Doesn't that take care of it? AJOY-> Sure you can but I think you are complicating the protocol. The L2-> L3 mapping is a simple problem and we should keep it simple. [Govind] I don't think so at all. We need refreshing clearly to take care of dyanmic capabilities. So why is it complicated? Ofcourse, you will have handovers happening between them anyways which will also refresh state. So the main thing would be to choose a lifetime that makes sure that at least one handover happens (if you use soft state at ARs).. For example, if you keep the lifetime is 1 day. You would hope that at least one handover (after the first ever handover) happens between the ARs in 1 day to refresh state. Which I think is pretty reasonable. In a real systems, handovers will always happen so why not let the system learn from that? I agree that the lifetime is something we need to think about and we have done some simulations to study the effect of lifetimes on the cache hit ratio. AJOY-> BTW, you do not need do this because L2->L3 mapping is initiated by link layer trigger that happens prior to L2 handoff. Hence, I do not see any reason to optimize this RTT. This is probably noto relevant in this context. [Govind] Well this comment was to answer your earlier statement where you said that you can optimize this round trip time like you said above. Now you say it is not necessary. However, I think this minimization of round trip is needed for the very reason that is mentioned in the DT draft. AJOY-> I am not sure just limiting the number of entries created by single MN will fix this problem. The attacker can use multiple MN to launch such attack. Whereas this type of attack is not possible when scope-id is used? [Govind] Consider that we limit one entry per MN. How many colluding MNs would you need? We have done simulations on this and have seen that the performance is not very much affected even when we limit the number of entries per MN, in a steady state system. The colluding attack is even possible in the DT draft. Consider this. A malicious MN keeps changing its identity and keeps sending up "incorrect" L2 ids. The AR keeps asking the server for translation. Isn't this a DoS attack waiting to happen. I think you have acknowledged this in the DT draft too. How does the scope-id prevent this? AJOY-> You can configure the appropriately sized cache at AR if you know the number of ARs being covered by a given scope-id. This will also ensure that cache overflow would never happen. Hence, it will be impossible for an attacker to inject fake message to remove the useful entries from the AR. I do not see how will you achieve this in dycard? [Govind] A similar argument can hold good also in a server free approach. Clearly my point is, if you have no problems with DoS attacks why will you ever contact the server again? Regarding dycard, I have explained how it is done in the earlier part of this email and other emaisl. However, whatever the DoS prevention mechanism, you wouldn't need servers. [snip] AJOY-> This is difficult to justify without proper data from real deployment or simulation. Do have any real data to prove me otherwise? [Govind] We have implemented dycard and we have gotten it to work with FMIPv6 in our local test-bed. We have demonstrated dycard at Mobicom2002. We have done simulations and a performance analysis on dycard. My observations are based on that. I hope you consider this "real data". Now on the flip side, do you have any "real data", as you put it, to quantify your statements that you would need servers and a serverless approach will not work? Or the server based approach is better? [snip] AJOY-> This does not fix the problem. The attacker can use multiple MN to launch such attack. Do you believe that service provider would deploy an such network that can be disabled by few malicious attackers? [Govind] Can you define "few". I don't clearly think it is few. I would urge you read our draft to see whether you can do it with a few malicious MNs. We will be updating our draft in the next couple of days. But the basic idea is what I have explained. [snip] AJOY-> What is the cost? You can deploy the CARD server on existing server platform for example AAA platform. I do not see any extra cost of doing this. [Govind] Why should you add a server at all? DT approach is server + cache. Dycard is cache alone. We have shown that it works fine. You agreed yesterday about the task (w.r.t to convincing the AAA WG) involved in putting it in a AAA platform. At least thats the opinion I got from the WG mails. But the previous one is just a minor point, even if it were easy why have a server at all when it is not going to be used after sometime, if you have taken care of DoS attacks, and the network is in steady state. AJOY-> Well you can. This means that every time you configure a router, you have to configure its scope-id. Whereas in former case, you can do it at once? [Govind] I don't think you would need to. But I think you are missing the point. My main point is severs are unnecessary in a steady state and as long as you take care of ensuring that DoS is difficult. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 18:53:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19953 for ; Thu, 6 Mar 2003 18:53:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2704KK29474 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 19:04:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2704KO29471 for ; Thu, 6 Mar 2003 19:04:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19932 for ; Thu, 6 Mar 2003 18:52:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27033O29432; Thu, 6 Mar 2003 19:03:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27027O29372 for ; Thu, 6 Mar 2003 19:02:07 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19848 for ; Thu, 6 Mar 2003 18:50:21 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26NqSa29663 for ; Thu, 6 Mar 2003 17:52:28 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 17:52:25 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 15:52:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 18:52:24 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkOu/2gMtSF4QfR7yZT8JfKBH3OgAAE/eA To: , X-OriginalArrivalTime: 06 Mar 2003 23:52:25.0682 (UTC) FILETIME=[70399320:01C2E43B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27027O29373 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Daichi: DT hat off> -----Original Message----- From: ext Daichi Funato [mailto:funato@docomolabs-usa.com] Sent: Thursday, March 06, 2003 6:45 PM To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on DT CARD draft Hi Eunsoo, > 1) First of all, the dycard draft shows that CARD works without any central > server. That is, we don't need the server for CARD. In dycard, ARs need to be stateful for every MN just for CARD. Most of the MN states in ARs would be useless since we just need one MN report to build one CAR entry. Only a few MN may discover new CARs. Hemant -> This not how dyCARD works. You should check the draft again. After CAR cache comes to an stable condition, the MN state maintenance is in vain. Unfortunately, an AR never knows whether it is in the stable condition or not. So, the AR needs to continue to maintain every MN's state. I think this is waste of the resources and not worth doing such a useless MN state maintenance in every AR. Hemant -> Again, this is now how dyCARD works. If we take the server approach, we can keep ARs stateless. This is much simpler than the dycard approach. (ARs may have some states to avoid cache contamination, as James proposed before. But, it is not like the dycard MN states, which are not to be used in most cases.) So, I believe the server approach keeps the system simple and avoids wasting the AR's resources for the useless MN state maintenance. Regards, Daichi _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 18:53:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19981 for ; Thu, 6 Mar 2003 18:53:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27033O29432; Thu, 6 Mar 2003 19:03:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27027O29372 for ; Thu, 6 Mar 2003 19:02:07 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19848 for ; Thu, 6 Mar 2003 18:50:21 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26NqSa29663 for ; Thu, 6 Mar 2003 17:52:28 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 17:52:25 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 15:52:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 18:52:24 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkOu/2gMtSF4QfR7yZT8JfKBH3OgAAE/eA To: , X-OriginalArrivalTime: 06 Mar 2003 23:52:25.0682 (UTC) FILETIME=[70399320:01C2E43B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27027O29373 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Daichi: DT hat off> -----Original Message----- From: ext Daichi Funato [mailto:funato@docomolabs-usa.com] Sent: Thursday, March 06, 2003 6:45 PM To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on DT CARD draft Hi Eunsoo, > 1) First of all, the dycard draft shows that CARD works without any central > server. That is, we don't need the server for CARD. In dycard, ARs need to be stateful for every MN just for CARD. Most of the MN states in ARs would be useless since we just need one MN report to build one CAR entry. Only a few MN may discover new CARs. Hemant -> This not how dyCARD works. You should check the draft again. After CAR cache comes to an stable condition, the MN state maintenance is in vain. Unfortunately, an AR never knows whether it is in the stable condition or not. So, the AR needs to continue to maintain every MN's state. I think this is waste of the resources and not worth doing such a useless MN state maintenance in every AR. Hemant -> Again, this is now how dyCARD works. If we take the server approach, we can keep ARs stateless. This is much simpler than the dycard approach. (ARs may have some states to avoid cache contamination, as James proposed before. But, it is not like the dycard MN states, which are not to be used in most cases.) So, I believe the server approach keeps the system simple and avoids wasting the AR's resources for the useless MN state maintenance. Regards, Daichi _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 19:30:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21581 for ; Thu, 6 Mar 2003 19:30:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h270ft432741 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 19:41:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270ftO32738 for ; Thu, 6 Mar 2003 19:41:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21574 for ; Thu, 6 Mar 2003 19:30:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270fbO32725; Thu, 6 Mar 2003 19:41:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270eFO32669 for ; Thu, 6 Mar 2003 19:40:15 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21468 for ; Thu, 6 Mar 2003 19:28:22 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h270U5828913 for ; Thu, 6 Mar 2003 18:30:15 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 18:30:04 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 16:29:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 19:29:15 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkDhSeIqGL1v+RSXSi1wOVJFE5fQAMmQYQ To: , , X-OriginalArrivalTime: 07 Mar 2003 00:29:16.0741 (UTC) FILETIME=[961E6750:01C2E440] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h270eFO32670 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Which thread? Which section? If you know quick pointer to it, please paste it here. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Thursday, March 06, 2003 1:27 PM To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> You please see my reply to Govind. OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 19:31:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21641 for ; Thu, 6 Mar 2003 19:31:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270fbO32725; Thu, 6 Mar 2003 19:41:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270eFO32669 for ; Thu, 6 Mar 2003 19:40:15 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21468 for ; Thu, 6 Mar 2003 19:28:22 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h270U5828913 for ; Thu, 6 Mar 2003 18:30:15 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 18:30:04 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 16:29:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Thu, 6 Mar 2003 19:29:15 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLkDhSeIqGL1v+RSXSi1wOVJFE5fQAMmQYQ To: , , X-OriginalArrivalTime: 07 Mar 2003 00:29:16.0741 (UTC) FILETIME=[961E6750:01C2E440] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h270eFO32670 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Which thread? Which section? If you know quick pointer to it, please paste it here. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Thursday, March 06, 2003 1:27 PM To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> You please see my reply to Govind. OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 19:35:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21723 for ; Thu, 6 Mar 2003 19:35:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h270kHd00537 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 19:46:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270kHO00534 for ; Thu, 6 Mar 2003 19:46:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21719 for ; Thu, 6 Mar 2003 19:34:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270k5O00526; Thu, 6 Mar 2003 19:46:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270irO00420 for ; Thu, 6 Mar 2003 19:44:53 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21680 for ; Thu, 6 Mar 2003 19:33:07 -0500 (EST) Message-ID: <02a101c2e441$30ca80e0$156015ac@T23KEMPF> From: "James Kempf" To: , Cc: , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 16:33:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Some clarification on possibility of DoS in current DT draft. The following DoS attacks are possible in the current protocol: > > + MN sending bogus L2 ids to current AR. This in turn means that current AR makes request to CARD server to resolve it. Server returns error condition (no such mapping or mapping out of scope ID). > > + Limiting requests per MN is not possible to avoid the above. MN may keep disconnecting and connecting back frequently, each time sending a set of bogus L2 IDs. In each reconnection, MN may acquire a different CoA, and hence, current AR cannot keep track of which MN is sending how many L2 IDs over a period of time. > Rate limiting isn't done on any particular MN, it is done on *all* CARD requests. If the default limits defined in the protocol are gone over, the router starts dropping CARD requests, regardless of what IP address they have on them. Service begins to degrade, but it is not denied. Meanwhile, legitimate users begin to notice, get a sysadmin, and find the villian. > + Scope ID is simple mechanism to limit cache contamination from domain scale to region scale. However, it is easily possible that malicious node would make the cache at current AR always filled up will all ARs in scope ID. > So? > + If additional mechanisms are introduced such as tagging cache entries with MN identifier (as asserted by AAA when access was granted), DoS can be managed however. Then scope ID wont be necessary, IMHO. > Why should the router care where the information came from? Regardless, it will check against the database. Otherwise, anybody could advertise an AP. jak > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 19:35:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21737 for ; Thu, 6 Mar 2003 19:35:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270k5O00526; Thu, 6 Mar 2003 19:46:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270irO00420 for ; Thu, 6 Mar 2003 19:44:53 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21680 for ; Thu, 6 Mar 2003 19:33:07 -0500 (EST) Message-ID: <02a101c2e441$30ca80e0$156015ac@T23KEMPF> From: "James Kempf" To: , Cc: , References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Thu, 6 Mar 2003 16:33:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Some clarification on possibility of DoS in current DT draft. The following DoS attacks are possible in the current protocol: > > + MN sending bogus L2 ids to current AR. This in turn means that current AR makes request to CARD server to resolve it. Server returns error condition (no such mapping or mapping out of scope ID). > > + Limiting requests per MN is not possible to avoid the above. MN may keep disconnecting and connecting back frequently, each time sending a set of bogus L2 IDs. In each reconnection, MN may acquire a different CoA, and hence, current AR cannot keep track of which MN is sending how many L2 IDs over a period of time. > Rate limiting isn't done on any particular MN, it is done on *all* CARD requests. If the default limits defined in the protocol are gone over, the router starts dropping CARD requests, regardless of what IP address they have on them. Service begins to degrade, but it is not denied. Meanwhile, legitimate users begin to notice, get a sysadmin, and find the villian. > + Scope ID is simple mechanism to limit cache contamination from domain scale to region scale. However, it is easily possible that malicious node would make the cache at current AR always filled up will all ARs in scope ID. > So? > + If additional mechanisms are introduced such as tagging cache entries with MN identifier (as asserted by AAA when access was granted), DoS can be managed however. Then scope ID wont be necessary, IMHO. > Why should the router care where the information came from? Regardless, it will check against the database. Otherwise, anybody could advertise an AP. jak > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 20:09:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22466 for ; Thu, 6 Mar 2003 20:09:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h271KVv02685 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 20:20:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271KVO02682 for ; Thu, 6 Mar 2003 20:20:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22433 for ; Thu, 6 Mar 2003 20:08:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271KGO02662; Thu, 6 Mar 2003 20:20:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271AUO02334 for ; Thu, 6 Mar 2003 20:10:30 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22230 for ; Thu, 6 Mar 2003 19:58:43 -0500 (EST) Message-ID: <02d001c2e444$c4917010$156015ac@T23KEMPF> From: "James Kempf" To: "Robert Chalmers" , References: <01d401c2e282$bbf1b140$636015ac@T23KEMPF> <3E67C910.9060200@cs.ucsb.edu> Subject: Re: [Seamoby] CARD Draft Date: Thu, 6 Mar 2003 16:59:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert, Thank you for your very clearly thought out and well reasoned comments. Some responses below. > In any case, using a centralized server to > manage the valid AP-AR mappings is a fine idea, but doesn't imply that > the server must be part of the resolution process. Rather, it seems like > a completely separate issue: how to manage configuration data (AR-AP > mappings) for a large number of routers. There are a number of existing > techniques for doing that, and they are orthogonal to how the mappings > are used at the AR. > Yes, this is a key point. The server shouldn't need to be involved in the immediate resolution when an MN requests a mapping. That could be done from the AR's cache. However, if the mapping isn't in the cache, the AR must go to some authenticatble source of information on what APs are authorized. That's the point of the server. It acts as a kind of ACL list for APs. > 1.c. Populating the cache with an initial entry does not require handover. > This is the strongest argument for the server-based approach, but there > are a number of issues that must be addressed to understand the true > benefit available. First, the expectation of both techniques, > server-based and learning-based, is that the cache is fully populated > during steady-state operation. For the learning-based approach, if a > AP-AR mapping does not exist, no help is available. In the server-based > approach, the time to resolve the mapping with the server, as well as > gather any necessary capabilities from the neighboring AR cannot be > expected to complete prior to the information being needed for TAR > selection. > I view these approachs as complimentary. In a small, home network, the router may have an ACL list of authorized APs built in and the server is not needed. In a large corporate network, a sysadmin may find it easier to program the ACL list into a server. But, I think the ACL list is required somewhere. The AR can't simply trust information provided by the MN without verifying that the AP is authorized. So a pure learning based approach, without any information about whether an AP is authorized, would not satisfy security requirements. > Consider a MN moving through an AP's coverage area. Let's say from left > to right for simplicity. Performing resolution early will most likely > provide mappings and capabilities for the APs on the left of the > coverage area, thus behind the mobile node. The APs to the right won't > become "visible" until the MN approaches the righthand border (unless > there is extreme overlap). At this point, the time necessary to resolve > the new APs as well as decide to handover may be short. In short, early > resolution won't gain you much in way of eventual targets, and late > resolution requires cache hits. > > So for both techniques, proper configuration of lifetimes (or even > dynamic lifetimes as Dirk? suggested) are necessary to ensure viable > response times. So, the real question is whether both techniques can > maintain satisfactory cache fill ratios. This needs some experimentation > to confirm, but I think that the server-based approach may have a > slight advantage here, and I do mean slight. > > Just for note, there are techniques that can be used to improve the > cache fill ratio of the learning-based technique. In particular, once > one handover between two ARs occurs, they can exchange a list of > attached APs as a special form of capabilities. This means that as long > as handovers continue between the two ARs, no matter which APs are > involved, all AR-AP mappings are maintained for the two neighbors. > The performance aspects of this aren't the key issue, IMHO. The key issue is security. > In the end, I don't think that the server is really necessary. It may > provide a small benefit for keeping the cache full, but this is > completely dependant upon the properties of the network and the dynamics > of the MNs. Moreover, I think that the server-based approach is harder > to secure against malicious mobiles. For the learning-based approach, an > attack requires a large number of mobiles spread across numerous > networks working in tight synchronization. For the server-based > approach, a few local malicious mobiles could fill the current AR's > cache with little effort. > A server provides a convenient way for enterprises and ISPs to configure their network. I think it is important to have, but not part of the base draft. That is why I have suggested it be moved out of the base draft. It is a complementary technology used for large networks. Exactly how the AR verifies an MN-offered AP as being authorized or not is out of scope for the base protocol. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 6 20:09:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22483 for ; Thu, 6 Mar 2003 20:09:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h271Klw02779 for seamoby-archive@odin.ietf.org; Thu, 6 Mar 2003 20:20:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271KlO02776 for ; Thu, 6 Mar 2003 20:20:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22446 for ; Thu, 6 Mar 2003 20:08:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271KaO02720; Thu, 6 Mar 2003 20:20:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271GEO02439 for ; Thu, 6 Mar 2003 20:16:14 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22338 for ; Thu, 6 Mar 2003 20:04:26 -0500 (EST) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2716V128659 for ; Thu, 6 Mar 2003 17:06:31 -0800 (PST) Message-ID: <3E67F097.4080706@cs.ucsb.edu> Date: Thu, 06 Mar 2003 17:06:31 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on DT CARD draft References: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> <20030306150029.89BE.FUNATO@docomolabs-usa.com> In-Reply-To: <20030306150029.89BE.FUNATO@docomolabs-usa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Daichi, >>1) First of all, the dycard draft shows that CARD works without any central >>server. That is, we don't need the server for CARD. > > > In dycard, ARs need to be stateful for every MN just for CARD. > Most of the MN states in ARs would be useless since we just need one > MN report to build one CAR entry. Only a few MN may discover new CARs. > > After CAR cache comes to an stable condition, the MN state maintenance > is in vain. Unfortunately, an AR never knows whether it is in the stable > condition or not. So, the AR needs to continue to maintain every MN's state. > I think this is waste of the resources and not worth doing such a > useless MN state maintenance in every AR. > > If we take the server approach, we can keep ARs stateless. > This is much simpler than the dycard approach. (ARs may have some > states to avoid cache contamination, as James proposed before. > But, it is not like the dycard MN states, which are not to be used > in most cases.) > > So, I believe the server approach keeps the system simple and avoids > wasting the AR's resources for the useless MN state maintenance. > I may be misinterpretting what your saying here, so please let me know if that is the case. However, MN state is not necessary for dyCARD to work. The protocol does introduce a stateful mode where the AR can maintain reachability state for the mobile node, but this is just an optional mode. Admittedly, the initial draft was written with the stateful mode in mind. We've updated the draft to make this distinction cleaer. Anyway, the state maintained by the AR for the MN (in stateful mode only) has nothing to do with the learning process between ARs. It's purpose is to streamline the AR-MN resolution process. And again, it's optional. ttyl, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 20:09:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22524 for ; Thu, 6 Mar 2003 20:09:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271KGO02662; Thu, 6 Mar 2003 20:20:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271AUO02334 for ; Thu, 6 Mar 2003 20:10:30 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22230 for ; Thu, 6 Mar 2003 19:58:43 -0500 (EST) Message-ID: <02d001c2e444$c4917010$156015ac@T23KEMPF> From: "James Kempf" To: "Robert Chalmers" , References: <01d401c2e282$bbf1b140$636015ac@T23KEMPF> <3E67C910.9060200@cs.ucsb.edu> Subject: Re: [Seamoby] CARD Draft Date: Thu, 6 Mar 2003 16:59:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, Thank you for your very clearly thought out and well reasoned comments. Some responses below. > In any case, using a centralized server to > manage the valid AP-AR mappings is a fine idea, but doesn't imply that > the server must be part of the resolution process. Rather, it seems like > a completely separate issue: how to manage configuration data (AR-AP > mappings) for a large number of routers. There are a number of existing > techniques for doing that, and they are orthogonal to how the mappings > are used at the AR. > Yes, this is a key point. The server shouldn't need to be involved in the immediate resolution when an MN requests a mapping. That could be done from the AR's cache. However, if the mapping isn't in the cache, the AR must go to some authenticatble source of information on what APs are authorized. That's the point of the server. It acts as a kind of ACL list for APs. > 1.c. Populating the cache with an initial entry does not require handover. > This is the strongest argument for the server-based approach, but there > are a number of issues that must be addressed to understand the true > benefit available. First, the expectation of both techniques, > server-based and learning-based, is that the cache is fully populated > during steady-state operation. For the learning-based approach, if a > AP-AR mapping does not exist, no help is available. In the server-based > approach, the time to resolve the mapping with the server, as well as > gather any necessary capabilities from the neighboring AR cannot be > expected to complete prior to the information being needed for TAR > selection. > I view these approachs as complimentary. In a small, home network, the router may have an ACL list of authorized APs built in and the server is not needed. In a large corporate network, a sysadmin may find it easier to program the ACL list into a server. But, I think the ACL list is required somewhere. The AR can't simply trust information provided by the MN without verifying that the AP is authorized. So a pure learning based approach, without any information about whether an AP is authorized, would not satisfy security requirements. > Consider a MN moving through an AP's coverage area. Let's say from left > to right for simplicity. Performing resolution early will most likely > provide mappings and capabilities for the APs on the left of the > coverage area, thus behind the mobile node. The APs to the right won't > become "visible" until the MN approaches the righthand border (unless > there is extreme overlap). At this point, the time necessary to resolve > the new APs as well as decide to handover may be short. In short, early > resolution won't gain you much in way of eventual targets, and late > resolution requires cache hits. > > So for both techniques, proper configuration of lifetimes (or even > dynamic lifetimes as Dirk? suggested) are necessary to ensure viable > response times. So, the real question is whether both techniques can > maintain satisfactory cache fill ratios. This needs some experimentation > to confirm, but I think that the server-based approach may have a > slight advantage here, and I do mean slight. > > Just for note, there are techniques that can be used to improve the > cache fill ratio of the learning-based technique. In particular, once > one handover between two ARs occurs, they can exchange a list of > attached APs as a special form of capabilities. This means that as long > as handovers continue between the two ARs, no matter which APs are > involved, all AR-AP mappings are maintained for the two neighbors. > The performance aspects of this aren't the key issue, IMHO. The key issue is security. > In the end, I don't think that the server is really necessary. It may > provide a small benefit for keeping the cache full, but this is > completely dependant upon the properties of the network and the dynamics > of the MNs. Moreover, I think that the server-based approach is harder > to secure against malicious mobiles. For the learning-based approach, an > attack requires a large number of mobiles spread across numerous > networks working in tight synchronization. For the server-based > approach, a few local malicious mobiles could fill the current AR's > cache with little effort. > A server provides a convenient way for enterprises and ISPs to configure their network. I think it is important to have, but not part of the base draft. That is why I have suggested it be moved out of the base draft. It is a complementary technology used for large networks. Exactly how the AR verifies an MN-offered AP as being authorized or not is out of scope for the base protocol. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 6 20:10:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22558 for ; Thu, 6 Mar 2003 20:10:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271KaO02720; Thu, 6 Mar 2003 20:20:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271GEO02439 for ; Thu, 6 Mar 2003 20:16:14 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22338 for ; Thu, 6 Mar 2003 20:04:26 -0500 (EST) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2716V128659 for ; Thu, 6 Mar 2003 17:06:31 -0800 (PST) Message-ID: <3E67F097.4080706@cs.ucsb.edu> Date: Thu, 06 Mar 2003 17:06:31 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on DT CARD draft References: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> <20030306150029.89BE.FUNATO@docomolabs-usa.com> In-Reply-To: <20030306150029.89BE.FUNATO@docomolabs-usa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Daichi, >>1) First of all, the dycard draft shows that CARD works without any central >>server. That is, we don't need the server for CARD. > > > In dycard, ARs need to be stateful for every MN just for CARD. > Most of the MN states in ARs would be useless since we just need one > MN report to build one CAR entry. Only a few MN may discover new CARs. > > After CAR cache comes to an stable condition, the MN state maintenance > is in vain. Unfortunately, an AR never knows whether it is in the stable > condition or not. So, the AR needs to continue to maintain every MN's state. > I think this is waste of the resources and not worth doing such a > useless MN state maintenance in every AR. > > If we take the server approach, we can keep ARs stateless. > This is much simpler than the dycard approach. (ARs may have some > states to avoid cache contamination, as James proposed before. > But, it is not like the dycard MN states, which are not to be used > in most cases.) > > So, I believe the server approach keeps the system simple and avoids > wasting the AR's resources for the useless MN state maintenance. > I may be misinterpretting what your saying here, so please let me know if that is the case. However, MN state is not necessary for dyCARD to work. The protocol does introduce a stateful mode where the AR can maintain reachability state for the mobile node, but this is just an optional mode. Admittedly, the initial draft was written with the stateful mode in mind. We've updated the draft to make this distinction cleaer. Anyway, the state maintained by the AR for the MN (in stateful mode only) has nothing to do with the learning process between ARs. It's purpose is to streamline the AR-MN resolution process. And again, it's optional. ttyl, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 06:58:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22301 for ; Fri, 7 Mar 2003 06:58:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27CAP316901 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 07:10:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CAPO16898 for ; Fri, 7 Mar 2003 07:10:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22264 for ; Fri, 7 Mar 2003 06:58:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CAEO16819; Fri, 7 Mar 2003 07:10:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C1KO15506 for ; Fri, 7 Mar 2003 07:01:20 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20293 for ; Fri, 7 Mar 2003 06:49:21 -0500 (EST) Received: from eunsoo ([138.15.98.110] RDNS failed) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Mar 2003 06:51:19 -0500 Message-ID: <005e01c2e4b9$31b9fb70$6e620f8a@eunsoo> From: "Eunsoo Shim" To: "Daichi Funato" , References: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> <20030306150029.89BE.FUNATO@docomolabs-usa.com> Subject: Re: [Seamoby] Comments on DT CARD draft Date: Fri, 7 Mar 2003 06:52:18 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 07 Mar 2003 11:51:23.0373 (UTC) FILETIME=[E04AD9D0:01C2E49F] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Daichi, My comments are after yours. ----- Original Message ----- From: "Daichi Funato" To: Sent: Thursday, March 06, 2003 3:45 PM Subject: Re: [Seamoby] Comments on DT CARD draft > Hi Eunsoo, > > > 1) First of all, the dycard draft shows that CARD works without any central > > server. That is, we don't need the server for CARD. > > In dycard, ARs need to be stateful for every MN just for CARD. > Most of the MN states in ARs would be useless since we just need one > MN report to build one CAR entry. Only a few MN may discover new CARs. > > After CAR cache comes to an stable condition, the MN state maintenance > is in vain. Unfortunately, an AR never knows whether it is in the stable > condition or not. So, the AR needs to continue to maintain every MN's state. > I think this is waste of the resources and not worth doing such a > useless MN state maintenance in every AR. > > If we take the server approach, we can keep ARs stateless. > This is much simpler than the dycard approach. (ARs may have some > states to avoid cache contamination, as James proposed before. > But, it is not like the dycard MN states, which are not to be used > in most cases.) > > So, I believe the server approach keeps the system simple and avoids > wasting the AR's resources for the useless MN state maintenance. > > Regards, > Daichi Dycard does NOT require MN state maintenance at AR at all just for discovery. For AAA, I am sure each AR may have to maintain state of MN. But it is independent of Dycard. Could you explain why Dycard needs MN state maintenance at AR? Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 06:59:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22384 for ; Fri, 7 Mar 2003 06:59:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CAEO16819; Fri, 7 Mar 2003 07:10:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C1KO15506 for ; Fri, 7 Mar 2003 07:01:20 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20293 for ; Fri, 7 Mar 2003 06:49:21 -0500 (EST) Received: from eunsoo ([138.15.98.110] RDNS failed) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Mar 2003 06:51:19 -0500 Message-ID: <005e01c2e4b9$31b9fb70$6e620f8a@eunsoo> From: "Eunsoo Shim" To: "Daichi Funato" , References: <02a101c2e41b$ac527450$e26b0f8a@eunsoo> <20030306150029.89BE.FUNATO@docomolabs-usa.com> Subject: Re: [Seamoby] Comments on DT CARD draft Date: Fri, 7 Mar 2003 06:52:18 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 07 Mar 2003 11:51:23.0373 (UTC) FILETIME=[E04AD9D0:01C2E49F] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Daichi, My comments are after yours. ----- Original Message ----- From: "Daichi Funato" To: Sent: Thursday, March 06, 2003 3:45 PM Subject: Re: [Seamoby] Comments on DT CARD draft > Hi Eunsoo, > > > 1) First of all, the dycard draft shows that CARD works without any central > > server. That is, we don't need the server for CARD. > > In dycard, ARs need to be stateful for every MN just for CARD. > Most of the MN states in ARs would be useless since we just need one > MN report to build one CAR entry. Only a few MN may discover new CARs. > > After CAR cache comes to an stable condition, the MN state maintenance > is in vain. Unfortunately, an AR never knows whether it is in the stable > condition or not. So, the AR needs to continue to maintain every MN's state. > I think this is waste of the resources and not worth doing such a > useless MN state maintenance in every AR. > > If we take the server approach, we can keep ARs stateless. > This is much simpler than the dycard approach. (ARs may have some > states to avoid cache contamination, as James proposed before. > But, it is not like the dycard MN states, which are not to be used > in most cases.) > > So, I believe the server approach keeps the system simple and avoids > wasting the AR's resources for the useless MN state maintenance. > > Regards, > Daichi Dycard does NOT require MN state maintenance at AR at all just for discovery. For AAA, I am sure each AR may have to maintain state of MN. But it is independent of Dycard. Could you explain why Dycard needs MN state maintenance at AR? Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 07:26:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25355 for ; Fri, 7 Mar 2003 07:26:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Cc9q19744 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 07:38:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Cc9O19741 for ; Fri, 7 Mar 2003 07:38:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25313 for ; Fri, 7 Mar 2003 07:26:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CbvO19677; Fri, 7 Mar 2003 07:37:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CKqO17753 for ; Fri, 7 Mar 2003 07:20:52 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23750 for ; Fri, 7 Mar 2003 07:08:52 -0500 (EST) Received: from eunsoo ([138.15.98.110] RDNS failed) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Mar 2003 07:10:56 -0500 Message-ID: <002101c2e4bb$ed07bdc0$6e620f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , Cc: , References: <02a101c2e441$30ca80e0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 07:12:08 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 07 Mar 2003 12:10:56.0641 (UTC) FILETIME=[9B9D5710:01C2E4A2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, My comments are inline. ----- Original Message ----- From: "James Kempf" To: ; Cc: ; Sent: Thursday, March 06, 2003 4:33 PM Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > Some clarification on possibility of DoS in current DT draft. The following > DoS attacks are possible in the current protocol: > > > > + MN sending bogus L2 ids to current AR. This in turn means that current AR > makes request to CARD server to resolve it. Server returns error condition (no > such mapping or mapping out of scope ID). > > > > + Limiting requests per MN is not possible to avoid the above. MN may keep > disconnecting and connecting back frequently, each time sending a set of bogus > L2 IDs. In each reconnection, MN may acquire a different CoA, and hence, current > AR cannot keep track of which MN is sending how many L2 IDs over a period of > time. > > > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > requests. If the default limits defined in the protocol are gone over, the > router starts dropping CARD requests, regardless of what IP address they have on > them. Service begins to degrade, but it is not denied. > [eunsoo] If the server cannot answer all CARD requests after the limit, the whole network is affected by that. Why do we want this while there is an alternative? > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > villian. > > [eunsoo] This should be the last resort. We should prevent or minimize this kind of situation from the protocol design stage. Dycard has an advantag regarding this. > > + Scope ID is simple mechanism to limit cache contamination from domain scale > to region scale. However, it is easily possible that malicious node would make > the cache at current AR always filled up will all ARs in scope ID. > > > > So? > [eunsoo] I gave you an example of the negative impact of this situation in the past. In short, it means the cache is not useful for most of other CARD applications except L2-L3 mapping. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 07:27:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25418 for ; Fri, 7 Mar 2003 07:27:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CbvO19677; Fri, 7 Mar 2003 07:37:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CKqO17753 for ; Fri, 7 Mar 2003 07:20:52 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23750 for ; Fri, 7 Mar 2003 07:08:52 -0500 (EST) Received: from eunsoo ([138.15.98.110] RDNS failed) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Mar 2003 07:10:56 -0500 Message-ID: <002101c2e4bb$ed07bdc0$6e620f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , Cc: , References: <02a101c2e441$30ca80e0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 07:12:08 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 07 Mar 2003 12:10:56.0641 (UTC) FILETIME=[9B9D5710:01C2E4A2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, My comments are inline. ----- Original Message ----- From: "James Kempf" To: ; Cc: ; Sent: Thursday, March 06, 2003 4:33 PM Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > Some clarification on possibility of DoS in current DT draft. The following > DoS attacks are possible in the current protocol: > > > > + MN sending bogus L2 ids to current AR. This in turn means that current AR > makes request to CARD server to resolve it. Server returns error condition (no > such mapping or mapping out of scope ID). > > > > + Limiting requests per MN is not possible to avoid the above. MN may keep > disconnecting and connecting back frequently, each time sending a set of bogus > L2 IDs. In each reconnection, MN may acquire a different CoA, and hence, current > AR cannot keep track of which MN is sending how many L2 IDs over a period of > time. > > > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > requests. If the default limits defined in the protocol are gone over, the > router starts dropping CARD requests, regardless of what IP address they have on > them. Service begins to degrade, but it is not denied. > [eunsoo] If the server cannot answer all CARD requests after the limit, the whole network is affected by that. Why do we want this while there is an alternative? > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > villian. > > [eunsoo] This should be the last resort. We should prevent or minimize this kind of situation from the protocol design stage. Dycard has an advantag regarding this. > > + Scope ID is simple mechanism to limit cache contamination from domain scale > to region scale. However, it is easily possible that malicious node would make > the cache at current AR always filled up will all ARs in scope ID. > > > > So? > [eunsoo] I gave you an example of the negative impact of this situation in the past. In short, it means the cache is not useful for most of other CARD applications except L2-L3 mapping. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 10:39:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11278 for ; Fri, 7 Mar 2003 10:39:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27FpRw05554 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 10:51:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FpRO05551 for ; Fri, 7 Mar 2003 10:51:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11272 for ; Fri, 7 Mar 2003 10:39:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FpEO05532; Fri, 7 Mar 2003 10:51:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FoqO05509 for ; Fri, 7 Mar 2003 10:50:52 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11246 for ; Fri, 7 Mar 2003 10:38:48 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27Fep823712 for ; Fri, 7 Mar 2003 09:40:51 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 09:40:48 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 07:39:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 10:39:56 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkop7bhdaU55aGRC6uY2z+Lu8pawAGelsw To: , Cc: , X-OriginalArrivalTime: 07 Mar 2003 15:39:57.0347 (UTC) FILETIME=[CE753730:01C2E4BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27FoqO05510 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Eunsoo, Good points. Comments embedded. Thanks, Govind. > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > requests. If the default limits defined in the protocol are gone over, the > router starts dropping CARD requests, regardless of what IP address they have on > them. Service begins to degrade, but it is not denied. > [eunsoo] If the server cannot answer all CARD requests after the limit, the whole network is affected by that. Why do we want this while there is an alternative? [Govind] Very good point. Dycard provides an alternative wherein the probability of a DoS happening is quite low, as has been pointed out by Robert in his email. The probability of such a DoS attack happening in the DT draft is quite high. Also another question would be: is such a situation possible from happening in a non-malicious case? Consider the following scenario. Genuine MNs report beacons from APs other domains. Wouldn't a similar case happen in even then as the number of APs/ given area begin to increase? Note the server or the AR has no way to make out whether such APs are genuine or not. Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email increase and the system provides degraded service even here? Ofcourse, one way is for the AR to maintain a list of all APs for which the the server sent a nack in the past. Isn't this an added burden? Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch such an attack. > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > villian. > > [eunsoo] This should be the last resort. We should prevent or minimize this kind of situation from the protocol design stage. Dycard has an advantag regarding this. [Govind] One more question to ponder is when there are multiple "villains". One could just move away once the rate falls and another one takes over after sometime. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 10:40:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11314 for ; Fri, 7 Mar 2003 10:40:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FpEO05532; Fri, 7 Mar 2003 10:51:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FoqO05509 for ; Fri, 7 Mar 2003 10:50:52 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11246 for ; Fri, 7 Mar 2003 10:38:48 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27Fep823712 for ; Fri, 7 Mar 2003 09:40:51 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 09:40:48 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 07:39:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 10:39:56 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkop7bhdaU55aGRC6uY2z+Lu8pawAGelsw To: , Cc: , X-OriginalArrivalTime: 07 Mar 2003 15:39:57.0347 (UTC) FILETIME=[CE753730:01C2E4BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27FoqO05510 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Eunsoo, Good points. Comments embedded. Thanks, Govind. > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > requests. If the default limits defined in the protocol are gone over, the > router starts dropping CARD requests, regardless of what IP address they have on > them. Service begins to degrade, but it is not denied. > [eunsoo] If the server cannot answer all CARD requests after the limit, the whole network is affected by that. Why do we want this while there is an alternative? [Govind] Very good point. Dycard provides an alternative wherein the probability of a DoS happening is quite low, as has been pointed out by Robert in his email. The probability of such a DoS attack happening in the DT draft is quite high. Also another question would be: is such a situation possible from happening in a non-malicious case? Consider the following scenario. Genuine MNs report beacons from APs other domains. Wouldn't a similar case happen in even then as the number of APs/ given area begin to increase? Note the server or the AR has no way to make out whether such APs are genuine or not. Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email increase and the system provides degraded service even here? Ofcourse, one way is for the AR to maintain a list of all APs for which the the server sent a nack in the past. Isn't this an added burden? Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch such an attack. > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > villian. > > [eunsoo] This should be the last resort. We should prevent or minimize this kind of situation from the protocol design stage. Dycard has an advantag regarding this. [Govind] One more question to ponder is when there are multiple "villains". One could just move away once the rate falls and another one takes over after sometime. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 10:57:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12320 for ; Fri, 7 Mar 2003 10:57:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27G8bN07735 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 11:08:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27G8bO07732 for ; Fri, 7 Mar 2003 11:08:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12270 for ; Fri, 7 Mar 2003 10:56:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27G8LO07668; Fri, 7 Mar 2003 11:08:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27G73O06917 for ; Fri, 7 Mar 2003 11:07:03 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12073 for ; Fri, 7 Mar 2003 10:54:59 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27Fus827185 for ; Fri, 7 Mar 2003 09:56:54 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 09:56:54 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 09:56:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 10:56:51 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkop7bhdaU55aGRC6uY2z+Lu8pawAGelswAAFSHEA= To: , Cc: X-OriginalArrivalTime: 07 Mar 2003 15:56:54.0019 (UTC) FILETIME=[2C710D30:01C2E4C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27G73O06918 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi: In current DT draft, it is not the intention to create a database from administrator in CARD server to validate AP addresses. What we have assumed is that some L2 layer mechanism is available which enables AR to know what APs are attached to it, as well as AR to know when some APs are removed or new ones are introduced. AR reports this AP list to CARD server. So, effectively ARs are in control of validating AP addresses that are attached to them. Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Friday, March 07, 2003 10:40 AM To: eunsoo@nec-labs.com; Chaskar Hemant (NRC/Boston) Cc: pcalhoun@airespace.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi Eunsoo, Good points. Comments embedded. Thanks, Govind. > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > requests. If the default limits defined in the protocol are gone over, the > router starts dropping CARD requests, regardless of what IP address they have on > them. Service begins to degrade, but it is not denied. > [eunsoo] If the server cannot answer all CARD requests after the limit, the whole network is affected by that. Why do we want this while there is an alternative? [Govind] Very good point. Dycard provides an alternative wherein the probability of a DoS happening is quite low, as has been pointed out by Robert in his email. The probability of such a DoS attack happening in the DT draft is quite high. Also another question would be: is such a situation possible from happening in a non-malicious case? Consider the following scenario. Genuine MNs report beacons from APs other domains. Wouldn't a similar case happen in even then as the number of APs/ given area begin to increase? Note the server or the AR has no way to make out whether such APs are genuine or not. Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email increase and the system provides degraded service even here? Ofcourse, one way is for the AR to maintain a list of all APs for which the the server sent a nack in the past. Isn't this an added burden? Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch such an attack. > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > villian. > > [eunsoo] This should be the last resort. We should prevent or minimize this kind of situation from the protocol design stage. Dycard has an advantag regarding this. [Govind] One more question to ponder is when there are multiple "villains". One could just move away once the rate falls and another one takes over after sometime. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 10:57:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12354 for ; Fri, 7 Mar 2003 10:57:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27G8LO07668; Fri, 7 Mar 2003 11:08:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27G73O06917 for ; Fri, 7 Mar 2003 11:07:03 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12073 for ; Fri, 7 Mar 2003 10:54:59 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27Fus827185 for ; Fri, 7 Mar 2003 09:56:54 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 09:56:54 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 09:56:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 10:56:51 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkop7bhdaU55aGRC6uY2z+Lu8pawAGelswAAFSHEA= To: , Cc: X-OriginalArrivalTime: 07 Mar 2003 15:56:54.0019 (UTC) FILETIME=[2C710D30:01C2E4C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27G73O06918 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi: In current DT draft, it is not the intention to create a database from administrator in CARD server to validate AP addresses. What we have assumed is that some L2 layer mechanism is available which enables AR to know what APs are attached to it, as well as AR to know when some APs are removed or new ones are introduced. AR reports this AP list to CARD server. So, effectively ARs are in control of validating AP addresses that are attached to them. Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Friday, March 07, 2003 10:40 AM To: eunsoo@nec-labs.com; Chaskar Hemant (NRC/Boston) Cc: pcalhoun@airespace.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi Eunsoo, Good points. Comments embedded. Thanks, Govind. > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > requests. If the default limits defined in the protocol are gone over, the > router starts dropping CARD requests, regardless of what IP address they have on > them. Service begins to degrade, but it is not denied. > [eunsoo] If the server cannot answer all CARD requests after the limit, the whole network is affected by that. Why do we want this while there is an alternative? [Govind] Very good point. Dycard provides an alternative wherein the probability of a DoS happening is quite low, as has been pointed out by Robert in his email. The probability of such a DoS attack happening in the DT draft is quite high. Also another question would be: is such a situation possible from happening in a non-malicious case? Consider the following scenario. Genuine MNs report beacons from APs other domains. Wouldn't a similar case happen in even then as the number of APs/ given area begin to increase? Note the server or the AR has no way to make out whether such APs are genuine or not. Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email increase and the system provides degraded service even here? Ofcourse, one way is for the AR to maintain a list of all APs for which the the server sent a nack in the past. Isn't this an added burden? Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch such an attack. > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > villian. > > [eunsoo] This should be the last resort. We should prevent or minimize this kind of situation from the protocol design stage. Dycard has an advantag regarding this. [Govind] One more question to ponder is when there are multiple "villains". One could just move away once the rate falls and another one takes over after sometime. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 12:06:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16933 for ; Fri, 7 Mar 2003 12:06:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HISn14558 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 12:18:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HISO14555 for ; Fri, 7 Mar 2003 12:18:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16915 for ; Fri, 7 Mar 2003 12:06:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HI5O14471; Fri, 7 Mar 2003 12:18:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27H5NO12226 for ; Fri, 7 Mar 2003 12:05:23 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16081 for ; Fri, 7 Mar 2003 11:53:17 -0500 (EST) Message-ID: <008101c2e4ca$1fab1e30$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , Cc: , References: <02a101c2e441$30ca80e0$156015ac@T23KEMPF> <002101c2e4bb$ed07bdc0$6e620f8a@eunsoo> Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 08:53:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [eunsoo] This should be the last resort. We should prevent or minimize this > kind of situation from the protocol design stage. Dycard has an advantag > regarding this. > If you mean dycard, I don't see the alternative as any better. An MN can still bombard the router with requests. > > > + Scope ID is simple mechanism to limit cache contamination from domain > scale > > to region scale. However, it is easily possible that malicious node would > make > > the cache at current AR always filled up will all ARs in scope ID. > > > > > > > So? > > > [eunsoo] I gave you an example of the negative impact of this situation in > the past. In short, it means the cache is not useful for most of other CARD > applications except L2-L3 mapping. > You've missed my point. If the cache is large enough to hold all the entries in the domain, what does it matter if all the entries in the domain are in the cache? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 12:07:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16970 for ; Fri, 7 Mar 2003 12:07:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HI5O14471; Fri, 7 Mar 2003 12:18:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27H5NO12226 for ; Fri, 7 Mar 2003 12:05:23 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16081 for ; Fri, 7 Mar 2003 11:53:17 -0500 (EST) Message-ID: <008101c2e4ca$1fab1e30$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , Cc: , References: <02a101c2e441$30ca80e0$156015ac@T23KEMPF> <002101c2e4bb$ed07bdc0$6e620f8a@eunsoo> Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 08:53:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [eunsoo] This should be the last resort. We should prevent or minimize this > kind of situation from the protocol design stage. Dycard has an advantag > regarding this. > If you mean dycard, I don't see the alternative as any better. An MN can still bombard the router with requests. > > > + Scope ID is simple mechanism to limit cache contamination from domain > scale > > to region scale. However, it is easily possible that malicious node would > make > > the cache at current AR always filled up will all ARs in scope ID. > > > > > > > So? > > > [eunsoo] I gave you an example of the negative impact of this situation in > the past. In short, it means the cache is not useful for most of other CARD > applications except L2-L3 mapping. > You've missed my point. If the cache is large enough to hold all the entries in the domain, what does it matter if all the entries in the domain are in the cache? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 12:07:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17011 for ; Fri, 7 Mar 2003 12:07:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HJLC14725 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 12:19:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HJLO14722 for ; Fri, 7 Mar 2003 12:19:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16988 for ; Fri, 7 Mar 2003 12:07:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HJ2O14663; Fri, 7 Mar 2003 12:19:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27H8nO13220 for ; Fri, 7 Mar 2003 12:08:49 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16299 for ; Fri, 7 Mar 2003 11:56:43 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Mar 2003 11:58:48 -0500 Message-ID: <00a701c2e4e4$24072680$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: , Cc: References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 12:00:02 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 07 Mar 2003 16:58:48.0088 (UTC) FILETIME=[D2330180:01C2E4CA] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hermant, OK. But the problem is not how an AR find the addresses of the AP attached to itself. The problem is that MN will hear various beacons which may come from different domains. This is often the case for WLAN. And MN will send an inquiry to the current AR and the current AR will send an inquiry to the CARD server. As the number of MN increases, the number of inquires from ARs to the CARD server will increase. Then the measure proposed by James will cause blocking the CARD server from answering any more inquiries and we may see high probability of such situation. Eunsoo ----- Original Message ----- From: To: ; Cc: Sent: Friday, March 07, 2003 7:56 AM Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi: In current DT draft, it is not the intention to create a database from administrator in CARD server to validate AP addresses. What we have assumed is that some L2 layer mechanism is available which enables AR to know what APs are attached to it, as well as AR to know when some APs are removed or new ones are introduced. AR reports this AP list to CARD server. So, effectively ARs are in control of validating AP addresses that are attached to them. Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Friday, March 07, 2003 10:40 AM To: eunsoo@nec-labs.com; Chaskar Hemant (NRC/Boston) Cc: pcalhoun@airespace.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi Eunsoo, Good points. Comments embedded. Thanks, Govind. > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > requests. If the default limits defined in the protocol are gone over, the > router starts dropping CARD requests, regardless of what IP address they have on > them. Service begins to degrade, but it is not denied. > [eunsoo] If the server cannot answer all CARD requests after the limit, the whole network is affected by that. Why do we want this while there is an alternative? [Govind] Very good point. Dycard provides an alternative wherein the probability of a DoS happening is quite low, as has been pointed out by Robert in his email. The probability of such a DoS attack happening in the DT draft is quite high. Also another question would be: is such a situation possible from happening in a non-malicious case? Consider the following scenario. Genuine MNs report beacons from APs other domains. Wouldn't a similar case happen in even then as the number of APs/ given area begin to increase? Note the server or the AR has no way to make out whether such APs are genuine or not. Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email increase and the system provides degraded service even here? Ofcourse, one way is for the AR to maintain a list of all APs for which the the server sent a nack in the past. Isn't this an added burden? Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch such an attack. > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > villian. > > [eunsoo] This should be the last resort. We should prevent or minimize this kind of situation from the protocol design stage. Dycard has an advantag regarding this. [Govind] One more question to ponder is when there are multiple "villains". One could just move away once the rate falls and another one takes over after sometime. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 12:08:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17043 for ; Fri, 7 Mar 2003 12:08:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HJ2O14663; Fri, 7 Mar 2003 12:19:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27H8nO13220 for ; Fri, 7 Mar 2003 12:08:49 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16299 for ; Fri, 7 Mar 2003 11:56:43 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Mar 2003 11:58:48 -0500 Message-ID: <00a701c2e4e4$24072680$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: , Cc: References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 12:00:02 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 07 Mar 2003 16:58:48.0088 (UTC) FILETIME=[D2330180:01C2E4CA] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hermant, OK. But the problem is not how an AR find the addresses of the AP attached to itself. The problem is that MN will hear various beacons which may come from different domains. This is often the case for WLAN. And MN will send an inquiry to the current AR and the current AR will send an inquiry to the CARD server. As the number of MN increases, the number of inquires from ARs to the CARD server will increase. Then the measure proposed by James will cause blocking the CARD server from answering any more inquiries and we may see high probability of such situation. Eunsoo ----- Original Message ----- From: To: ; Cc: Sent: Friday, March 07, 2003 7:56 AM Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi: In current DT draft, it is not the intention to create a database from administrator in CARD server to validate AP addresses. What we have assumed is that some L2 layer mechanism is available which enables AR to know what APs are attached to it, as well as AR to know when some APs are removed or new ones are introduced. AR reports this AP list to CARD server. So, effectively ARs are in control of validating AP addresses that are attached to them. Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Friday, March 07, 2003 10:40 AM To: eunsoo@nec-labs.com; Chaskar Hemant (NRC/Boston) Cc: pcalhoun@airespace.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi Eunsoo, Good points. Comments embedded. Thanks, Govind. > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > requests. If the default limits defined in the protocol are gone over, the > router starts dropping CARD requests, regardless of what IP address they have on > them. Service begins to degrade, but it is not denied. > [eunsoo] If the server cannot answer all CARD requests after the limit, the whole network is affected by that. Why do we want this while there is an alternative? [Govind] Very good point. Dycard provides an alternative wherein the probability of a DoS happening is quite low, as has been pointed out by Robert in his email. The probability of such a DoS attack happening in the DT draft is quite high. Also another question would be: is such a situation possible from happening in a non-malicious case? Consider the following scenario. Genuine MNs report beacons from APs other domains. Wouldn't a similar case happen in even then as the number of APs/ given area begin to increase? Note the server or the AR has no way to make out whether such APs are genuine or not. Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email increase and the system provides degraded service even here? Ofcourse, one way is for the AR to maintain a list of all APs for which the the server sent a nack in the past. Isn't this an added burden? Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch such an attack. > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > villian. > > [eunsoo] This should be the last resort. We should prevent or minimize this kind of situation from the protocol design stage. Dycard has an advantag regarding this. [Govind] One more question to ponder is when there are multiple "villains". One could just move away once the rate falls and another one takes over after sometime. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 12:10:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17285 for ; Fri, 7 Mar 2003 12:10:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HMFV15218 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 12:22:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HMFO15215 for ; Fri, 7 Mar 2003 12:22:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17189 for ; Fri, 7 Mar 2003 12:10:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HM4O15115; Fri, 7 Mar 2003 12:22:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HHfO14358 for ; Fri, 7 Mar 2003 12:17:41 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16810 for ; Fri, 7 Mar 2003 12:05:34 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27H7c816796 for ; Fri, 7 Mar 2003 11:07:38 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 11:07:38 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 11:07:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 12:07:37 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkymRAOuqY1I6JRsqhMSWmveQhoAAACexA To: , , Cc: , X-OriginalArrivalTime: 07 Mar 2003 17:07:38.0294 (UTC) FILETIME=[0E3A0560:01C2E4CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27HHfO14361 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > [eunsoo] This should be the last resort. We should prevent or minimize this > kind of situation from the protocol design stage. Dycard has an advantag > regarding this. > If you mean dycard, I don't see the alternative as any better. An MN can still bombard the router with requests. [Govind] The MN can bombard the AR with L2 ids, but it does not cause a deterioration of performance in dycard as in the DT draft. I don't think you are correct on this. The very fact that the DT draft asks the L2-L3 mapping from the server if not available at the AR is bound to have problems. > > > + Scope ID is simple mechanism to limit cache contamination from domain > scale > > to region scale. However, it is easily possible that malicious node would > make > > the cache at current AR always filled up will all ARs in scope ID. > > > > > > > So? > > > [eunsoo] I gave you an example of the negative impact of this situation in > the past. In short, it means the cache is not useful for most of other CARD > applications except L2-L3 mapping. > You've missed my point. If the cache is large enough to hold all the entries in the domain, what does it matter if all the entries in the domain are in the cache? [Govind] The problem is that dynamic updates need refreshing. This leads to unnecessary communication between ARs that are not CARs. The more the number of such incorrect entries more the communication, which is another DoS. Also, once all genuine entries are in the cache why would you ever need a server? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 12:10:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17319 for ; Fri, 7 Mar 2003 12:10:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HM4O15115; Fri, 7 Mar 2003 12:22:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HHfO14358 for ; Fri, 7 Mar 2003 12:17:41 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16810 for ; Fri, 7 Mar 2003 12:05:34 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27H7c816796 for ; Fri, 7 Mar 2003 11:07:38 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 11:07:38 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 11:07:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 12:07:37 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkymRAOuqY1I6JRsqhMSWmveQhoAAACexA To: , , Cc: , X-OriginalArrivalTime: 07 Mar 2003 17:07:38.0294 (UTC) FILETIME=[0E3A0560:01C2E4CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27HHfO14361 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > [eunsoo] This should be the last resort. We should prevent or minimize this > kind of situation from the protocol design stage. Dycard has an advantag > regarding this. > If you mean dycard, I don't see the alternative as any better. An MN can still bombard the router with requests. [Govind] The MN can bombard the AR with L2 ids, but it does not cause a deterioration of performance in dycard as in the DT draft. I don't think you are correct on this. The very fact that the DT draft asks the L2-L3 mapping from the server if not available at the AR is bound to have problems. > > > + Scope ID is simple mechanism to limit cache contamination from domain > scale > > to region scale. However, it is easily possible that malicious node would > make > > the cache at current AR always filled up will all ARs in scope ID. > > > > > > > So? > > > [eunsoo] I gave you an example of the negative impact of this situation in > the past. In short, it means the cache is not useful for most of other CARD > applications except L2-L3 mapping. > You've missed my point. If the cache is large enough to hold all the entries in the domain, what does it matter if all the entries in the domain are in the cache? [Govind] The problem is that dynamic updates need refreshing. This leads to unnecessary communication between ARs that are not CARs. The more the number of such incorrect entries more the communication, which is another DoS. Also, once all genuine entries are in the cache why would you ever need a server? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 12:11:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17385 for ; Fri, 7 Mar 2003 12:11:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HNIn15397 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 12:23:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HNIO15394 for ; Fri, 7 Mar 2003 12:23:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17361 for ; Fri, 7 Mar 2003 12:11:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HN6O15345; Fri, 7 Mar 2003 12:23:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HLUO14905 for ; Fri, 7 Mar 2003 12:21:30 -0500 Received: from mailer.nec-labs.com (mailer.ccrl.nj.nec.com [138.15.108.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17131 for ; Fri, 7 Mar 2003 12:09:25 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Mar 2003 12:08:25 -0500 Message-ID: <00ae01c2e4e5$7bf87780$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , Cc: , References: <02a101c2e441$30ca80e0$156015ac@T23KEMPF> <002101c2e4bb$ed07bdc0$6e620f8a@eunsoo> <008101c2e4ca$1fab1e30$156015ac@T23KEMPF> Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 12:09:39 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 07 Mar 2003 17:08:25.0152 (UTC) FILETIME=[2A27FC00:01C2E4CC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, My comments are inline. ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; ; Cc: ; Sent: Friday, March 07, 2003 8:53 AM Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > [eunsoo] This should be the last resort. We should prevent or minimize this > > kind of situation from the protocol design stage. Dycard has an advantag > > regarding this. > > > > If you mean dycard, I don't see the alternative as any better. An MN can still > bombard the router with requests. > [eunsoo] You should distinguish two things: cache contamination and DoS attack. Cache contamination is a problem that should be prevented with our best. The problem of the server approach is that it opens a wide door for easy cache contamination. DoS attack: In any protocol, a client can send lots of request to a server. In our case, a client can send lots of L2-L3 mapping inquires. You cannot prevent MN from sending inquiries unless you can shutdown MN remotely. So what is the difference? The server approach makes the situation worse by affecting the cental server. That is, a malicious attack can affect the whole network. In Dycard case, the attacker can only affect the current AR. So the impact is local. Also look-up of local memory is much smaller job than doing the same thing and then generating and sending an inquiry message to the CARD server. So the attacker should have much more capability to do DoS attack on Dycard than the server approach. > > > > + Scope ID is simple mechanism to limit cache contamination from domain > > scale > > > to region scale. However, it is easily possible that malicious node would > > make > > > the cache at current AR always filled up will all ARs in scope ID. > > > > > > > > > > So? > > > > > [eunsoo] I gave you an example of the negative impact of this situation in > > the past. In short, it means the cache is not useful for most of other CARD > > applications except L2-L3 mapping. > > > > You've missed my point. > > If the cache is large enough to hold all the entries in the domain, what does it > matter if all the entries in the domain are in the cache? > > [eunsoo] It seems to me that you are considering L2-L3 mapping as the only application of CARD. Please recheck the issue draft which describes various applications of CARD. If the cache is filled with lots of false entries, all those applications won't be possible except L2-L3 mapping. I don't think you are really proposing such a large cache size. Anyway, now we have to add also capability information of each AP or AR to each entry. So how much memory do you want to allocate at each AR for the entries? And why do we want to do this when there is an alternative? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 12:12:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17458 for ; Fri, 7 Mar 2003 12:12:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HN6O15345; Fri, 7 Mar 2003 12:23:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HLUO14905 for ; Fri, 7 Mar 2003 12:21:30 -0500 Received: from mailer.nec-labs.com (mailer.ccrl.nj.nec.com [138.15.108.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17131 for ; Fri, 7 Mar 2003 12:09:25 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Mar 2003 12:08:25 -0500 Message-ID: <00ae01c2e4e5$7bf87780$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , Cc: , References: <02a101c2e441$30ca80e0$156015ac@T23KEMPF> <002101c2e4bb$ed07bdc0$6e620f8a@eunsoo> <008101c2e4ca$1fab1e30$156015ac@T23KEMPF> Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 12:09:39 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 07 Mar 2003 17:08:25.0152 (UTC) FILETIME=[2A27FC00:01C2E4CC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, My comments are inline. ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; ; Cc: ; Sent: Friday, March 07, 2003 8:53 AM Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > [eunsoo] This should be the last resort. We should prevent or minimize this > > kind of situation from the protocol design stage. Dycard has an advantag > > regarding this. > > > > If you mean dycard, I don't see the alternative as any better. An MN can still > bombard the router with requests. > [eunsoo] You should distinguish two things: cache contamination and DoS attack. Cache contamination is a problem that should be prevented with our best. The problem of the server approach is that it opens a wide door for easy cache contamination. DoS attack: In any protocol, a client can send lots of request to a server. In our case, a client can send lots of L2-L3 mapping inquires. You cannot prevent MN from sending inquiries unless you can shutdown MN remotely. So what is the difference? The server approach makes the situation worse by affecting the cental server. That is, a malicious attack can affect the whole network. In Dycard case, the attacker can only affect the current AR. So the impact is local. Also look-up of local memory is much smaller job than doing the same thing and then generating and sending an inquiry message to the CARD server. So the attacker should have much more capability to do DoS attack on Dycard than the server approach. > > > > + Scope ID is simple mechanism to limit cache contamination from domain > > scale > > > to region scale. However, it is easily possible that malicious node would > > make > > > the cache at current AR always filled up will all ARs in scope ID. > > > > > > > > > > So? > > > > > [eunsoo] I gave you an example of the negative impact of this situation in > > the past. In short, it means the cache is not useful for most of other CARD > > applications except L2-L3 mapping. > > > > You've missed my point. > > If the cache is large enough to hold all the entries in the domain, what does it > matter if all the entries in the domain are in the cache? > > [eunsoo] It seems to me that you are considering L2-L3 mapping as the only application of CARD. Please recheck the issue draft which describes various applications of CARD. If the cache is filled with lots of false entries, all those applications won't be possible except L2-L3 mapping. I don't think you are really proposing such a large cache size. Anyway, now we have to add also capability information of each AP or AR to each entry. So how much memory do you want to allocate at each AR for the entries? And why do we want to do this when there is an alternative? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 12:18:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17889 for ; Fri, 7 Mar 2003 12:18:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HTch16048 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 12:29:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HTcO16045 for ; Fri, 7 Mar 2003 12:29:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17844 for ; Fri, 7 Mar 2003 12:17:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HTRO16000; Fri, 7 Mar 2003 12:29:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HRcO15858 for ; Fri, 7 Mar 2003 12:27:38 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17665 for ; Fri, 7 Mar 2003 12:15:31 -0500 (EST) Message-ID: <00e501c2e4cd$3c2d8540$156015ac@T23KEMPF> From: "James Kempf" To: , , Cc: References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 09:16:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Right, but what about APs that are attached to other ARs? How can AR1 know that an AP being presented to it by MN is not bogus? jak ----- Original Message ----- From: To: ; Cc: Sent: Friday, March 07, 2003 7:56 AM Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > Hi: > > In current DT draft, it is not the intention to create a database from administrator in CARD server to validate AP addresses. What we have assumed is that some L2 layer mechanism is available which enables AR to know what APs are attached to it, as well as AR to know when some APs are removed or new ones are introduced. AR reports this AP list to CARD server. So, effectively ARs are in control of validating AP addresses that are attached to them. > > Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com > [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Friday, March 07, 2003 10:40 AM > To: eunsoo@nec-labs.com; Chaskar Hemant (NRC/Boston) > Cc: pcalhoun@airespace.com; seamoby@ietf.org > Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > > Hi Eunsoo, > Good points. > Comments embedded. > Thanks, > Govind. > > > > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > > requests. If the default limits defined in the protocol are gone over, the > > router starts dropping CARD requests, regardless of what IP address they > have on > > them. Service begins to degrade, but it is not denied. > > > > [eunsoo] If the server cannot answer all CARD requests after the limit, the > whole network is affected by that. Why do we want this while there is an > alternative? > > [Govind] Very good point. Dycard provides an alternative wherein the probability > of a DoS happening is quite low, as has been pointed out by Robert in his email. The > probability of such a DoS attack happening in the DT draft is quite high. > Also another question would be: is such a situation possible from happening > in a non-malicious case? > Consider the following scenario. Genuine MNs report beacons from APs other domains. > Wouldn't a similar case happen in even then as the number of APs/ given area > begin to increase? Note the server or the AR has no way to make out whether such APs are genuine > or not. > Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email > increase and the system provides degraded service even here? Ofcourse, one way is for the > AR to maintain a list of all APs for which the the server sent a nack in the past. > Isn't this an added burden? > Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch > such an attack. > > > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > > villian. > > > > > [eunsoo] This should be the last resort. We should prevent or minimize this > kind of situation from the protocol design stage. Dycard has an advantag > regarding this. > > [Govind] One more question to ponder is when there are multiple "villains". > One could just move away once the rate falls and another one takes over > after sometime. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 12:18:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17916 for ; Fri, 7 Mar 2003 12:18:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HTRO16000; Fri, 7 Mar 2003 12:29:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HRcO15858 for ; Fri, 7 Mar 2003 12:27:38 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17665 for ; Fri, 7 Mar 2003 12:15:31 -0500 (EST) Message-ID: <00e501c2e4cd$3c2d8540$156015ac@T23KEMPF> From: "James Kempf" To: , , Cc: References: Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 09:16:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Right, but what about APs that are attached to other ARs? How can AR1 know that an AP being presented to it by MN is not bogus? jak ----- Original Message ----- From: To: ; Cc: Sent: Friday, March 07, 2003 7:56 AM Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > Hi: > > In current DT draft, it is not the intention to create a database from administrator in CARD server to validate AP addresses. What we have assumed is that some L2 layer mechanism is available which enables AR to know what APs are attached to it, as well as AR to know when some APs are removed or new ones are introduced. AR reports this AP list to CARD server. So, effectively ARs are in control of validating AP addresses that are attached to them. > > Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com > [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Friday, March 07, 2003 10:40 AM > To: eunsoo@nec-labs.com; Chaskar Hemant (NRC/Boston) > Cc: pcalhoun@airespace.com; seamoby@ietf.org > Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > > Hi Eunsoo, > Good points. > Comments embedded. > Thanks, > Govind. > > > > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > > requests. If the default limits defined in the protocol are gone over, the > > router starts dropping CARD requests, regardless of what IP address they > have on > > them. Service begins to degrade, but it is not denied. > > > > [eunsoo] If the server cannot answer all CARD requests after the limit, the > whole network is affected by that. Why do we want this while there is an > alternative? > > [Govind] Very good point. Dycard provides an alternative wherein the probability > of a DoS happening is quite low, as has been pointed out by Robert in his email. The > probability of such a DoS attack happening in the DT draft is quite high. > Also another question would be: is such a situation possible from happening > in a non-malicious case? > Consider the following scenario. Genuine MNs report beacons from APs other domains. > Wouldn't a similar case happen in even then as the number of APs/ given area > begin to increase? Note the server or the AR has no way to make out whether such APs are genuine > or not. > Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email > increase and the system provides degraded service even here? Ofcourse, one way is for the > AR to maintain a list of all APs for which the the server sent a nack in the past. > Isn't this an added burden? > Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch > such an attack. > > > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > > villian. > > > > > [eunsoo] This should be the last resort. We should prevent or minimize this > kind of situation from the protocol design stage. Dycard has an advantag > regarding this. > > [Govind] One more question to ponder is when there are multiple "villains". > One could just move away once the rate falls and another one takes over > after sometime. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 12:18:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17966 for ; Fri, 7 Mar 2003 12:18:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HUJp16180 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 12:30:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HUJO16177 for ; Fri, 7 Mar 2003 12:30:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17908 for ; Fri, 7 Mar 2003 12:18:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HU3O16097; Fri, 7 Mar 2003 12:30:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HTHO15971 for ; Fri, 7 Mar 2003 12:29:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17833 for ; Fri, 7 Mar 2003 12:17:10 -0500 (EST) Message-ID: <00ee01c2e4cd$7695c2b0$156015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 7 Mar 2003 09:17:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Question on CTSR Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Question for the DT: is there any time when the MN would initiate a CTSR when it would *not* be undergoing handover? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 12:19:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18010 for ; Fri, 7 Mar 2003 12:19:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HU3O16097; Fri, 7 Mar 2003 12:30:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HTHO15971 for ; Fri, 7 Mar 2003 12:29:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17833 for ; Fri, 7 Mar 2003 12:17:10 -0500 (EST) Message-ID: <00ee01c2e4cd$7695c2b0$156015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 7 Mar 2003 09:17:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Question on CTSR Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Question for the DT: is there any time when the MN would initiate a CTSR when it would *not* be undergoing handover? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 12:44:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19401 for ; Fri, 7 Mar 2003 12:44:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HuWk19454 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 12:56:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HuWO19451 for ; Fri, 7 Mar 2003 12:56:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19380 for ; Fri, 7 Mar 2003 12:44:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HuHO19416; Fri, 7 Mar 2003 12:56:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HtkO19352 for ; Fri, 7 Mar 2003 12:55:46 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19272 for ; Fri, 7 Mar 2003 12:43:38 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27HiM105672 for ; Fri, 7 Mar 2003 19:44:22 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 19:45:41 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 19:45:41 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 09:45:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 12:45:36 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkzXlGg6sqYrBnQ6G5hRXPOe4MywAAycfw To: , , Cc: X-OriginalArrivalTime: 07 Mar 2003 17:45:37.0224 (UTC) FILETIME=[5C932480:01C2E4D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27HtlO19354 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: The bogus AP is understood as an AP that is "not physically adjacent" to current AP. The bogus AP may be valid AP in the domain (attached to another AR) or non-existent. Scope ID solution restricts the bogus AP (in non-physical adjacency sense) DoS on AR cache to a subset of domain APs. If AP does not exist in the domain, an error is returned from CARD server. - Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, March 07, 2003 12:16 PM To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston); eunsoo@nec-labs.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Right, but what about APs that are attached to other ARs? How can AR1 know that an AP being presented to it by MN is not bogus? jak ----- Original Message ----- From: To: ; Cc: Sent: Friday, March 07, 2003 7:56 AM Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > Hi: > > In current DT draft, it is not the intention to create a database from administrator in CARD server to validate AP addresses. What we have assumed is that some L2 layer mechanism is available which enables AR to know what APs are attached to it, as well as AR to know when some APs are removed or new ones are introduced. AR reports this AP list to CARD server. So, effectively ARs are in control of validating AP addresses that are attached to them. > > Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com > [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Friday, March 07, 2003 10:40 AM > To: eunsoo@nec-labs.com; Chaskar Hemant (NRC/Boston) > Cc: pcalhoun@airespace.com; seamoby@ietf.org > Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > > Hi Eunsoo, > Good points. > Comments embedded. > Thanks, > Govind. > > > > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > > requests. If the default limits defined in the protocol are gone over, the > > router starts dropping CARD requests, regardless of what IP address they > have on > > them. Service begins to degrade, but it is not denied. > > > > [eunsoo] If the server cannot answer all CARD requests after the limit, the > whole network is affected by that. Why do we want this while there is an > alternative? > > [Govind] Very good point. Dycard provides an alternative wherein the probability > of a DoS happening is quite low, as has been pointed out by Robert in his email. The > probability of such a DoS attack happening in the DT draft is quite high. > Also another question would be: is such a situation possible from happening > in a non-malicious case? > Consider the following scenario. Genuine MNs report beacons from APs other domains. > Wouldn't a similar case happen in even then as the number of APs/ given area > begin to increase? Note the server or the AR has no way to make out whether such APs are genuine > or not. > Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email > increase and the system provides degraded service even here? Ofcourse, one way is for the > AR to maintain a list of all APs for which the the server sent a nack in the past. > Isn't this an added burden? > Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch > such an attack. > > > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > > villian. > > > > > [eunsoo] This should be the last resort. We should prevent or minimize this > kind of situation from the protocol design stage. Dycard has an advantag > regarding this. > > [Govind] One more question to ponder is when there are multiple "villains". > One could just move away once the rate falls and another one takes over > after sometime. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 12:46:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19496 for ; Fri, 7 Mar 2003 12:46:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HuHO19416; Fri, 7 Mar 2003 12:56:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HtkO19352 for ; Fri, 7 Mar 2003 12:55:46 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19272 for ; Fri, 7 Mar 2003 12:43:38 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27HiM105672 for ; Fri, 7 Mar 2003 19:44:22 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 19:45:41 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 19:45:41 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 09:45:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Fri, 7 Mar 2003 12:45:36 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkzXlGg6sqYrBnQ6G5hRXPOe4MywAAycfw To: , , Cc: X-OriginalArrivalTime: 07 Mar 2003 17:45:37.0224 (UTC) FILETIME=[5C932480:01C2E4D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27HtlO19354 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: The bogus AP is understood as an AP that is "not physically adjacent" to current AP. The bogus AP may be valid AP in the domain (attached to another AR) or non-existent. Scope ID solution restricts the bogus AP (in non-physical adjacency sense) DoS on AR cache to a subset of domain APs. If AP does not exist in the domain, an error is returned from CARD server. - Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, March 07, 2003 12:16 PM To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston); eunsoo@nec-labs.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Right, but what about APs that are attached to other ARs? How can AR1 know that an AP being presented to it by MN is not bogus? jak ----- Original Message ----- From: To: ; Cc: Sent: Friday, March 07, 2003 7:56 AM Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > Hi: > > In current DT draft, it is not the intention to create a database from administrator in CARD server to validate AP addresses. What we have assumed is that some L2 layer mechanism is available which enables AR to know what APs are attached to it, as well as AR to know when some APs are removed or new ones are introduced. AR reports this AP list to CARD server. So, effectively ARs are in control of validating AP addresses that are attached to them. > > Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com > [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Friday, March 07, 2003 10:40 AM > To: eunsoo@nec-labs.com; Chaskar Hemant (NRC/Boston) > Cc: pcalhoun@airespace.com; seamoby@ietf.org > Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt > > > Hi Eunsoo, > Good points. > Comments embedded. > Thanks, > Govind. > > > > > Rate limiting isn't done on any particular MN, it is done on *all* CARD > > requests. If the default limits defined in the protocol are gone over, the > > router starts dropping CARD requests, regardless of what IP address they > have on > > them. Service begins to degrade, but it is not denied. > > > > [eunsoo] If the server cannot answer all CARD requests after the limit, the > whole network is affected by that. Why do we want this while there is an > alternative? > > [Govind] Very good point. Dycard provides an alternative wherein the probability > of a DoS happening is quite low, as has been pointed out by Robert in his email. The > probability of such a DoS attack happening in the DT draft is quite high. > Also another question would be: is such a situation possible from happening > in a non-malicious case? > Consider the following scenario. Genuine MNs report beacons from APs other domains. > Wouldn't a similar case happen in even then as the number of APs/ given area > begin to increase? Note the server or the AR has no way to make out whether such APs are genuine > or not. > Now if we have multiple MNs doing this wouldn't the problem described by Hemant in his email > increase and the system provides degraded service even here? Ofcourse, one way is for the > AR to maintain a list of all APs for which the the server sent a nack in the past. > Isn't this an added burden? > Since I think dycard bases cache entries on actual handovers, this is quite difficult to launch > such an attack. > > > Meanwhile, legitimate users begin to notice, get a sysadmin, and find the > > villian. > > > > > [eunsoo] This should be the last resort. We should prevent or minimize this > kind of situation from the protocol design stage. Dycard has an advantag > regarding this. > > [Govind] One more question to ponder is when there are multiple "villains". > One could just move away once the rate falls and another one takes over > after sometime. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 16:21:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04821 for ; Fri, 7 Mar 2003 16:21:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27LWxa11583 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 16:32:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LWxO11580 for ; Fri, 7 Mar 2003 16:32:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04784 for ; Fri, 7 Mar 2003 16:20:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LWYO11544; Fri, 7 Mar 2003 16:32:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LG3O09987 for ; Fri, 7 Mar 2003 16:16:03 -0500 Received: from fep02-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03158 for ; Fri, 7 Mar 2003 16:03:49 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030307210534.IGRH311274.fep02-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 7 Mar 2003 16:05:34 -0500 Message-ID: <3E6909A7.4000404@ee.ryerson.ca> Date: Fri, 07 Mar 2003 16:05:43 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org References: <3E618A3C.5060708@ee.ryerson.ca> Content-Type: multipart/alternative; boundary="------------020809080205020109000606" X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Fri, 7 Mar 2003 16:05:34 -0500 Subject: [Seamoby] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Approaching March 10 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------020809080205020109000606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) --------------020809080205020109000606 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Call for Papers - IP Mobility 2003
IEEE VTC Symposium on IP Mobility
October 4-9, 2003 Orlando, FL, USA

in Conjunction with IEEE VTC Fall 2003
Submission Deadline Extended: March 10, 2003

Scope
=====
Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: 
* Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance
* New approaches to wide-area and local mobility
* Quality of Service models, resource management, and provisioning
* Traffic Engineering in mobile wireless IP access networks
* Transport protocol design for mobile wireless networks
* Security including security threat models, threat analysis and their impact on routing
* Application level protocol design and performance
* Mobile and wireless applications, their service requirements and performance
* Content delivery support in IP network for mobile users
* Multicasting for mobile wireless services
* Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network)
* Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular)
* Inter-vehicular network architecture
* Mobile wireless IP access network deployment and management

Posters are also solicited on the projects related to **Support for Network Mobility**.

Submission Instructions
=======================
Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/.

Important Dates
Extended Abstract Due:  March 10, 2003
Acceptance Notification:  May 15, 2003
Camera Ready Copy of Full Paper Due:  July 15, 2003
Symposium Date:  October 4, 2003

Organization
============

Program Co-Chairs:

Muhammad Jaseemuddin (jaseem@ee.ryerson.ca)
Department of Electrical and Computer Engineering
Ryerson University
Toronto, Canada

Hongyi Li (hyli@nortelnetworks.com)
Wireless Technology Lab
Nortel Networks
Ottawa, Canada

Publicity Co-Chair:

Junaid Zubairi (junaid.zubairi@fredonia.edu)
Department of Mathematics and Computer Science
SUNY at Fredonia
Fredonia, NY, USA

Technical Program Committee
===========================
* Ahmed Helmy (U of Southern California, USA)
* Abdelsalam Helal (U of Florida, Gainesville, USA)
* Alan O'Neill (Flarion Technologies, USA)
* Behcet Sarikaya (Alcatel, USA)
* Christophe Janneteau (Motorola, France)
* Govindan Ravindran (Soma Networks, Canada)
* Haseeb Akhtar (inCode Telecom group, USA)
* Hany Elgebaly (Intel Corporation, USA)
* Hesham Soliman (Ericsson, Sweden)
* Lars Wolf (TU Braunschweig, Germany)
* Michael Wolf (Daimler-Chrysler, Germany)
* Raouf Boutaba (U of Waterloo, Canada)
* Sajal Das (The U of Texas at Arlington, USA)
* Samir R. Das (SUNY at Stony Brook, USA)
* Thiery Ernst (Wide, Keio U, Japan)
* Thomas Noel (U of Strasbourg, France)
* Yasser Rasheed (Intel Corporation, USA)
--------------020809080205020109000606-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 16:21:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04854 for ; Fri, 7 Mar 2003 16:21:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LWYO11544; Fri, 7 Mar 2003 16:32:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LG3O09987 for ; Fri, 7 Mar 2003 16:16:03 -0500 Received: from fep02-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03158 for ; Fri, 7 Mar 2003 16:03:49 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030307210534.IGRH311274.fep02-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 7 Mar 2003 16:05:34 -0500 Message-ID: <3E6909A7.4000404@ee.ryerson.ca> Date: Fri, 07 Mar 2003 16:05:43 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org References: <3E618A3C.5060708@ee.ryerson.ca> Content-Type: multipart/alternative; boundary="------------020809080205020109000606" X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Fri, 7 Mar 2003 16:05:34 -0500 Subject: [Seamoby] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Approaching March 10 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------020809080205020109000606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) --------------020809080205020109000606 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Call for Papers - IP Mobility 2003
IEEE VTC Symposium on IP Mobility
October 4-9, 2003 Orlando, FL, USA

in Conjunction with IEEE VTC Fall 2003
Submission Deadline Extended: March 10, 2003

Scope
=====
Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: 
* Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance
* New approaches to wide-area and local mobility
* Quality of Service models, resource management, and provisioning
* Traffic Engineering in mobile wireless IP access networks
* Transport protocol design for mobile wireless networks
* Security including security threat models, threat analysis and their impact on routing
* Application level protocol design and performance
* Mobile and wireless applications, their service requirements and performance
* Content delivery support in IP network for mobile users
* Multicasting for mobile wireless services
* Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network)
* Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular)
* Inter-vehicular network architecture
* Mobile wireless IP access network deployment and management

Posters are also solicited on the projects related to **Support for Network Mobility**.

Submission Instructions
=======================
Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/.

Important Dates
Extended Abstract Due:  March 10, 2003
Acceptance Notification:  May 15, 2003
Camera Ready Copy of Full Paper Due:  July 15, 2003
Symposium Date:  October 4, 2003

Organization
============

Program Co-Chairs:

Muhammad Jaseemuddin (jaseem@ee.ryerson.ca)
Department of Electrical and Computer Engineering
Ryerson University
Toronto, Canada

Hongyi Li (hyli@nortelnetworks.com)
Wireless Technology Lab
Nortel Networks
Ottawa, Canada

Publicity Co-Chair:

Junaid Zubairi (junaid.zubairi@fredonia.edu)
Department of Mathematics and Computer Science
SUNY at Fredonia
Fredonia, NY, USA

Technical Program Committee
===========================
* Ahmed Helmy (U of Southern California, USA)
* Abdelsalam Helal (U of Florida, Gainesville, USA)
* Alan O'Neill (Flarion Technologies, USA)
* Behcet Sarikaya (Alcatel, USA)
* Christophe Janneteau (Motorola, France)
* Govindan Ravindran (Soma Networks, Canada)
* Haseeb Akhtar (inCode Telecom group, USA)
* Hany Elgebaly (Intel Corporation, USA)
* Hesham Soliman (Ericsson, Sweden)
* Lars Wolf (TU Braunschweig, Germany)
* Michael Wolf (Daimler-Chrysler, Germany)
* Raouf Boutaba (U of Waterloo, Canada)
* Sajal Das (The U of Texas at Arlington, USA)
* Samir R. Das (SUNY at Stony Brook, USA)
* Thiery Ernst (Wide, Keio U, Japan)
* Thomas Noel (U of Strasbourg, France)
* Yasser Rasheed (Intel Corporation, USA)
--------------020809080205020109000606-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 16:48:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07642 for ; Fri, 7 Mar 2003 16:48:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27M0RW15888 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 17:00:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27M0QO15880 for ; Fri, 7 Mar 2003 17:00:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07562 for ; Fri, 7 Mar 2003 16:48:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27M0BO15778; Fri, 7 Mar 2003 17:00:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LxtO15478 for ; Fri, 7 Mar 2003 16:59:55 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07408 for ; Fri, 7 Mar 2003 16:47:44 -0500 (EST) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h27Lnm113866 for ; Fri, 7 Mar 2003 13:49:48 -0800 (PST) Message-ID: <3E6913FB.6030000@cs.ucsb.edu> Date: Fri, 07 Mar 2003 13:49:47 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 MIME-Version: 1.0 To: seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] latest dyCARD draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We have updated the dyCARD draft to better address some of the issues that have been brought up during the recent discussion. The latest version is available at: http://www.cs.ucsb.edu/~robertc/drafts/draft-trossen-seamoby-dycard-01.txt thanks, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 16:49:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07669 for ; Fri, 7 Mar 2003 16:49:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27M0BO15778; Fri, 7 Mar 2003 17:00:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LxtO15478 for ; Fri, 7 Mar 2003 16:59:55 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07408 for ; Fri, 7 Mar 2003 16:47:44 -0500 (EST) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h27Lnm113866 for ; Fri, 7 Mar 2003 13:49:48 -0800 (PST) Message-ID: <3E6913FB.6030000@cs.ucsb.edu> Date: Fri, 07 Mar 2003 13:49:47 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 MIME-Version: 1.0 To: seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] latest dyCARD draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We have updated the dyCARD draft to better address some of the issues that have been brought up during the recent discussion. The latest version is available at: http://www.cs.ucsb.edu/~robertc/drafts/draft-trossen-seamoby-dycard-01.txt thanks, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 17:52:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11712 for ; Fri, 7 Mar 2003 17:52:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27N4d722811 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 18:04:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27N4cO22808 for ; Fri, 7 Mar 2003 18:04:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11692 for ; Fri, 7 Mar 2003 17:52:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27N4LO22758; Fri, 7 Mar 2003 18:04:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27N16O22577 for ; Fri, 7 Mar 2003 18:01:06 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11345 for ; Fri, 7 Mar 2003 17:48:54 -0500 (EST) Message-ID: <00fa01c2e4fb$ce8b38f0$156015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 7 Mar 2003 14:49:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] DT Draft and DyCard Security Comparison Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert, thank you for posting the draft. I assume the draft that you just posted to the list has more details on it, since the original draft had nothing. Obviously, the DyCard folks have a particular security model in mind from which they are arguing, and it has been hard for the DT members to respond because their assumptions were not entirely clear. Now, they should be. I'd like to see some discussion comparing the security approaches of the DT draft and DyCard. Please try to keep the discussion objective, technically focussed and specific. And remember that the solution must scale from small office networks to enterprises and ISPs. The solution doesn't have to span two administrative domains, however. I'll try to find some time to read the draft myself and comment. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 17:53:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11729 for ; Fri, 7 Mar 2003 17:53:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27N4LO22758; Fri, 7 Mar 2003 18:04:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27N16O22577 for ; Fri, 7 Mar 2003 18:01:06 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11345 for ; Fri, 7 Mar 2003 17:48:54 -0500 (EST) Message-ID: <00fa01c2e4fb$ce8b38f0$156015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 7 Mar 2003 14:49:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] DT Draft and DyCard Security Comparison Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, thank you for posting the draft. I assume the draft that you just posted to the list has more details on it, since the original draft had nothing. Obviously, the DyCard folks have a particular security model in mind from which they are arguing, and it has been hard for the DT members to respond because their assumptions were not entirely clear. Now, they should be. I'd like to see some discussion comparing the security approaches of the DT draft and DyCard. Please try to keep the discussion objective, technically focussed and specific. And remember that the solution must scale from small office networks to enterprises and ISPs. The solution doesn't have to span two administrative domains, however. I'll try to find some time to read the draft myself and comment. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 20:19:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25009 for ; Fri, 7 Mar 2003 20:19:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h281VFn05222 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 20:31:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281VFO05219 for ; Fri, 7 Mar 2003 20:31:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24900 for ; Fri, 7 Mar 2003 20:18:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281V1O05196; Fri, 7 Mar 2003 20:31:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281RMO04771 for ; Fri, 7 Mar 2003 20:27:22 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24022 for ; Fri, 7 Mar 2003 20:15:06 -0500 (EST) 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 RAA24996; Fri, 7 Mar 2003 17:17:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h281H9P13458; Fri, 7 Mar 2003 17:17:09 -0800 X-mProtect: <200303080117> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpde2Gqcf; Fri, 07 Mar 2003 17:17:08 PST Message-ID: <3E694494.5F0BADB6@iprg.nokia.com> Date: Fri, 07 Mar 2003 17:17:08 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Question on CTSR References: <00ee01c2e4cd$7695c2b0$156015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jim, James Kempf wrote: > Question for the DT: is there any time when the MN would initiate a CTSR when it > would *not* be undergoing handover? > I cannot think of any, as of now. -Rajeev > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 20:19:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25046 for ; Fri, 7 Mar 2003 20:19:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281V1O05196; Fri, 7 Mar 2003 20:31:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281RMO04771 for ; Fri, 7 Mar 2003 20:27:22 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24022 for ; Fri, 7 Mar 2003 20:15:06 -0500 (EST) 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 RAA24996; Fri, 7 Mar 2003 17:17:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h281H9P13458; Fri, 7 Mar 2003 17:17:09 -0800 X-mProtect: <200303080117> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpde2Gqcf; Fri, 07 Mar 2003 17:17:08 PST Message-ID: <3E694494.5F0BADB6@iprg.nokia.com> Date: Fri, 07 Mar 2003 17:17:08 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Question on CTSR References: <00ee01c2e4cd$7695c2b0$156015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Jim, James Kempf wrote: > Question for the DT: is there any time when the MN would initiate a CTSR when it > would *not* be undergoing handover? > I cannot think of any, as of now. -Rajeev > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 20:40:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27020 for ; Fri, 7 Mar 2003 20:40:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h281q6x08334 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 20:52:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281q6O08331 for ; Fri, 7 Mar 2003 20:52:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26905 for ; Fri, 7 Mar 2003 20:39:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281prO08271; Fri, 7 Mar 2003 20:51:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Ki4O05585 for ; Fri, 7 Mar 2003 15:44:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28108; Fri, 7 Mar 2003 15:31:53 -0500 (EST) Message-Id: <200303072031.PAA28108@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:31:53 -0500 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-protocol-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Candidate Access Router Discovery Author(s) : M. Liebsch et al. Filename : draft-ietf-seamoby-card-protocol-01.txt Pages : 28 Date : 2003-3-7 To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities of candidate ARs (CARs) for handover, along with their capabilities, prior to the initiation of the IP-layer handover. Depending upon the mode of operation, the current AR may or may not be involved in the CAR discovery process. The act of discovery of CARs has two aspects to it: Identifying the IP addresses of the CARs and finding the capabilities of those CARs. This process is called 'candidate access router discovery' (CARD). At the time of IP-layer handover, that CAR, whose capabilities are a good match to the preferences of the MN, may be chosen as the target AR (TAR) for handover. This draft describes a solution to perform CARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-card-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-card-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143448.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 20:40:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27041 for ; Fri, 7 Mar 2003 20:40:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h281q8E08350 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 20:52:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281q7O08347 for ; Fri, 7 Mar 2003 20:52:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26910 for ; Fri, 7 Mar 2003 20:39:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281ptO08287; Fri, 7 Mar 2003 20:51:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Ki9O05589 for ; Fri, 7 Mar 2003 15:44:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28144; Fri, 7 Mar 2003 15:31:58 -0500 (EST) Message-Id: <200303072031.PAA28144@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:31:58 -0500 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-ctp-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Context Transfer Protocol Author(s) : J. Loughney et al. Filename : draft-ietf-seamoby-ctp-01.txt Pages : 21 Date : 2003-3-7 This document presents a context transfer protocol that enables authorized context transfers. Context transfers allows better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reducing latency, packet losses and avoid re-initiation of signaling to and from the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ctp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-ctp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-ctp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-ctp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-ctp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143456.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 7 20:40:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27060 for ; Fri, 7 Mar 2003 20:40:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h281q9908366 for seamoby-archive@odin.ietf.org; Fri, 7 Mar 2003 20:52:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281q9O08363 for ; Fri, 7 Mar 2003 20:52:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26923 for ; Fri, 7 Mar 2003 20:39:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281puO08305; Fri, 7 Mar 2003 20:51:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KiFO05594 for ; Fri, 7 Mar 2003 15:44:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28180; Fri, 7 Mar 2003 15:32:04 -0500 (EST) Message-Id: <200303072032.PAA28180@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:32:04 -0500 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-mobility-terminology-02.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Mobility Related Terminology Author(s) : J. Manner, M. Kojo Filename : draft-ietf-seamoby-mobility-terminology-02.txt Pages : 31 Date : 2003-3-7 There is a need for common definitions of terminology in the work to be done around IP mobility. This memo defines terms for mobility related terminology. It is intended as a living document for use by the Seamoby Working Group in Seamoby drafts and in WG discussions, but not limited in scope to the terms needed by the Seamoby Working Group. Other working groups dealing with mobility may take advantage of this terminology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-mobility-terminology-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-mobility-terminology-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-mobility-terminology-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-mobility-terminology-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143505.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 20:40:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27092 for ; Fri, 7 Mar 2003 20:40:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281prO08271; Fri, 7 Mar 2003 20:51:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Ki4O05585 for ; Fri, 7 Mar 2003 15:44:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28108; Fri, 7 Mar 2003 15:31:53 -0500 (EST) Message-Id: <200303072031.PAA28108@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:31:53 -0500 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-protocol-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Candidate Access Router Discovery Author(s) : M. Liebsch et al. Filename : draft-ietf-seamoby-card-protocol-01.txt Pages : 28 Date : 2003-3-7 To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities of candidate ARs (CARs) for handover, along with their capabilities, prior to the initiation of the IP-layer handover. Depending upon the mode of operation, the current AR may or may not be involved in the CAR discovery process. The act of discovery of CARs has two aspects to it: Identifying the IP addresses of the CARs and finding the capabilities of those CARs. This process is called 'candidate access router discovery' (CARD). At the time of IP-layer handover, that CAR, whose capabilities are a good match to the preferences of the MN, may be chosen as the target AR (TAR) for handover. This draft describes a solution to perform CARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-card-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-card-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143448.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 20:40:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27105 for ; Fri, 7 Mar 2003 20:40:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281ptO08287; Fri, 7 Mar 2003 20:51:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Ki9O05589 for ; Fri, 7 Mar 2003 15:44:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28144; Fri, 7 Mar 2003 15:31:58 -0500 (EST) Message-Id: <200303072031.PAA28144@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:31:58 -0500 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-ctp-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Context Transfer Protocol Author(s) : J. Loughney et al. Filename : draft-ietf-seamoby-ctp-01.txt Pages : 21 Date : 2003-3-7 This document presents a context transfer protocol that enables authorized context transfers. Context transfers allows better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reducing latency, packet losses and avoid re-initiation of signaling to and from the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ctp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-ctp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-ctp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-ctp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-ctp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143456.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 7 20:40:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27143 for ; Fri, 7 Mar 2003 20:40:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281puO08305; Fri, 7 Mar 2003 20:51:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KiFO05594 for ; Fri, 7 Mar 2003 15:44:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28180; Fri, 7 Mar 2003 15:32:04 -0500 (EST) Message-Id: <200303072032.PAA28180@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:32:04 -0500 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-mobility-terminology-02.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Mobility Related Terminology Author(s) : J. Manner, M. Kojo Filename : draft-ietf-seamoby-mobility-terminology-02.txt Pages : 31 Date : 2003-3-7 There is a need for common definitions of terminology in the work to be done around IP mobility. This memo defines terms for mobility related terminology. It is intended as a living document for use by the Seamoby Working Group in Seamoby drafts and in WG discussions, but not limited in scope to the terms needed by the Seamoby Working Group. Other working groups dealing with mobility may take advantage of this terminology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-mobility-terminology-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-mobility-terminology-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-mobility-terminology-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-mobility-terminology-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143505.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 10:11:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28544 for ; Mon, 10 Mar 2003 10:11:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AFO3h18469 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 10:24:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFO3O18466 for ; Mon, 10 Mar 2003 10:24:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28493 for ; Mon, 10 Mar 2003 10:10:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFNfO18442; Mon, 10 Mar 2003 10:23:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFM8O18377 for ; Mon, 10 Mar 2003 10:22:08 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28113 for ; Mon, 10 Mar 2003 10:08:36 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AFAh811248 for ; Mon, 10 Mar 2003 09:10:43 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 09:10:43 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:10:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 10:10:42 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkGYuzTLF1XDCgQA+Is9KArhkmmwC/RZjA To: , , X-OriginalArrivalTime: 10 Mar 2003 15:10:43.0137 (UTC) FILETIME=[381B4310:01C2E717] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AFM8O18378 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, >> If the (MN-)requested L2-L3 mapping does not exist in the AR cache, >> a request is sent to the server to obtain this information >(maybe I missed >> something in the draft). If the MN does the request for all >n ARs in the >scope, >> the cache will soon be filled up with all possible ARs in >the scope region. >But even >> more, the MN can also explicitly request L2-L3 mappings of >ARs that are not >within the region >> (the AR does not know about the region, and it does not know >whether or not >the supplied >> information is correct, so it has to ask the server). The >mapping is requested >from the server >> by the AR, the server rejects the request (reason "out of >scope region"). >Result of this would be >> server and AR load, i.e., DoS attack. >> > >Where's the denial of service? All you've described above is >how the router >cache gets populated by all the APs in the region. Properly >sizing the router >cache is required, of course. Well, it was said quite a lot, but maybe another time would help to get the picture. You've got two cases. One is to have a malicous MN sending in-scope L2 id to the AR. This eventually leads to filling up the cache with all scope L2 id. But I wasn't talking about this case. In the case described above, the malicous MN requests L2-L3 mappings of ARs that are not within the region. Since the AR cannot figure this out, it will forward the request to the server, asking for resolving. The server will answer (correctly) with "out-of-region" (or whatever). If the MN keeps injecting these kind of requests, you'll add load to the server. The cache will not get populated at all, but the AR and server keep communicating. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 10:11:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28562 for ; Mon, 10 Mar 2003 10:11:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFNfO18442; Mon, 10 Mar 2003 10:23:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFM8O18377 for ; Mon, 10 Mar 2003 10:22:08 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28113 for ; Mon, 10 Mar 2003 10:08:36 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AFAh811248 for ; Mon, 10 Mar 2003 09:10:43 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 09:10:43 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:10:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 10:10:42 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLkGYuzTLF1XDCgQA+Is9KArhkmmwC/RZjA To: , , X-OriginalArrivalTime: 10 Mar 2003 15:10:43.0137 (UTC) FILETIME=[381B4310:01C2E717] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AFM8O18378 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, >> If the (MN-)requested L2-L3 mapping does not exist in the AR cache, >> a request is sent to the server to obtain this information >(maybe I missed >> something in the draft). If the MN does the request for all >n ARs in the >scope, >> the cache will soon be filled up with all possible ARs in >the scope region. >But even >> more, the MN can also explicitly request L2-L3 mappings of >ARs that are not >within the region >> (the AR does not know about the region, and it does not know >whether or not >the supplied >> information is correct, so it has to ask the server). The >mapping is requested >from the server >> by the AR, the server rejects the request (reason "out of >scope region"). >Result of this would be >> server and AR load, i.e., DoS attack. >> > >Where's the denial of service? All you've described above is >how the router >cache gets populated by all the APs in the region. Properly >sizing the router >cache is required, of course. Well, it was said quite a lot, but maybe another time would help to get the picture. You've got two cases. One is to have a malicous MN sending in-scope L2 id to the AR. This eventually leads to filling up the cache with all scope L2 id. But I wasn't talking about this case. In the case described above, the malicous MN requests L2-L3 mappings of ARs that are not within the region. Since the AR cannot figure this out, it will forward the request to the server, asking for resolving. The server will answer (correctly) with "out-of-region" (or whatever). If the MN keeps injecting these kind of requests, you'll add load to the server. The cache will not get populated at all, but the AR and server keep communicating. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 11:20:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01316 for ; Mon, 10 Mar 2003 11:20:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AGXPJ23717 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 11:33:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGXPO23714 for ; Mon, 10 Mar 2003 11:33:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01251 for ; Mon, 10 Mar 2003 11:19:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGXCO23665; Mon, 10 Mar 2003 11:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGOrO23167 for ; Mon, 10 Mar 2003 11:24:53 -0500 Received: from eccles.ee.ryerson.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00898 for ; Mon, 10 Mar 2003 11:11:19 -0500 (EST) Received: from ee.ryerson.ca ([172.16.30.72]) by eccles.ee.ryerson.ca (8.12.8/8.12.8) with ESMTP id h2AGDQ9o079282 for ; Mon, 10 Mar 2003 11:13:26 -0500 (EST) (envelope-from jaseem@ee.ryerson.ca) Message-ID: <3E6CB9A5.7020007@ee.ryerson.ca> Date: Mon, 10 Mar 2003 11:13:25 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org References: <3E618A3C.5060708@ee.ryerson.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 24 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 24, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 24, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 11:20:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01354 for ; Mon, 10 Mar 2003 11:20:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGXCO23665; Mon, 10 Mar 2003 11:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGOrO23167 for ; Mon, 10 Mar 2003 11:24:53 -0500 Received: from eccles.ee.ryerson.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00898 for ; Mon, 10 Mar 2003 11:11:19 -0500 (EST) Received: from ee.ryerson.ca ([172.16.30.72]) by eccles.ee.ryerson.ca (8.12.8/8.12.8) with ESMTP id h2AGDQ9o079282 for ; Mon, 10 Mar 2003 11:13:26 -0500 (EST) (envelope-from jaseem@ee.ryerson.ca) Message-ID: <3E6CB9A5.7020007@ee.ryerson.ca> Date: Mon, 10 Mar 2003 11:13:25 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org References: <3E618A3C.5060708@ee.ryerson.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 24 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 24, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 24, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 11:38:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02197 for ; Mon, 10 Mar 2003 11:38:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AGpL225850 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 11:51:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGpLO25847 for ; Mon, 10 Mar 2003 11:51:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02187 for ; Mon, 10 Mar 2003 11:37:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGp9O25812; Mon, 10 Mar 2003 11:51:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGo4O25747 for ; Mon, 10 Mar 2003 11:50:04 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02158 for ; Mon, 10 Mar 2003 11:36:28 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2AGcVZj027440 for ; Mon, 10 Mar 2003 09:38:31 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA10025 for ; Mon, 10 Mar 2003 09:38:34 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 10:37:45 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3A@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , kempf@docomolabs-usa.com, Govind.Krishnamurthi@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 10:37:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Monday, March 10, 2003 9:11 AM To: kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi James, >> If the (MN-)requested L2-L3 mapping does not exist in the AR cache, >> a request is sent to the server to obtain this information >(maybe I missed >> something in the draft). If the MN does the request for all >n ARs in the >scope, >> the cache will soon be filled up with all possible ARs in >the scope region. >But even >> more, the MN can also explicitly request L2-L3 mappings of >ARs that are not >within the region >> (the AR does not know about the region, and it does not know >whether or not >the supplied >> information is correct, so it has to ask the server). The >mapping is requested >from the server >> by the AR, the server rejects the request (reason "out of >scope region"). >Result of this would be >> server and AR load, i.e., DoS attack. >> > >Where's the denial of service? All you've described above is >how the router >cache gets populated by all the APs in the region. Properly >sizing the router >cache is required, of course. Well, it was said quite a lot, but maybe another time would help to get the picture. You've got two cases. One is to have a malicous MN sending in-scope L2 id to the AR. This eventually leads to filling up the cache with all scope L2 id. But I wasn't talking about this case. In the case described above, the malicous MN requests L2-L3 mappings of ARs that are not within the region. Since the AR cannot figure this out, it will forward the request to the server, asking for resolving. The server will answer (correctly) with "out-of-region" (or whatever). If the MN keeps injecting these kind of requests, you'll add load to the server. The cache will not get populated at all, but the AR and server keep communicating. AJOY-> I think this can be easily solved by maintaining some soft-state at AR. AR should able to track the number of requests made by connected MN during given time interval. The AR should avoid forwarding request from malicious MN to the CARD server once the number of attempts crosses the pre-configured threshold. I am sure there are lots of other ways to solve this problem. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 11:38:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02211 for ; Mon, 10 Mar 2003 11:38:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGp9O25812; Mon, 10 Mar 2003 11:51:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGo4O25747 for ; Mon, 10 Mar 2003 11:50:04 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02158 for ; Mon, 10 Mar 2003 11:36:28 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2AGcVZj027440 for ; Mon, 10 Mar 2003 09:38:31 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA10025 for ; Mon, 10 Mar 2003 09:38:34 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 10:37:45 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3A@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , kempf@docomolabs-usa.com, Govind.Krishnamurthi@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 10:37:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Monday, March 10, 2003 9:11 AM To: kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi James, >> If the (MN-)requested L2-L3 mapping does not exist in the AR cache, >> a request is sent to the server to obtain this information >(maybe I missed >> something in the draft). If the MN does the request for all >n ARs in the >scope, >> the cache will soon be filled up with all possible ARs in >the scope region. >But even >> more, the MN can also explicitly request L2-L3 mappings of >ARs that are not >within the region >> (the AR does not know about the region, and it does not know >whether or not >the supplied >> information is correct, so it has to ask the server). The >mapping is requested >from the server >> by the AR, the server rejects the request (reason "out of >scope region"). >Result of this would be >> server and AR load, i.e., DoS attack. >> > >Where's the denial of service? All you've described above is >how the router >cache gets populated by all the APs in the region. Properly >sizing the router >cache is required, of course. Well, it was said quite a lot, but maybe another time would help to get the picture. You've got two cases. One is to have a malicous MN sending in-scope L2 id to the AR. This eventually leads to filling up the cache with all scope L2 id. But I wasn't talking about this case. In the case described above, the malicous MN requests L2-L3 mappings of ARs that are not within the region. Since the AR cannot figure this out, it will forward the request to the server, asking for resolving. The server will answer (correctly) with "out-of-region" (or whatever). If the MN keeps injecting these kind of requests, you'll add load to the server. The cache will not get populated at all, but the AR and server keep communicating. AJOY-> I think this can be easily solved by maintaining some soft-state at AR. AR should able to track the number of requests made by connected MN during given time interval. The AR should avoid forwarding request from malicious MN to the CARD server once the number of attempts crosses the pre-configured threshold. I am sure there are lots of other ways to solve this problem. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 11:55:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02758 for ; Mon, 10 Mar 2003 11:55:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AH8ZQ28150 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:08:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH8YO28147 for ; Mon, 10 Mar 2003 12:08:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02724 for ; Mon, 10 Mar 2003 11:54:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH8EO28106; Mon, 10 Mar 2003 12:08:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH6bO27050 for ; Mon, 10 Mar 2003 12:06:37 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02684 for ; Mon, 10 Mar 2003 11:53:02 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2AGt5XR027553 for ; Mon, 10 Mar 2003 09:55:09 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA26700 for ; Mon, 10 Mar 2003 09:55:04 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 10:55:05 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Singh Ajoy-ASINGH1 , Dirk.Trossen@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 10:55:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Thursday, March 06, 2003 6:29 PM To: Ajoy Singh; Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Which thread? Which section? If you know quick pointer to it, please paste it here. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Thursday, March 06, 2003 1:27 PM To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> Sure there is. But what is wrong in using AAA? OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? AJOY-> this is not relevant in current discussion. But if ever decide to design CARD as an extension to DNS protocol then I do not see any reason for not re-using the DNS security mechanism. But why do you think otherwise? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 11:56:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02827 for ; Mon, 10 Mar 2003 11:56:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH8EO28106; Mon, 10 Mar 2003 12:08:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH6bO27050 for ; Mon, 10 Mar 2003 12:06:37 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02684 for ; Mon, 10 Mar 2003 11:53:02 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2AGt5XR027553 for ; Mon, 10 Mar 2003 09:55:09 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA26700 for ; Mon, 10 Mar 2003 09:55:04 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 10:55:05 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Singh Ajoy-ASINGH1 , Dirk.Trossen@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 10:55:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Thursday, March 06, 2003 6:29 PM To: Ajoy Singh; Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Which thread? Which section? If you know quick pointer to it, please paste it here. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Thursday, March 06, 2003 1:27 PM To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> Sure there is. But what is wrong in using AAA? OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? AJOY-> this is not relevant in current discussion. But if ever decide to design CARD as an extension to DNS protocol then I do not see any reason for not re-using the DNS security mechanism. But why do you think otherwise? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:04:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03206 for ; Mon, 10 Mar 2003 12:04:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHHCl28815 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:17:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHHBO28812 for ; Mon, 10 Mar 2003 12:17:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03155 for ; Mon, 10 Mar 2003 12:03:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHGxO28756; Mon, 10 Mar 2003 12:16:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHCuO28456 for ; Mon, 10 Mar 2003 12:12:56 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02912 for ; Mon, 10 Mar 2003 11:59:21 -0500 (EST) Message-ID: <005201c2e726$7b178e30$156015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <00ee01c2e4cd$7695c2b0$156015ac@T23KEMPF> <3E694494.5F0BADB6@iprg.nokia.com> Subject: Re: [Seamoby] Question on CTSR Date: Mon, 10 Mar 2003 08:59:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Then perhaps someone on the DT could tell me the point of having this message be separate from signaling from the MN that triggers the handover? If a MN has to send two messages over the air prior to handover, one to trigger the handover and one to trigger the CT, that's two opportunities for something to go wrong (packet gets dropped, signaling cut off by link switch), etc. jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: Sent: Friday, March 07, 2003 5:17 PM Subject: Re: [Seamoby] Question on CTSR > > Hello Jim, > > James Kempf wrote: > > > Question for the DT: is there any time when the MN would initiate a CTSR when it > > would *not* be undergoing handover? > > > > I cannot think of any, as of now. > > -Rajeev > > > > > > jak > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:04:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03228 for ; Mon, 10 Mar 2003 12:04:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHGxO28756; Mon, 10 Mar 2003 12:16:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHCuO28456 for ; Mon, 10 Mar 2003 12:12:56 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02912 for ; Mon, 10 Mar 2003 11:59:21 -0500 (EST) Message-ID: <005201c2e726$7b178e30$156015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: References: <00ee01c2e4cd$7695c2b0$156015ac@T23KEMPF> <3E694494.5F0BADB6@iprg.nokia.com> Subject: Re: [Seamoby] Question on CTSR Date: Mon, 10 Mar 2003 08:59:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Then perhaps someone on the DT could tell me the point of having this message be separate from signaling from the MN that triggers the handover? If a MN has to send two messages over the air prior to handover, one to trigger the handover and one to trigger the CT, that's two opportunities for something to go wrong (packet gets dropped, signaling cut off by link switch), etc. jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: Sent: Friday, March 07, 2003 5:17 PM Subject: Re: [Seamoby] Question on CTSR > > Hello Jim, > > James Kempf wrote: > > > Question for the DT: is there any time when the MN would initiate a CTSR when it > > would *not* be undergoing handover? > > > > I cannot think of any, as of now. > > -Rajeev > > > > > > jak > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:07:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03396 for ; Mon, 10 Mar 2003 12:07:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHKLQ29187 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:20:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHKLO29184 for ; Mon, 10 Mar 2003 12:20:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03372 for ; Mon, 10 Mar 2003 12:06:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHK7O29071; Mon, 10 Mar 2003 12:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHGCO28683 for ; Mon, 10 Mar 2003 12:16:12 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03105 for ; Mon, 10 Mar 2003 12:02:37 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AH4i812932 for ; Mon, 10 Mar 2003 11:04:44 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:04:44 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:03:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 12:03:48 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLnJf2pajejdLcQRzWfgXrQLcfm5gAAJQHA To: , , X-OriginalArrivalTime: 10 Mar 2003 17:03:49.0993 (UTC) FILETIME=[05634D90:01C2E727] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHGDO28684 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy: There is nothing wrong with AAA. The point is that AAA functionality is not central to CARD service. In fact, they are quite independent functionality wise, and hence, CARD server should be treated as logical entity and people can integrate it with whatever server they want it to be. Then, CARD service should be usable even if there is no AAA server of one's choice present in some network. These integration tasks can be taken as separate drafts in collaboration with respective server WGs. Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Monday, March 10, 2003 11:55 AM To: Chaskar Hemant (NRC/Boston); Singh Ajoy-ASINGH1; Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Hemant, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Thursday, March 06, 2003 6:29 PM To: Ajoy Singh; Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Which thread? Which section? If you know quick pointer to it, please paste it here. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Thursday, March 06, 2003 1:27 PM To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> Sure there is. But what is wrong in using AAA? OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? AJOY-> this is not relevant in current discussion. But if ever decide to design CARD as an extension to DNS protocol then I do not see any reason for not re-using the DNS security mechanism. But why do you think otherwise? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:07:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03416 for ; Mon, 10 Mar 2003 12:07:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHKTV29204 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:20:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHKTO29201 for ; Mon, 10 Mar 2003 12:20:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03379 for ; Mon, 10 Mar 2003 12:06:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHK9O29111; Mon, 10 Mar 2003 12:20:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHIBO28878 for ; Mon, 10 Mar 2003 12:18:11 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03260 for ; Mon, 10 Mar 2003 12:04:36 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AH6g813557 for ; Mon, 10 Mar 2003 11:06:43 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:06:42 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:05:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 12:05:40 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLnI7VLX3fLH2QdQd6fnuTD7MRymQAA1yqw To: , , , , X-OriginalArrivalTime: 10 Mar 2003 17:05:41.0119 (UTC) FILETIME=[479FC8F0:01C2E727] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHIBO28879 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy: I do not see how AR can track number of request from a specific malicious node. When node disconnects and reconnects, it appears as a completely different node to AR. To pinpoint MN's identity additional mechanisms may be needed. Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Monday, March 10, 2003 11:38 AM To: Trossen Dirk (NRC/Boston); kempf@docomolabs-usa.com; Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Monday, March 10, 2003 9:11 AM To: kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi James, >> If the (MN-)requested L2-L3 mapping does not exist in the AR cache, >> a request is sent to the server to obtain this information >(maybe I missed >> something in the draft). If the MN does the request for all >n ARs in the >scope, >> the cache will soon be filled up with all possible ARs in >the scope region. >But even >> more, the MN can also explicitly request L2-L3 mappings of >ARs that are not >within the region >> (the AR does not know about the region, and it does not know >whether or not >the supplied >> information is correct, so it has to ask the server). The >mapping is requested >from the server >> by the AR, the server rejects the request (reason "out of >scope region"). >Result of this would be >> server and AR load, i.e., DoS attack. >> > >Where's the denial of service? All you've described above is >how the router >cache gets populated by all the APs in the region. Properly >sizing the router >cache is required, of course. Well, it was said quite a lot, but maybe another time would help to get the picture. You've got two cases. One is to have a malicous MN sending in-scope L2 id to the AR. This eventually leads to filling up the cache with all scope L2 id. But I wasn't talking about this case. In the case described above, the malicous MN requests L2-L3 mappings of ARs that are not within the region. Since the AR cannot figure this out, it will forward the request to the server, asking for resolving. The server will answer (correctly) with "out-of-region" (or whatever). If the MN keeps injecting these kind of requests, you'll add load to the server. The cache will not get populated at all, but the AR and server keep communicating. AJOY-> I think this can be easily solved by maintaining some soft-state at AR. AR should able to track the number of requests made by connected MN during given time interval. The AR should avoid forwarding request from malicious MN to the CARD server once the number of attempts crosses the pre-configured threshold. I am sure there are lots of other ways to solve this problem. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:07:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03429 for ; Mon, 10 Mar 2003 12:07:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHK9O29111; Mon, 10 Mar 2003 12:20:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHIBO28878 for ; Mon, 10 Mar 2003 12:18:11 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03260 for ; Mon, 10 Mar 2003 12:04:36 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AH6g813557 for ; Mon, 10 Mar 2003 11:06:43 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:06:42 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:05:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 12:05:40 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLnI7VLX3fLH2QdQd6fnuTD7MRymQAA1yqw To: , , , , X-OriginalArrivalTime: 10 Mar 2003 17:05:41.0119 (UTC) FILETIME=[479FC8F0:01C2E727] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHIBO28879 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy: I do not see how AR can track number of request from a specific malicious node. When node disconnects and reconnects, it appears as a completely different node to AR. To pinpoint MN's identity additional mechanisms may be needed. Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Monday, March 10, 2003 11:38 AM To: Trossen Dirk (NRC/Boston); kempf@docomolabs-usa.com; Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Monday, March 10, 2003 9:11 AM To: kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi James, >> If the (MN-)requested L2-L3 mapping does not exist in the AR cache, >> a request is sent to the server to obtain this information >(maybe I missed >> something in the draft). If the MN does the request for all >n ARs in the >scope, >> the cache will soon be filled up with all possible ARs in >the scope region. >But even >> more, the MN can also explicitly request L2-L3 mappings of >ARs that are not >within the region >> (the AR does not know about the region, and it does not know >whether or not >the supplied >> information is correct, so it has to ask the server). The >mapping is requested >from the server >> by the AR, the server rejects the request (reason "out of >scope region"). >Result of this would be >> server and AR load, i.e., DoS attack. >> > >Where's the denial of service? All you've described above is >how the router >cache gets populated by all the APs in the region. Properly >sizing the router >cache is required, of course. Well, it was said quite a lot, but maybe another time would help to get the picture. You've got two cases. One is to have a malicous MN sending in-scope L2 id to the AR. This eventually leads to filling up the cache with all scope L2 id. But I wasn't talking about this case. In the case described above, the malicous MN requests L2-L3 mappings of ARs that are not within the region. Since the AR cannot figure this out, it will forward the request to the server, asking for resolving. The server will answer (correctly) with "out-of-region" (or whatever). If the MN keeps injecting these kind of requests, you'll add load to the server. The cache will not get populated at all, but the AR and server keep communicating. AJOY-> I think this can be easily solved by maintaining some soft-state at AR. AR should able to track the number of requests made by connected MN during given time interval. The AR should avoid forwarding request from malicious MN to the CARD server once the number of attempts crosses the pre-configured threshold. I am sure there are lots of other ways to solve this problem. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:07:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03465 for ; Mon, 10 Mar 2003 12:07:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHK7O29071; Mon, 10 Mar 2003 12:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHGCO28683 for ; Mon, 10 Mar 2003 12:16:12 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03105 for ; Mon, 10 Mar 2003 12:02:37 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AH4i812932 for ; Mon, 10 Mar 2003 11:04:44 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:04:44 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:03:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 12:03:48 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLnJf2pajejdLcQRzWfgXrQLcfm5gAAJQHA To: , , X-OriginalArrivalTime: 10 Mar 2003 17:03:49.0993 (UTC) FILETIME=[05634D90:01C2E727] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHGDO28684 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy: There is nothing wrong with AAA. The point is that AAA functionality is not central to CARD service. In fact, they are quite independent functionality wise, and hence, CARD server should be treated as logical entity and people can integrate it with whatever server they want it to be. Then, CARD service should be usable even if there is no AAA server of one's choice present in some network. These integration tasks can be taken as separate drafts in collaboration with respective server WGs. Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Monday, March 10, 2003 11:55 AM To: Chaskar Hemant (NRC/Boston); Singh Ajoy-ASINGH1; Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Hemant, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Thursday, March 06, 2003 6:29 PM To: Ajoy Singh; Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Which thread? Which section? If you know quick pointer to it, please paste it here. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Thursday, March 06, 2003 1:27 PM To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> Sure there is. But what is wrong in using AAA? OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? AJOY-> this is not relevant in current discussion. But if ever decide to design CARD as an extension to DNS protocol then I do not see any reason for not re-using the DNS security mechanism. But why do you think otherwise? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:11:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03766 for ; Mon, 10 Mar 2003 12:11:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHOIY29576 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:24:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHOIO29573 for ; Mon, 10 Mar 2003 12:24:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03707 for ; Mon, 10 Mar 2003 12:10:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHO7O29534; Mon, 10 Mar 2003 12:24:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHN3O29430 for ; Mon, 10 Mar 2003 12:23:03 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03601 for ; Mon, 10 Mar 2003 12:09:27 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2AHBYXR002794 for ; Mon, 10 Mar 2003 10:11:34 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA07018 for ; Mon, 10 Mar 2003 10:09:35 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 11:11:33 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3C@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 11:11:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 06, 2003 4:55 PM To: Ajoy Singh; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Ajoy, Comments embedded. Regards, -Govind. This is difficult to justify without proper data from real deployment or simulation. Do have any real data to prove me otherwise? [Govind] We have implemented dycard and we have gotten it to work with FMIPv6 in our local test-bed. We have demonstrated dycard at Mobicom2002. We have done simulations and a performance analysis on dycard. My observations are based on that. I hope you consider this "real data". Now on the flip side, do you have any "real data", as you put it, to quantify your statements that you would need servers and a serverless approach will not work? Or the server based approach is better? AJOY-> We have also implemented some sort of server approach and saw it working. My question was more towards validating your protocol with real world handoff data. BTW, you do not need do this because L2->L3 mapping is initiated by link layer trigger that happens prior to L2 handoff. Hence, I do not see any reason to optimize this RTT. This is probably noto relevant in this context. [Govind] Well this comment was to answer your earlier statement where you said that you can optimize this round trip time like you said above. Now you say it is not necessary. AJOY-> I stated this but on second thought I do not see any reason to optimize the RTT given that L2->L3 cache is built prior to any handoff and is not in critical path of handoff. However, I think this minimization of round trip is needed for the very reason that is mentioned in the DT draft. AJOY-> To be honest, I do not see any need for this and probably we should remove such claim from DT draft unless you can provide some valid reason for keeping this in DT draft. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:11:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03806 for ; Mon, 10 Mar 2003 12:11:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHO7O29534; Mon, 10 Mar 2003 12:24:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHN3O29430 for ; Mon, 10 Mar 2003 12:23:03 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03601 for ; Mon, 10 Mar 2003 12:09:27 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2AHBYXR002794 for ; Mon, 10 Mar 2003 10:11:34 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA07018 for ; Mon, 10 Mar 2003 10:09:35 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 11:11:33 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3C@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 11:11:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 06, 2003 4:55 PM To: Ajoy Singh; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Ajoy, Comments embedded. Regards, -Govind. This is difficult to justify without proper data from real deployment or simulation. Do have any real data to prove me otherwise? [Govind] We have implemented dycard and we have gotten it to work with FMIPv6 in our local test-bed. We have demonstrated dycard at Mobicom2002. We have done simulations and a performance analysis on dycard. My observations are based on that. I hope you consider this "real data". Now on the flip side, do you have any "real data", as you put it, to quantify your statements that you would need servers and a serverless approach will not work? Or the server based approach is better? AJOY-> We have also implemented some sort of server approach and saw it working. My question was more towards validating your protocol with real world handoff data. BTW, you do not need do this because L2->L3 mapping is initiated by link layer trigger that happens prior to L2 handoff. Hence, I do not see any reason to optimize this RTT. This is probably noto relevant in this context. [Govind] Well this comment was to answer your earlier statement where you said that you can optimize this round trip time like you said above. Now you say it is not necessary. AJOY-> I stated this but on second thought I do not see any reason to optimize the RTT given that L2->L3 cache is built prior to any handoff and is not in critical path of handoff. However, I think this minimization of round trip is needed for the very reason that is mentioned in the DT draft. AJOY-> To be honest, I do not see any need for this and probably we should remove such claim from DT draft unless you can provide some valid reason for keeping this in DT draft. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:15:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03956 for ; Mon, 10 Mar 2003 12:15:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHSNn29977 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:28:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHSNO29974 for ; Mon, 10 Mar 2003 12:28:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03942 for ; Mon, 10 Mar 2003 12:14:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHS6O29935; Mon, 10 Mar 2003 12:28:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHRNO29875 for ; Mon, 10 Mar 2003 12:27:23 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03903 for ; Mon, 10 Mar 2003 12:13:46 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AHFua11078 for ; Mon, 10 Mar 2003 11:15:56 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:15:43 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:15:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 12:15:30 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLnJhZ7Kagq/Sx6TsyVZ3eCzMtWswAAFRyA To: , , , X-OriginalArrivalTime: 10 Mar 2003 17:15:31.0966 (UTC) FILETIME=[A7CBE1E0:01C2E728] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHRNO29876 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ajoy, Just curious. Regarding AAA: Just because it can be done, it doesn't need to be done. I think we don't need to invent a problem and then solve it. I think there is a trust relationship existing between routers of the same domain already. Isn't this true?. Routers don't forward packets arbitrarily. We can use those keys or derive keys from that existing trust relationship right. Therefore, why do you want to introduce a new scheme to distribute keys, that too specifically for CARD? I don't think we need special trust relationship, solely for the purpose of CARD. As Hemant pointed out, if we have shared secrets between routers of the same domain, then we are through is it not. I have heard in many routing networks, keys are put in manually in routers as part of their configuration, though I am not claiming that this is the only way it is done. Correct me if I'm wrong in any of my above staements. Regards, Govind. -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Monday, March 10, 2003 11:55 AM To: Chaskar Hemant (NRC/Boston); Singh Ajoy-ASINGH1; Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Hemant, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Thursday, March 06, 2003 6:29 PM To: Ajoy Singh; Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Which thread? Which section? If you know quick pointer to it, please paste it here. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Thursday, March 06, 2003 1:27 PM To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> Sure there is. But what is wrong in using AAA? OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? AJOY-> this is not relevant in current discussion. But if ever decide to design CARD as an extension to DNS protocol then I do not see any reason for not re-using the DNS security mechanism. But why do you think otherwise? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:15:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03976 for ; Mon, 10 Mar 2003 12:15:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHS6O29935; Mon, 10 Mar 2003 12:28:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHRNO29875 for ; Mon, 10 Mar 2003 12:27:23 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03903 for ; Mon, 10 Mar 2003 12:13:46 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AHFua11078 for ; Mon, 10 Mar 2003 11:15:56 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:15:43 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:15:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 12:15:30 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLnJhZ7Kagq/Sx6TsyVZ3eCzMtWswAAFRyA To: , , , X-OriginalArrivalTime: 10 Mar 2003 17:15:31.0966 (UTC) FILETIME=[A7CBE1E0:01C2E728] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHRNO29876 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ajoy, Just curious. Regarding AAA: Just because it can be done, it doesn't need to be done. I think we don't need to invent a problem and then solve it. I think there is a trust relationship existing between routers of the same domain already. Isn't this true?. Routers don't forward packets arbitrarily. We can use those keys or derive keys from that existing trust relationship right. Therefore, why do you want to introduce a new scheme to distribute keys, that too specifically for CARD? I don't think we need special trust relationship, solely for the purpose of CARD. As Hemant pointed out, if we have shared secrets between routers of the same domain, then we are through is it not. I have heard in many routing networks, keys are put in manually in routers as part of their configuration, though I am not claiming that this is the only way it is done. Correct me if I'm wrong in any of my above staements. Regards, Govind. -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Monday, March 10, 2003 11:55 AM To: Chaskar Hemant (NRC/Boston); Singh Ajoy-ASINGH1; Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi Hemant, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Thursday, March 06, 2003 6:29 PM To: Ajoy Singh; Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Which thread? Which section? If you know quick pointer to it, please paste it here. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Thursday, March 06, 2003 1:27 PM To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 05, 2003 3:19 PM To: Dirk.Trossen@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Hi, One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework. AJOY-> Sure there is. But what is wrong in using AAA? OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it? AJOY-> this is not relevant in current discussion. But if ever decide to design CARD as an extension to DNS protocol then I do not see any reason for not re-using the DNS security mechanism. But why do you think otherwise? Hemant -----Original Message----- From: ext Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 05, 2003 2:37 PM To: seamoby@ietf.org Subject: FW: [Seamoby] Comments on DT CARD draft Hi Ajoy, some comments inline. >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 05, 2003 12:02 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: RE: [Seamoby] Comments on DT CARD draft > > >Hello Govind, >Thanks for your initial feedback. Please >find my inline reply. >Regards, >Ajoy > >-----Original Message----- >From: Govind.Krishnamurthi@nokia.com >[mailto:Govind.Krishnamurthi@nokia.com] >Sent: Tuesday, March 04, 2003 5:27 PM >To: seamoby@ietf.org >Subject: [Seamoby] Comments on DT CARD draft > > >Hi guys, >I glanced through the CARD draft and I have some preliminary >comments. Here they are: > >1. Violation of Requirement 3.8 >The draft violates Requirement 3.8, by introducing a new >network element specifically intended for CARD. > >AJOY-> We are aware of this. What is the status of >requirement draft? Is it approved by IESG yet. Probably >we need to change this requirement in case WG likes >to go with server based approach. I'm wondering why we have discussions about requirements when later we are so easily willing to change requirements to push certain solutions. Doesn't it contradict the purpose of requirements?? > >2. Need for CARD server. >The CARD server will never be used once the network reaches >steady state. >So we are talking about introducing a network element for the >sake of CARD discovery that will be never used probably after >one handover between ARs. > >AJOY-> This depends upon the cache timeout as well as handoff traffic. Cache population through any means, i.e., server or dycard-like approach, depends on the timeout of the cache entries, and you certainly want to minimize any kind of extra measures to run those population mechanisms. >BTW, the server based approach is easier to manage as well >it provides extra security. Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. I don't see anything in the draft regarding the server approach that would justify this statement. More specifically, it is quite unclear to me why an approach that does have an extra element compared to another one, is easier to manage than an approach that doesn't need the extra element. >If we deploy scope-id with serve >based approach, then >it is very much possible to reduce or even eliminate the >problem of cache contamination. How would this happen? If I have n ARs in the scope of one scope-id, I still have the possibility of n false cache entries. Could you give some details on how such elimination would happen? >This also minimizes the affect DoS attack. > >Once a handover happens between CARs, >you can push all the AP information as capabilities to the >CARs. So why do we need this server again? > >AJOY-> These entries may not be cached for ever. Smaller the >cache timeout, >the earlier you will be able to detect any change of capability >or L2->L3 mapping information. > >Apart from this, the DT draft has acknowledged the fact that >there is no guarantee that the response from the CARD server >will get to the MN in time for the handover. So even when the >server is present, at least the first handover is a seamless >in a probabilistic sense. > >AJOY-> I think this will be better than the case where cache >entries are solely >propagated by the mobile node. I think in the later case, the >first handoff >will always be the slower. Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 (sometimes even <<1) that the first handoff would be seamless with the necessity of an additional server. Is this really worth the effort?? > Moreover the later approach is very >difficult to manage and is even less secure. Again, this sounds very weird to me. Having an server-less approach is more complicated to manage than a server-based approach? Further, could you also elaborate on the security issues that you see with a server-free approach that would be solved with the server approach? > >The CARD server is a single point of failure. To avoid this we >may introduce some kind of redundancy here. But then we are >talking about making the architecture even more complicated, >along with associated baggage, for a functionality that will >probably be never used after sometime. > >BTW-> The IP packets are not routed via CARD server so I am >not sure if it a big >drawback. I will be more concerned about the single point of >failure where IP packets are >routed through it. CARD server will provide a similar function >as DNS server >So, probably it is not a big drawback in my understanding. The single-point-of-failure is to be seen for the functionality, it is supposed to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated, ALL handoffs are break-before-make. Compared to a server-less approach, this sound significant to me. > As I mentioned above, >with clever use of scope-id, it is possible to reduce the >affect of DoS attack as >well as cache contamination problem. "Clever usage" of parameters is a security measure that sounds quite suspicious to me, and I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are. > >There is some discussion in the draft that we can add this >server functionality to AAA and RADIUS servers. But can this >be such an unilateral decision that doesn't really need >discussion with the AAA WG? I therefore think this is not >quite a feasible solution right now. Please correct me if I'm >wrong about this. > >AJOY-> Probably you are right. We do need to get consensus >from AAA group for doing this. >BTW, If we use AAA server, then it is also possible to use AAA >server for the >purpose of key distribution. I would like to receive feedback >from other members of >WG about the potential use of AAA server as CARD server. Hmm, so now we are integrating CARD with AAA? Looking at the progress of the AAA WG, I'm not sure they're quite willing to open this box. And I don't think we should either. Using AAA for key distribution sounds quite out of scope to me. > >3. Security section >I think "Scope ID" is a complicated solution, whose cost of >usage far out weighs the benefit. Even here we are limiting >the granularity of error to that decided by Scope IDs. >Therefore if there are n ARs with the same scope ID then we >allow n invalid entries in the cache. > >AJOY-> I am not sure I agree with you here. Could you provide >some additional >detail why you think scope id is complicated? Mainly because of your wording of "clever usage". A parameter that requires "clever" setting in order to provide security concerns me. So it is up to you to provide additional detail how this would work. I do see Govind's point quite clearly, that having n ARs in the same scope would allow for n false entries in the cache. Assuming inter-CAR exchange of capabilities between those ARs doen't make my concern smaller. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:28:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04504 for ; Mon, 10 Mar 2003 12:28:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHfTo31582 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:41:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHfTO31579 for ; Mon, 10 Mar 2003 12:41:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04487 for ; Mon, 10 Mar 2003 12:27:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHfIO31567; Mon, 10 Mar 2003 12:41:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHeQO31515 for ; Mon, 10 Mar 2003 12:40:26 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04459 for ; Mon, 10 Mar 2003 12:26:51 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2AHSwXR007517 for ; Mon, 10 Mar 2003 10:28:59 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA17619 for ; Mon, 10 Mar 2003 10:27:00 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 11:28:56 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3D@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Singh Ajoy-ASINGH1 , Dirk.Trossen@nokia.com, kempf@docomolabs-usa.com, Govind.Krishnamurthi@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 11:28:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, I do not see how AR can track number of request from a specific malicious node. When node disconnects and reconnects, it appears as a completely different node to AR. To pinpoint MN's identity additional mechanisms may be needed. AJOY-> You can always maintain history information that is independent of MN call state. You just need to uniquely identity MN. You can use information such as user name, NAI or IMSI to do this. BTW, I am just talking about some soft-state that should be cached only for pre-configurable amount of time. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Monday, March 10, 2003 11:06 AM To: Ajoy Singh; Dirk.Trossen@nokia.com; kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi Ajoy: I do not see how AR can track number of request from a specific malicious node. When node disconnects and reconnects, it appears as a completely different node to AR. To pinpoint MN's identity additional mechanisms may be needed. Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Monday, March 10, 2003 11:38 AM To: Trossen Dirk (NRC/Boston); kempf@docomolabs-usa.com; Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Monday, March 10, 2003 9:11 AM To: kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi James, >> If the (MN-)requested L2-L3 mapping does not exist in the AR cache, >> a request is sent to the server to obtain this information >(maybe I missed >> something in the draft). If the MN does the request for all >n ARs in the >scope, >> the cache will soon be filled up with all possible ARs in >the scope region. >But even >> more, the MN can also explicitly request L2-L3 mappings of >ARs that are not >within the region >> (the AR does not know about the region, and it does not know >whether or not >the supplied >> information is correct, so it has to ask the server). The >mapping is requested >from the server >> by the AR, the server rejects the request (reason "out of >scope region"). >Result of this would be >> server and AR load, i.e., DoS attack. >> > >Where's the denial of service? All you've described above is >how the router >cache gets populated by all the APs in the region. Properly >sizing the router >cache is required, of course. Well, it was said quite a lot, but maybe another time would help to get the picture. You've got two cases. One is to have a malicous MN sending in-scope L2 id to the AR. This eventually leads to filling up the cache with all scope L2 id. But I wasn't talking about this case. In the case described above, the malicous MN requests L2-L3 mappings of ARs that are not within the region. Since the AR cannot figure this out, it will forward the request to the server, asking for resolving. The server will answer (correctly) with "out-of-region" (or whatever). If the MN keeps injecting these kind of requests, you'll add load to the server. The cache will not get populated at all, but the AR and server keep communicating. AJOY-> I think this can be easily solved by maintaining some soft-state at AR. AR should able to track the number of requests made by connected MN during given time interval. The AR should avoid forwarding request from malicious MN to the CARD server once the number of attempts crosses the pre-configured threshold. I am sure there are lots of other ways to solve this problem. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:28:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04525 for ; Mon, 10 Mar 2003 12:28:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHfIO31567; Mon, 10 Mar 2003 12:41:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHeQO31515 for ; Mon, 10 Mar 2003 12:40:26 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04459 for ; Mon, 10 Mar 2003 12:26:51 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2AHSwXR007517 for ; Mon, 10 Mar 2003 10:28:59 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA17619 for ; Mon, 10 Mar 2003 10:27:00 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 11:28:56 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3D@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Singh Ajoy-ASINGH1 , Dirk.Trossen@nokia.com, kempf@docomolabs-usa.com, Govind.Krishnamurthi@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 11:28:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, I do not see how AR can track number of request from a specific malicious node. When node disconnects and reconnects, it appears as a completely different node to AR. To pinpoint MN's identity additional mechanisms may be needed. AJOY-> You can always maintain history information that is independent of MN call state. You just need to uniquely identity MN. You can use information such as user name, NAI or IMSI to do this. BTW, I am just talking about some soft-state that should be cached only for pre-configurable amount of time. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Monday, March 10, 2003 11:06 AM To: Ajoy Singh; Dirk.Trossen@nokia.com; kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi Ajoy: I do not see how AR can track number of request from a specific malicious node. When node disconnects and reconnects, it appears as a completely different node to AR. To pinpoint MN's identity additional mechanisms may be needed. Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Monday, March 10, 2003 11:38 AM To: Trossen Dirk (NRC/Boston); kempf@docomolabs-usa.com; Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Monday, March 10, 2003 9:11 AM To: kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Hi James, >> If the (MN-)requested L2-L3 mapping does not exist in the AR cache, >> a request is sent to the server to obtain this information >(maybe I missed >> something in the draft). If the MN does the request for all >n ARs in the >scope, >> the cache will soon be filled up with all possible ARs in >the scope region. >But even >> more, the MN can also explicitly request L2-L3 mappings of >ARs that are not >within the region >> (the AR does not know about the region, and it does not know >whether or not >the supplied >> information is correct, so it has to ask the server). The >mapping is requested >from the server >> by the AR, the server rejects the request (reason "out of >scope region"). >Result of this would be >> server and AR load, i.e., DoS attack. >> > >Where's the denial of service? All you've described above is >how the router >cache gets populated by all the APs in the region. Properly >sizing the router >cache is required, of course. Well, it was said quite a lot, but maybe another time would help to get the picture. You've got two cases. One is to have a malicous MN sending in-scope L2 id to the AR. This eventually leads to filling up the cache with all scope L2 id. But I wasn't talking about this case. In the case described above, the malicous MN requests L2-L3 mappings of ARs that are not within the region. Since the AR cannot figure this out, it will forward the request to the server, asking for resolving. The server will answer (correctly) with "out-of-region" (or whatever). If the MN keeps injecting these kind of requests, you'll add load to the server. The cache will not get populated at all, but the AR and server keep communicating. AJOY-> I think this can be easily solved by maintaining some soft-state at AR. AR should able to track the number of requests made by connected MN during given time interval. The AR should avoid forwarding request from malicious MN to the CARD server once the number of attempts crosses the pre-configured threshold. I am sure there are lots of other ways to solve this problem. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:29:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04546 for ; Mon, 10 Mar 2003 12:29:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHgHJ31686 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:42:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHgHO31683 for ; Mon, 10 Mar 2003 12:42:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04539 for ; Mon, 10 Mar 2003 12:28:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHg2O31658; Mon, 10 Mar 2003 12:42:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHfCO31559 for ; Mon, 10 Mar 2003 12:41:12 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04480 for ; Mon, 10 Mar 2003 12:27:36 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AHTi819486 for ; Mon, 10 Mar 2003 11:29:44 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:29:43 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:29:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 12:29:37 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLnKCJyrBY1G7GTTtG0CrRz5iC3NAAAJ7yQ To: , X-OriginalArrivalTime: 10 Mar 2003 17:29:38.0581 (UTC) FILETIME=[A06B1450:01C2E72A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHfCO31560 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ajoy, AJOY-> We have also implemented some sort of server approach and saw it working. My question was more towards validating your protocol with real world handoff data. [snip] [Govind] I don't have access to real world handover data. Maybe if you do, you could provide it to us and we can test it out. We have done simulations as best as we could and our results are based on that. I guess this is the approach taken by many to do performance analysis. The point was that the server was useless after bootstrap. I guess this was agreed by one of your DT members too. Another point was that the DT approach is susceptible to attacks detailed out in earlier mails. You haven't said anything that helps me reverse my opinion on any of these issues. AJOY-> I stated this but on second thought I do not see any reason to optimize the RTT given that L2->L3 cache is built prior to any handoff and is not in critical path of handoff. [Govind] I have explained in my earlier mails about why this is useful. So have others. You can never claim that the cache, in the DT scheme is built prior to handovers. It clearly depends on the order the MN reports. I think you should read prior threads that explains these points quite clearly. Therefore the RTT is clearly important. Having said that, if have subsequent handovers wherein the mappings are in cache you wouldn't need the server at all. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:29:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04573 for ; Mon, 10 Mar 2003 12:29:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHg2O31658; Mon, 10 Mar 2003 12:42:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHfCO31559 for ; Mon, 10 Mar 2003 12:41:12 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04480 for ; Mon, 10 Mar 2003 12:27:36 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AHTi819486 for ; Mon, 10 Mar 2003 11:29:44 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:29:43 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:29:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 12:29:37 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on DT CARD draft Thread-Index: AcLnKCJyrBY1G7GTTtG0CrRz5iC3NAAAJ7yQ To: , X-OriginalArrivalTime: 10 Mar 2003 17:29:38.0581 (UTC) FILETIME=[A06B1450:01C2E72A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHfCO31560 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ajoy, AJOY-> We have also implemented some sort of server approach and saw it working. My question was more towards validating your protocol with real world handoff data. [snip] [Govind] I don't have access to real world handover data. Maybe if you do, you could provide it to us and we can test it out. We have done simulations as best as we could and our results are based on that. I guess this is the approach taken by many to do performance analysis. The point was that the server was useless after bootstrap. I guess this was agreed by one of your DT members too. Another point was that the DT approach is susceptible to attacks detailed out in earlier mails. You haven't said anything that helps me reverse my opinion on any of these issues. AJOY-> I stated this but on second thought I do not see any reason to optimize the RTT given that L2->L3 cache is built prior to any handoff and is not in critical path of handoff. [Govind] I have explained in my earlier mails about why this is useful. So have others. You can never claim that the cache, in the DT scheme is built prior to handovers. It clearly depends on the order the MN reports. I think you should read prior threads that explains these points quite clearly. Therefore the RTT is clearly important. Having said that, if have subsequent handovers wherein the mappings are in cache you wouldn't need the server at all. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:35:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04792 for ; Mon, 10 Mar 2003 12:35:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHmDr31937 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:48:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHmDO31934 for ; Mon, 10 Mar 2003 12:48:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04766 for ; Mon, 10 Mar 2003 12:34:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHm3O31925; Mon, 10 Mar 2003 12:48:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHlAO31884 for ; Mon, 10 Mar 2003 12:47:10 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04736 for ; Mon, 10 Mar 2003 12:33:34 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AHZg822166 for ; Mon, 10 Mar 2003 11:35:42 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:35:20 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:35:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 12:35:12 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLnI2SVrhHI+rUPQMy76CXNvmzqNgAB32YQ To: , , , X-OriginalArrivalTime: 10 Mar 2003 17:35:13.0458 (UTC) FILETIME=[68054120:01C2E72B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHlAO31885 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy, AJOY-> I think this can be easily solved by maintaining some soft-state at AR. AR should able to track the number of requests made by connected MN during given time interval. The AR should avoid forwarding request from malicious MN to the CARD server once the number of attempts crosses the pre-configured threshold. I am sure there are lots of other ways to solve this problem. [Govind] As pointed out earlier, this is not restricted to a malicious MN. A non-malicious MN can cause this kind of situation too, by reporting beacons that are not in the same domain. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:35:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04844 for ; Mon, 10 Mar 2003 12:35:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHm3O31925; Mon, 10 Mar 2003 12:48:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHlAO31884 for ; Mon, 10 Mar 2003 12:47:10 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04736 for ; Mon, 10 Mar 2003 12:33:34 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AHZg822166 for ; Mon, 10 Mar 2003 11:35:42 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 11:35:20 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 09:35:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Date: Mon, 10 Mar 2003 12:35:12 -0500 Message-ID: Thread-Topic: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt Thread-Index: AcLnI2SVrhHI+rUPQMy76CXNvmzqNgAB32YQ To: , , , X-OriginalArrivalTime: 10 Mar 2003 17:35:13.0458 (UTC) FILETIME=[68054120:01C2E72B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHlAO31885 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy, AJOY-> I think this can be easily solved by maintaining some soft-state at AR. AR should able to track the number of requests made by connected MN during given time interval. The AR should avoid forwarding request from malicious MN to the CARD server once the number of attempts crosses the pre-configured threshold. I am sure there are lots of other ways to solve this problem. [Govind] As pointed out earlier, this is not restricted to a malicious MN. A non-malicious MN can cause this kind of situation too, by reporting beacons that are not in the same domain. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:45:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05176 for ; Mon, 10 Mar 2003 12:45:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHwKt32499 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 12:58:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHwKO32496 for ; Mon, 10 Mar 2003 12:58:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05159 for ; Mon, 10 Mar 2003 12:44:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHwAO32480; Mon, 10 Mar 2003 12:58:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHvAO32435 for ; Mon, 10 Mar 2003 12:57:10 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05113 for ; Mon, 10 Mar 2003 12:43:34 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2AHkaCq003084 for ; Mon, 10 Mar 2003 10:46:36 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA19011 for ; Mon, 10 Mar 2003 10:45:42 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 11:45:42 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3E@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 11:45:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Govind, [Govind] I have explained in my earlier mails about why this is useful. So have others. You can never claim that the cache, in the DT scheme is built prior to handovers. It clearly depends on the order the MN reports. I think you should read prior threads that explains these points quite clearly. Therefore the RTT is clearly important. AJOY-> I have not seen any objective reply from any one so far. If there is sufficient overlap between neighboring AR, then it is safe to assume that cache will be built prior to L3 handoff. Without sufficient overlap, it is difficult to assume any seamless handoff between neighboring ARs. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Monday, March 10, 2003 11:30 AM To: Ajoy Singh; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Ajoy, AJOY-> We have also implemented some sort of server approach and saw it working. My question was more towards validating your protocol with real world handoff data. [snip] [Govind] I don't have access to real world handover data. Maybe if you do, you could provide it to us and we can test it out. We have done simulations as best as we could and our results are based on that. I guess this is the approach taken by many to do performance analysis. The point was that the server was useless after bootstrap. I guess this was agreed by one of your DT members too. Another point was that the DT approach is susceptible to attacks detailed out in earlier mails. You haven't said anything that helps me reverse my opinion on any of these issues. AJOY-> I stated this but on second thought I do not see any reason to optimize the RTT given that L2->L3 cache is built prior to any handoff and is not in critical path of handoff. [Govind] I have explained in my earlier mails about why this is useful. So have others. You can never claim that the cache, in the DT scheme is built prior to handovers. It clearly depends on the order the MN reports. I think you should read prior threads that explains these points quite clearly. Therefore the RTT is clearly important. Having said that, if have subsequent handovers wherein the mappings are in cache you wouldn't need the server at all. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:45:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05204 for ; Mon, 10 Mar 2003 12:45:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHwAO32480; Mon, 10 Mar 2003 12:58:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHvAO32435 for ; Mon, 10 Mar 2003 12:57:10 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05113 for ; Mon, 10 Mar 2003 12:43:34 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2AHkaCq003084 for ; Mon, 10 Mar 2003 10:46:36 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA19011 for ; Mon, 10 Mar 2003 10:45:42 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 11:45:42 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE3E@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Date: Mon, 10 Mar 2003 11:45:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Govind, [Govind] I have explained in my earlier mails about why this is useful. So have others. You can never claim that the cache, in the DT scheme is built prior to handovers. It clearly depends on the order the MN reports. I think you should read prior threads that explains these points quite clearly. Therefore the RTT is clearly important. AJOY-> I have not seen any objective reply from any one so far. If there is sufficient overlap between neighboring AR, then it is safe to assume that cache will be built prior to L3 handoff. Without sufficient overlap, it is difficult to assume any seamless handoff between neighboring ARs. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Monday, March 10, 2003 11:30 AM To: Ajoy Singh; seamoby@ietf.org Subject: RE: [Seamoby] Comments on DT CARD draft Ajoy, AJOY-> We have also implemented some sort of server approach and saw it working. My question was more towards validating your protocol with real world handoff data. [snip] [Govind] I don't have access to real world handover data. Maybe if you do, you could provide it to us and we can test it out. We have done simulations as best as we could and our results are based on that. I guess this is the approach taken by many to do performance analysis. The point was that the server was useless after bootstrap. I guess this was agreed by one of your DT members too. Another point was that the DT approach is susceptible to attacks detailed out in earlier mails. You haven't said anything that helps me reverse my opinion on any of these issues. AJOY-> I stated this but on second thought I do not see any reason to optimize the RTT given that L2->L3 cache is built prior to any handoff and is not in critical path of handoff. [Govind] I have explained in my earlier mails about why this is useful. So have others. You can never claim that the cache, in the DT scheme is built prior to handovers. It clearly depends on the order the MN reports. I think you should read prior threads that explains these points quite clearly. Therefore the RTT is clearly important. Having said that, if have subsequent handovers wherein the mappings are in cache you wouldn't need the server at all. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 12:47:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05301 for ; Mon, 10 Mar 2003 12:47:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AI0NZ32711 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 13:00:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AI0NO32708 for ; Mon, 10 Mar 2003 13:00:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05283 for ; Mon, 10 Mar 2003 12:46:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AI0CO32699; Mon, 10 Mar 2003 13:00:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHxvO32631 for ; Mon, 10 Mar 2003 12:59:57 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05255 for ; Mon, 10 Mar 2003 12:46:22 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AHmT824936 for ; Mon, 10 Mar 2003 11:48:29 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Mar 2003 11:48:28 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 11:47:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Mar 2003 12:47:53 -0500 Message-ID: Thread-Topic: A suggestion. Thread-Index: AcLnLSzPPefcwq67TM6+R+DdsxQ3OQ== To: X-OriginalArrivalTime: 10 Mar 2003 17:47:54.0250 (UTC) FILETIME=[2D7CE6A0:01C2E72D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHxvO32632 Subject: [Seamoby] A suggestion. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hello all, I think we need to split the issues being discussed into three for the sake of clarity. IMHO, there are three issues. 1a. Need for server 1b. DoS attacks on servers 2. CARD cache contamination issues. 3 DoS attacks on ARs due to incorrect entries in the ARs. I think they need to be handled in different threads. Else, it is difficult to have a handle on the issues that are being discussed. Points 2 and 3 (which are related) are relevant to both dycard and the DT draft. 1a and 1b are restricted to the DT draft. Discussing these separately may make it more clear for people who want to have a track on the merits of either approach. Thanks, Govind _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 12:47:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05316 for ; Mon, 10 Mar 2003 12:47:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AI0CO32699; Mon, 10 Mar 2003 13:00:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHxvO32631 for ; Mon, 10 Mar 2003 12:59:57 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05255 for ; Mon, 10 Mar 2003 12:46:22 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AHmT824936 for ; Mon, 10 Mar 2003 11:48:29 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Mar 2003 11:48:28 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 11:47:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Mar 2003 12:47:53 -0500 Message-ID: Thread-Topic: A suggestion. Thread-Index: AcLnLSzPPefcwq67TM6+R+DdsxQ3OQ== To: X-OriginalArrivalTime: 10 Mar 2003 17:47:54.0250 (UTC) FILETIME=[2D7CE6A0:01C2E72D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AHxvO32632 Subject: [Seamoby] A suggestion. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello all, I think we need to split the issues being discussed into three for the sake of clarity. IMHO, there are three issues. 1a. Need for server 1b. DoS attacks on servers 2. CARD cache contamination issues. 3 DoS attacks on ARs due to incorrect entries in the ARs. I think they need to be handled in different threads. Else, it is difficult to have a handle on the issues that are being discussed. Points 2 and 3 (which are related) are relevant to both dycard and the DT draft. 1a and 1b are restricted to the DT draft. Discussing these separately may make it more clear for people who want to have a track on the merits of either approach. Thanks, Govind _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 13:41:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07448 for ; Mon, 10 Mar 2003 13:41:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AIsZW04829 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 13:54:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AIsYO04826 for ; Mon, 10 Mar 2003 13:54:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07398 for ; Mon, 10 Mar 2003 13:40:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AIsNO04817; Mon, 10 Mar 2003 13:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AIqcO04663 for ; Mon, 10 Mar 2003 13:52:38 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07345 for ; Mon, 10 Mar 2003 13:39:01 -0500 (EST) Message-ID: <032501c2e734$67cb7d60$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] A suggestion. Date: Mon, 10 Mar 2003 10:39:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think I would rather partition the discussion separately. I'll send out email suggesting a partition. jak ----- Original Message ----- From: To: Sent: Monday, March 10, 2003 9:47 AM Subject: [Seamoby] A suggestion. > Hello all, > I think we need to split the issues being discussed into three for the sake of clarity. > IMHO, there are three issues. > > > 1a. Need for server > > 1b. DoS attacks on servers > > > 2. CARD cache contamination issues. > > 3 DoS attacks on ARs due to incorrect entries in the ARs. > > I think they need to be handled in different threads. Else, it is difficult to have a handle on the issues that are being discussed. > Points 2 and 3 (which are related) are relevant to both dycard and the DT draft. 1a and 1b are restricted to the DT draft. > Discussing these separately may make it more clear for people who want to have a track on the merits of either approach. > > Thanks, > Govind > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 13:41:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07488 for ; Mon, 10 Mar 2003 13:41:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AIsNO04817; Mon, 10 Mar 2003 13:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AIqcO04663 for ; Mon, 10 Mar 2003 13:52:38 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07345 for ; Mon, 10 Mar 2003 13:39:01 -0500 (EST) Message-ID: <032501c2e734$67cb7d60$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] A suggestion. Date: Mon, 10 Mar 2003 10:39:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think I would rather partition the discussion separately. I'll send out email suggesting a partition. jak ----- Original Message ----- From: To: Sent: Monday, March 10, 2003 9:47 AM Subject: [Seamoby] A suggestion. > Hello all, > I think we need to split the issues being discussed into three for the sake of clarity. > IMHO, there are three issues. > > > 1a. Need for server > > 1b. DoS attacks on servers > > > 2. CARD cache contamination issues. > > 3 DoS attacks on ARs due to incorrect entries in the ARs. > > I think they need to be handled in different threads. Else, it is difficult to have a handle on the issues that are being discussed. > Points 2 and 3 (which are related) are relevant to both dycard and the DT draft. 1a and 1b are restricted to the DT draft. > Discussing these separately may make it more clear for people who want to have a track on the merits of either approach. > > Thanks, > Govind > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 15:06:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11232 for ; Mon, 10 Mar 2003 15:06:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AKJq511337 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 15:19:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKJqO11334 for ; Mon, 10 Mar 2003 15:19:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11134 for ; Mon, 10 Mar 2003 15:06:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKJWO11260; Mon, 10 Mar 2003 15:19:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKD6O10971 for ; Mon, 10 Mar 2003 15:13:06 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10619 for ; Mon, 10 Mar 2003 14:59:29 -0500 (EST) Message-ID: <037b01c2e73f$a41e24b0$156015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 10 Mar 2003 12:00:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Topic #1: Dos Attack Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One objection that was raised to having a server provide the list of authentic access points is that an MN can launch a DoS attack on the server. If the router uses a softstate cache, the server load will only occur if the MN presents a new AP id. Now, it is possible that an MN can attack by making up AP ids and sending them to the router. A properly provisioned server should be able to handle that if the attacking MN tries to pose as a legitimate one by regulating its traffic. The server capacity must be large enough to handle the routers that are using it. If the MN doesn't regulate traffic and it bombards the router, the router can selectively drop message packets if the message volume becomes too large. Thus, service degrades but is not denied, until the sysadmin finds the offending MN and takes it off the air. Note that the same problem, an MN bombarding a router with packets, can occur for dycard as well, so it is not exclusive to the server approach. What am I missing? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 15:07:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11368 for ; Mon, 10 Mar 2003 15:07:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKJWO11260; Mon, 10 Mar 2003 15:19:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKD6O10971 for ; Mon, 10 Mar 2003 15:13:06 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10619 for ; Mon, 10 Mar 2003 14:59:29 -0500 (EST) Message-ID: <037b01c2e73f$a41e24b0$156015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 10 Mar 2003 12:00:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Topic #1: Dos Attack Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One objection that was raised to having a server provide the list of authentic access points is that an MN can launch a DoS attack on the server. If the router uses a softstate cache, the server load will only occur if the MN presents a new AP id. Now, it is possible that an MN can attack by making up AP ids and sending them to the router. A properly provisioned server should be able to handle that if the attacking MN tries to pose as a legitimate one by regulating its traffic. The server capacity must be large enough to handle the routers that are using it. If the MN doesn't regulate traffic and it bombards the router, the router can selectively drop message packets if the message volume becomes too large. Thus, service degrades but is not denied, until the sysadmin finds the offending MN and takes it off the air. Note that the same problem, an MN bombarding a router with packets, can occur for dycard as well, so it is not exclusive to the server approach. What am I missing? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 15:34:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12763 for ; Mon, 10 Mar 2003 15:34:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AKlOR15228 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 15:47:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKlOO15225 for ; Mon, 10 Mar 2003 15:47:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12742 for ; Mon, 10 Mar 2003 15:33:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKlAO15216; Mon, 10 Mar 2003 15:47:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKksO15178 for ; Mon, 10 Mar 2003 15:46:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12696 for ; Mon, 10 Mar 2003 15:33:15 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AKZM809801 for ; Mon, 10 Mar 2003 14:35:22 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 14:35:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 12:34:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 15:34:18 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLnQM6cjMcN4G47Q7ufZjc2EZoaoAAAnE5w To: , X-OriginalArrivalTime: 10 Mar 2003 20:34:19.0714 (UTC) FILETIME=[6D49CA20:01C2E744] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AKksO15179 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: See comments below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, March 10, 2003 3:00 PM To: seamoby@ietf.org Subject: [Seamoby] Topic #1: Dos Attack One objection that was raised to having a server provide the list of authentic access points is that an MN can launch a DoS attack on the server. If the router uses a softstate cache, the server load will only occur if the MN presents a new AP id. Hemant -> Agree. Now, it is possible that an MN can attack by making up AP ids and sending them to the router. Hemant -> Agree. A properly provisioned server should be able to handle that if the attacking MN tries to pose as a legitimate one by regulating its traffic. Hemant -> Are you defining legitimate MN as the one whose authenticity has been asserted to router by AAA during connection phase? I think this is right assumption. But, this MN can launch the above attack too. So, MN can be legitimate, still malicious (or erroneously configured/programmed MN). The server capacity must be large enough to handle the routers that are using it. Hemant -> Agree. If the MN doesn't regulate traffic and it bombards the router, the router can selectively drop message packets if the message volume becomes too large. Hemant -> We need to describe at least MAY method of how selective dropping is achieved. In IPv6, AR identifies MN with CoA. An MN that disconnects and reconnects gets different CoA. Thus, MN can keep disconnecting and reconnecting each time sending a bunch of bogus L2 IDs. Thus, service degrades but is not denied, until the sysadmin finds the offending MN and takes it off the air. Hemant -> Service degradation is a form of DoS. But, we have to live with that. Note that the same problem, an MN bombarding a router with packets, can occur for dycard as well, so it is not exclusive to the server approach. Hemant -> I think so. What am I missing? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 15:34:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12803 for ; Mon, 10 Mar 2003 15:34:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKlAO15216; Mon, 10 Mar 2003 15:47:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKksO15178 for ; Mon, 10 Mar 2003 15:46:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12696 for ; Mon, 10 Mar 2003 15:33:15 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AKZM809801 for ; Mon, 10 Mar 2003 14:35:22 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 14:35:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 12:34:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 15:34:18 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLnQM6cjMcN4G47Q7ufZjc2EZoaoAAAnE5w To: , X-OriginalArrivalTime: 10 Mar 2003 20:34:19.0714 (UTC) FILETIME=[6D49CA20:01C2E744] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AKksO15179 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: See comments below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, March 10, 2003 3:00 PM To: seamoby@ietf.org Subject: [Seamoby] Topic #1: Dos Attack One objection that was raised to having a server provide the list of authentic access points is that an MN can launch a DoS attack on the server. If the router uses a softstate cache, the server load will only occur if the MN presents a new AP id. Hemant -> Agree. Now, it is possible that an MN can attack by making up AP ids and sending them to the router. Hemant -> Agree. A properly provisioned server should be able to handle that if the attacking MN tries to pose as a legitimate one by regulating its traffic. Hemant -> Are you defining legitimate MN as the one whose authenticity has been asserted to router by AAA during connection phase? I think this is right assumption. But, this MN can launch the above attack too. So, MN can be legitimate, still malicious (or erroneously configured/programmed MN). The server capacity must be large enough to handle the routers that are using it. Hemant -> Agree. If the MN doesn't regulate traffic and it bombards the router, the router can selectively drop message packets if the message volume becomes too large. Hemant -> We need to describe at least MAY method of how selective dropping is achieved. In IPv6, AR identifies MN with CoA. An MN that disconnects and reconnects gets different CoA. Thus, MN can keep disconnecting and reconnecting each time sending a bunch of bogus L2 IDs. Thus, service degrades but is not denied, until the sysadmin finds the offending MN and takes it off the air. Hemant -> Service degradation is a form of DoS. But, we have to live with that. Note that the same problem, an MN bombarding a router with packets, can occur for dycard as well, so it is not exclusive to the server approach. Hemant -> I think so. What am I missing? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 15:38:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12926 for ; Mon, 10 Mar 2003 15:38:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AKpEO15407 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 15:51:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKpEO15404 for ; Mon, 10 Mar 2003 15:51:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12906 for ; Mon, 10 Mar 2003 15:37:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKp3O15383; Mon, 10 Mar 2003 15:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKoGO15341 for ; Mon, 10 Mar 2003 15:50:16 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12861 for ; Mon, 10 Mar 2003 15:36:38 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AKcla08166 for ; Mon, 10 Mar 2003 14:38:47 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 14:38:44 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:38:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 15:38:41 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLnQM6cjMcN4G47Q7ufZjc2EZoaoAAAnE5wAABnBgA= To: , , X-OriginalArrivalTime: 10 Mar 2003 20:38:42.0834 (UTC) FILETIME=[0A1EB720:01C2E745] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AKoGO15342 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, one addition to this. Even though the MN can also bombard the router with messages in the dycard approach, the damage is local. In the server-based approach, there is communication happening between router and server, affecting other network elements. Dirk >-----Original Message----- >From: ext Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] >Sent: Monday, March 10, 2003 3:34 PM >To: kempf@docomolabs-usa.com; seamoby@ietf.org >Subject: RE: [Seamoby] Topic #1: Dos Attack > > >Hi James: > >See comments below: > >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Monday, March 10, 2003 3:00 PM >To: seamoby@ietf.org >Subject: [Seamoby] Topic #1: Dos Attack > > >One objection that was raised to having a server provide the >list of authentic >access points is that an MN can launch a DoS attack on the server. > >If the router uses a softstate cache, the server load will >only occur if the MN >presents a new AP id. > >Hemant -> Agree. > >Now, it is possible that an MN can attack by making up AP >ids and sending them to the router. > >Hemant -> Agree. > >A properly provisioned server should be able >to handle that if the attacking MN tries to pose as a legitimate one by >regulating its traffic. > >Hemant -> Are you defining legitimate MN as the one whose >authenticity has been asserted to router by AAA during >connection phase? I think this is right assumption. But, this >MN can launch the above attack too. So, MN can be legitimate, >still malicious (or erroneously configured/programmed MN). > > The server capacity must be large enough to handle the >routers that are using it. > >Hemant -> Agree. > >If the MN doesn't regulate traffic and it bombards >the router, the router can selectively drop message packets if >the message >volume becomes too large. > >Hemant -> We need to describe at least MAY method of how >selective dropping is achieved. In IPv6, AR identifies MN with >CoA. An MN that disconnects and reconnects gets different CoA. >Thus, MN can keep disconnecting and reconnecting each time >sending a bunch of bogus L2 IDs. > >Thus, service degrades but is not denied, until the >sysadmin finds the offending MN and takes it off the air. > >Hemant -> Service degradation is a form of DoS. But, we have >to live with that. > >Note that the same problem, an MN bombarding a router with >packets, can occur >for dycard as well, so it is not exclusive to the server approach. > >Hemant -> I think so. > >What am I missing? > > jak > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 15:38:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12993 for ; Mon, 10 Mar 2003 15:38:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKp3O15383; Mon, 10 Mar 2003 15:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKoGO15341 for ; Mon, 10 Mar 2003 15:50:16 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12861 for ; Mon, 10 Mar 2003 15:36:38 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AKcla08166 for ; Mon, 10 Mar 2003 14:38:47 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 14:38:44 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 14:38:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 15:38:41 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLnQM6cjMcN4G47Q7ufZjc2EZoaoAAAnE5wAABnBgA= To: , , X-OriginalArrivalTime: 10 Mar 2003 20:38:42.0834 (UTC) FILETIME=[0A1EB720:01C2E745] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AKoGO15342 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, one addition to this. Even though the MN can also bombard the router with messages in the dycard approach, the damage is local. In the server-based approach, there is communication happening between router and server, affecting other network elements. Dirk >-----Original Message----- >From: ext Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] >Sent: Monday, March 10, 2003 3:34 PM >To: kempf@docomolabs-usa.com; seamoby@ietf.org >Subject: RE: [Seamoby] Topic #1: Dos Attack > > >Hi James: > >See comments below: > >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Monday, March 10, 2003 3:00 PM >To: seamoby@ietf.org >Subject: [Seamoby] Topic #1: Dos Attack > > >One objection that was raised to having a server provide the >list of authentic >access points is that an MN can launch a DoS attack on the server. > >If the router uses a softstate cache, the server load will >only occur if the MN >presents a new AP id. > >Hemant -> Agree. > >Now, it is possible that an MN can attack by making up AP >ids and sending them to the router. > >Hemant -> Agree. > >A properly provisioned server should be able >to handle that if the attacking MN tries to pose as a legitimate one by >regulating its traffic. > >Hemant -> Are you defining legitimate MN as the one whose >authenticity has been asserted to router by AAA during >connection phase? I think this is right assumption. But, this >MN can launch the above attack too. So, MN can be legitimate, >still malicious (or erroneously configured/programmed MN). > > The server capacity must be large enough to handle the >routers that are using it. > >Hemant -> Agree. > >If the MN doesn't regulate traffic and it bombards >the router, the router can selectively drop message packets if >the message >volume becomes too large. > >Hemant -> We need to describe at least MAY method of how >selective dropping is achieved. In IPv6, AR identifies MN with >CoA. An MN that disconnects and reconnects gets different CoA. >Thus, MN can keep disconnecting and reconnecting each time >sending a bunch of bogus L2 IDs. > >Thus, service degrades but is not denied, until the >sysadmin finds the offending MN and takes it off the air. > >Hemant -> Service degradation is a form of DoS. But, we have >to live with that. > >Note that the same problem, an MN bombarding a router with >packets, can occur >for dycard as well, so it is not exclusive to the server approach. > >Hemant -> I think so. > >What am I missing? > > jak > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 15:52:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13709 for ; Mon, 10 Mar 2003 15:52:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AL5Ot16785 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 16:05:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AL5OO16780 for ; Mon, 10 Mar 2003 16:05:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13688 for ; Mon, 10 Mar 2003 15:51:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AL58O16164; Mon, 10 Mar 2003 16:05:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AL4hO16125 for ; Mon, 10 Mar 2003 16:04:43 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13667 for ; Mon, 10 Mar 2003 15:51:04 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AKuaF11262 for ; Mon, 10 Mar 2003 22:56:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 22:53:10 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 22:53:09 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 12:53:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 15:53:03 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLnQM7C2ObxbffmQ+Kt+d/c8i7ZYAAAXFkw To: , X-OriginalArrivalTime: 10 Mar 2003 20:53:04.0659 (UTC) FILETIME=[0BCEC630:01C2E747] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AL4hO16126 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit James, I think the answers to these questions are there in previous threads. Anyways, here they are again embedded. I think, the fundamental topic is to be discussed before is whether we need a server at all. [anip] If the router uses a softstate cache, the server load will only occur if the MN presents a new AP id. Now, it is possible that an MN can attack by making up AP ids and sending them to the router. [snip] Not necessarily. A MN could be reporting APs not in the same domain. This is not a malicious MN. A properly provisioned server should be able to handle that if the attacking MN tries to pose as a legitimate one by regulating its traffic. The server capacity must be large enough to handle the routers that are using it. [snip] If the MN doesn't regulate traffic and it bombards the router, the router can selectively drop message packets if the message volume becomes too large. Thus, service degrades but is not denied, until the sysadmin finds the offending MN and takes it off the air. [Govind] Even when talking about malicious MNs, I don't think this is so simple, unless you track MNs that are making requests as what dycard does. Unless as Hemant pointed out, it is quite easy to deceive. Note that the same problem, an MN bombarding a router with packets, can occur for dycard as well, so it is not exclusive to the server approach. [Govind] In dycard, cache entries are not created because MNs hear the beacons. In the DT draft the protocol attempts to create cache entries based on what a MN hears. This is fundamental problem (?). I therefore don't understand the DoS attack you are referring to w.r.t to dycard. What am I missing? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 15:52:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13771 for ; Mon, 10 Mar 2003 15:52:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AL58O16164; Mon, 10 Mar 2003 16:05:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AL4hO16125 for ; Mon, 10 Mar 2003 16:04:43 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13667 for ; Mon, 10 Mar 2003 15:51:04 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AKuaF11262 for ; Mon, 10 Mar 2003 22:56:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 22:53:10 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 22:53:09 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 12:53:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 15:53:03 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLnQM7C2ObxbffmQ+Kt+d/c8i7ZYAAAXFkw To: , X-OriginalArrivalTime: 10 Mar 2003 20:53:04.0659 (UTC) FILETIME=[0BCEC630:01C2E747] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2AL4hO16126 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, I think the answers to these questions are there in previous threads. Anyways, here they are again embedded. I think, the fundamental topic is to be discussed before is whether we need a server at all. [anip] If the router uses a softstate cache, the server load will only occur if the MN presents a new AP id. Now, it is possible that an MN can attack by making up AP ids and sending them to the router. [snip] Not necessarily. A MN could be reporting APs not in the same domain. This is not a malicious MN. A properly provisioned server should be able to handle that if the attacking MN tries to pose as a legitimate one by regulating its traffic. The server capacity must be large enough to handle the routers that are using it. [snip] If the MN doesn't regulate traffic and it bombards the router, the router can selectively drop message packets if the message volume becomes too large. Thus, service degrades but is not denied, until the sysadmin finds the offending MN and takes it off the air. [Govind] Even when talking about malicious MNs, I don't think this is so simple, unless you track MNs that are making requests as what dycard does. Unless as Hemant pointed out, it is quite easy to deceive. Note that the same problem, an MN bombarding a router with packets, can occur for dycard as well, so it is not exclusive to the server approach. [Govind] In dycard, cache entries are not created because MNs hear the beacons. In the DT draft the protocol attempts to create cache entries based on what a MN hears. This is fundamental problem (?). I therefore don't understand the DoS attack you are referring to w.r.t to dycard. What am I missing? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 16:25:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15013 for ; Mon, 10 Mar 2003 16:25:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ALcis21233 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 16:38:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALchO21230 for ; Mon, 10 Mar 2003 16:38:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14984 for ; Mon, 10 Mar 2003 16:25:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALcSO21222; Mon, 10 Mar 2003 16:38:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALbjO21172 for ; Mon, 10 Mar 2003 16:37:45 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14963 for ; Mon, 10 Mar 2003 16:24:05 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ALQFa13278 for ; Mon, 10 Mar 2003 15:26:15 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 15:26:12 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 13:24:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 16:24:48 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLnQM7C2ObxbffmQ+Kt+d/c8i7ZYAACRg3g To: , X-OriginalArrivalTime: 10 Mar 2003 21:24:50.0078 (UTC) FILETIME=[7B86A3E0:01C2E74B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ALbjO21173 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Note that the same problem, an MN bombarding a router with packets, can occur for dycard as well, so it is not exclusive to the server approach. [Govind] Just a clarification, if you are talking about the increase in processing load on the AR to handle APid packets then you are right. This is a problem, not only with dycard but, with any protocol that sends and receives packets and has the possibility of malicious nodes. Even to selectively drop packets you need to look at the fields of the packet. I was talking about the other additional associated problems brought in by the unique handling of APid packets by the DT draft. Sorry if I was not clear in my earlier mail. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 16:25:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15027 for ; Mon, 10 Mar 2003 16:25:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALcSO21222; Mon, 10 Mar 2003 16:38:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALbjO21172 for ; Mon, 10 Mar 2003 16:37:45 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14963 for ; Mon, 10 Mar 2003 16:24:05 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ALQFa13278 for ; Mon, 10 Mar 2003 15:26:15 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 15:26:12 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 13:24:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 16:24:48 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLnQM7C2ObxbffmQ+Kt+d/c8i7ZYAACRg3g To: , X-OriginalArrivalTime: 10 Mar 2003 21:24:50.0078 (UTC) FILETIME=[7B86A3E0:01C2E74B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ALbjO21173 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Note that the same problem, an MN bombarding a router with packets, can occur for dycard as well, so it is not exclusive to the server approach. [Govind] Just a clarification, if you are talking about the increase in processing load on the AR to handle APid packets then you are right. This is a problem, not only with dycard but, with any protocol that sends and receives packets and has the possibility of malicious nodes. Even to selectively drop packets you need to look at the fields of the packet. I was talking about the other additional associated problems brought in by the unique handling of APid packets by the DT draft. Sorry if I was not clear in my earlier mail. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 16:37:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15472 for ; Mon, 10 Mar 2003 16:37:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ALoG121838 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 16:50:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALoGO21835 for ; Mon, 10 Mar 2003 16:50:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15450 for ; Mon, 10 Mar 2003 16:36:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALo5O21815; Mon, 10 Mar 2003 16:50:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALnYO21754 for ; Mon, 10 Mar 2003 16:49:34 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15410 for ; Mon, 10 Mar 2003 16:35:54 -0500 (EST) Message-ID: <03c801c2e74d$1c2351d0$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Mon, 10 Mar 2003 13:36:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [Govind] In dycard, cache entries are not created because MNs hear the beacons. In the DT > draft the protocol attempts to create cache entries based on > what a MN hears. This is fundamental problem (?). I therefore don't understand the DoS > attack you are referring to w.r.t to dycard. > Pg. 4, last paragraph on the page, draft-trossen-seamoby-dycard-01.txt: Following a handover, a MN informs its new access router (nAR) as seen in Figure 1, about its prevous point of attachment. In particular, the MN sends to nAR a Router Identity (RI) message (see Section 4.2) containing the IP address of the previous access router (pAR), the link-layer address of the prevous access point, as well as the link layer address of the new AP. So, for the scenarios depeicted in Figure 1, the MN would send the tuple (pAR,pAP,nAP) to nAR. Now, suppose, instead of just sending a single message, the MN pumps out a stream of packets at one per millisecond in order to tie up the router processing packets. Suppose the MN changes the IP address or uses other tricks so that the AR can't filter based on whether or not the MN is legitimate. That's the DoS attack I'm talking about. Furthermore, there is a problem with the information tuple in the dycard message. It is useless to the next MN that wants to come along and handover to pAR. Where does the MN get pAR's IP address? According to RFC 2461, a router never gives out a global IP address in ND. Yes, I know you can get one via traceroute so this prohibition has little effect on anything but the RFC says link local addresses are a MUST. Are you proposing a change in RFC 2461? What the MN really needs when it hands over to pAR is the L2 address on the wireless interface for pAR. So that it can send packets to pAR for forwarding without having to solicit an RA. Also the subnet prefix(s) and any other router configuration information so that it can perform address configuration without having to solicit an RA. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 16:37:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15498 for ; Mon, 10 Mar 2003 16:37:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALo5O21815; Mon, 10 Mar 2003 16:50:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALnYO21754 for ; Mon, 10 Mar 2003 16:49:34 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15410 for ; Mon, 10 Mar 2003 16:35:54 -0500 (EST) Message-ID: <03c801c2e74d$1c2351d0$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Mon, 10 Mar 2003 13:36:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [Govind] In dycard, cache entries are not created because MNs hear the beacons. In the DT > draft the protocol attempts to create cache entries based on > what a MN hears. This is fundamental problem (?). I therefore don't understand the DoS > attack you are referring to w.r.t to dycard. > Pg. 4, last paragraph on the page, draft-trossen-seamoby-dycard-01.txt: Following a handover, a MN informs its new access router (nAR) as seen in Figure 1, about its prevous point of attachment. In particular, the MN sends to nAR a Router Identity (RI) message (see Section 4.2) containing the IP address of the previous access router (pAR), the link-layer address of the prevous access point, as well as the link layer address of the new AP. So, for the scenarios depeicted in Figure 1, the MN would send the tuple (pAR,pAP,nAP) to nAR. Now, suppose, instead of just sending a single message, the MN pumps out a stream of packets at one per millisecond in order to tie up the router processing packets. Suppose the MN changes the IP address or uses other tricks so that the AR can't filter based on whether or not the MN is legitimate. That's the DoS attack I'm talking about. Furthermore, there is a problem with the information tuple in the dycard message. It is useless to the next MN that wants to come along and handover to pAR. Where does the MN get pAR's IP address? According to RFC 2461, a router never gives out a global IP address in ND. Yes, I know you can get one via traceroute so this prohibition has little effect on anything but the RFC says link local addresses are a MUST. Are you proposing a change in RFC 2461? What the MN really needs when it hands over to pAR is the L2 address on the wireless interface for pAR. So that it can send packets to pAR for forwarding without having to solicit an RA. Also the subnet prefix(s) and any other router configuration information so that it can perform address configuration without having to solicit an RA. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 16:42:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15617 for ; Mon, 10 Mar 2003 16:42:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ALtMg22057 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 16:55:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALtMO22054 for ; Mon, 10 Mar 2003 16:55:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15611 for ; Mon, 10 Mar 2003 16:41:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALt4O22029; Mon, 10 Mar 2003 16:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALssO22008 for ; Mon, 10 Mar 2003 16:54:54 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15591 for ; Mon, 10 Mar 2003 16:41:14 -0500 (EST) Message-ID: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 13:41:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Agreed the server is a bottleneck if the router has to resolve unidentified APs against the server. If the number of ARs per server is kept small, the scope-id can be dumped. And the server can download the list of authentic APs to the routers once, when they start. After that, the router just compares with the list, the server pushes new authentic APs to the router when they appear or deletes ones when they disappear. The server is really only useful for allowing the sysadmin to control which APs are authentic and which not, for some collection of routers. Otherwise, each router would have to be configured by hand. How does dycard propose giving a sysadmin control over what APs are recognized as authentic and what are not? In any case, this is why I think the issue of a server does not belong in the base draft. jak ----- Original Message ----- From: To: ; ; Sent: Monday, March 10, 2003 12:38 PM Subject: RE: [Seamoby] Topic #1: Dos Attack > Hi James, > > one addition to this. Even though the MN can also bombard the router with > messages in the dycard approach, the damage is local. In the server-based > approach, there is communication happening between router and server, affecting > other network elements. > > Dirk > > >-----Original Message----- > >From: ext Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > >Sent: Monday, March 10, 2003 3:34 PM > >To: kempf@docomolabs-usa.com; seamoby@ietf.org > >Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > >Hi James: > > > >See comments below: > > > >-----Original Message----- > >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > >Sent: Monday, March 10, 2003 3:00 PM > >To: seamoby@ietf.org > >Subject: [Seamoby] Topic #1: Dos Attack > > > > > >One objection that was raised to having a server provide the > >list of authentic > >access points is that an MN can launch a DoS attack on the server. > > > >If the router uses a softstate cache, the server load will > >only occur if the MN > >presents a new AP id. > > > >Hemant -> Agree. > > > >Now, it is possible that an MN can attack by making up AP > >ids and sending them to the router. > > > >Hemant -> Agree. > > > >A properly provisioned server should be able > >to handle that if the attacking MN tries to pose as a legitimate one by > >regulating its traffic. > > > >Hemant -> Are you defining legitimate MN as the one whose > >authenticity has been asserted to router by AAA during > >connection phase? I think this is right assumption. But, this > >MN can launch the above attack too. So, MN can be legitimate, > >still malicious (or erroneously configured/programmed MN). > > > > The server capacity must be large enough to handle the > >routers that are using it. > > > >Hemant -> Agree. > > > >If the MN doesn't regulate traffic and it bombards > >the router, the router can selectively drop message packets if > >the message > >volume becomes too large. > > > >Hemant -> We need to describe at least MAY method of how > >selective dropping is achieved. In IPv6, AR identifies MN with > >CoA. An MN that disconnects and reconnects gets different CoA. > >Thus, MN can keep disconnecting and reconnecting each time > >sending a bunch of bogus L2 IDs. > > > >Thus, service degrades but is not denied, until the > >sysadmin finds the offending MN and takes it off the air. > > > >Hemant -> Service degradation is a form of DoS. But, we have > >to live with that. > > > >Note that the same problem, an MN bombarding a router with > >packets, can occur > >for dycard as well, so it is not exclusive to the server approach. > > > >Hemant -> I think so. > > > >What am I missing? > > > > jak > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 16:42:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15634 for ; Mon, 10 Mar 2003 16:42:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALt4O22029; Mon, 10 Mar 2003 16:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALssO22008 for ; Mon, 10 Mar 2003 16:54:54 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15591 for ; Mon, 10 Mar 2003 16:41:14 -0500 (EST) Message-ID: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 13:41:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Agreed the server is a bottleneck if the router has to resolve unidentified APs against the server. If the number of ARs per server is kept small, the scope-id can be dumped. And the server can download the list of authentic APs to the routers once, when they start. After that, the router just compares with the list, the server pushes new authentic APs to the router when they appear or deletes ones when they disappear. The server is really only useful for allowing the sysadmin to control which APs are authentic and which not, for some collection of routers. Otherwise, each router would have to be configured by hand. How does dycard propose giving a sysadmin control over what APs are recognized as authentic and what are not? In any case, this is why I think the issue of a server does not belong in the base draft. jak ----- Original Message ----- From: To: ; ; Sent: Monday, March 10, 2003 12:38 PM Subject: RE: [Seamoby] Topic #1: Dos Attack > Hi James, > > one addition to this. Even though the MN can also bombard the router with > messages in the dycard approach, the damage is local. In the server-based > approach, there is communication happening between router and server, affecting > other network elements. > > Dirk > > >-----Original Message----- > >From: ext Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > >Sent: Monday, March 10, 2003 3:34 PM > >To: kempf@docomolabs-usa.com; seamoby@ietf.org > >Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > >Hi James: > > > >See comments below: > > > >-----Original Message----- > >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > >Sent: Monday, March 10, 2003 3:00 PM > >To: seamoby@ietf.org > >Subject: [Seamoby] Topic #1: Dos Attack > > > > > >One objection that was raised to having a server provide the > >list of authentic > >access points is that an MN can launch a DoS attack on the server. > > > >If the router uses a softstate cache, the server load will > >only occur if the MN > >presents a new AP id. > > > >Hemant -> Agree. > > > >Now, it is possible that an MN can attack by making up AP > >ids and sending them to the router. > > > >Hemant -> Agree. > > > >A properly provisioned server should be able > >to handle that if the attacking MN tries to pose as a legitimate one by > >regulating its traffic. > > > >Hemant -> Are you defining legitimate MN as the one whose > >authenticity has been asserted to router by AAA during > >connection phase? I think this is right assumption. But, this > >MN can launch the above attack too. So, MN can be legitimate, > >still malicious (or erroneously configured/programmed MN). > > > > The server capacity must be large enough to handle the > >routers that are using it. > > > >Hemant -> Agree. > > > >If the MN doesn't regulate traffic and it bombards > >the router, the router can selectively drop message packets if > >the message > >volume becomes too large. > > > >Hemant -> We need to describe at least MAY method of how > >selective dropping is achieved. In IPv6, AR identifies MN with > >CoA. An MN that disconnects and reconnects gets different CoA. > >Thus, MN can keep disconnecting and reconnecting each time > >sending a bunch of bogus L2 IDs. > > > >Thus, service degrades but is not denied, until the > >sysadmin finds the offending MN and takes it off the air. > > > >Hemant -> Service degradation is a form of DoS. But, we have > >to live with that. > > > >Note that the same problem, an MN bombarding a router with > >packets, can occur > >for dycard as well, so it is not exclusive to the server approach. > > > >Hemant -> I think so. > > > >What am I missing? > > > > jak > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 17:00:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16382 for ; Mon, 10 Mar 2003 17:00:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AMDN624304 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 17:13:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMDMO24301 for ; Mon, 10 Mar 2003 17:13:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16350 for ; Mon, 10 Mar 2003 16:59:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMD8O24262; Mon, 10 Mar 2003 17:13:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMCWO24227 for ; Mon, 10 Mar 2003 17:12:32 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16332 for ; Mon, 10 Mar 2003 16:58:52 -0500 (EST) Message-ID: <03fe01c2e750$517f4390$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 13:56:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So whatever the protocol, there needs to be some definition of rate-limiting in the standard, and instructions for the router to protect itself if the rate is exceeded. The DT draft currently doesn't have anything in on this. This is an issue. jak ----- Original Message ----- From: To: ; Sent: Monday, March 10, 2003 1:24 PM Subject: RE: [Seamoby] Topic #1: Dos Attack > Note that the same problem, an MN bombarding a router with packets, can occur > for dycard as well, so it is not exclusive to the server approach. > > [Govind] Just a clarification, if you are talking about the increase in processing > load on the AR to handle APid packets then you are right. This is a problem, not only with dycard but, with any protocol that sends and receives packets and has the possibility of malicious > nodes. Even to selectively drop packets you need to look at the fields of the packet. > I was talking about the other additional associated problems brought in by the unique handling > of APid packets by the DT draft. Sorry if I was not clear in my earlier mail. > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 17:00:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16395 for ; Mon, 10 Mar 2003 17:00:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMD8O24262; Mon, 10 Mar 2003 17:13:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMCWO24227 for ; Mon, 10 Mar 2003 17:12:32 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16332 for ; Mon, 10 Mar 2003 16:58:52 -0500 (EST) Message-ID: <03fe01c2e750$517f4390$156015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 13:56:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So whatever the protocol, there needs to be some definition of rate-limiting in the standard, and instructions for the router to protect itself if the rate is exceeded. The DT draft currently doesn't have anything in on this. This is an issue. jak ----- Original Message ----- From: To: ; Sent: Monday, March 10, 2003 1:24 PM Subject: RE: [Seamoby] Topic #1: Dos Attack > Note that the same problem, an MN bombarding a router with packets, can occur > for dycard as well, so it is not exclusive to the server approach. > > [Govind] Just a clarification, if you are talking about the increase in processing > load on the AR to handle APid packets then you are right. This is a problem, not only with dycard but, with any protocol that sends and receives packets and has the possibility of malicious > nodes. Even to selectively drop packets you need to look at the fields of the packet. > I was talking about the other additional associated problems brought in by the unique handling > of APid packets by the DT draft. Sorry if I was not clear in my earlier mail. > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 18:42:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21046 for ; Mon, 10 Mar 2003 18:42:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ANtVe31691 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 18:55:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ANtVO31688 for ; Mon, 10 Mar 2003 18:55:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21040 for ; Mon, 10 Mar 2003 18:41:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ANtJO31672; Mon, 10 Mar 2003 18:55:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ANsIO31611 for ; Mon, 10 Mar 2003 18:54:18 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21019 for ; Mon, 10 Mar 2003 18:40:34 -0500 (EST) Message-ID: <045d01c2e75e$87648890$156015ac@T23KEMPF> From: "James Kempf" To: "James Kempf" , , , References: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 15:41:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Agreed the server is a bottleneck if the router has to resolve unidentified APs > against the server. > Furthermore, I think dycard has the same problem. Pg. 5, 4th paragraph from the top draft-trossen-seamoby-dycard-01.txt: To further verify the contents of the RI message, the AR sends a Physical Neighbor Exchange (PNE) message (see Sectoin 4.7) to pAr. The PNE includes both the new and previous AP identifiers, pAP and nAP. pAR verifies that pAP is indeed valid via its own local PNC entries, and the the MN was recently present. pAR replies to nAR, indicating the result of the validation. If the report was valid, pAR updates its own PNC with an entry for nAR and nAP. It's the same attack as in the previous case, except this time the nAR ends up bombarding the pAR with PNE messages. Note that if the AR only accepts messages from MNs for which it has established an authentication relationship (AAA or SEND), then the MN can use only one IP address, and the router can rate limit on that address. This technqiue can be used regardless of whether the back end queries a database on a server or queries a neighboring router. Messages from a nonauthenticted address are thrown away. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 18:42:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21078 for ; Mon, 10 Mar 2003 18:42:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ANtJO31672; Mon, 10 Mar 2003 18:55:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ANsIO31611 for ; Mon, 10 Mar 2003 18:54:18 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21019 for ; Mon, 10 Mar 2003 18:40:34 -0500 (EST) Message-ID: <045d01c2e75e$87648890$156015ac@T23KEMPF> From: "James Kempf" To: "James Kempf" , , , References: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 15:41:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Agreed the server is a bottleneck if the router has to resolve unidentified APs > against the server. > Furthermore, I think dycard has the same problem. Pg. 5, 4th paragraph from the top draft-trossen-seamoby-dycard-01.txt: To further verify the contents of the RI message, the AR sends a Physical Neighbor Exchange (PNE) message (see Sectoin 4.7) to pAr. The PNE includes both the new and previous AP identifiers, pAP and nAP. pAR verifies that pAP is indeed valid via its own local PNC entries, and the the MN was recently present. pAR replies to nAR, indicating the result of the validation. If the report was valid, pAR updates its own PNC with an entry for nAR and nAP. It's the same attack as in the previous case, except this time the nAR ends up bombarding the pAR with PNE messages. Note that if the AR only accepts messages from MNs for which it has established an authentication relationship (AAA or SEND), then the MN can use only one IP address, and the router can rate limit on that address. This technqiue can be used regardless of whether the back end queries a database on a server or queries a neighboring router. Messages from a nonauthenticted address are thrown away. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 20:14:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23080 for ; Mon, 10 Mar 2003 20:14:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B1SAN04644 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 20:28:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1SAO04641 for ; Mon, 10 Mar 2003 20:28:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23071 for ; Mon, 10 Mar 2003 20:14:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1RVO04613; Mon, 10 Mar 2003 20:27:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1Q1O04577 for ; Mon, 10 Mar 2003 20:26:01 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23024 for ; Mon, 10 Mar 2003 20:12:16 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Mar 2003 20:14:24 -0500 Message-ID: <019701c2e784$e03675c0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> <045d01c2e75e$87648890$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 20:15:39 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 01:14:24.0783 (UTC) FILETIME=[8DE3D1F0:01C2E76B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, My comments are inline. ----- Original Message ----- From: "James Kempf" To: "James Kempf" ; ; ; Sent: Monday, March 10, 2003 3:41 PM Subject: Re: [Seamoby] Topic #1: Dos Attack > > > Agreed the server is a bottleneck if the router has to resolve unidentified > APs > > against the server. > > > > Furthermore, I think dycard has the same problem. Pg. 5, 4th paragraph from the > top draft-trossen-seamoby-dycard-01.txt: > > To further verify the contents of the RI message, the AR sends a Physical > Neighbor Exchange (PNE) message (see Sectoin 4.7) to pAr. The > PNE includes both the new and previous AP identifiers, pAP and nAP. > pAR verifies that pAP is indeed valid via its own local PNC entries, and > the the MN was recently present. pAR replies to nAR, indicating the > result of the validation. If the report was valid, pAR updates its own > PNC with an entry for nAR and nAP. > > It's the same attack as in the previous case, except this time the nAR ends up > bombarding the pAR with PNE messages. > I don't understand where there is anything in dycard similar to the server of the server approach. The pAR is not a server where all the ARs in the domain should communicate with. The nAR will send PNE to pAR only when its identity was reported by a MN and the nAR does not have a record about the pAR. Once the nAR recognize the pAR as one of its neighbors, the nAR does not have to send PNE to the pAR even if lots of MNs report about the pAR. > Note that if the AR only accepts messages from MNs for which it has established > an authentication relationship (AAA or SEND), then the MN can use only one IP > address, and the router can rate limit on that address. This technqiue can be > used regardless of whether the back end queries a database on a server or > queries a neighboring router. Messages from a nonauthenticted address are thrown > away. > I think Dycard assumes that MN is authenticated and it is known to AR. Checking identity of the MN is an important part of the security aspects of Dycard. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 20:15:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23093 for ; Mon, 10 Mar 2003 20:15:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1RVO04613; Mon, 10 Mar 2003 20:27:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1Q1O04577 for ; Mon, 10 Mar 2003 20:26:01 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23024 for ; Mon, 10 Mar 2003 20:12:16 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Mar 2003 20:14:24 -0500 Message-ID: <019701c2e784$e03675c0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> <045d01c2e75e$87648890$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 20:15:39 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 01:14:24.0783 (UTC) FILETIME=[8DE3D1F0:01C2E76B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, My comments are inline. ----- Original Message ----- From: "James Kempf" To: "James Kempf" ; ; ; Sent: Monday, March 10, 2003 3:41 PM Subject: Re: [Seamoby] Topic #1: Dos Attack > > > Agreed the server is a bottleneck if the router has to resolve unidentified > APs > > against the server. > > > > Furthermore, I think dycard has the same problem. Pg. 5, 4th paragraph from the > top draft-trossen-seamoby-dycard-01.txt: > > To further verify the contents of the RI message, the AR sends a Physical > Neighbor Exchange (PNE) message (see Sectoin 4.7) to pAr. The > PNE includes both the new and previous AP identifiers, pAP and nAP. > pAR verifies that pAP is indeed valid via its own local PNC entries, and > the the MN was recently present. pAR replies to nAR, indicating the > result of the validation. If the report was valid, pAR updates its own > PNC with an entry for nAR and nAP. > > It's the same attack as in the previous case, except this time the nAR ends up > bombarding the pAR with PNE messages. > I don't understand where there is anything in dycard similar to the server of the server approach. The pAR is not a server where all the ARs in the domain should communicate with. The nAR will send PNE to pAR only when its identity was reported by a MN and the nAR does not have a record about the pAR. Once the nAR recognize the pAR as one of its neighbors, the nAR does not have to send PNE to the pAR even if lots of MNs report about the pAR. > Note that if the AR only accepts messages from MNs for which it has established > an authentication relationship (AAA or SEND), then the MN can use only one IP > address, and the router can rate limit on that address. This technqiue can be > used regardless of whether the back end queries a database on a server or > queries a neighboring router. Messages from a nonauthenticted address are thrown > away. > I think Dycard assumes that MN is authenticated and it is known to AR. Checking identity of the MN is an important part of the security aspects of Dycard. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 20:22:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23175 for ; Mon, 10 Mar 2003 20:22:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B1ZH504892 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 20:35:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1ZHO04889 for ; Mon, 10 Mar 2003 20:35:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23163 for ; Mon, 10 Mar 2003 20:21:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1Z2O04866; Mon, 10 Mar 2003 20:35:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1YeO04842 for ; Mon, 10 Mar 2003 20:34:40 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23156 for ; Mon, 10 Mar 2003 20:20:57 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Mar 2003 20:23:04 -0500 Message-ID: <01a001c2e786$15caa070$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 20:24:19 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 01:23:04.0194 (UTC) FILETIME=[C37BA620:01C2E76C] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, My comments are inline. ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Monday, March 10, 2003 1:41 PM Subject: Re: [Seamoby] Topic #1: Dos Attack > Agreed the server is a bottleneck if the router has to resolve unidentified APs > against the server. > > If the number of ARs per server is kept small, the scope-id can be dumped. [eunsoo] Are you proposing many servers per domain? Then we will end up with many kind of sub-domains across which CARD does not work in the server approach. This is not a good situation because we cannot take any advantage of CARD across sub-domain boundaries. And > the server can download the list of authentic APs to the routers once, when they > start. After that, the router just compares with the list, the server pushes new > authentic APs to the router when they appear or deletes ones when they > disappear. > > The server is really only useful for allowing the sysadmin to control which APs > are authentic and which not, for some collection of routers. Otherwise, each > router would have to be configured by hand. > [eunsoo] It seems that you are advocating the server as a kind of network management system. If any network admin needs really remote configuration of ARs, she/he can use other existing tools. We don't need to invent any new protocol for this. So the idea of the server approach is allowing system admin to update the L2-L3 mapping table on each AR from a central office rather than visiting one by one? > How does dycard propose giving a sysadmin control over what APs are recognized > as authentic and what are not? > [eunsoo] In dycard, the system admin can set up a policy such that only authorized or classifed APs should be recognized in the CARD process. > In any case, this is why I think the issue of a server does not belong in the > base draft. > [eunsoo] I think the server is one of the central issues of the DT draft. The fundamental question is whether we need the server at all for CARD. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 20:22:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23192 for ; Mon, 10 Mar 2003 20:22:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1Z2O04866; Mon, 10 Mar 2003 20:35:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1YeO04842 for ; Mon, 10 Mar 2003 20:34:40 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23156 for ; Mon, 10 Mar 2003 20:20:57 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Mar 2003 20:23:04 -0500 Message-ID: <01a001c2e786$15caa070$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Mon, 10 Mar 2003 20:24:19 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 01:23:04.0194 (UTC) FILETIME=[C37BA620:01C2E76C] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, My comments are inline. ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Monday, March 10, 2003 1:41 PM Subject: Re: [Seamoby] Topic #1: Dos Attack > Agreed the server is a bottleneck if the router has to resolve unidentified APs > against the server. > > If the number of ARs per server is kept small, the scope-id can be dumped. [eunsoo] Are you proposing many servers per domain? Then we will end up with many kind of sub-domains across which CARD does not work in the server approach. This is not a good situation because we cannot take any advantage of CARD across sub-domain boundaries. And > the server can download the list of authentic APs to the routers once, when they > start. After that, the router just compares with the list, the server pushes new > authentic APs to the router when they appear or deletes ones when they > disappear. > > The server is really only useful for allowing the sysadmin to control which APs > are authentic and which not, for some collection of routers. Otherwise, each > router would have to be configured by hand. > [eunsoo] It seems that you are advocating the server as a kind of network management system. If any network admin needs really remote configuration of ARs, she/he can use other existing tools. We don't need to invent any new protocol for this. So the idea of the server approach is allowing system admin to update the L2-L3 mapping table on each AR from a central office rather than visiting one by one? > How does dycard propose giving a sysadmin control over what APs are recognized > as authentic and what are not? > [eunsoo] In dycard, the system admin can set up a policy such that only authorized or classifed APs should be recognized in the CARD process. > In any case, this is why I think the issue of a server does not belong in the > base draft. > [eunsoo] I think the server is one of the central issues of the DT draft. The fundamental question is whether we need the server at all for CARD. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 10 20:33:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23350 for ; Mon, 10 Mar 2003 20:33:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B1kPb06014 for seamoby-archive@odin.ietf.org; Mon, 10 Mar 2003 20:46:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1kPO06011 for ; Mon, 10 Mar 2003 20:46:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23344 for ; Mon, 10 Mar 2003 20:32:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1kBO06001; Mon, 10 Mar 2003 20:46:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1jEO05973 for ; Mon, 10 Mar 2003 20:45:14 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23325 for ; Mon, 10 Mar 2003 20:31:30 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Mar 2003 20:33:37 -0500 Message-ID: <01b301c2e787$8f184990$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <03c801c2e74d$1c2351d0$156015ac@T23KEMPF> Subject: Re: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Mon, 10 Mar 2003 20:34:52 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 01:33:37.0275 (UTC) FILETIME=[3CD424B0:01C2E76E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, My comments are inline. > > [Govind] In dycard, cache entries are not created because MNs hear the > beacons. In the DT > > draft the protocol attempts to create cache entries based on > > what a MN hears. This is fundamental problem (?). I therefore don't understand > the DoS > > attack you are referring to w.r.t to dycard. > > > > Pg. 4, last paragraph on the page, draft-trossen-seamoby-dycard-01.txt: > > Following a handover, a MN informs its new access router (nAR) > as seen in Figure 1, about its prevous point of attachment. In > particular, the MN sends to nAR a Router Identity (RI) message > (see Section 4.2) containing the IP address of the previous access > router (pAR), the link-layer address of the prevous access point, > as well as the link layer address of the new AP. So, for the > scenarios depeicted in Figure 1, the MN would send the tuple > (pAR,pAP,nAP) to nAR. > > Now, suppose, instead of just sending a single message, the MN pumps out a > stream of packets at one per millisecond in order to tie up the router > processing packets. Suppose the MN changes the IP address or uses other tricks > so that the AR can't filter based on whether or not the MN is legitimate. That's > the DoS attack I'm talking about. > [eunsoo] As I said in a previous email, authenticating MN is an important requirement for security in Dycard. The problem of the server approach is that authenticating MN does not help preventing MN from doing cache contamination. There is no way to prevent MN from causing cache contamination in the server approach as far as I understand. If I am missing something, please let me know. > Furthermore, there is a problem with the information tuple in the dycard > message. It is useless to the next MN that wants to come along and handover to > pAR. Where does the MN get pAR's IP address? According to RFC 2461, a router > never gives out a global IP address in ND. Yes, I know you can get one via > traceroute so this prohibition has little effect on anything but the RFC says > link local addresses are a MUST. Are you proposing a change in RFC 2461? What > the MN really needs when it hands over to pAR is the L2 address on the wireless > interface for pAR. So that it can send packets to pAR for forwarding without > having to solicit an RA. [eunsoo] I think you were confused here. What MN needs eventually is L3 address (IP address) of pAR for fast handoff when it hands over to pAR. I don't understand how MN can send packets to pAR without knowing pAR's IP address unless the packets are for multicasting or broadcasting. Also the subnet prefix(s) and any other router > configuration information so that it can perform address configuration without > having to solicit an RA. > Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 10 20:33:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23363 for ; Mon, 10 Mar 2003 20:33:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1kBO06001; Mon, 10 Mar 2003 20:46:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1jEO05973 for ; Mon, 10 Mar 2003 20:45:14 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23325 for ; Mon, 10 Mar 2003 20:31:30 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Mar 2003 20:33:37 -0500 Message-ID: <01b301c2e787$8f184990$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <03c801c2e74d$1c2351d0$156015ac@T23KEMPF> Subject: Re: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Mon, 10 Mar 2003 20:34:52 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 01:33:37.0275 (UTC) FILETIME=[3CD424B0:01C2E76E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, My comments are inline. > > [Govind] In dycard, cache entries are not created because MNs hear the > beacons. In the DT > > draft the protocol attempts to create cache entries based on > > what a MN hears. This is fundamental problem (?). I therefore don't understand > the DoS > > attack you are referring to w.r.t to dycard. > > > > Pg. 4, last paragraph on the page, draft-trossen-seamoby-dycard-01.txt: > > Following a handover, a MN informs its new access router (nAR) > as seen in Figure 1, about its prevous point of attachment. In > particular, the MN sends to nAR a Router Identity (RI) message > (see Section 4.2) containing the IP address of the previous access > router (pAR), the link-layer address of the prevous access point, > as well as the link layer address of the new AP. So, for the > scenarios depeicted in Figure 1, the MN would send the tuple > (pAR,pAP,nAP) to nAR. > > Now, suppose, instead of just sending a single message, the MN pumps out a > stream of packets at one per millisecond in order to tie up the router > processing packets. Suppose the MN changes the IP address or uses other tricks > so that the AR can't filter based on whether or not the MN is legitimate. That's > the DoS attack I'm talking about. > [eunsoo] As I said in a previous email, authenticating MN is an important requirement for security in Dycard. The problem of the server approach is that authenticating MN does not help preventing MN from doing cache contamination. There is no way to prevent MN from causing cache contamination in the server approach as far as I understand. If I am missing something, please let me know. > Furthermore, there is a problem with the information tuple in the dycard > message. It is useless to the next MN that wants to come along and handover to > pAR. Where does the MN get pAR's IP address? According to RFC 2461, a router > never gives out a global IP address in ND. Yes, I know you can get one via > traceroute so this prohibition has little effect on anything but the RFC says > link local addresses are a MUST. Are you proposing a change in RFC 2461? What > the MN really needs when it hands over to pAR is the L2 address on the wireless > interface for pAR. So that it can send packets to pAR for forwarding without > having to solicit an RA. [eunsoo] I think you were confused here. What MN needs eventually is L3 address (IP address) of pAR for fast handoff when it hands over to pAR. I don't understand how MN can send packets to pAR without knowing pAR's IP address unless the packets are for multicasting or broadcasting. Also the subnet prefix(s) and any other router > configuration information so that it can perform address configuration without > having to solicit an RA. > Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 11:37:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26524 for ; Tue, 11 Mar 2003 11:37:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BGoqS11868 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 11:50:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGopO11865 for ; Tue, 11 Mar 2003 11:50:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26491 for ; Tue, 11 Mar 2003 11:36:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGoYO11855; Tue, 11 Mar 2003 11:50:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGnRO11772 for ; Tue, 11 Mar 2003 11:49:27 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26450 for ; Tue, 11 Mar 2003 11:35:23 -0500 (EST) Message-ID: <005501c2e7ec$4d0beb00$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , References: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> <045d01c2e75e$87648890$156015ac@T23KEMPF> <019701c2e784$e03675c0$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 08:36:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I don't understand where there is anything in dycard similar to the server > of the server approach. > The pAR is not a server where all the ARs in the domain should communicate > with. > The nAR will send PNE to pAR only when its identity was reported by a MN and > the nAR does not have a record about the pAR. Once the nAR recognize the pAR > as one of its neighbors, the nAR does not have to send PNE to the pAR even > if lots of MNs report about the pAR. > Suppose MN starts making up pAR addresses and bombarding nAR with them? nAR must send PNE messages to resolve, causing a DoS attack on nAR, even though the pAR don't exist. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 11:37:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26541 for ; Tue, 11 Mar 2003 11:37:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGoYO11855; Tue, 11 Mar 2003 11:50:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGnRO11772 for ; Tue, 11 Mar 2003 11:49:27 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26450 for ; Tue, 11 Mar 2003 11:35:23 -0500 (EST) Message-ID: <005501c2e7ec$4d0beb00$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , References: <03ce01c2e74d$dbc95ca0$156015ac@T23KEMPF> <045d01c2e75e$87648890$156015ac@T23KEMPF> <019701c2e784$e03675c0$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 08:36:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I don't understand where there is anything in dycard similar to the server > of the server approach. > The pAR is not a server where all the ARs in the domain should communicate > with. > The nAR will send PNE to pAR only when its identity was reported by a MN and > the nAR does not have a record about the pAR. Once the nAR recognize the pAR > as one of its neighbors, the nAR does not have to send PNE to the pAR even > if lots of MNs report about the pAR. > Suppose MN starts making up pAR addresses and bombarding nAR with them? nAR must send PNE messages to resolve, causing a DoS attack on nAR, even though the pAR don't exist. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 11:56:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27406 for ; Tue, 11 Mar 2003 11:56:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BHA3l14110 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 12:10:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHA3O14107 for ; Tue, 11 Mar 2003 12:10:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27370 for ; Tue, 11 Mar 2003 11:55:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH9mO14075; Tue, 11 Mar 2003 12:09:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH7wO13991 for ; Tue, 11 Mar 2003 12:07:58 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27268 for ; Tue, 11 Mar 2003 11:53:55 -0500 (EST) Message-ID: <007301c2e7ee$e35d9930$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <03c801c2e74d$1c2351d0$156015ac@T23KEMPF> <01b301c2e787$8f184990$e26b0f8a@eunsoo> Subject: Re: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Tue, 11 Mar 2003 08:54:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [eunsoo] As I said in a previous email, authenticating MN is an important > requirement for security in Dycard. The problem of the server approach is > that authenticating MN does not help preventing MN from doing cache > contamination. There is no way to prevent MN from causing cache > contamination in the server approach as far as I understand. If I am missing > something, please let me know. > What is your definition of cache contamination? >> [eunsoo] I think you were confused here. What MN needs eventually is L3 > address (IP address) of pAR for fast handoff when it hands over to pAR. I > don't understand how MN can send packets to pAR without knowing pAR's IP > address unless the packets are for multicasting or broadcasting. > No it doesn't. Currently, FMIPv6 uses a global address for pAR in only one way: the MN sends FBU to pAR to set up the tunnel. But providing security for this has been a problem, and there is discussion in the MIP group for the signaling to go to the current AR (whether pAR or nAR is immaterial) to set up the tunnel. That way, SEND could be used to secure the signaling (possibly with some authorization token to the pAR, that is still under discussion) between the MN and AR, and the HI/HAck would be secured using the interrouter security association. With dycard, nAR needs pAR's address from the MN in order to be able to send PNE. Dycard establishes a dependency on the global IP address of the router being provided by the MN which may not be there in the end for fast handover. This is one reason why I think the CARD work needs to be moved into the MIP group (or, at least, the MN to AR part). Seamoby could end up designing a protocol that doesn't provide what FMIP needs. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 11:56:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27433 for ; Tue, 11 Mar 2003 11:56:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH9mO14075; Tue, 11 Mar 2003 12:09:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH7wO13991 for ; Tue, 11 Mar 2003 12:07:58 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27268 for ; Tue, 11 Mar 2003 11:53:55 -0500 (EST) Message-ID: <007301c2e7ee$e35d9930$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <03c801c2e74d$1c2351d0$156015ac@T23KEMPF> <01b301c2e787$8f184990$e26b0f8a@eunsoo> Subject: Re: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Tue, 11 Mar 2003 08:54:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [eunsoo] As I said in a previous email, authenticating MN is an important > requirement for security in Dycard. The problem of the server approach is > that authenticating MN does not help preventing MN from doing cache > contamination. There is no way to prevent MN from causing cache > contamination in the server approach as far as I understand. If I am missing > something, please let me know. > What is your definition of cache contamination? >> [eunsoo] I think you were confused here. What MN needs eventually is L3 > address (IP address) of pAR for fast handoff when it hands over to pAR. I > don't understand how MN can send packets to pAR without knowing pAR's IP > address unless the packets are for multicasting or broadcasting. > No it doesn't. Currently, FMIPv6 uses a global address for pAR in only one way: the MN sends FBU to pAR to set up the tunnel. But providing security for this has been a problem, and there is discussion in the MIP group for the signaling to go to the current AR (whether pAR or nAR is immaterial) to set up the tunnel. That way, SEND could be used to secure the signaling (possibly with some authorization token to the pAR, that is still under discussion) between the MN and AR, and the HI/HAck would be secured using the interrouter security association. With dycard, nAR needs pAR's address from the MN in order to be able to send PNE. Dycard establishes a dependency on the global IP address of the router being provided by the MN which may not be there in the end for fast handover. This is one reason why I think the CARD work needs to be moved into the MIP group (or, at least, the MN to AR part). Seamoby could end up designing a protocol that doesn't provide what FMIP needs. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 12:01:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27785 for ; Tue, 11 Mar 2003 12:01:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BHF8n14395 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 12:15:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHF8O14392 for ; Tue, 11 Mar 2003 12:15:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27756 for ; Tue, 11 Mar 2003 12:01:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHBmO14167; Tue, 11 Mar 2003 12:11:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH90O14025 for ; Tue, 11 Mar 2003 12:09:00 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27288 for ; Tue, 11 Mar 2003 11:54:57 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BGv4821499 for ; Tue, 11 Mar 2003 10:57:04 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 10:56:57 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 08:56:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 11:56:56 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLn7L9bU7JLe3rRTf2b4O6vuSG9dgAATuZw To: , , , , X-OriginalArrivalTime: 11 Mar 2003 16:56:57.0496 (UTC) FILETIME=[39EF0180:01C2E7EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BH90O14026 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jim, The nAR DOES NOT send PNE messages just because the MN reports pARs. Clearly if the MN does report more than one pAR then it is clearly a malicious MN and it can be filtered out. Also, all MNs are allowed to send dycard messages only after they have been authenticated by the network. We use a unique, third party verified identity for the MN and the number of entries that can be created per MN can be restricted. So if the limit for the MNs (set by the network) have been reached then there are no PNE messages exchanged for RI messages sent by that particular MN. All subsequent messages from the MN are silently discarded. Could you let me know where you see the DoS attack? Thanks, Govind. > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, March 11, 2003 11:36 AM > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > (NRC/Boston); > seamoby@ietf.org > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > I don't understand where there is anything in dycard > similar to the server > > of the server approach. > > The pAR is not a server where all the ARs in the domain > should communicate > > with. > > The nAR will send PNE to pAR only when its identity was > reported by a MN and > > the nAR does not have a record about the pAR. Once the nAR > recognize the pAR > > as one of its neighbors, the nAR does not have to send PNE > to the pAR even > > if lots of MNs report about the pAR. > > > > Suppose MN starts making up pAR addresses and bombarding nAR > with them? nAR must > send PNE messages to resolve, causing a DoS attack on nAR, > even though the pAR > don't exist. > > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 12:01:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27821 for ; Tue, 11 Mar 2003 12:01:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHBmO14167; Tue, 11 Mar 2003 12:11:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH90O14025 for ; Tue, 11 Mar 2003 12:09:00 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27288 for ; Tue, 11 Mar 2003 11:54:57 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BGv4821499 for ; Tue, 11 Mar 2003 10:57:04 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 10:56:57 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 08:56:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 11:56:56 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLn7L9bU7JLe3rRTf2b4O6vuSG9dgAATuZw To: , , , , X-OriginalArrivalTime: 11 Mar 2003 16:56:57.0496 (UTC) FILETIME=[39EF0180:01C2E7EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BH90O14026 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Jim, The nAR DOES NOT send PNE messages just because the MN reports pARs. Clearly if the MN does report more than one pAR then it is clearly a malicious MN and it can be filtered out. Also, all MNs are allowed to send dycard messages only after they have been authenticated by the network. We use a unique, third party verified identity for the MN and the number of entries that can be created per MN can be restricted. So if the limit for the MNs (set by the network) have been reached then there are no PNE messages exchanged for RI messages sent by that particular MN. All subsequent messages from the MN are silently discarded. Could you let me know where you see the DoS attack? Thanks, Govind. > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, March 11, 2003 11:36 AM > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > (NRC/Boston); > seamoby@ietf.org > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > I don't understand where there is anything in dycard > similar to the server > > of the server approach. > > The pAR is not a server where all the ARs in the domain > should communicate > > with. > > The nAR will send PNE to pAR only when its identity was > reported by a MN and > > the nAR does not have a record about the pAR. Once the nAR > recognize the pAR > > as one of its neighbors, the nAR does not have to send PNE > to the pAR even > > if lots of MNs report about the pAR. > > > > Suppose MN starts making up pAR addresses and bombarding nAR > with them? nAR must > send PNE messages to resolve, causing a DoS attack on nAR, > even though the pAR > don't exist. > > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 12:34:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28976 for ; Tue, 11 Mar 2003 12:34:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BHmFZ16758 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 12:48:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHmEO16755 for ; Tue, 11 Mar 2003 12:48:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28965 for ; Tue, 11 Mar 2003 12:34:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHisO16655; Tue, 11 Mar 2003 12:44:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHgnO16567 for ; Tue, 11 Mar 2003 12:42:49 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28771 for ; Tue, 11 Mar 2003 12:28:44 -0500 (EST) Message-ID: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> From: "James Kempf" To: , , , , References: Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 09:27:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Suppose MN starts making up its own IP address too. jak ----- Original Message ----- From: To: ; ; ; ; Sent: Tuesday, March 11, 2003 8:56 AM Subject: RE: [Seamoby] Topic #1: Dos Attack > Hi Jim, > The nAR DOES NOT send PNE messages > just because the MN reports pARs. Clearly if the MN does report more > than one pAR then it is clearly a malicious MN and it can > be filtered out. Also, all MNs are allowed to send dycard messages > only after they have been authenticated by the network. > We use a unique, third party verified identity for the MN and > the number of entries that can be created per MN > can be restricted. So if the limit for the MNs (set by the network) > have been reached then there are no PNE messages exchanged for RI messages sent > by that particular MN. All subsequent messages from the MN are silently discarded. Could you let me know where you see the DoS attack? > > Thanks, > Govind. > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Tuesday, March 11, 2003 11:36 AM > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > (NRC/Boston); > > seamoby@ietf.org > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > I don't understand where there is anything in dycard > > similar to the server > > > of the server approach. > > > The pAR is not a server where all the ARs in the domain > > should communicate > > > with. > > > The nAR will send PNE to pAR only when its identity was > > reported by a MN and > > > the nAR does not have a record about the pAR. Once the nAR > > recognize the pAR > > > as one of its neighbors, the nAR does not have to send PNE > > to the pAR even > > > if lots of MNs report about the pAR. > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > with them? nAR must > > send PNE messages to resolve, causing a DoS attack on nAR, > > even though the pAR > > don't exist. > > > > > > jak > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 12:35:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29014 for ; Tue, 11 Mar 2003 12:35:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHisO16655; Tue, 11 Mar 2003 12:44:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHgnO16567 for ; Tue, 11 Mar 2003 12:42:49 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28771 for ; Tue, 11 Mar 2003 12:28:44 -0500 (EST) Message-ID: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> From: "James Kempf" To: , , , , References: Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 09:27:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Suppose MN starts making up its own IP address too. jak ----- Original Message ----- From: To: ; ; ; ; Sent: Tuesday, March 11, 2003 8:56 AM Subject: RE: [Seamoby] Topic #1: Dos Attack > Hi Jim, > The nAR DOES NOT send PNE messages > just because the MN reports pARs. Clearly if the MN does report more > than one pAR then it is clearly a malicious MN and it can > be filtered out. Also, all MNs are allowed to send dycard messages > only after they have been authenticated by the network. > We use a unique, third party verified identity for the MN and > the number of entries that can be created per MN > can be restricted. So if the limit for the MNs (set by the network) > have been reached then there are no PNE messages exchanged for RI messages sent > by that particular MN. All subsequent messages from the MN are silently discarded. Could you let me know where you see the DoS attack? > > Thanks, > Govind. > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Tuesday, March 11, 2003 11:36 AM > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > (NRC/Boston); > > seamoby@ietf.org > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > I don't understand where there is anything in dycard > > similar to the server > > > of the server approach. > > > The pAR is not a server where all the ARs in the domain > > should communicate > > > with. > > > The nAR will send PNE to pAR only when its identity was > > reported by a MN and > > > the nAR does not have a record about the pAR. Once the nAR > > recognize the pAR > > > as one of its neighbors, the nAR does not have to send PNE > > to the pAR even > > > if lots of MNs report about the pAR. > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > with them? nAR must > > send PNE messages to resolve, causing a DoS attack on nAR, > > even though the pAR > > don't exist. > > > > > > jak > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 12:45:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29350 for ; Tue, 11 Mar 2003 12:45:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BHxUW17274 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 12:59:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHxUO17271 for ; Tue, 11 Mar 2003 12:59:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29343 for ; Tue, 11 Mar 2003 12:45:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHuAO17151; Tue, 11 Mar 2003 12:56:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHrvO17045 for ; Tue, 11 Mar 2003 12:53:57 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29166 for ; Tue, 11 Mar 2003 12:39:52 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BHfx804046 for ; Tue, 11 Mar 2003 11:42:00 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 11:41:59 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 11:41:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Tue, 11 Mar 2003 12:41:58 -0500 Message-ID: Thread-Topic: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Thread-Index: AcLn7yNSqtc8+ZFNQRmrRbhJKfU0fQAAKA7Q To: , , X-OriginalArrivalTime: 11 Mar 2003 17:41:59.0632 (UTC) FILETIME=[84883D00:01C2E7F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BHrvO17046 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > No it doesn't. Currently, FMIPv6 uses a global address for > pAR in only one way: > the MN sends FBU to pAR to set up the tunnel. But providing > security for this > has been a problem, and there is discussion in the MIP group > for the signaling > to go to the current AR (whether pAR or nAR is immaterial) to > set up the tunnel. > That way, SEND could be used to secure the signaling > (possibly with some > authorization token to the pAR, that is still under > discussion) between the MN > and AR, and the HI/HAck would be secured using the > interrouter security > association. > > With dycard, nAR needs pAR's address from the MN in order to > be able to send > PNE. Dycard establishes a dependency on the global IP address > of the router > being provided by the MN which may not be there in the end > for fast handover. > [Govind] Can't any of the dycard messages from the AR to the MN can carry the global IP address of the AR to the MN as the source address of the packet. This can be protected by an existing AR-MN SA if needed. > This is one reason why I think the CARD work needs to be > moved into the MIP > group (or, at least, the MN to AR part). Seamoby could end up > designing a > protocol that doesn't provide what FMIP needs. [Govind] I don't think this restriction is needed. I think CARD protocol can provide input for FMIP as well as other seamless handover protocols. It is a generic protocol and it should remain as one. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 12:46:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29383 for ; Tue, 11 Mar 2003 12:46:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHuAO17151; Tue, 11 Mar 2003 12:56:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHrvO17045 for ; Tue, 11 Mar 2003 12:53:57 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29166 for ; Tue, 11 Mar 2003 12:39:52 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BHfx804046 for ; Tue, 11 Mar 2003 11:42:00 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 11:41:59 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 11:41:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Tue, 11 Mar 2003 12:41:58 -0500 Message-ID: Thread-Topic: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Thread-Index: AcLn7yNSqtc8+ZFNQRmrRbhJKfU0fQAAKA7Q To: , , X-OriginalArrivalTime: 11 Mar 2003 17:41:59.0632 (UTC) FILETIME=[84883D00:01C2E7F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BHrvO17046 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > No it doesn't. Currently, FMIPv6 uses a global address for > pAR in only one way: > the MN sends FBU to pAR to set up the tunnel. But providing > security for this > has been a problem, and there is discussion in the MIP group > for the signaling > to go to the current AR (whether pAR or nAR is immaterial) to > set up the tunnel. > That way, SEND could be used to secure the signaling > (possibly with some > authorization token to the pAR, that is still under > discussion) between the MN > and AR, and the HI/HAck would be secured using the > interrouter security > association. > > With dycard, nAR needs pAR's address from the MN in order to > be able to send > PNE. Dycard establishes a dependency on the global IP address > of the router > being provided by the MN which may not be there in the end > for fast handover. > [Govind] Can't any of the dycard messages from the AR to the MN can carry the global IP address of the AR to the MN as the source address of the packet. This can be protected by an existing AR-MN SA if needed. > This is one reason why I think the CARD work needs to be > moved into the MIP > group (or, at least, the MN to AR part). Seamoby could end up > designing a > protocol that doesn't provide what FMIP needs. [Govind] I don't think this restriction is needed. I think CARD protocol can provide input for FMIP as well as other seamless handover protocols. It is a generic protocol and it should remain as one. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 13:45:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01472 for ; Tue, 11 Mar 2003 13:45:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BIxFY21749 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 13:59:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIxFO21746 for ; Tue, 11 Mar 2003 13:59:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01457 for ; Tue, 11 Mar 2003 13:45:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIx1O21724; Tue, 11 Mar 2003 13:59:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIu6O21604 for ; Tue, 11 Mar 2003 13:56:06 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01346 for ; Tue, 11 Mar 2003 13:42:00 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 13:44:09 -0500 Message-ID: <00b801c2e817$854e0590$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 13:45:23 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 18:44:09.0002 (UTC) FILETIME=[3368F0A0:01C2E7FE] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Suppose MN starts making up its own IP address too. > > jak [eunsoo] First, MN is allowed to send a report per handoff, that is, it is allowed only one report after it arrived to the nAR because there is only one pAR. Also MN should be authenticated to participate in the discovery process in Dycard. Let's say we assume MN can disguise itself with a new IP address. How often could MN do it going through binding expiration or revokation and reauthentication? It would be rarely possible for a MN to do DoS attack on Dycard that way. Eunsoo > > ----- Original Message ----- > From: > To: ; ; ; > ; > Sent: Tuesday, March 11, 2003 8:56 AM > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > Hi Jim, > > The nAR DOES NOT send PNE messages > > just because the MN reports pARs. Clearly if the MN does report more > > than one pAR then it is clearly a malicious MN and it can > > be filtered out. Also, all MNs are allowed to send dycard messages > > only after they have been authenticated by the network. > > We use a unique, third party verified identity for the MN and > > the number of entries that can be created per MN > > can be restricted. So if the limit for the MNs (set by the network) > > have been reached then there are no PNE messages exchanged for RI messages > sent > > by that particular MN. All subsequent messages from the MN are silently > discarded. Could you let me know where you see the DoS attack? > > > > Thanks, > > Govind. > > > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > (NRC/Boston); > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > I don't understand where there is anything in dycard > > > similar to the server > > > > of the server approach. > > > > The pAR is not a server where all the ARs in the domain > > > should communicate > > > > with. > > > > The nAR will send PNE to pAR only when its identity was > > > reported by a MN and > > > > the nAR does not have a record about the pAR. Once the nAR > > > recognize the pAR > > > > as one of its neighbors, the nAR does not have to send PNE > > > to the pAR even > > > > if lots of MNs report about the pAR. > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > with them? nAR must > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > even though the pAR > > > don't exist. > > > > > > > > > jak > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 13:45:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01493 for ; Tue, 11 Mar 2003 13:45:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIx1O21724; Tue, 11 Mar 2003 13:59:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIu6O21604 for ; Tue, 11 Mar 2003 13:56:06 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01346 for ; Tue, 11 Mar 2003 13:42:00 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 13:44:09 -0500 Message-ID: <00b801c2e817$854e0590$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 13:45:23 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 18:44:09.0002 (UTC) FILETIME=[3368F0A0:01C2E7FE] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Suppose MN starts making up its own IP address too. > > jak [eunsoo] First, MN is allowed to send a report per handoff, that is, it is allowed only one report after it arrived to the nAR because there is only one pAR. Also MN should be authenticated to participate in the discovery process in Dycard. Let's say we assume MN can disguise itself with a new IP address. How often could MN do it going through binding expiration or revokation and reauthentication? It would be rarely possible for a MN to do DoS attack on Dycard that way. Eunsoo > > ----- Original Message ----- > From: > To: ; ; ; > ; > Sent: Tuesday, March 11, 2003 8:56 AM > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > Hi Jim, > > The nAR DOES NOT send PNE messages > > just because the MN reports pARs. Clearly if the MN does report more > > than one pAR then it is clearly a malicious MN and it can > > be filtered out. Also, all MNs are allowed to send dycard messages > > only after they have been authenticated by the network. > > We use a unique, third party verified identity for the MN and > > the number of entries that can be created per MN > > can be restricted. So if the limit for the MNs (set by the network) > > have been reached then there are no PNE messages exchanged for RI messages > sent > > by that particular MN. All subsequent messages from the MN are silently > discarded. Could you let me know where you see the DoS attack? > > > > Thanks, > > Govind. > > > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > (NRC/Boston); > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > I don't understand where there is anything in dycard > > > similar to the server > > > > of the server approach. > > > > The pAR is not a server where all the ARs in the domain > > > should communicate > > > > with. > > > > The nAR will send PNE to pAR only when its identity was > > > reported by a MN and > > > > the nAR does not have a record about the pAR. Once the nAR > > > recognize the pAR > > > > as one of its neighbors, the nAR does not have to send PNE > > > to the pAR even > > > > if lots of MNs report about the pAR. > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > with them? nAR must > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > even though the pAR > > > don't exist. > > > > > > > > > jak > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 14:00:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02959 for ; Tue, 11 Mar 2003 14:00:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BJDq923333 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 14:13:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJDqO23330 for ; Tue, 11 Mar 2003 14:13:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02879 for ; Tue, 11 Mar 2003 13:59:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJD0O23281; Tue, 11 Mar 2003 14:13:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJA7O23166 for ; Tue, 11 Mar 2003 14:10:07 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02456 for ; Tue, 11 Mar 2003 13:56:00 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 13:58:08 -0500 Message-ID: <00c101c2e819$79ef5670$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <03c801c2e74d$1c2351d0$156015ac@T23KEMPF> <01b301c2e787$8f184990$e26b0f8a@eunsoo> <007301c2e7ee$e35d9930$156015ac@T23KEMPF> Subject: Re: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Tue, 11 Mar 2003 13:59:23 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 18:58:08.0968 (UTC) FILETIME=[28119480:01C2E800] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > [eunsoo] As I said in a previous email, authenticating MN is an important > > requirement for security in Dycard. The problem of the server approach is > > that authenticating MN does not help preventing MN from doing cache > > contamination. There is no way to prevent MN from causing cache > > contamination in the server approach as far as I understand. If I am missing > > something, please let me know. > > > > What is your definition of cache contamination? > [eunsoo] Hmm, strange. I have used the term in the same way as before. Anyway, I mean putting wrong entries (that is, entries for AR that are not CAR) in the cache (the CAR table). Even if an entry is for an AR that is within the domain and authentic, it is a wrong entry if it is not a candidate access router for the AR where the cache is located. > > >> [eunsoo] I think you were confused here. What MN needs eventually is L3 > > address (IP address) of pAR for fast handoff when it hands over to pAR. I > > don't understand how MN can send packets to pAR without knowing pAR's IP > > address unless the packets are for multicasting or broadcasting. > > > > No it doesn't. Currently, FMIPv6 uses a global address for pAR in only one way: > the MN sends FBU to pAR to set up the tunnel. But providing security for this > has been a problem, and there is discussion in the MIP group for the signaling > to go to the current AR (whether pAR or nAR is immaterial) to set up the tunnel. > That way, SEND could be used to secure the signaling (possibly with some > authorization token to the pAR, that is still under discussion) between the MN > and AR, and the HI/HAck would be secured using the interrouter security > association. > [eunsoo] Whether MN talks to nAR directly or pAR talks to nAR on behalf of MN does not make a difference in the requirement that MN needs IP address of nAR for fast handoff. That's the reason L2-L3 mapping became an issue which we are tackling with now. If pAR talks to nAR on behalf of MN, nAR needs to know IP address of pARand that information should come from somewhere. L2 address of nAR is usefuly only when L2-L3 mapping is possible and that's what CARD enables. > With dycard, nAR needs pAR's address from the MN in order to be able to send > PNE. Dycard establishes a dependency on the global IP address of the router > being provided by the MN which may not be there in the end for fast handover. > [eunsoo] I don't understand this. You don't need globally routable IP address of nAR (or something similar) for fast handoff? If not, how does pAR or MN talk to nAR? > This is one reason why I think the CARD work needs to be moved into the MIP > group (or, at least, the MN to AR part). Seamoby could end up designing a > protocol that doesn't provide what FMIP needs. > > [eunsoo] I think many people in the SeaMoby WG participate in the MIP WG or at least monitor the development there. Of course, folks in MIP WG can participate in our discussion any time. Also FMIPv6 is still evolving and thus we cannot wait until FMIPv6 is finalized. While we have the DT draft (version 01) and serious discussion going on, I don't think it is a good idea to think of moving the work to another WG. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 14:00:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03060 for ; Tue, 11 Mar 2003 14:00:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJD0O23281; Tue, 11 Mar 2003 14:13:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJA7O23166 for ; Tue, 11 Mar 2003 14:10:07 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02456 for ; Tue, 11 Mar 2003 13:56:00 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 13:58:08 -0500 Message-ID: <00c101c2e819$79ef5670$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <03c801c2e74d$1c2351d0$156015ac@T23KEMPF> <01b301c2e787$8f184990$e26b0f8a@eunsoo> <007301c2e7ee$e35d9930$156015ac@T23KEMPF> Subject: Re: DoS Attack and Information Gap in Dycard (was: Re: [Seamoby] Topic #1: Dos Attack) Date: Tue, 11 Mar 2003 13:59:23 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 18:58:08.0968 (UTC) FILETIME=[28119480:01C2E800] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > [eunsoo] As I said in a previous email, authenticating MN is an important > > requirement for security in Dycard. The problem of the server approach is > > that authenticating MN does not help preventing MN from doing cache > > contamination. There is no way to prevent MN from causing cache > > contamination in the server approach as far as I understand. If I am missing > > something, please let me know. > > > > What is your definition of cache contamination? > [eunsoo] Hmm, strange. I have used the term in the same way as before. Anyway, I mean putting wrong entries (that is, entries for AR that are not CAR) in the cache (the CAR table). Even if an entry is for an AR that is within the domain and authentic, it is a wrong entry if it is not a candidate access router for the AR where the cache is located. > > >> [eunsoo] I think you were confused here. What MN needs eventually is L3 > > address (IP address) of pAR for fast handoff when it hands over to pAR. I > > don't understand how MN can send packets to pAR without knowing pAR's IP > > address unless the packets are for multicasting or broadcasting. > > > > No it doesn't. Currently, FMIPv6 uses a global address for pAR in only one way: > the MN sends FBU to pAR to set up the tunnel. But providing security for this > has been a problem, and there is discussion in the MIP group for the signaling > to go to the current AR (whether pAR or nAR is immaterial) to set up the tunnel. > That way, SEND could be used to secure the signaling (possibly with some > authorization token to the pAR, that is still under discussion) between the MN > and AR, and the HI/HAck would be secured using the interrouter security > association. > [eunsoo] Whether MN talks to nAR directly or pAR talks to nAR on behalf of MN does not make a difference in the requirement that MN needs IP address of nAR for fast handoff. That's the reason L2-L3 mapping became an issue which we are tackling with now. If pAR talks to nAR on behalf of MN, nAR needs to know IP address of pARand that information should come from somewhere. L2 address of nAR is usefuly only when L2-L3 mapping is possible and that's what CARD enables. > With dycard, nAR needs pAR's address from the MN in order to be able to send > PNE. Dycard establishes a dependency on the global IP address of the router > being provided by the MN which may not be there in the end for fast handover. > [eunsoo] I don't understand this. You don't need globally routable IP address of nAR (or something similar) for fast handoff? If not, how does pAR or MN talk to nAR? > This is one reason why I think the CARD work needs to be moved into the MIP > group (or, at least, the MN to AR part). Seamoby could end up designing a > protocol that doesn't provide what FMIP needs. > > [eunsoo] I think many people in the SeaMoby WG participate in the MIP WG or at least monitor the development there. Of course, folks in MIP WG can participate in our discussion any time. Also FMIPv6 is still evolving and thus we cannot wait until FMIPv6 is finalized. While we have the DT draft (version 01) and serious discussion going on, I don't think it is a good idea to think of moving the work to another WG. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 14:18:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05225 for ; Tue, 11 Mar 2003 14:18:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BJVbO24423 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 14:31:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJVbO24420 for ; Tue, 11 Mar 2003 14:31:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05140 for ; Tue, 11 Mar 2003 14:17:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJVPO24400; Tue, 11 Mar 2003 14:31:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJQEO24105 for ; Tue, 11 Mar 2003 14:26:14 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04235 for ; Tue, 11 Mar 2003 14:12:07 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 14:14:16 -0500 Message-ID: <00f101c2e81b$ba561580$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Eunsoo Shim" , "James Kempf" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> <00b801c2e817$854e0590$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 14:15:30 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 19:14:16.0075 (UTC) FILETIME=[688265B0:01C2E802] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > Suppose MN starts making up its own IP address too. > > > > jak > > [eunsoo] First, MN is allowed to send a report per handoff, that is, it is > allowed only one report after it arrived to the nAR because there is only > one pAR. Also MN should be authenticated to participate in the discovery > process in Dycard. Let's say we assume MN can disguise itself with a new IP > address. How often could MN do it going through binding expiration or > revokation and reauthentication? It would be rarely possible for a MN to do > DoS attack on Dycard that way. > > Eunsoo > [eunsoo] The above statement is for MIPv4. If MIPv6 runs, AR does not get binding request from MN. In the case, we need to put limit on the number of reports from MN. Since we expect one report per handoff, we can put very strict limit such as 1 report per 10 seconds. I explained the difference between Dycard and the server approach in a previous email about this. Eunsoo > > > > > ----- Original Message ----- > > From: > > To: ; ; > ; > > ; > > Sent: Tuesday, March 11, 2003 8:56 AM > > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > > > Hi Jim, > > > The nAR DOES NOT send PNE messages > > > just because the MN reports pARs. Clearly if the MN does report more > > > than one pAR then it is clearly a malicious MN and it can > > > be filtered out. Also, all MNs are allowed to send dycard messages > > > only after they have been authenticated by the network. > > > We use a unique, third party verified identity for the MN and > > > the number of entries that can be created per MN > > > can be restricted. So if the limit for the MNs (set by the network) > > > have been reached then there are no PNE messages exchanged for RI > messages > > sent > > > by that particular MN. All subsequent messages from the MN are silently > > discarded. Could you let me know where you see the DoS attack? > > > > > > Thanks, > > > Govind. > > > > > > > -----Original Message----- > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > > (NRC/Boston); > > > > seamoby@ietf.org > > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > > > > I don't understand where there is anything in dycard > > > > similar to the server > > > > > of the server approach. > > > > > The pAR is not a server where all the ARs in the domain > > > > should communicate > > > > > with. > > > > > The nAR will send PNE to pAR only when its identity was > > > > reported by a MN and > > > > > the nAR does not have a record about the pAR. Once the nAR > > > > recognize the pAR > > > > > as one of its neighbors, the nAR does not have to send PNE > > > > to the pAR even > > > > > if lots of MNs report about the pAR. > > > > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > > with them? nAR must > > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > > even though the pAR > > > > don't exist. > > > > > > > > > > > > jak > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 14:18:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05245 for ; Tue, 11 Mar 2003 14:18:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJVPO24400; Tue, 11 Mar 2003 14:31:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJQEO24105 for ; Tue, 11 Mar 2003 14:26:14 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04235 for ; Tue, 11 Mar 2003 14:12:07 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 14:14:16 -0500 Message-ID: <00f101c2e81b$ba561580$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Eunsoo Shim" , "James Kempf" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> <00b801c2e817$854e0590$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 14:15:30 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 19:14:16.0075 (UTC) FILETIME=[688265B0:01C2E802] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > Suppose MN starts making up its own IP address too. > > > > jak > > [eunsoo] First, MN is allowed to send a report per handoff, that is, it is > allowed only one report after it arrived to the nAR because there is only > one pAR. Also MN should be authenticated to participate in the discovery > process in Dycard. Let's say we assume MN can disguise itself with a new IP > address. How often could MN do it going through binding expiration or > revokation and reauthentication? It would be rarely possible for a MN to do > DoS attack on Dycard that way. > > Eunsoo > [eunsoo] The above statement is for MIPv4. If MIPv6 runs, AR does not get binding request from MN. In the case, we need to put limit on the number of reports from MN. Since we expect one report per handoff, we can put very strict limit such as 1 report per 10 seconds. I explained the difference between Dycard and the server approach in a previous email about this. Eunsoo > > > > > ----- Original Message ----- > > From: > > To: ; ; > ; > > ; > > Sent: Tuesday, March 11, 2003 8:56 AM > > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > > > Hi Jim, > > > The nAR DOES NOT send PNE messages > > > just because the MN reports pARs. Clearly if the MN does report more > > > than one pAR then it is clearly a malicious MN and it can > > > be filtered out. Also, all MNs are allowed to send dycard messages > > > only after they have been authenticated by the network. > > > We use a unique, third party verified identity for the MN and > > > the number of entries that can be created per MN > > > can be restricted. So if the limit for the MNs (set by the network) > > > have been reached then there are no PNE messages exchanged for RI > messages > > sent > > > by that particular MN. All subsequent messages from the MN are silently > > discarded. Could you let me know where you see the DoS attack? > > > > > > Thanks, > > > Govind. > > > > > > > -----Original Message----- > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > > (NRC/Boston); > > > > seamoby@ietf.org > > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > > > > I don't understand where there is anything in dycard > > > > similar to the server > > > > > of the server approach. > > > > > The pAR is not a server where all the ARs in the domain > > > > should communicate > > > > > with. > > > > > The nAR will send PNE to pAR only when its identity was > > > > reported by a MN and > > > > > the nAR does not have a record about the pAR. Once the nAR > > > > recognize the pAR > > > > > as one of its neighbors, the nAR does not have to send PNE > > > > to the pAR even > > > > > if lots of MNs report about the pAR. > > > > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > > with them? nAR must > > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > > even though the pAR > > > > don't exist. > > > > > > > > > > > > jak > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 14:54:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07993 for ; Tue, 11 Mar 2003 14:54:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BK7oL28301 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 15:07:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BK7oO28298 for ; Tue, 11 Mar 2003 15:07:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07973 for ; Tue, 11 Mar 2003 14:53:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BK1CO27193; Tue, 11 Mar 2003 15:01:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJwRO27031 for ; Tue, 11 Mar 2003 14:58:27 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07463 for ; Tue, 11 Mar 2003 14:44:19 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 14:46:28 -0500 Message-ID: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: Subject: [SeaMoby] Topic #2:Do we need a server for CARD Date: Tue, 11 Mar 2003 14:47:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 19:46:28.0579 (UTC) FILETIME=[E85F1B30:01C2E806] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Currently a series of discussion about DoS attack is going on about CARD. Also we had lots of discussion about possible problems about the server approach. But I'd like to raise a more fundamental question about the server approach taken in the DT draft. Dycard shows that CARD is possible without introducing any server which causes concerns about reliability and scalability. Then why do we need the server at all? Or why do we have to introduce the server for CARD? I look forward to hearing the necessity of introducing the server before how the server approach can or cannot defend certain threats or resolve certain issues. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 14:54:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08006 for ; Tue, 11 Mar 2003 14:54:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BK1CO27193; Tue, 11 Mar 2003 15:01:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJwRO27031 for ; Tue, 11 Mar 2003 14:58:27 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07463 for ; Tue, 11 Mar 2003 14:44:19 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 14:46:28 -0500 Message-ID: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: Subject: [SeaMoby] Topic #2:Do we need a server for CARD Date: Tue, 11 Mar 2003 14:47:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 19:46:28.0579 (UTC) FILETIME=[E85F1B30:01C2E806] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Currently a series of discussion about DoS attack is going on about CARD. Also we had lots of discussion about possible problems about the server approach. But I'd like to raise a more fundamental question about the server approach taken in the DT draft. Dycard shows that CARD is possible without introducing any server which causes concerns about reliability and scalability. Then why do we need the server at all? Or why do we have to introduce the server for CARD? I look forward to hearing the necessity of introducing the server before how the server approach can or cannot defend certain threats or resolve certain issues. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 15:00:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08255 for ; Tue, 11 Mar 2003 15:00:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BKE5R28629 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 15:14:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKE5O28626 for ; Tue, 11 Mar 2003 15:14:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08205 for ; Tue, 11 Mar 2003 14:59:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKDpO28610; Tue, 11 Mar 2003 15:13:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKB3O28434 for ; Tue, 11 Mar 2003 15:11:03 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08074 for ; Tue, 11 Mar 2003 14:56:54 -0500 (EST) Message-ID: <028e01c2e808$73e539e0$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> <00b801c2e817$854e0590$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 11:57:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eunsoo, Now, that's not fair. You and Govind are claiming a DoS attack on the DT draft because the MN can make up its address. It can do that with Dycard too. Whether the server is involved or not is immaterial. A stream of packets bombarding the router will tie up the router regardless. What is to prevent a random MN from making up IP addresses and sending Dycard messages to the AR? The router needs to check the authentication, but that doesn't happen until the packet is at the router, and meantime, the router is tied up in authentication checking. My point is that CARD (regardless of the approach) needs to specify rate limiting for the MN to AR messages, and that the AR can selectively drop packets so that it can limit such an attack. jak > > Suppose MN starts making up its own IP address too. > > > > jak > > [eunsoo] First, MN is allowed to send a report per handoff, that is, it is > allowed only one report after it arrived to the nAR because there is only > one pAR. Also MN should be authenticated to participate in the discovery > process in Dycard. Let's say we assume MN can disguise itself with a new IP > address. How often could MN do it going through binding expiration or > revokation and reauthentication? It would be rarely possible for a MN to do > DoS attack on Dycard that way. > > Eunsoo > > > > > > ----- Original Message ----- > > From: > > To: ; ; > ; > > ; > > Sent: Tuesday, March 11, 2003 8:56 AM > > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > > > Hi Jim, > > > The nAR DOES NOT send PNE messages > > > just because the MN reports pARs. Clearly if the MN does report more > > > than one pAR then it is clearly a malicious MN and it can > > > be filtered out. Also, all MNs are allowed to send dycard messages > > > only after they have been authenticated by the network. > > > We use a unique, third party verified identity for the MN and > > > the number of entries that can be created per MN > > > can be restricted. So if the limit for the MNs (set by the network) > > > have been reached then there are no PNE messages exchanged for RI > messages > > sent > > > by that particular MN. All subsequent messages from the MN are silently > > discarded. Could you let me know where you see the DoS attack? > > > > > > Thanks, > > > Govind. > > > > > > > -----Original Message----- > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > > (NRC/Boston); > > > > seamoby@ietf.org > > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > > > > I don't understand where there is anything in dycard > > > > similar to the server > > > > > of the server approach. > > > > > The pAR is not a server where all the ARs in the domain > > > > should communicate > > > > > with. > > > > > The nAR will send PNE to pAR only when its identity was > > > > reported by a MN and > > > > > the nAR does not have a record about the pAR. Once the nAR > > > > recognize the pAR > > > > > as one of its neighbors, the nAR does not have to send PNE > > > > to the pAR even > > > > > if lots of MNs report about the pAR. > > > > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > > with them? nAR must > > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > > even though the pAR > > > > don't exist. > > > > > > > > > > > > jak > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 15:00:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08273 for ; Tue, 11 Mar 2003 15:00:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKDpO28610; Tue, 11 Mar 2003 15:13:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKB3O28434 for ; Tue, 11 Mar 2003 15:11:03 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08074 for ; Tue, 11 Mar 2003 14:56:54 -0500 (EST) Message-ID: <028e01c2e808$73e539e0$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> <00b801c2e817$854e0590$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 11:57:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eunsoo, Now, that's not fair. You and Govind are claiming a DoS attack on the DT draft because the MN can make up its address. It can do that with Dycard too. Whether the server is involved or not is immaterial. A stream of packets bombarding the router will tie up the router regardless. What is to prevent a random MN from making up IP addresses and sending Dycard messages to the AR? The router needs to check the authentication, but that doesn't happen until the packet is at the router, and meantime, the router is tied up in authentication checking. My point is that CARD (regardless of the approach) needs to specify rate limiting for the MN to AR messages, and that the AR can selectively drop packets so that it can limit such an attack. jak > > Suppose MN starts making up its own IP address too. > > > > jak > > [eunsoo] First, MN is allowed to send a report per handoff, that is, it is > allowed only one report after it arrived to the nAR because there is only > one pAR. Also MN should be authenticated to participate in the discovery > process in Dycard. Let's say we assume MN can disguise itself with a new IP > address. How often could MN do it going through binding expiration or > revokation and reauthentication? It would be rarely possible for a MN to do > DoS attack on Dycard that way. > > Eunsoo > > > > > > ----- Original Message ----- > > From: > > To: ; ; > ; > > ; > > Sent: Tuesday, March 11, 2003 8:56 AM > > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > > > Hi Jim, > > > The nAR DOES NOT send PNE messages > > > just because the MN reports pARs. Clearly if the MN does report more > > > than one pAR then it is clearly a malicious MN and it can > > > be filtered out. Also, all MNs are allowed to send dycard messages > > > only after they have been authenticated by the network. > > > We use a unique, third party verified identity for the MN and > > > the number of entries that can be created per MN > > > can be restricted. So if the limit for the MNs (set by the network) > > > have been reached then there are no PNE messages exchanged for RI > messages > > sent > > > by that particular MN. All subsequent messages from the MN are silently > > discarded. Could you let me know where you see the DoS attack? > > > > > > Thanks, > > > Govind. > > > > > > > -----Original Message----- > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > > (NRC/Boston); > > > > seamoby@ietf.org > > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > > > > I don't understand where there is anything in dycard > > > > similar to the server > > > > > of the server approach. > > > > > The pAR is not a server where all the ARs in the domain > > > > should communicate > > > > > with. > > > > > The nAR will send PNE to pAR only when its identity was > > > > reported by a MN and > > > > > the nAR does not have a record about the pAR. Once the nAR > > > > recognize the pAR > > > > > as one of its neighbors, the nAR does not have to send PNE > > > > to the pAR even > > > > > if lots of MNs report about the pAR. > > > > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > > with them? nAR must > > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > > even though the pAR > > > > don't exist. > > > > > > > > > > > > jak > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 15:04:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08526 for ; Tue, 11 Mar 2003 15:04:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BKHx528801 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 15:17:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKHxO28796 for ; Tue, 11 Mar 2003 15:17:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08452 for ; Tue, 11 Mar 2003 15:03:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKHmO28783; Tue, 11 Mar 2003 15:17:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKEEO28642 for ; Tue, 11 Mar 2003 15:14:14 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08242 for ; Tue, 11 Mar 2003 15:00:05 -0500 (EST) Message-ID: <02b001c2e808$e5ef1ab0$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> <00b801c2e817$854e0590$e26b0f8a@eunsoo> <00f101c2e81b$ba561580$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 12:00:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok. I think the protocol needs a limit in any event. In MIPv4, the MN could as well bombard the FA. jak ----- Original Message ----- From: "Eunsoo Shim" To: "Eunsoo Shim" ; "James Kempf" ; ; ; ; Sent: Tuesday, March 11, 2003 2:15 PM Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > Suppose MN starts making up its own IP address too. > > > > > > jak > > > > [eunsoo] First, MN is allowed to send a report per handoff, that is, it is > > allowed only one report after it arrived to the nAR because there is only > > one pAR. Also MN should be authenticated to participate in the discovery > > process in Dycard. Let's say we assume MN can disguise itself with a new > IP > > address. How often could MN do it going through binding expiration or > > revokation and reauthentication? It would be rarely possible for a MN to > do > > DoS attack on Dycard that way. > > > > Eunsoo > > > [eunsoo] The above statement is for MIPv4. If MIPv6 runs, AR does not get > binding request from MN. In the case, we need to put limit on the number of > reports from MN. Since we expect one report per handoff, we can put very > strict limit such as 1 report per 10 seconds. I explained the difference > between Dycard and the server approach in a previous email about this. > > Eunsoo > > > > > > > > > ----- Original Message ----- > > > From: > > > To: ; ; > > ; > > > ; > > > Sent: Tuesday, March 11, 2003 8:56 AM > > > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > Hi Jim, > > > > The nAR DOES NOT send PNE messages > > > > just because the MN reports pARs. Clearly if the MN does report more > > > > than one pAR then it is clearly a malicious MN and it can > > > > be filtered out. Also, all MNs are allowed to send dycard messages > > > > only after they have been authenticated by the network. > > > > We use a unique, third party verified identity for the MN and > > > > the number of entries that can be created per MN > > > > can be restricted. So if the limit for the MNs (set by the network) > > > > have been reached then there are no PNE messages exchanged for RI > > messages > > > sent > > > > by that particular MN. All subsequent messages from the MN are > silently > > > discarded. Could you let me know where you see the DoS attack? > > > > > > > > Thanks, > > > > Govind. > > > > > > > > > -----Original Message----- > > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > > > (NRC/Boston); > > > > > seamoby@ietf.org > > > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > > > > > > > I don't understand where there is anything in dycard > > > > > similar to the server > > > > > > of the server approach. > > > > > > The pAR is not a server where all the ARs in the domain > > > > > should communicate > > > > > > with. > > > > > > The nAR will send PNE to pAR only when its identity was > > > > > reported by a MN and > > > > > > the nAR does not have a record about the pAR. Once the nAR > > > > > recognize the pAR > > > > > > as one of its neighbors, the nAR does not have to send PNE > > > > > to the pAR even > > > > > > if lots of MNs report about the pAR. > > > > > > > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > > > with them? nAR must > > > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > > > even though the pAR > > > > > don't exist. > > > > > > > > > > > > > > > jak > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 15:04:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08562 for ; Tue, 11 Mar 2003 15:04:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKHmO28783; Tue, 11 Mar 2003 15:17:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKEEO28642 for ; Tue, 11 Mar 2003 15:14:14 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08242 for ; Tue, 11 Mar 2003 15:00:05 -0500 (EST) Message-ID: <02b001c2e808$e5ef1ab0$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> <00b801c2e817$854e0590$e26b0f8a@eunsoo> <00f101c2e81b$ba561580$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 12:00:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok. I think the protocol needs a limit in any event. In MIPv4, the MN could as well bombard the FA. jak ----- Original Message ----- From: "Eunsoo Shim" To: "Eunsoo Shim" ; "James Kempf" ; ; ; ; Sent: Tuesday, March 11, 2003 2:15 PM Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > Suppose MN starts making up its own IP address too. > > > > > > jak > > > > [eunsoo] First, MN is allowed to send a report per handoff, that is, it is > > allowed only one report after it arrived to the nAR because there is only > > one pAR. Also MN should be authenticated to participate in the discovery > > process in Dycard. Let's say we assume MN can disguise itself with a new > IP > > address. How often could MN do it going through binding expiration or > > revokation and reauthentication? It would be rarely possible for a MN to > do > > DoS attack on Dycard that way. > > > > Eunsoo > > > [eunsoo] The above statement is for MIPv4. If MIPv6 runs, AR does not get > binding request from MN. In the case, we need to put limit on the number of > reports from MN. Since we expect one report per handoff, we can put very > strict limit such as 1 report per 10 seconds. I explained the difference > between Dycard and the server approach in a previous email about this. > > Eunsoo > > > > > > > > > ----- Original Message ----- > > > From: > > > To: ; ; > > ; > > > ; > > > Sent: Tuesday, March 11, 2003 8:56 AM > > > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > Hi Jim, > > > > The nAR DOES NOT send PNE messages > > > > just because the MN reports pARs. Clearly if the MN does report more > > > > than one pAR then it is clearly a malicious MN and it can > > > > be filtered out. Also, all MNs are allowed to send dycard messages > > > > only after they have been authenticated by the network. > > > > We use a unique, third party verified identity for the MN and > > > > the number of entries that can be created per MN > > > > can be restricted. So if the limit for the MNs (set by the network) > > > > have been reached then there are no PNE messages exchanged for RI > > messages > > > sent > > > > by that particular MN. All subsequent messages from the MN are > silently > > > discarded. Could you let me know where you see the DoS attack? > > > > > > > > Thanks, > > > > Govind. > > > > > > > > > -----Original Message----- > > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > > > (NRC/Boston); > > > > > seamoby@ietf.org > > > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > > > > > > > I don't understand where there is anything in dycard > > > > > similar to the server > > > > > > of the server approach. > > > > > > The pAR is not a server where all the ARs in the domain > > > > > should communicate > > > > > > with. > > > > > > The nAR will send PNE to pAR only when its identity was > > > > > reported by a MN and > > > > > > the nAR does not have a record about the pAR. Once the nAR > > > > > recognize the pAR > > > > > > as one of its neighbors, the nAR does not have to send PNE > > > > > to the pAR even > > > > > > if lots of MNs report about the pAR. > > > > > > > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > > > with them? nAR must > > > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > > > even though the pAR > > > > > don't exist. > > > > > > > > > > > > > > > jak > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 15:40:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11270 for ; Tue, 11 Mar 2003 15:40:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BKrxp31006 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 15:53:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKrxO31003 for ; Tue, 11 Mar 2003 15:53:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11246 for ; Tue, 11 Mar 2003 15:39:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKoKO30861; Tue, 11 Mar 2003 15:50:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKliO30750 for ; Tue, 11 Mar 2003 15:47:44 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11085 for ; Tue, 11 Mar 2003 15:33:37 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 15:35:44 -0500 Message-ID: <015f01c2e827$1bc948e0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> <00b801c2e817$854e0590$e26b0f8a@eunsoo> <028e01c2e808$73e539e0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 15:36:58 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 20:35:44.0327 (UTC) FILETIME=[CA227570:01C2E80D] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Eunsoo, > > Now, that's not fair. You and Govind are claiming a DoS attack on the DT draft > because the MN can make up its address. It can do that with Dycard too. Whether > the server is involved or not is immaterial. A stream of packets bombarding the > router will tie up the router regardless. > [eunsoo] I did say that we could not prevent MN from sending lots of messages to AR. It is the same for any kind of signaling protocol. The question is how the AR can handle them and what's the impact on AR. The difference between Dycard and the server approach is that the impact stops at the receiving AR for Dycard and the impact goes up to the central server and thus the whole network is affected in the server approach. > What is to prevent a random MN from making up IP addresses and sending Dycard > messages to the AR? The router needs to check the authentication, but that > doesn't happen until the packet is at the router, and meantime, the router is > tied up in authentication checking. > [eunsoo] Sure. What I was talking about was that there would be no overwhelming messages from nAR to pAR because of lots of reports from MN in Dycard. All the attacking traffic is filtered out by the receiving AR. > My point is that CARD (regardless of the approach) needs to specify rate > limiting for the MN to AR messages, and that the AR can selectively drop packets > so that it can limit such an attack. > [eunsoo] In Dycard, it is necessary for MIPv6. Binding history check-up can replace such rate limiting for MIPv4 in Dycard. In the server approach, it is always necessary. Eunsoo > jak > > > > Suppose MN starts making up its own IP address too. > > > > > > jak > > > > [eunsoo] First, MN is allowed to send a report per handoff, that is, it is > > allowed only one report after it arrived to the nAR because there is only > > one pAR. Also MN should be authenticated to participate in the discovery > > process in Dycard. Let's say we assume MN can disguise itself with a new IP > > address. How often could MN do it going through binding expiration or > > revokation and reauthentication? It would be rarely possible for a MN to do > > DoS attack on Dycard that way. > > > > Eunsoo > > > > > > > > > > ----- Original Message ----- > > > From: > > > To: ; ; > > ; > > > ; > > > Sent: Tuesday, March 11, 2003 8:56 AM > > > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > Hi Jim, > > > > The nAR DOES NOT send PNE messages > > > > just because the MN reports pARs. Clearly if the MN does report more > > > > than one pAR then it is clearly a malicious MN and it can > > > > be filtered out. Also, all MNs are allowed to send dycard messages > > > > only after they have been authenticated by the network. > > > > We use a unique, third party verified identity for the MN and > > > > the number of entries that can be created per MN > > > > can be restricted. So if the limit for the MNs (set by the network) > > > > have been reached then there are no PNE messages exchanged for RI > > messages > > > sent > > > > by that particular MN. All subsequent messages from the MN are silently > > > discarded. Could you let me know where you see the DoS attack? > > > > > > > > Thanks, > > > > Govind. > > > > > > > > > -----Original Message----- > > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > > > (NRC/Boston); > > > > > seamoby@ietf.org > > > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > > > > > > > I don't understand where there is anything in dycard > > > > > similar to the server > > > > > > of the server approach. > > > > > > The pAR is not a server where all the ARs in the domain > > > > > should communicate > > > > > > with. > > > > > > The nAR will send PNE to pAR only when its identity was > > > > > reported by a MN and > > > > > > the nAR does not have a record about the pAR. Once the nAR > > > > > recognize the pAR > > > > > > as one of its neighbors, the nAR does not have to send PNE > > > > > to the pAR even > > > > > > if lots of MNs report about the pAR. > > > > > > > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > > > with them? nAR must > > > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > > > even though the pAR > > > > > don't exist. > > > > > > > > > > > > > > > jak > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 15:40:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11289 for ; Tue, 11 Mar 2003 15:40:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKoKO30861; Tue, 11 Mar 2003 15:50:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKliO30750 for ; Tue, 11 Mar 2003 15:47:44 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11085 for ; Tue, 11 Mar 2003 15:33:37 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 15:35:44 -0500 Message-ID: <015f01c2e827$1bc948e0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , , References: <015101c2e7f3$c0f05400$156015ac@T23KEMPF> <00b801c2e817$854e0590$e26b0f8a@eunsoo> <028e01c2e808$73e539e0$156015ac@T23KEMPF> Subject: Re: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 15:36:58 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 11 Mar 2003 20:35:44.0327 (UTC) FILETIME=[CA227570:01C2E80D] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Eunsoo, > > Now, that's not fair. You and Govind are claiming a DoS attack on the DT draft > because the MN can make up its address. It can do that with Dycard too. Whether > the server is involved or not is immaterial. A stream of packets bombarding the > router will tie up the router regardless. > [eunsoo] I did say that we could not prevent MN from sending lots of messages to AR. It is the same for any kind of signaling protocol. The question is how the AR can handle them and what's the impact on AR. The difference between Dycard and the server approach is that the impact stops at the receiving AR for Dycard and the impact goes up to the central server and thus the whole network is affected in the server approach. > What is to prevent a random MN from making up IP addresses and sending Dycard > messages to the AR? The router needs to check the authentication, but that > doesn't happen until the packet is at the router, and meantime, the router is > tied up in authentication checking. > [eunsoo] Sure. What I was talking about was that there would be no overwhelming messages from nAR to pAR because of lots of reports from MN in Dycard. All the attacking traffic is filtered out by the receiving AR. > My point is that CARD (regardless of the approach) needs to specify rate > limiting for the MN to AR messages, and that the AR can selectively drop packets > so that it can limit such an attack. > [eunsoo] In Dycard, it is necessary for MIPv6. Binding history check-up can replace such rate limiting for MIPv4 in Dycard. In the server approach, it is always necessary. Eunsoo > jak > > > > Suppose MN starts making up its own IP address too. > > > > > > jak > > > > [eunsoo] First, MN is allowed to send a report per handoff, that is, it is > > allowed only one report after it arrived to the nAR because there is only > > one pAR. Also MN should be authenticated to participate in the discovery > > process in Dycard. Let's say we assume MN can disguise itself with a new IP > > address. How often could MN do it going through binding expiration or > > revokation and reauthentication? It would be rarely possible for a MN to do > > DoS attack on Dycard that way. > > > > Eunsoo > > > > > > > > > > ----- Original Message ----- > > > From: > > > To: ; ; > > ; > > > ; > > > Sent: Tuesday, March 11, 2003 8:56 AM > > > Subject: RE: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > Hi Jim, > > > > The nAR DOES NOT send PNE messages > > > > just because the MN reports pARs. Clearly if the MN does report more > > > > than one pAR then it is clearly a malicious MN and it can > > > > be filtered out. Also, all MNs are allowed to send dycard messages > > > > only after they have been authenticated by the network. > > > > We use a unique, third party verified identity for the MN and > > > > the number of entries that can be created per MN > > > > can be restricted. So if the limit for the MNs (set by the network) > > > > have been reached then there are no PNE messages exchanged for RI > > messages > > > sent > > > > by that particular MN. All subsequent messages from the MN are silently > > > discarded. Could you let me know where you see the DoS attack? > > > > > > > > Thanks, > > > > Govind. > > > > > > > > > -----Original Message----- > > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: Tuesday, March 11, 2003 11:36 AM > > > > > To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant > > > > > (NRC/Boston); > > > > > seamoby@ietf.org > > > > > Subject: Re: [Seamoby] Topic #1: Dos Attack > > > > > > > > > > > > > > > > I don't understand where there is anything in dycard > > > > > similar to the server > > > > > > of the server approach. > > > > > > The pAR is not a server where all the ARs in the domain > > > > > should communicate > > > > > > with. > > > > > > The nAR will send PNE to pAR only when its identity was > > > > > reported by a MN and > > > > > > the nAR does not have a record about the pAR. Once the nAR > > > > > recognize the pAR > > > > > > as one of its neighbors, the nAR does not have to send PNE > > > > > to the pAR even > > > > > > if lots of MNs report about the pAR. > > > > > > > > > > > > > > > > Suppose MN starts making up pAR addresses and bombarding nAR > > > > > with them? nAR must > > > > > send PNE messages to resolve, causing a DoS attack on nAR, > > > > > even though the pAR > > > > > don't exist. > > > > > > > > > > > > > > > jak > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 15:57:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11957 for ; Tue, 11 Mar 2003 15:57:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BLBZH32712 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 16:11:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BLBZO32709 for ; Tue, 11 Mar 2003 16:11:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11899 for ; Tue, 11 Mar 2003 15:57:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BL80O32544; Tue, 11 Mar 2003 16:08:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BL5JO31718 for ; Tue, 11 Mar 2003 16:05:19 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11711 for ; Tue, 11 Mar 2003 15:51:11 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BKrLa05541 for ; Tue, 11 Mar 2003 14:53:21 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 14:53:18 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 14:53:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 15:53:16 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLoCLFFYu3t+/EwStuycbxdFa7T4gAANEkA To: , , , , X-OriginalArrivalTime: 11 Mar 2003 20:53:17.0123 (UTC) FILETIME=[3DA66130:01C2E810] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BL5JO31719 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, > > Eunsoo, > > Now, that's not fair. You and Govind are claiming a DoS > attack on the DT draft > because the MN can make up its address. [Govind] I can't speak for Eunsoo, but since my name is mentioned here, I will respond. You have got my intention wrong here. It can do that with > Dycard too. [Govind] I did not say that dycard is inherently immune to such DoS attacks and we don't need to take care of it. I never said that MNs cannot send in a slew of packets to the AR. I also agreed that processing load is a concern anywhere. I just pointed out that we have considered these attacks and are taking (and have taken) steps to minimize the effect of these attacks. Whether > the server is involved or not is immaterial. A stream of > packets bombarding the > router will tie up the router regardless. [Govind] I don't think anyone prevent this, the best we can do is silently discard packets at the AR. > > What is to prevent a random MN from making up IP addresses > and sending Dycard > messages to the AR? The router needs to check the > authentication, but that > doesn't happen until the packet is at the router, and > meantime, the router is > tied up in authentication checking. [Govind] Noone can prevent the MN from doing that. However, the protocol can control what the router does on receiving the packets. Spoofing IP addresses by MNs may not be too difficult to handle for dycard as there are additional checks. But I'll think about this. Ofcourse, there is processing needed to make these checks before silently discarding the packets. > > My point is that CARD (regardless of the approach) needs to > specify rate > limiting for the MN to AR messages, and that the AR can > selectively drop packets > so that it can limit such an attack. [Govind] I have no disagreement about this. Rate limiting is needed in both approaches. The very fact that we say that dycard handles this in some way is accepting the fact that this is to be handled. The only point that is not clear to me, is that once a MN does send multiple RI messages it is clearly a malicious MN, and you can silently discard the packets from this MN after uniquely identifying this MN. Hopefully, with the inbuilt checks dycard will be able to identify such MNs. However, a MN that supplies multiple APid messages is not necessarily a malicious MN. One cannot have control on how many APids spring up in an AR's neighborhood that are not in the same domain. Rate-limiting without taking this into consideration may not be the right approach, IMO. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 15:58:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11971 for ; Tue, 11 Mar 2003 15:58:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BL80O32544; Tue, 11 Mar 2003 16:08:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BL5JO31718 for ; Tue, 11 Mar 2003 16:05:19 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11711 for ; Tue, 11 Mar 2003 15:51:11 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BKrLa05541 for ; Tue, 11 Mar 2003 14:53:21 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 14:53:18 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 14:53:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Topic #1: Dos Attack Date: Tue, 11 Mar 2003 15:53:16 -0500 Message-ID: Thread-Topic: [Seamoby] Topic #1: Dos Attack Thread-Index: AcLoCLFFYu3t+/EwStuycbxdFa7T4gAANEkA To: , , , , X-OriginalArrivalTime: 11 Mar 2003 20:53:17.0123 (UTC) FILETIME=[3DA66130:01C2E810] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BL5JO31719 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, > > Eunsoo, > > Now, that's not fair. You and Govind are claiming a DoS > attack on the DT draft > because the MN can make up its address. [Govind] I can't speak for Eunsoo, but since my name is mentioned here, I will respond. You have got my intention wrong here. It can do that with > Dycard too. [Govind] I did not say that dycard is inherently immune to such DoS attacks and we don't need to take care of it. I never said that MNs cannot send in a slew of packets to the AR. I also agreed that processing load is a concern anywhere. I just pointed out that we have considered these attacks and are taking (and have taken) steps to minimize the effect of these attacks. Whether > the server is involved or not is immaterial. A stream of > packets bombarding the > router will tie up the router regardless. [Govind] I don't think anyone prevent this, the best we can do is silently discard packets at the AR. > > What is to prevent a random MN from making up IP addresses > and sending Dycard > messages to the AR? The router needs to check the > authentication, but that > doesn't happen until the packet is at the router, and > meantime, the router is > tied up in authentication checking. [Govind] Noone can prevent the MN from doing that. However, the protocol can control what the router does on receiving the packets. Spoofing IP addresses by MNs may not be too difficult to handle for dycard as there are additional checks. But I'll think about this. Ofcourse, there is processing needed to make these checks before silently discarding the packets. > > My point is that CARD (regardless of the approach) needs to > specify rate > limiting for the MN to AR messages, and that the AR can > selectively drop packets > so that it can limit such an attack. [Govind] I have no disagreement about this. Rate limiting is needed in both approaches. The very fact that we say that dycard handles this in some way is accepting the fact that this is to be handled. The only point that is not clear to me, is that once a MN does send multiple RI messages it is clearly a malicious MN, and you can silently discard the packets from this MN after uniquely identifying this MN. Hopefully, with the inbuilt checks dycard will be able to identify such MNs. However, a MN that supplies multiple APid messages is not necessarily a malicious MN. One cannot have control on how many APids spring up in an AR's neighborhood that are not in the same domain. Rate-limiting without taking this into consideration may not be the right approach, IMO. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 17:49:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16029 for ; Tue, 11 Mar 2003 17:49:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BN3Kk08589 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 18:03:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN3KO08586 for ; Tue, 11 Mar 2003 18:03:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16002 for ; Tue, 11 Mar 2003 17:49:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN36O08463; Tue, 11 Mar 2003 18:03:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMqiO08073 for ; Tue, 11 Mar 2003 17:52:45 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15764 for ; Tue, 11 Mar 2003 17:38:34 -0500 (EST) Message-ID: <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Tue, 11 Mar 2003 14:39:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Why are these approaches mutually exclusive? One of the drawbacks of Dycard is that it needs a learning period. Naturally, the ISP can hire somebody to walk around and seed the cache, but that's expensive. A server could prime the cache in the router with a collection of AP/AR mappings that may not be geographically adjacent, but over time the ones that aren't would drop out. Thus, the ISP would not have to go through the timeconsuming task of classifying whether they APs are geographically adjacent. After the server has been used to initially populate the cache, any changes would be propagated directly by CARD. jak ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Tuesday, March 11, 2003 2:47 PM Subject: [SeaMoby] Topic #2:Do we need a server for CARD > Hi, > > Currently a series of discussion about DoS attack is going on about CARD. > Also we had lots of discussion about possible problems about the server > approach. > > But I'd like to raise a more fundamental question about the server approach > taken in the DT draft. > Dycard shows that CARD is possible without introducing any server which > causes concerns about reliability and scalability. > Then why do we need the server at all? Or why do we have to introduce the > server for CARD? > I look forward to hearing the necessity of introducing the server before how > the server approach can or cannot defend certain threats or resolve certain > issues. > Regards, > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 17:49:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16047 for ; Tue, 11 Mar 2003 17:49:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN36O08463; Tue, 11 Mar 2003 18:03:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMqiO08073 for ; Tue, 11 Mar 2003 17:52:45 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15764 for ; Tue, 11 Mar 2003 17:38:34 -0500 (EST) Message-ID: <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Tue, 11 Mar 2003 14:39:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Why are these approaches mutually exclusive? One of the drawbacks of Dycard is that it needs a learning period. Naturally, the ISP can hire somebody to walk around and seed the cache, but that's expensive. A server could prime the cache in the router with a collection of AP/AR mappings that may not be geographically adjacent, but over time the ones that aren't would drop out. Thus, the ISP would not have to go through the timeconsuming task of classifying whether they APs are geographically adjacent. After the server has been used to initially populate the cache, any changes would be propagated directly by CARD. jak ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Tuesday, March 11, 2003 2:47 PM Subject: [SeaMoby] Topic #2:Do we need a server for CARD > Hi, > > Currently a series of discussion about DoS attack is going on about CARD. > Also we had lots of discussion about possible problems about the server > approach. > > But I'd like to raise a more fundamental question about the server approach > taken in the DT draft. > Dycard shows that CARD is possible without introducing any server which > causes concerns about reliability and scalability. > Then why do we need the server at all? Or why do we have to introduce the > server for CARD? > I look forward to hearing the necessity of introducing the server before how > the server approach can or cannot defend certain threats or resolve certain > issues. > Regards, > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 18:45:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19111 for ; Tue, 11 Mar 2003 18:45:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BNxKf12607 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 18:59:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNxKO12604 for ; Tue, 11 Mar 2003 18:59:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19094 for ; Tue, 11 Mar 2003 18:45:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNx0O12543; Tue, 11 Mar 2003 18:59:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNpMO12253 for ; Tue, 11 Mar 2003 18:51:22 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18831 for ; Tue, 11 Mar 2003 18:37:10 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BNdI805571 for ; Tue, 11 Mar 2003 17:39:18 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 17:39:18 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 17:39:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Tue, 11 Mar 2003 18:39:16 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoIMBPXDE7Mt/KSk6shybMfstktQAAnkaw To: , , X-OriginalArrivalTime: 11 Mar 2003 23:39:17.0969 (UTC) FILETIME=[6EC6DC10:01C2E827] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BNpNO12254 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, > > Why are these approaches mutually exclusive? [Govind] As I pointed out in my first email, I don't think they are mutually exclusive. One approach works with just a cache, second with a cache and server. > > One of the drawbacks of Dycard is that it needs a learning > period. [Govind] dycard, as is in the 01 draft now, needs one handover between ARs. I would rather put it that way than open ended as "learning period". In a real life scenario, this handover will happen quite soon. In the future, if there are pico-cellular environments I would guess it may be more frequent. Note, until a handover happens you don't need to know about the other AR. Once a handover happens you will know about the other AR in dycard. The correct choice of lifetimes of cache entries should be able to take care of the rest. >Naturally, > the ISP can hire somebody to walk around and seed the cache, > but that's > expensive. [Govind] I don't think the ISP really needs to do it. I don't think the loss of ability to provide one seamless handover between ARs is a big deal in the long run. Plus, as the DT draft points out, it does not guarantee that the request made to a server will get back in time for the MN anyways. Even in the DT scheme, any non cache answered case is not guaranteed. dycard has a way to make the first handover seamless in a probabilistic sense also, but in all honestly I don't think that one handover is that big of a deal, compared to putting up a server. >A server could prime the cache in the router with > a collection of > AP/AR mappings that may not be geographically adjacent, but > over time the ones > that aren't would drop out. [Govind] Well this causes an increase in traffic between ARs that are not GAARs (using a defunct term) which I think is more problematic than loosing one handover. I'm not saying that in dycard you cannot have incorrect entries in the cache. This is an issue that both the protocols need to address in detail. But dycard handles this quite similarly. The other issue is how easy it is to get these entries into the AR's cache in either scheme. This is something that probably needs some more thought. >Thus, the ISP would not have to > go through the > timeconsuming task of classifying whether they APs are > geographically adjacent. [Govind] I don't know what you are implying by this statement. But if you are stating that ISPs need to do this in dycard, then it is incorrect. If you are talking about the scope-id approach which would need some classification, I agree. > > After the server has been used to initially populate the > cache, any changes > would be propagated directly by CARD. [Govind] I don't think we need a server initially to propagate the cache. I think handovers between ARs, that will happen anyways, can be used to maintain the cache. We have done some study in this scenario and in the steady state the chances of a cache miss is quite low, even with incorporating some of the security schemes to prevent contamination of cache. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 18:45:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19129 for ; Tue, 11 Mar 2003 18:45:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNx0O12543; Tue, 11 Mar 2003 18:59:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNpMO12253 for ; Tue, 11 Mar 2003 18:51:22 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18831 for ; Tue, 11 Mar 2003 18:37:10 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BNdI805571 for ; Tue, 11 Mar 2003 17:39:18 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 17:39:18 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 17:39:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Tue, 11 Mar 2003 18:39:16 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoIMBPXDE7Mt/KSk6shybMfstktQAAnkaw To: , , X-OriginalArrivalTime: 11 Mar 2003 23:39:17.0969 (UTC) FILETIME=[6EC6DC10:01C2E827] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BNpNO12254 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, > > Why are these approaches mutually exclusive? [Govind] As I pointed out in my first email, I don't think they are mutually exclusive. One approach works with just a cache, second with a cache and server. > > One of the drawbacks of Dycard is that it needs a learning > period. [Govind] dycard, as is in the 01 draft now, needs one handover between ARs. I would rather put it that way than open ended as "learning period". In a real life scenario, this handover will happen quite soon. In the future, if there are pico-cellular environments I would guess it may be more frequent. Note, until a handover happens you don't need to know about the other AR. Once a handover happens you will know about the other AR in dycard. The correct choice of lifetimes of cache entries should be able to take care of the rest. >Naturally, > the ISP can hire somebody to walk around and seed the cache, > but that's > expensive. [Govind] I don't think the ISP really needs to do it. I don't think the loss of ability to provide one seamless handover between ARs is a big deal in the long run. Plus, as the DT draft points out, it does not guarantee that the request made to a server will get back in time for the MN anyways. Even in the DT scheme, any non cache answered case is not guaranteed. dycard has a way to make the first handover seamless in a probabilistic sense also, but in all honestly I don't think that one handover is that big of a deal, compared to putting up a server. >A server could prime the cache in the router with > a collection of > AP/AR mappings that may not be geographically adjacent, but > over time the ones > that aren't would drop out. [Govind] Well this causes an increase in traffic between ARs that are not GAARs (using a defunct term) which I think is more problematic than loosing one handover. I'm not saying that in dycard you cannot have incorrect entries in the cache. This is an issue that both the protocols need to address in detail. But dycard handles this quite similarly. The other issue is how easy it is to get these entries into the AR's cache in either scheme. This is something that probably needs some more thought. >Thus, the ISP would not have to > go through the > timeconsuming task of classifying whether they APs are > geographically adjacent. [Govind] I don't know what you are implying by this statement. But if you are stating that ISPs need to do this in dycard, then it is incorrect. If you are talking about the scope-id approach which would need some classification, I agree. > > After the server has been used to initially populate the > cache, any changes > would be propagated directly by CARD. [Govind] I don't think we need a server initially to propagate the cache. I think handovers between ARs, that will happen anyways, can be used to maintain the cache. We have done some study in this scenario and in the steady state the chances of a cache miss is quite low, even with incorporating some of the security schemes to prevent contamination of cache. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 11 18:58:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19512 for ; Tue, 11 Mar 2003 18:58:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C0CLx14036 for seamoby-archive@odin.ietf.org; Tue, 11 Mar 2003 19:12:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0CLO14033 for ; Tue, 11 Mar 2003 19:12:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19502 for ; Tue, 11 Mar 2003 18:58:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0C9O14022; Tue, 11 Mar 2003 19:12:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0BCO13959 for ; Tue, 11 Mar 2003 19:11:12 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19465 for ; Tue, 11 Mar 2003 18:56:59 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2BNx82w003638 for ; Tue, 11 Mar 2003 16:59:08 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA25959 for ; Tue, 11 Mar 2003 16:59:08 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Mar 2003 17:59:07 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE47@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Tue, 11 Mar 2003 17:59:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ks_c_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, March 11, 2003 5:39 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi James, > > Why are these approaches mutually exclusive? [Govind] As I pointed out in my first email, I don't think they are mutually exclusive. One approach works with just a cache, second with a cache and server. > > One of the drawbacks of Dycard is that it needs a learning > period. [Govind] dycard, as is in the 01 draft now, needs one handover between ARs. I would rather put it that way than open ended as "learning period". In a real life scenario, this handover will happen quite soon. In the future, if there are pico-cellular environments I would guess it may be more frequent. Note, until a handover happens you don't need to know about the other AR. Once a handover happens you will know about the other AR in dycard. The correct choice of lifetimes of cache entries should be able to take care of the rest. >Naturally, > the ISP can hire somebody to walk around and seed the cache, > but that's > expensive. [Govind] I don't think the ISP really needs to do it. I don't think the loss of ability to provide one seamless handover between ARs is a big deal in the long run. AJOY-> The cache is not permanent so whenever there is loss of cached information, dycard will not be able to support fast handoff. Plus, as the DT draft points out, it does not guarantee that the request made to a server will get back in time for the MN anyways. Even in the DT scheme, any non cache answered case is not guaranteed. dycard has a way to make the first handover seamless in a probabilistic sense also, but in all honestly I don't think that one handover is that big of a deal, compared to putting up a server. AJOY->This is not correct and should be removed from design team draft. Whenever there is sufficient overlap between coverage area of adjacent ARs, server based approach should not have any problem. >A server could prime the cache in the router with > a collection of > AP/AR mappings that may not be geographically adjacent, but > over time the ones > that aren't would drop out. [Govind] Well this causes an increase in traffic between ARs that are not GAARs (using a defunct term) which I think is more problematic than loosing one handover. I'm not saying that in dycard you cannot have incorrect entries in the cache. This is an issue that both the protocols need to address in detail. But dycard handles this quite similarly. The other issue is how easy it is to get these entries into the AR's cache in either scheme. This is something that probably needs some more thought. >Thus, the ISP would not have to > go through the > timeconsuming task of classifying whether they APs are > geographically adjacent. [Govind] I don't know what you are implying by this statement. But if you are stating that ISPs need to do this in dycard, then it is incorrect. If you are talking about the scope-id approach which would need some classification, I agree. > > After the server has been used to initially populate the > cache, any changes > would be propagated directly by CARD. [Govind] I don't think we need a server initially to propagate the cache. I think handovers between ARs, that will happen anyways, can be used to maintain the cache. We have done some study in this scenario and in the steady state the chances of a cache miss is quite low, even with incorporating some of the security schemes to prevent contamination of cache. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 11 18:59:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19533 for ; Tue, 11 Mar 2003 18:59:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0C9O14022; Tue, 11 Mar 2003 19:12:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0BCO13959 for ; Tue, 11 Mar 2003 19:11:12 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19465 for ; Tue, 11 Mar 2003 18:56:59 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2BNx82w003638 for ; Tue, 11 Mar 2003 16:59:08 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA25959 for ; Tue, 11 Mar 2003 16:59:08 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Mar 2003 17:59:07 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE47@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Tue, 11 Mar 2003 17:59:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ks_c_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, March 11, 2003 5:39 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi James, > > Why are these approaches mutually exclusive? [Govind] As I pointed out in my first email, I don't think they are mutually exclusive. One approach works with just a cache, second with a cache and server. > > One of the drawbacks of Dycard is that it needs a learning > period. [Govind] dycard, as is in the 01 draft now, needs one handover between ARs. I would rather put it that way than open ended as "learning period". In a real life scenario, this handover will happen quite soon. In the future, if there are pico-cellular environments I would guess it may be more frequent. Note, until a handover happens you don't need to know about the other AR. Once a handover happens you will know about the other AR in dycard. The correct choice of lifetimes of cache entries should be able to take care of the rest. >Naturally, > the ISP can hire somebody to walk around and seed the cache, > but that's > expensive. [Govind] I don't think the ISP really needs to do it. I don't think the loss of ability to provide one seamless handover between ARs is a big deal in the long run. AJOY-> The cache is not permanent so whenever there is loss of cached information, dycard will not be able to support fast handoff. Plus, as the DT draft points out, it does not guarantee that the request made to a server will get back in time for the MN anyways. Even in the DT scheme, any non cache answered case is not guaranteed. dycard has a way to make the first handover seamless in a probabilistic sense also, but in all honestly I don't think that one handover is that big of a deal, compared to putting up a server. AJOY->This is not correct and should be removed from design team draft. Whenever there is sufficient overlap between coverage area of adjacent ARs, server based approach should not have any problem. >A server could prime the cache in the router with > a collection of > AP/AR mappings that may not be geographically adjacent, but > over time the ones > that aren't would drop out. [Govind] Well this causes an increase in traffic between ARs that are not GAARs (using a defunct term) which I think is more problematic than loosing one handover. I'm not saying that in dycard you cannot have incorrect entries in the cache. This is an issue that both the protocols need to address in detail. But dycard handles this quite similarly. The other issue is how easy it is to get these entries into the AR's cache in either scheme. This is something that probably needs some more thought. >Thus, the ISP would not have to > go through the > timeconsuming task of classifying whether they APs are > geographically adjacent. [Govind] I don't know what you are implying by this statement. But if you are stating that ISPs need to do this in dycard, then it is incorrect. If you are talking about the scope-id approach which would need some classification, I agree. > > After the server has been used to initially populate the > cache, any changes > would be propagated directly by CARD. [Govind] I don't think we need a server initially to propagate the cache. I think handovers between ARs, that will happen anyways, can be used to maintain the cache. We have done some study in this scenario and in the steady state the chances of a cache miss is quite low, even with incorporating some of the security schemes to prevent contamination of cache. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 05:56:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29062 for ; Wed, 12 Mar 2003 05:56:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CBAiU02876 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 06:10:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBAiO02873 for ; Wed, 12 Mar 2003 06:10:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29052 for ; Wed, 12 Mar 2003 05:56:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBASO02852; Wed, 12 Mar 2003 06:10:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CB9tO02790 for ; Wed, 12 Mar 2003 06:09:55 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28974 for ; Wed, 12 Mar 2003 05:55:29 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h2CAvTv90600; Wed, 12 Mar 2003 11:57:30 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4F6469317D; Wed, 12 Mar 2003 11:58:53 +0100 (CET) Message-ID: <3E6F1344.4080005@ccrle.nec.de> Date: Wed, 12 Mar 2003 12:00:20 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Govind.Krishnamurthi@nokia.com Cc: kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD References: Content-Type: text/plain; charset=x-windows-949 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Govind and all, please see inline for comments. Regards, marco Govind.Krishnamurthi@nokia.com wrote: >Hi James, > > >>Why are these approaches mutually exclusive? >> >> > >[Govind] As I pointed out in my first email, I don't think they are mutually exclusive. >One approach works with just a cache, second with a cache and server. > Not sure about this. If we think about functional entities for CARD, the server function is one, but for dycard, in addition the actual CAR discovery, a further functional entity is on the mobile terminal performing similar functions as the server function in the DT draft, isn't it? This is to keep caches updated in ARs, same as the server function does. The only difference is that the additional dycard function is not based on a request-response approach, but on a push approach, and this with much more expensive link-costs between ARs and the push function. What do you think? > > >>One of the drawbacks of Dycard is that it needs a learning >>period. >> >> > >[Govind] dycard, as is in the 01 draft now, needs one handover between ARs. > I would rather put it that way than open ended as "learning period". In a real life scenario, > this handover will happen quite soon. In the future, if there are pico-cellular environments >I would guess it may be more frequent. Note, until a handover happens you don't need >to know about the other AR. Once a handover happens you will know about the other AR in dycard. >The correct choice of lifetimes of cache entries should be able to take care of the rest. > > > >>Naturally, >>the ISP can hire somebody to walk around and seed the cache, >>but that's >>expensive. >> >> >[Govind] I don't think the ISP really needs to do it. I don't think the loss of >ability to provide one seamless handover between ARs is a big deal in the >long run. Plus, as the DT draft points out, it does not guarantee that the >request made to a server will get back in time for the MN anyways. >Even in the DT scheme, any non cache answered case is not guaranteed. >dycard has a way to make the first handover seamless in a probabilistic >sense also, but in all honestly I don't think that one handover is that big of a deal, >compared to putting up a server. > > I don't think that the server function approach has a large impact on handover timing issues, since I do not expect that a mobile tries to learn about CARs when already losing connection to its current AR. Worst case is that a current AR has no entry for a particular requested CAR in its cache. This means that the current AR retrieves address info of this CAR from the server function, possibly together with static capabilities. For further requests, the current AR just contacts the CAR directly to request dynamic capabilities directly withour contacting the server anymore until the cache etry is about to expire. Now, we could evaluate and compare probability of CARD failure due to a small delay (server function access) and an immediately breaking connection, and a failure due to a missing entry in the current AR's cache in dycard. I don't expect results that degrade the server function based approach. Now, a stronger argument for the server function here is to not rely on mobiles to fill ARs' caches, always making use of radio bandwidth to update caches. If cache updating in dycard should achieve same efficiency as the server based approach, static capabilities are to be transmitted over the air as well, isn't it? Not sure if this is really a good solution. > > >>A server could prime the cache in the router with >>a collection of >>AP/AR mappings that may not be geographically adjacent, but >>over time the ones >>that aren't would drop out. >> >> >[Govind] Well this causes an increase in traffic between ARs that are >not GAARs (using a defunct term) which I think is more problematic >than loosing one handover. I'm not saying that in dycard you cannot have >incorrect entries in the cache. This is an issue that both the protocols >need to address in detail. But dycard handles this quite similarly. The other >issue is how easy it is to get these entries into the AR's cache in either scheme. >This is something that probably needs some more thought. > > Here, I guess, the server function could support ARs learning capability about wrong or right cache entries when using the scope-ID approach, as briefly referred to in the DT draft. Either ARs process scope-IDs or the server could already do, which reduces superfluous traffic in the network. Since feeding caches in dycard is mobile controlled, malicious mobiles could update caches regularly and maintain wrong information in caches, isn't it? marco > > >>Thus, the ISP would not have to >>go through the >>timeconsuming task of classifying whether they APs are >>geographically adjacent. >> >> > >[Govind] I don't know what you are implying by this statement. But >if you are stating that ISPs need to do this in dycard, then it is incorrect. >If you are talking about the scope-id approach which would need some >classification, I agree. > > > >>After the server has been used to initially populate the >>cache, any changes >>would be propagated directly by CARD. >> >> > >[Govind] I don't think we need a server initially to propagate the cache. I think handovers >between ARs, that will happen anyways, can be used to maintain the cache. We have >done some study in this scenario and in the steady state the chances of a cache miss is >quite low, even with incorporating some of the security schemes to prevent contamination >of cache. > >-Govind. >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > -- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 05:57:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29075 for ; Wed, 12 Mar 2003 05:57:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBASO02852; Wed, 12 Mar 2003 06:10:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CB9tO02790 for ; Wed, 12 Mar 2003 06:09:55 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28974 for ; Wed, 12 Mar 2003 05:55:29 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h2CAvTv90600; Wed, 12 Mar 2003 11:57:30 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4F6469317D; Wed, 12 Mar 2003 11:58:53 +0100 (CET) Message-ID: <3E6F1344.4080005@ccrle.nec.de> Date: Wed, 12 Mar 2003 12:00:20 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Govind.Krishnamurthi@nokia.com Cc: kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD References: Content-Type: text/plain; charset=x-windows-949 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Govind and all, please see inline for comments. Regards, marco Govind.Krishnamurthi@nokia.com wrote: >Hi James, > > >>Why are these approaches mutually exclusive? >> >> > >[Govind] As I pointed out in my first email, I don't think they are mutually exclusive. >One approach works with just a cache, second with a cache and server. > Not sure about this. If we think about functional entities for CARD, the server function is one, but for dycard, in addition the actual CAR discovery, a further functional entity is on the mobile terminal performing similar functions as the server function in the DT draft, isn't it? This is to keep caches updated in ARs, same as the server function does. The only difference is that the additional dycard function is not based on a request-response approach, but on a push approach, and this with much more expensive link-costs between ARs and the push function. What do you think? > > >>One of the drawbacks of Dycard is that it needs a learning >>period. >> >> > >[Govind] dycard, as is in the 01 draft now, needs one handover between ARs. > I would rather put it that way than open ended as "learning period". In a real life scenario, > this handover will happen quite soon. In the future, if there are pico-cellular environments >I would guess it may be more frequent. Note, until a handover happens you don't need >to know about the other AR. Once a handover happens you will know about the other AR in dycard. >The correct choice of lifetimes of cache entries should be able to take care of the rest. > > > >>Naturally, >>the ISP can hire somebody to walk around and seed the cache, >>but that's >>expensive. >> >> >[Govind] I don't think the ISP really needs to do it. I don't think the loss of >ability to provide one seamless handover between ARs is a big deal in the >long run. Plus, as the DT draft points out, it does not guarantee that the >request made to a server will get back in time for the MN anyways. >Even in the DT scheme, any non cache answered case is not guaranteed. >dycard has a way to make the first handover seamless in a probabilistic >sense also, but in all honestly I don't think that one handover is that big of a deal, >compared to putting up a server. > > I don't think that the server function approach has a large impact on handover timing issues, since I do not expect that a mobile tries to learn about CARs when already losing connection to its current AR. Worst case is that a current AR has no entry for a particular requested CAR in its cache. This means that the current AR retrieves address info of this CAR from the server function, possibly together with static capabilities. For further requests, the current AR just contacts the CAR directly to request dynamic capabilities directly withour contacting the server anymore until the cache etry is about to expire. Now, we could evaluate and compare probability of CARD failure due to a small delay (server function access) and an immediately breaking connection, and a failure due to a missing entry in the current AR's cache in dycard. I don't expect results that degrade the server function based approach. Now, a stronger argument for the server function here is to not rely on mobiles to fill ARs' caches, always making use of radio bandwidth to update caches. If cache updating in dycard should achieve same efficiency as the server based approach, static capabilities are to be transmitted over the air as well, isn't it? Not sure if this is really a good solution. > > >>A server could prime the cache in the router with >>a collection of >>AP/AR mappings that may not be geographically adjacent, but >>over time the ones >>that aren't would drop out. >> >> >[Govind] Well this causes an increase in traffic between ARs that are >not GAARs (using a defunct term) which I think is more problematic >than loosing one handover. I'm not saying that in dycard you cannot have >incorrect entries in the cache. This is an issue that both the protocols >need to address in detail. But dycard handles this quite similarly. The other >issue is how easy it is to get these entries into the AR's cache in either scheme. >This is something that probably needs some more thought. > > Here, I guess, the server function could support ARs learning capability about wrong or right cache entries when using the scope-ID approach, as briefly referred to in the DT draft. Either ARs process scope-IDs or the server could already do, which reduces superfluous traffic in the network. Since feeding caches in dycard is mobile controlled, malicious mobiles could update caches regularly and maintain wrong information in caches, isn't it? marco > > >>Thus, the ISP would not have to >>go through the >>timeconsuming task of classifying whether they APs are >>geographically adjacent. >> >> > >[Govind] I don't know what you are implying by this statement. But >if you are stating that ISPs need to do this in dycard, then it is incorrect. >If you are talking about the scope-id approach which would need some >classification, I agree. > > > >>After the server has been used to initially populate the >>cache, any changes >>would be propagated directly by CARD. >> >> > >[Govind] I don't think we need a server initially to propagate the cache. I think handovers >between ARs, that will happen anyways, can be used to maintain the cache. We have >done some study in this scenario and in the steady state the chances of a cache miss is >quite low, even with incorporating some of the security schemes to prevent contamination >of cache. > >-Govind. >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > -- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 08:37:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03102 for ; Wed, 12 Mar 2003 08:37:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CDpU012802 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 08:51:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDpUO12799 for ; Wed, 12 Mar 2003 08:51:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03079 for ; Wed, 12 Mar 2003 08:37:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDpHO12777; Wed, 12 Mar 2003 08:51:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDoWO12752 for ; Wed, 12 Mar 2003 08:50:32 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03067 for ; Wed, 12 Mar 2003 08:36:02 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CDcB810523 for ; Wed, 12 Mar 2003 07:38:11 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 07:38:11 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 05:37:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 08:37:14 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoKjft49oafLgJRrmKcIjxzzvg/wAcX3Ww To: , , , X-OriginalArrivalTime: 12 Mar 2003 13:37:16.0089 (UTC) FILETIME=[7EDF2290:01C2E89C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CDoXO12753 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > AJOY-> The cache is not permanent so whenever there is > loss of cached information, dycard will not be able to support > fast handoff. > [Govind] I agree that cache entries have a lifetime. I think handovers are enough to update these entries. Handovers will happen in real life. > Plus, as the DT draft points out, it does not guarantee that the > request made to a server will get back in time for the MN anyways. > Even in the DT scheme, any non cache answered case is not guaranteed. > dycard has a way to make the first handover seamless in a > probabilistic > sense also, but in all honestly I don't think that one > handover is that big of a deal, > compared to putting up a server. > > AJOY->This is not correct and should be removed from design > team draft. Whenever > there is sufficient overlap between coverage area of adjacent > ARs, server based > approach should not have any problem. [Govind] Writing up a spec that is constrained on the assumptions on the physical layer scenario is not the correct approach IMO. But, lets leave this at that. I think you say it can be guaranteed most of the time, while I don't think so. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 08:37:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03119 for ; Wed, 12 Mar 2003 08:37:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDpHO12777; Wed, 12 Mar 2003 08:51:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDoWO12752 for ; Wed, 12 Mar 2003 08:50:32 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03067 for ; Wed, 12 Mar 2003 08:36:02 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CDcB810523 for ; Wed, 12 Mar 2003 07:38:11 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 07:38:11 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 05:37:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 08:37:14 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoKjft49oafLgJRrmKcIjxzzvg/wAcX3Ww To: , , , X-OriginalArrivalTime: 12 Mar 2003 13:37:16.0089 (UTC) FILETIME=[7EDF2290:01C2E89C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CDoXO12753 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > AJOY-> The cache is not permanent so whenever there is > loss of cached information, dycard will not be able to support > fast handoff. > [Govind] I agree that cache entries have a lifetime. I think handovers are enough to update these entries. Handovers will happen in real life. > Plus, as the DT draft points out, it does not guarantee that the > request made to a server will get back in time for the MN anyways. > Even in the DT scheme, any non cache answered case is not guaranteed. > dycard has a way to make the first handover seamless in a > probabilistic > sense also, but in all honestly I don't think that one > handover is that big of a deal, > compared to putting up a server. > > AJOY->This is not correct and should be removed from design > team draft. Whenever > there is sufficient overlap between coverage area of adjacent > ARs, server based > approach should not have any problem. [Govind] Writing up a spec that is constrained on the assumptions on the physical layer scenario is not the correct approach IMO. But, lets leave this at that. I think you say it can be guaranteed most of the time, while I don't think so. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 09:53:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04972 for ; Wed, 12 Mar 2003 09:53:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CF7ZQ17905 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 10:07:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CF7ZO17902 for ; Wed, 12 Mar 2003 10:07:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04965 for ; Wed, 12 Mar 2003 09:53:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CF7LO17560; Wed, 12 Mar 2003 10:07:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CF6cO17091 for ; Wed, 12 Mar 2003 10:06:38 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04945 for ; Wed, 12 Mar 2003 09:52:06 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CEsD828465 for ; Wed, 12 Mar 2003 08:54:13 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 08:54:12 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 06:54:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 09:54:10 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoIMBim+pcMOXcRA+Ywq91FmqLngAhbNPA To: , , X-OriginalArrivalTime: 12 Mar 2003 14:54:12.0337 (UTC) FILETIME=[3E5EAE10:01C2E8A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CF6cO17092 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, you are not seriously suggesting a "can you hear me now" guy as being required for Dycard, are you? As pointed out often enough, it is the very first handoff that is used to populate the cache, that's it. The drawback of that has also clearly pointed out, namely having the first handoff a hard one. Nobody ever denied that, on the contrary we explicitly asked the question whether or not the removal of this "drawback" is worth establishing a server. Coming now with "expensive walk around hiring" scenarios that are "time consuming" for ISPs (you exactly have to wait at each AR until ONE handoff happened) seems to me rather a nice anecdote than a technical argument. Thanks, Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Tuesday, March 11, 2003 5:39 PM >To: Eunsoo Shim; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >Why are these approaches mutually exclusive? > >One of the drawbacks of Dycard is that it needs a learning >period. Naturally, >the ISP can hire somebody to walk around and seed the cache, but that's >expensive. A server could prime the cache in the router with a >collection of >AP/AR mappings that may not be geographically adjacent, but >over time the ones >that aren't would drop out. Thus, the ISP would not have to go >through the >timeconsuming task of classifying whether they APs are >geographically adjacent. > >After the server has been used to initially populate the >cache, any changes >would be propagated directly by CARD. > > jak > >----- Original Message ----- >From: "Eunsoo Shim" >To: >Sent: Tuesday, March 11, 2003 2:47 PM >Subject: [SeaMoby] Topic #2:Do we need a server for CARD > > >> Hi, >> >> Currently a series of discussion about DoS attack is going >on about CARD. >> Also we had lots of discussion about possible problems about >the server >> approach. >> >> But I'd like to raise a more fundamental question about the >server approach >> taken in the DT draft. >> Dycard shows that CARD is possible without introducing any >server which >> causes concerns about reliability and scalability. >> Then why do we need the server at all? Or why do we have to >introduce the >> server for CARD? >> I look forward to hearing the necessity of introducing the >server before how >> the server approach can or cannot defend certain threats or >resolve certain >> issues. >> Regards, >> >> Eunsoo >> >> _______________________________________________ >> Seamoby mailing list >> Seamoby@ietf.org >> https://www1.ietf.org/mailman/listinfo/seamoby >> > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 09:53:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04985 for ; Wed, 12 Mar 2003 09:53:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CF7LO17560; Wed, 12 Mar 2003 10:07:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CF6cO17091 for ; Wed, 12 Mar 2003 10:06:38 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04945 for ; Wed, 12 Mar 2003 09:52:06 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CEsD828465 for ; Wed, 12 Mar 2003 08:54:13 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 08:54:12 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 06:54:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 09:54:10 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoIMBim+pcMOXcRA+Ywq91FmqLngAhbNPA To: , , X-OriginalArrivalTime: 12 Mar 2003 14:54:12.0337 (UTC) FILETIME=[3E5EAE10:01C2E8A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CF6cO17092 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, you are not seriously suggesting a "can you hear me now" guy as being required for Dycard, are you? As pointed out often enough, it is the very first handoff that is used to populate the cache, that's it. The drawback of that has also clearly pointed out, namely having the first handoff a hard one. Nobody ever denied that, on the contrary we explicitly asked the question whether or not the removal of this "drawback" is worth establishing a server. Coming now with "expensive walk around hiring" scenarios that are "time consuming" for ISPs (you exactly have to wait at each AR until ONE handoff happened) seems to me rather a nice anecdote than a technical argument. Thanks, Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Tuesday, March 11, 2003 5:39 PM >To: Eunsoo Shim; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >Why are these approaches mutually exclusive? > >One of the drawbacks of Dycard is that it needs a learning >period. Naturally, >the ISP can hire somebody to walk around and seed the cache, but that's >expensive. A server could prime the cache in the router with a >collection of >AP/AR mappings that may not be geographically adjacent, but >over time the ones >that aren't would drop out. Thus, the ISP would not have to go >through the >timeconsuming task of classifying whether they APs are >geographically adjacent. > >After the server has been used to initially populate the >cache, any changes >would be propagated directly by CARD. > > jak > >----- Original Message ----- >From: "Eunsoo Shim" >To: >Sent: Tuesday, March 11, 2003 2:47 PM >Subject: [SeaMoby] Topic #2:Do we need a server for CARD > > >> Hi, >> >> Currently a series of discussion about DoS attack is going >on about CARD. >> Also we had lots of discussion about possible problems about >the server >> approach. >> >> But I'd like to raise a more fundamental question about the >server approach >> taken in the DT draft. >> Dycard shows that CARD is possible without introducing any >server which >> causes concerns about reliability and scalability. >> Then why do we need the server at all? Or why do we have to >introduce the >> server for CARD? >> I look forward to hearing the necessity of introducing the >server before how >> the server approach can or cannot defend certain threats or >resolve certain >> issues. >> Regards, >> >> Eunsoo >> >> _______________________________________________ >> Seamoby mailing list >> Seamoby@ietf.org >> https://www1.ietf.org/mailman/listinfo/seamoby >> > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 10:03:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05266 for ; Wed, 12 Mar 2003 10:03:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CFHGm18407 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 10:17:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFHFO18404 for ; Wed, 12 Mar 2003 10:17:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05233 for ; Wed, 12 Mar 2003 10:02:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFH3O18373; Wed, 12 Mar 2003 10:17:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFF7O18276 for ; Wed, 12 Mar 2003 10:15:07 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05168 for ; Wed, 12 Mar 2003 10:00:20 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CF29801315 for ; Wed, 12 Mar 2003 09:02:25 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 09:02:09 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 09:02:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:02:07 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoKr7jgnXyNJFQQeWTOOdFTiK5BAAfJ88w To: , , , , X-OriginalArrivalTime: 12 Mar 2003 15:02:09.0225 (UTC) FILETIME=[5A9E0390:01C2E8A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CFF8O18277 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy, > Plus, as the DT draft points out, it does not guarantee that the >request made to a server will get back in time for the MN anyways. >Even in the DT scheme, any non cache answered case is not guaranteed. >dycard has a way to make the first handover seamless in a >probabilistic >sense also, but in all honestly I don't think that one >handover is that big of a deal, >compared to putting up a server. > >AJOY->This is not correct and should be removed from design >team draft. Whenever >there is sufficient overlap between coverage area of adjacent >ARs, server based >approach should not have any problem. Unfortunately, it is still rather subjective what "sufficient" overlap means in order to "not have any problems". It highly depends on your notion of "sufficient overlap", the mobility pattern of the mobile involved and the topology of your system, i.e., the experienced delay for L2-L3 requests. We need simulations and best current practices demonstrating how to set up the system properly for certain environments. These evaluations could also reveal how to prevent situations (if they are preventable) in which the probability of a seamless first handoff is actually damn close to zero (i.e., identifying pathological situations). It all boils down to the fact that it is unclear right now how the claimed P(failure of timely delivery of answer)=1 with "proper configuration" is actually achieved in the server approach. Until then, P(.) less than one is a valid assumption until proven otherwise, and the question remains whether or not it is worth going through the whole server thing for this. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 10:03:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05309 for ; Wed, 12 Mar 2003 10:03:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFH3O18373; Wed, 12 Mar 2003 10:17:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFF7O18276 for ; Wed, 12 Mar 2003 10:15:07 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05168 for ; Wed, 12 Mar 2003 10:00:20 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CF29801315 for ; Wed, 12 Mar 2003 09:02:25 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 09:02:09 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 09:02:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:02:07 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoKr7jgnXyNJFQQeWTOOdFTiK5BAAfJ88w To: , , , , X-OriginalArrivalTime: 12 Mar 2003 15:02:09.0225 (UTC) FILETIME=[5A9E0390:01C2E8A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CFF8O18277 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy, > Plus, as the DT draft points out, it does not guarantee that the >request made to a server will get back in time for the MN anyways. >Even in the DT scheme, any non cache answered case is not guaranteed. >dycard has a way to make the first handover seamless in a >probabilistic >sense also, but in all honestly I don't think that one >handover is that big of a deal, >compared to putting up a server. > >AJOY->This is not correct and should be removed from design >team draft. Whenever >there is sufficient overlap between coverage area of adjacent >ARs, server based >approach should not have any problem. Unfortunately, it is still rather subjective what "sufficient" overlap means in order to "not have any problems". It highly depends on your notion of "sufficient overlap", the mobility pattern of the mobile involved and the topology of your system, i.e., the experienced delay for L2-L3 requests. We need simulations and best current practices demonstrating how to set up the system properly for certain environments. These evaluations could also reveal how to prevent situations (if they are preventable) in which the probability of a seamless first handoff is actually damn close to zero (i.e., identifying pathological situations). It all boils down to the fact that it is unclear right now how the claimed P(failure of timely delivery of answer)=1 with "proper configuration" is actually achieved in the server approach. Until then, P(.) less than one is a valid assumption until proven otherwise, and the question remains whether or not it is worth going through the whole server thing for this. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 10:11:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06439 for ; Wed, 12 Mar 2003 10:11:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFPAO18871; Wed, 12 Mar 2003 10:25:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFOAO18799 for ; Wed, 12 Mar 2003 10:24:10 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06197 for ; Wed, 12 Mar 2003 10:09:40 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CFBl803832 for ; Wed, 12 Mar 2003 09:11:47 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 09:11:46 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 09:11:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:11:24 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLohlLtzcqneTspStuPLkBnemzxLgAIkmxA To: , Cc: , , X-OriginalArrivalTime: 12 Mar 2003 15:11:25.0013 (UTC) FILETIME=[A5E48850:01C2E8A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CFOAO18800 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marco, >>[Govind] I don't think the ISP really needs to do it. I don't >think the loss of >>ability to provide one seamless handover between ARs is a big >deal in the >>long run. Plus, as the DT draft points out, it does not >guarantee that the >>request made to a server will get back in time for the MN anyways. >>Even in the DT scheme, any non cache answered case is not guaranteed. >>dycard has a way to make the first handover seamless in a >probabilistic >>sense also, but in all honestly I don't think that one >handover is that big of a deal, >>compared to putting up a server. >> >> >I don't think that the server function approach has a large impact on >handover timing issues, >since I do not expect that a mobile tries to learn about CARs when >already losing connection >to its current AR. Worst case is that a current AR has no entry for a >particular requested >CAR in its cache. This means that the current AR retrieves address info >of this CAR >from the server function, possibly together with static capabilities. >For further requests, >the current AR just contacts the CAR directly to request dynamic >capabilities directly >withour contacting the server anymore until the cache etry is about to >expire. >Now, we could evaluate and compare probability of CARD >failure due to a small delay (server function access) and an >immediately >breaking connection, >and a failure due to a missing entry in the current AR's cache in >dycard. I don't expect results >that degrade the server function based approach. As I answered to Ajoy comment in this respect, these expectations of non-impact are too much dependent on the actual system setup, physical topology in place, and mobility pattern. Hence, I think that raising these expectations are mainly speculations until shown otherwise. But I think we all can agree that the probability of failure if somewhere below 1, and the question remains "is it worth doing it for this very first population handoff to be, maybe, seamless"?? >Now, a stronger argument for the server function here is to not rely on >mobiles to fill ARs' caches, >always making use of radio bandwidth to update caches. We are talking about a triple (see Dycard draft) of information to be sent after each handoff! This will certainly not decrease the overall performance of radio system, won't it? > If >cache updating >in dycard should >achieve same efficiency as the server based approach, static >capabilities are to be transmitted >over the air as well, isn't it? Not sure if this is really a >good solution. I'm not sure I understand what you mean? Do you suggest that Dycard is transmitting the capabilities of ARs (?) over the air or it should in order to be "efficient"? Dycard DOES NOT transmit the capabilities of any ARs over the air, and I don't see why it should in order to be more efficient (not even talking about how the MN knows ALL AR capabilities to be sent to the new AR). The new AR will contact the old AR to obtain the capabilities. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 10:14:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06744 for ; Wed, 12 Mar 2003 10:14:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CFPP318914 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 10:25:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFPPO18911 for ; Wed, 12 Mar 2003 10:25:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06352 for ; Wed, 12 Mar 2003 10:10:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFPAO18871; Wed, 12 Mar 2003 10:25:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFOAO18799 for ; Wed, 12 Mar 2003 10:24:10 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06197 for ; Wed, 12 Mar 2003 10:09:40 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CFBl803832 for ; Wed, 12 Mar 2003 09:11:47 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 09:11:46 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 09:11:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:11:24 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLohlLtzcqneTspStuPLkBnemzxLgAIkmxA To: , Cc: , , X-OriginalArrivalTime: 12 Mar 2003 15:11:25.0013 (UTC) FILETIME=[A5E48850:01C2E8A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CFOAO18800 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Marco, >>[Govind] I don't think the ISP really needs to do it. I don't >think the loss of >>ability to provide one seamless handover between ARs is a big >deal in the >>long run. Plus, as the DT draft points out, it does not >guarantee that the >>request made to a server will get back in time for the MN anyways. >>Even in the DT scheme, any non cache answered case is not guaranteed. >>dycard has a way to make the first handover seamless in a >probabilistic >>sense also, but in all honestly I don't think that one >handover is that big of a deal, >>compared to putting up a server. >> >> >I don't think that the server function approach has a large impact on >handover timing issues, >since I do not expect that a mobile tries to learn about CARs when >already losing connection >to its current AR. Worst case is that a current AR has no entry for a >particular requested >CAR in its cache. This means that the current AR retrieves address info >of this CAR >from the server function, possibly together with static capabilities. >For further requests, >the current AR just contacts the CAR directly to request dynamic >capabilities directly >withour contacting the server anymore until the cache etry is about to >expire. >Now, we could evaluate and compare probability of CARD >failure due to a small delay (server function access) and an >immediately >breaking connection, >and a failure due to a missing entry in the current AR's cache in >dycard. I don't expect results >that degrade the server function based approach. As I answered to Ajoy comment in this respect, these expectations of non-impact are too much dependent on the actual system setup, physical topology in place, and mobility pattern. Hence, I think that raising these expectations are mainly speculations until shown otherwise. But I think we all can agree that the probability of failure if somewhere below 1, and the question remains "is it worth doing it for this very first population handoff to be, maybe, seamless"?? >Now, a stronger argument for the server function here is to not rely on >mobiles to fill ARs' caches, >always making use of radio bandwidth to update caches. We are talking about a triple (see Dycard draft) of information to be sent after each handoff! This will certainly not decrease the overall performance of radio system, won't it? > If >cache updating >in dycard should >achieve same efficiency as the server based approach, static >capabilities are to be transmitted >over the air as well, isn't it? Not sure if this is really a >good solution. I'm not sure I understand what you mean? Do you suggest that Dycard is transmitting the capabilities of ARs (?) over the air or it should in order to be "efficient"? Dycard DOES NOT transmit the capabilities of any ARs over the air, and I don't see why it should in order to be more efficient (not even talking about how the MN knows ALL AR capabilities to be sent to the new AR). The new AR will contact the old AR to obtain the capabilities. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 10:53:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09022 for ; Wed, 12 Mar 2003 10:53:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CG7Rw22864 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 11:07:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CG7RO22853 for ; Wed, 12 Mar 2003 11:07:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09017 for ; Wed, 12 Mar 2003 10:52:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CG7AO22533; Wed, 12 Mar 2003 11:07:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CG6KO22305 for ; Wed, 12 Mar 2003 11:06:20 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08957 for ; Wed, 12 Mar 2003 10:51:49 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CFvQF28837 for ; Wed, 12 Mar 2003 17:57:26 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 17:53:57 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 17:53:56 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 09:53:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:53:43 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLohjfv2R/0Hnf2SAGQ+3zuf9dBRgAI6E5g To: Cc: , , X-OriginalArrivalTime: 12 Mar 2003 15:53:44.0968 (UTC) FILETIME=[8FD2E880:01C2E8AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CG6KO22306 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Marco, > Not sure about this. If we think about functional entities > for CARD, the > server function is one, but > for dycard, in addition the actual CAR discovery, a further functional > entity is on the mobile terminal > performing similar functions as the server function in the DT draft, > isn't it? [Govind] I don't know what functional identity you are talking about here. The MN sends the APids that it hears. As an optimization it then sends a message if it stops hearing a particular APid. This is to reduce the information that is sent down at the time of CAR selection. The MN sends a RI message on handover to a new AR. Thats it. This is to keep caches > updated in ARs, same as the server function does. The only > difference is > that the additional dycard > function is not based on a request-response approach, but on a push > approach, and this with > much more expensive link-costs between ARs and the push function. What > do you think? > [Govind] Cache entries are updated via handovers (which will happen) and capabilities are updated via refresh messages. I don't really think we need to worry about inter-AR bandwidth for now. I think the DT draft does something similar too for dynamic capabilities. I don't think proactively pushing dynamic capabilities is a problem. This helps during decision making. However, if you think that this is a big deal, we can always put it as an option and support a pull function too. > I don't think that the server function approach has a large impact on > handover timing issues, > since I do not expect that a mobile tries to learn about CARs when > already losing connection > to its current AR. Worst case is that a current AR has no entry for a > particular requested > CAR in its cache. This means that the current AR retrieves address info > of this CAR > from the server function, possibly together with static capabilities. > For further requests, > the current AR just contacts the CAR directly to request dynamic > capabilities directly > withour contacting the server anymore until the cache etry is about to > expire. > Now, we could evaluate and compare probability of CARD > failure due to a small delay (server function access) and an immediately > breaking connection, > and a failure due to a missing entry in the current AR's cache in > dycard. I don't expect results > that degrade the server function based approach. >Now, a stronger argument for the server function here is to not rely on > mobiles to fill ARs' caches, >always making use of radio bandwidth to update caches. If cache updating >in dycard should >achieve same efficiency as the server based approach, static >capabilities are to be transmitted >over the air as well, isn't it? Not sure if this is really a good solution. [Govind] As I described to Ajoy, I don't think we should decide a protocol on some physical layer assumptions that may not be true. I don't think you can ever guarantee that the overlap is large. It depends on the environment the speed of the MN and other issues, which we don't need to go through. Consider this case. Assume that there is an optimization in the MN that APids are not reported as soon as they are heard but when a bunch of them are heard to save on bandwidth. Now the time for reaction is less isn't it? Further, there was talk of tagging the server onto some existing network element. Apart from convincing the AAA (as an example) folks to accept this, these servers now will be time sharing between CARD as well as their regular functions. This is something that needs to be thought of too. Plus, I think in a steady state the chance that a server will be asked for info is quite less if cache entry updates happen. So whats the need of one? I thought one of the DT members sent out a mail that the server is useful only for bootstrap. So is the server justified? Regarding your point that radio bandwidth is used for cache population, I would guess you are talking about the RI message. You are right. One more message is needed. However, this could be piggybacked on existing messages. I don't think this is a gross wastage of bandwidth as you seem to point out. But note, even in the DT scheme, you do populate the cache with help of the MNs help too. The MN sends APids and the info is brought from the server down to the cache. Plus as I pointed out earlier, it is difficult to recognize malicious MNs which are artificially creating APids and transmitting them from MNs that listen to APids from other domains. The main point is that once we are talking about the cache, both the approaches need to work to make sure that it is secure. But the number of benefits got from servers may not justify in putting servers in the network for CARD. I don't understand your "static capabilities" point. > Here, I guess, the server function could support ARs learning > capability > about wrong or right > cache entries when using the scope-ID approach, as briefly referred to > in the DT draft. Either > ARs process scope-IDs or the server could already do, which reduces > superfluous traffic > in the network. Since feeding caches in dycard is mobile controlled, > malicious mobiles > could update caches regularly and maintain wrong information > in caches, > isn't it? [Govind] The scope-id reduces the scope of the problem to a "scope-id" scope. So it doesn't really solve the problem completely. All I was saying is that if there are better approaches to tackle the problem, and I believe there are, we should attempt to use it. Further this assumes that AR and AP locations are correlated, which may not be true at all. Further this needs some effort on the ISP's part to configure the server which is an added "cost". Regarding dycard, ofcourse there is a chance that malicious MNs may attempt to do what you suggest, and we are attempted to make this very difficult to do by putting in some checks into the protocol. Regards, -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 10:54:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09072 for ; Wed, 12 Mar 2003 10:54:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CG7AO22533; Wed, 12 Mar 2003 11:07:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CG6KO22305 for ; Wed, 12 Mar 2003 11:06:20 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08957 for ; Wed, 12 Mar 2003 10:51:49 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CFvQF28837 for ; Wed, 12 Mar 2003 17:57:26 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 17:53:57 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 17:53:56 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 09:53:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:53:43 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLohjfv2R/0Hnf2SAGQ+3zuf9dBRgAI6E5g To: Cc: , , X-OriginalArrivalTime: 12 Mar 2003 15:53:44.0968 (UTC) FILETIME=[8FD2E880:01C2E8AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CG6KO22306 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marco, > Not sure about this. If we think about functional entities > for CARD, the > server function is one, but > for dycard, in addition the actual CAR discovery, a further functional > entity is on the mobile terminal > performing similar functions as the server function in the DT draft, > isn't it? [Govind] I don't know what functional identity you are talking about here. The MN sends the APids that it hears. As an optimization it then sends a message if it stops hearing a particular APid. This is to reduce the information that is sent down at the time of CAR selection. The MN sends a RI message on handover to a new AR. Thats it. This is to keep caches > updated in ARs, same as the server function does. The only > difference is > that the additional dycard > function is not based on a request-response approach, but on a push > approach, and this with > much more expensive link-costs between ARs and the push function. What > do you think? > [Govind] Cache entries are updated via handovers (which will happen) and capabilities are updated via refresh messages. I don't really think we need to worry about inter-AR bandwidth for now. I think the DT draft does something similar too for dynamic capabilities. I don't think proactively pushing dynamic capabilities is a problem. This helps during decision making. However, if you think that this is a big deal, we can always put it as an option and support a pull function too. > I don't think that the server function approach has a large impact on > handover timing issues, > since I do not expect that a mobile tries to learn about CARs when > already losing connection > to its current AR. Worst case is that a current AR has no entry for a > particular requested > CAR in its cache. This means that the current AR retrieves address info > of this CAR > from the server function, possibly together with static capabilities. > For further requests, > the current AR just contacts the CAR directly to request dynamic > capabilities directly > withour contacting the server anymore until the cache etry is about to > expire. > Now, we could evaluate and compare probability of CARD > failure due to a small delay (server function access) and an immediately > breaking connection, > and a failure due to a missing entry in the current AR's cache in > dycard. I don't expect results > that degrade the server function based approach. >Now, a stronger argument for the server function here is to not rely on > mobiles to fill ARs' caches, >always making use of radio bandwidth to update caches. If cache updating >in dycard should >achieve same efficiency as the server based approach, static >capabilities are to be transmitted >over the air as well, isn't it? Not sure if this is really a good solution. [Govind] As I described to Ajoy, I don't think we should decide a protocol on some physical layer assumptions that may not be true. I don't think you can ever guarantee that the overlap is large. It depends on the environment the speed of the MN and other issues, which we don't need to go through. Consider this case. Assume that there is an optimization in the MN that APids are not reported as soon as they are heard but when a bunch of them are heard to save on bandwidth. Now the time for reaction is less isn't it? Further, there was talk of tagging the server onto some existing network element. Apart from convincing the AAA (as an example) folks to accept this, these servers now will be time sharing between CARD as well as their regular functions. This is something that needs to be thought of too. Plus, I think in a steady state the chance that a server will be asked for info is quite less if cache entry updates happen. So whats the need of one? I thought one of the DT members sent out a mail that the server is useful only for bootstrap. So is the server justified? Regarding your point that radio bandwidth is used for cache population, I would guess you are talking about the RI message. You are right. One more message is needed. However, this could be piggybacked on existing messages. I don't think this is a gross wastage of bandwidth as you seem to point out. But note, even in the DT scheme, you do populate the cache with help of the MNs help too. The MN sends APids and the info is brought from the server down to the cache. Plus as I pointed out earlier, it is difficult to recognize malicious MNs which are artificially creating APids and transmitting them from MNs that listen to APids from other domains. The main point is that once we are talking about the cache, both the approaches need to work to make sure that it is secure. But the number of benefits got from servers may not justify in putting servers in the network for CARD. I don't understand your "static capabilities" point. > Here, I guess, the server function could support ARs learning > capability > about wrong or right > cache entries when using the scope-ID approach, as briefly referred to > in the DT draft. Either > ARs process scope-IDs or the server could already do, which reduces > superfluous traffic > in the network. Since feeding caches in dycard is mobile controlled, > malicious mobiles > could update caches regularly and maintain wrong information > in caches, > isn't it? [Govind] The scope-id reduces the scope of the problem to a "scope-id" scope. So it doesn't really solve the problem completely. All I was saying is that if there are better approaches to tackle the problem, and I believe there are, we should attempt to use it. Further this assumes that AR and AP locations are correlated, which may not be true at all. Further this needs some effort on the ISP's part to configure the server which is an added "cost". Regarding dycard, ofcourse there is a chance that malicious MNs may attempt to do what you suggest, and we are attempted to make this very difficult to do by putting in some checks into the protocol. Regards, -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 11:15:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09791 for ; Wed, 12 Mar 2003 11:15:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CGTnl24230 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 11:29:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGTnO24227 for ; Wed, 12 Mar 2003 11:29:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09780 for ; Wed, 12 Mar 2003 11:15:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGTVO24213; Wed, 12 Mar 2003 11:29:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGSZO24174 for ; Wed, 12 Mar 2003 11:28:35 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09717 for ; Wed, 12 Mar 2003 11:14:03 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 11:16:11 -0500 Message-ID: <003a01c2e8cc$04a3a0c0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Marco Liebsch" , Cc: , References: <3E6F1344.4080005@ccrle.nec.de> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 11:17:26 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 16:16:11.0675 (UTC) FILETIME=[B28616B0:01C2E8B2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Macro, My comments are inline. > > > Not sure about this. If we think about functional entities for CARD, the > server function is one, but > for dycard, in addition the actual CAR discovery, a further functional > entity is on the mobile terminal > performing similar functions as the server function in the DT draft, > isn't it? This is to keep caches > updated in ARs, same as the server function does. The only difference is > that the additional dycard > function is not based on a request-response approach, but on a push > approach, and this with > much more expensive link-costs between ARs and the push function. What > do you think? > > [eunsoo] The question I raised was what is the server's function. You have not specified what the server function is. Can you please specify what the server function is if it is different from what James mentioned, that is, initial population of the cache? Also please note that the cache population requires reports from MN in both approaches. In the server approach, MN reports L2 address of BS to the current AR. In Dycard, MN reports IP address of the previous AR to the current AR. You may say the number of bytes in the report in Dycard is larger than the server approach. Well, I don't think the difference is so significant in the overall performace of the air link. Thus I don't think Dycard is more expensive than the server approach. > > > > > >>One of the drawbacks of Dycard is that it needs a learning > >>period. > >> > >> > > > >[Govind] dycard, as is in the 01 draft now, needs one handover between ARs. > > I would rather put it that way than open ended as "learning period". In a real life scenario, > > this handover will happen quite soon. In the future, if there are pico-cellular environments > >I would guess it may be more frequent. Note, until a handover happens you don't need > >to know about the other AR. Once a handover happens you will know about the other AR in dycard. > >The correct choice of lifetimes of cache entries should be able to take care of the rest. > > > > > > > >>Naturally, > >>the ISP can hire somebody to walk around and seed the cache, > >>but that's > >>expensive. > >> > >> > >[Govind] I don't think the ISP really needs to do it. I don't think the loss of > >ability to provide one seamless handover between ARs is a big deal in the > >long run. Plus, as the DT draft points out, it does not guarantee that the > >request made to a server will get back in time for the MN anyways. > >Even in the DT scheme, any non cache answered case is not guaranteed. > >dycard has a way to make the first handover seamless in a probabilistic > >sense also, but in all honestly I don't think that one handover is that big of a deal, > >compared to putting up a server. > > > > > I don't think that the server function approach has a large impact on > handover timing issues, > since I do not expect that a mobile tries to learn about CARs when > already losing connection > to its current AR. Worst case is that a current AR has no entry for a > particular requested > CAR in its cache. This means that the current AR retrieves address info > of this CAR > from the server function, possibly together with static capabilities. > For further requests, > the current AR just contacts the CAR directly to request dynamic > capabilities directly > withour contacting the server anymore until the cache etry is about to > expire. > Now, we could evaluate and compare probability of CARD > failure due to a small delay (server function access) and an immediately > breaking connection, > and a failure due to a missing entry in the current AR's cache in > dycard. I don't expect results > that degrade the server function based approach. > Now, a stronger argument for the server function here is to not rely on > mobiles to fill ARs' caches, > always making use of radio bandwidth to update caches. If cache updating > in dycard should > achieve same efficiency as the server based approach, static > capabilities are to be transmitted > over the air as well, isn't it? Not sure if this is really a good solution. > > > > > > > > > >>A server could prime the cache in the router with > >>a collection of > >>AP/AR mappings that may not be geographically adjacent, but > >>over time the ones > >>that aren't would drop out. > >> > >> > >[Govind] Well this causes an increase in traffic between ARs that are > >not GAARs (using a defunct term) which I think is more problematic > >than loosing one handover. I'm not saying that in dycard you cannot have > >incorrect entries in the cache. This is an issue that both the protocols > >need to address in detail. But dycard handles this quite similarly. The other > >issue is how easy it is to get these entries into the AR's cache in either scheme. > >This is something that probably needs some more thought. > > > > > Here, I guess, the server function could support ARs learning capability > about wrong or right > cache entries when using the scope-ID approach, as briefly referred to > in the DT draft. Either > ARs process scope-IDs or the server could already do, which reduces > superfluous traffic > in the network. Since feeding caches in dycard is mobile controlled, > malicious mobiles > could update caches regularly and maintain wrong information in caches, > isn't it? > [eunsoo] As Govind pointed out in his email, the scope-ID does not prevent cache contamination. I repeatedly request a scenario of how the scope-ID prevents cache contamination. I'd appreciate if you provide one. Dividing a domain into sub-domains or scopes does not solve the problem. Actually it brings another problem because the server approach does not support inter-domain operation or inter-scope operation. That is, now handoffs across small scopes cannot take advantage of CARD and thus they would be slow, inefficient, etc. In Dycard, the MN also can try to inject a wrong entry into the cache. But Dycard allows preventing by identifying the MN providing the IP address of the previous AR and checking the handoff history. That is, by checking whether the MN was really with the previous AR very recently, the report about the previous AR's IP address can be verified. That's why I said two cooperating ARs can make cache contamination very difficult. It is very different from the server approach where there is no way to verify whether the MN received the beacon (thus L2 address of an AR) at the location or not. This is a fundamental security problem of the server approach. I guess we should open the third topic, cache contamination, soon. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 11:16:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09826 for ; Wed, 12 Mar 2003 11:16:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGTVO24213; Wed, 12 Mar 2003 11:29:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGSZO24174 for ; Wed, 12 Mar 2003 11:28:35 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09717 for ; Wed, 12 Mar 2003 11:14:03 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 11:16:11 -0500 Message-ID: <003a01c2e8cc$04a3a0c0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Marco Liebsch" , Cc: , References: <3E6F1344.4080005@ccrle.nec.de> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 11:17:26 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 16:16:11.0675 (UTC) FILETIME=[B28616B0:01C2E8B2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Macro, My comments are inline. > > > Not sure about this. If we think about functional entities for CARD, the > server function is one, but > for dycard, in addition the actual CAR discovery, a further functional > entity is on the mobile terminal > performing similar functions as the server function in the DT draft, > isn't it? This is to keep caches > updated in ARs, same as the server function does. The only difference is > that the additional dycard > function is not based on a request-response approach, but on a push > approach, and this with > much more expensive link-costs between ARs and the push function. What > do you think? > > [eunsoo] The question I raised was what is the server's function. You have not specified what the server function is. Can you please specify what the server function is if it is different from what James mentioned, that is, initial population of the cache? Also please note that the cache population requires reports from MN in both approaches. In the server approach, MN reports L2 address of BS to the current AR. In Dycard, MN reports IP address of the previous AR to the current AR. You may say the number of bytes in the report in Dycard is larger than the server approach. Well, I don't think the difference is so significant in the overall performace of the air link. Thus I don't think Dycard is more expensive than the server approach. > > > > > >>One of the drawbacks of Dycard is that it needs a learning > >>period. > >> > >> > > > >[Govind] dycard, as is in the 01 draft now, needs one handover between ARs. > > I would rather put it that way than open ended as "learning period". In a real life scenario, > > this handover will happen quite soon. In the future, if there are pico-cellular environments > >I would guess it may be more frequent. Note, until a handover happens you don't need > >to know about the other AR. Once a handover happens you will know about the other AR in dycard. > >The correct choice of lifetimes of cache entries should be able to take care of the rest. > > > > > > > >>Naturally, > >>the ISP can hire somebody to walk around and seed the cache, > >>but that's > >>expensive. > >> > >> > >[Govind] I don't think the ISP really needs to do it. I don't think the loss of > >ability to provide one seamless handover between ARs is a big deal in the > >long run. Plus, as the DT draft points out, it does not guarantee that the > >request made to a server will get back in time for the MN anyways. > >Even in the DT scheme, any non cache answered case is not guaranteed. > >dycard has a way to make the first handover seamless in a probabilistic > >sense also, but in all honestly I don't think that one handover is that big of a deal, > >compared to putting up a server. > > > > > I don't think that the server function approach has a large impact on > handover timing issues, > since I do not expect that a mobile tries to learn about CARs when > already losing connection > to its current AR. Worst case is that a current AR has no entry for a > particular requested > CAR in its cache. This means that the current AR retrieves address info > of this CAR > from the server function, possibly together with static capabilities. > For further requests, > the current AR just contacts the CAR directly to request dynamic > capabilities directly > withour contacting the server anymore until the cache etry is about to > expire. > Now, we could evaluate and compare probability of CARD > failure due to a small delay (server function access) and an immediately > breaking connection, > and a failure due to a missing entry in the current AR's cache in > dycard. I don't expect results > that degrade the server function based approach. > Now, a stronger argument for the server function here is to not rely on > mobiles to fill ARs' caches, > always making use of radio bandwidth to update caches. If cache updating > in dycard should > achieve same efficiency as the server based approach, static > capabilities are to be transmitted > over the air as well, isn't it? Not sure if this is really a good solution. > > > > > > > > > >>A server could prime the cache in the router with > >>a collection of > >>AP/AR mappings that may not be geographically adjacent, but > >>over time the ones > >>that aren't would drop out. > >> > >> > >[Govind] Well this causes an increase in traffic between ARs that are > >not GAARs (using a defunct term) which I think is more problematic > >than loosing one handover. I'm not saying that in dycard you cannot have > >incorrect entries in the cache. This is an issue that both the protocols > >need to address in detail. But dycard handles this quite similarly. The other > >issue is how easy it is to get these entries into the AR's cache in either scheme. > >This is something that probably needs some more thought. > > > > > Here, I guess, the server function could support ARs learning capability > about wrong or right > cache entries when using the scope-ID approach, as briefly referred to > in the DT draft. Either > ARs process scope-IDs or the server could already do, which reduces > superfluous traffic > in the network. Since feeding caches in dycard is mobile controlled, > malicious mobiles > could update caches regularly and maintain wrong information in caches, > isn't it? > [eunsoo] As Govind pointed out in his email, the scope-ID does not prevent cache contamination. I repeatedly request a scenario of how the scope-ID prevents cache contamination. I'd appreciate if you provide one. Dividing a domain into sub-domains or scopes does not solve the problem. Actually it brings another problem because the server approach does not support inter-domain operation or inter-scope operation. That is, now handoffs across small scopes cannot take advantage of CARD and thus they would be slow, inefficient, etc. In Dycard, the MN also can try to inject a wrong entry into the cache. But Dycard allows preventing by identifying the MN providing the IP address of the previous AR and checking the handoff history. That is, by checking whether the MN was really with the previous AR very recently, the report about the previous AR's IP address can be verified. That's why I said two cooperating ARs can make cache contamination very difficult. It is very different from the server approach where there is no way to verify whether the MN received the beacon (thus L2 address of an AR) at the location or not. This is a fundamental security problem of the server approach. I guess we should open the third topic, cache contamination, soon. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 11:22:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10065 for ; Wed, 12 Mar 2003 11:22:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CGaF724614 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 11:36:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGaFO24611 for ; Wed, 12 Mar 2003 11:36:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10055 for ; Wed, 12 Mar 2003 11:21:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGa3O24595; Wed, 12 Mar 2003 11:36:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGZsO24581 for ; Wed, 12 Mar 2003 11:35:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10050 for ; Wed, 12 Mar 2003 11:21:22 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CGNT821591 for ; Wed, 12 Mar 2003 10:23:29 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 10:23:29 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 08:23:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 11:23:28 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoKr7Cb3QsNsuIT1qpBjcEDpbmigAiD9gg To: , , , , X-OriginalArrivalTime: 12 Mar 2003 16:23:28.0934 (UTC) FILETIME=[B7268460:01C2E8B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CGZtO24582 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy: One comment below, DT hat off. -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Tuesday, March 11, 2003 6:59 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, March 11, 2003 5:39 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi James, > > Why are these approaches mutually exclusive? [Govind] As I pointed out in my first email, I don't think they are mutually exclusive. One approach works with just a cache, second with a cache and server. > > One of the drawbacks of Dycard is that it needs a learning > period. [Govind] dycard, as is in the 01 draft now, needs one handover between ARs. I would rather put it that way than open ended as "learning period". In a real life scenario, this handover will happen quite soon. In the future, if there are pico-cellular environments I would guess it may be more frequent. Note, until a handover happens you don't need to know about the other AR. Once a handover happens you will know about the other AR in dycard. The correct choice of lifetimes of cache entries should be able to take care of the rest. >Naturally, > the ISP can hire somebody to walk around and seed the cache, > but that's > expensive. [Govind] I don't think the ISP really needs to do it. I don't think the loss of ability to provide one seamless handover between ARs is a big deal in the long run. AJOY-> The cache is not permanent so whenever there is loss of cached information, dycard will not be able to support fast handoff. Hemant -> I am trying to do some back of the envelope calculation here. There are two ARs and first handoff happens between them. Let us say cache lifetime is few hours. If another handoff occurs during those few hours, cache gets refreshed for another few hours. If no handoff occurs between those two ARs in few hours, why do we need to care of about seamlessness in the first place. Probably ARs are placed in the middle of the ocean. Of course assumption is that AR geographical closeness is static over few hours time scale. Plus, as the DT draft points out, it does not guarantee that the request made to a server will get back in time for the MN anyways. Even in the DT scheme, any non cache answered case is not guaranteed. dycard has a way to make the first handover seamless in a probabilistic sense also, but in all honestly I don't think that one handover is that big of a deal, compared to putting up a server. AJOY->This is not correct and should be removed from design team draft. Whenever there is sufficient overlap between coverage area of adjacent ARs, server based approach should not have any problem. >A server could prime the cache in the router with > a collection of > AP/AR mappings that may not be geographically adjacent, but > over time the ones > that aren't would drop out. [Govind] Well this causes an increase in traffic between ARs that are not GAARs (using a defunct term) which I think is more problematic than loosing one handover. I'm not saying that in dycard you cannot have incorrect entries in the cache. This is an issue that both the protocols need to address in detail. But dycard handles this quite similarly. The other issue is how easy it is to get these entries into the AR's cache in either scheme. This is something that probably needs some more thought. >Thus, the ISP would not have to > go through the > timeconsuming task of classifying whether they APs are > geographically adjacent. [Govind] I don't know what you are implying by this statement. But if you are stating that ISPs need to do this in dycard, then it is incorrect. If you are talking about the scope-id approach which would need some classification, I agree. > > After the server has been used to initially populate the > cache, any changes > would be propagated directly by CARD. [Govind] I don't think we need a server initially to propagate the cache. I think handovers between ARs, that will happen anyways, can be used to maintain the cache. We have done some study in this scenario and in the steady state the chances of a cache miss is quite low, even with incorporating some of the security schemes to prevent contamination of cache. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 11:24:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10132 for ; Wed, 12 Mar 2003 11:24:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGa3O24595; Wed, 12 Mar 2003 11:36:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGZsO24581 for ; Wed, 12 Mar 2003 11:35:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10050 for ; Wed, 12 Mar 2003 11:21:22 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CGNT821591 for ; Wed, 12 Mar 2003 10:23:29 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 10:23:29 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 08:23:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 11:23:28 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoKr7Cb3QsNsuIT1qpBjcEDpbmigAiD9gg To: , , , , X-OriginalArrivalTime: 12 Mar 2003 16:23:28.0934 (UTC) FILETIME=[B7268460:01C2E8B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CGZtO24582 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy: One comment below, DT hat off. -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Tuesday, March 11, 2003 6:59 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, March 11, 2003 5:39 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi James, > > Why are these approaches mutually exclusive? [Govind] As I pointed out in my first email, I don't think they are mutually exclusive. One approach works with just a cache, second with a cache and server. > > One of the drawbacks of Dycard is that it needs a learning > period. [Govind] dycard, as is in the 01 draft now, needs one handover between ARs. I would rather put it that way than open ended as "learning period". In a real life scenario, this handover will happen quite soon. In the future, if there are pico-cellular environments I would guess it may be more frequent. Note, until a handover happens you don't need to know about the other AR. Once a handover happens you will know about the other AR in dycard. The correct choice of lifetimes of cache entries should be able to take care of the rest. >Naturally, > the ISP can hire somebody to walk around and seed the cache, > but that's > expensive. [Govind] I don't think the ISP really needs to do it. I don't think the loss of ability to provide one seamless handover between ARs is a big deal in the long run. AJOY-> The cache is not permanent so whenever there is loss of cached information, dycard will not be able to support fast handoff. Hemant -> I am trying to do some back of the envelope calculation here. There are two ARs and first handoff happens between them. Let us say cache lifetime is few hours. If another handoff occurs during those few hours, cache gets refreshed for another few hours. If no handoff occurs between those two ARs in few hours, why do we need to care of about seamlessness in the first place. Probably ARs are placed in the middle of the ocean. Of course assumption is that AR geographical closeness is static over few hours time scale. Plus, as the DT draft points out, it does not guarantee that the request made to a server will get back in time for the MN anyways. Even in the DT scheme, any non cache answered case is not guaranteed. dycard has a way to make the first handover seamless in a probabilistic sense also, but in all honestly I don't think that one handover is that big of a deal, compared to putting up a server. AJOY->This is not correct and should be removed from design team draft. Whenever there is sufficient overlap between coverage area of adjacent ARs, server based approach should not have any problem. >A server could prime the cache in the router with > a collection of > AP/AR mappings that may not be geographically adjacent, but > over time the ones > that aren't would drop out. [Govind] Well this causes an increase in traffic between ARs that are not GAARs (using a defunct term) which I think is more problematic than loosing one handover. I'm not saying that in dycard you cannot have incorrect entries in the cache. This is an issue that both the protocols need to address in detail. But dycard handles this quite similarly. The other issue is how easy it is to get these entries into the AR's cache in either scheme. This is something that probably needs some more thought. >Thus, the ISP would not have to > go through the > timeconsuming task of classifying whether they APs are > geographically adjacent. [Govind] I don't know what you are implying by this statement. But if you are stating that ISPs need to do this in dycard, then it is incorrect. If you are talking about the scope-id approach which would need some classification, I agree. > > After the server has been used to initially populate the > cache, any changes > would be propagated directly by CARD. [Govind] I don't think we need a server initially to propagate the cache. I think handovers between ARs, that will happen anyways, can be used to maintain the cache. We have done some study in this scenario and in the steady state the chances of a cache miss is quite low, even with incorporating some of the security schemes to prevent contamination of cache. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 11:39:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10473 for ; Wed, 12 Mar 2003 11:39:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CGrAZ26101 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 11:53:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGrAO26098 for ; Wed, 12 Mar 2003 11:53:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10454 for ; Wed, 12 Mar 2003 11:38:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGqtO26079; Wed, 12 Mar 2003 11:52:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGpnO26012 for ; Wed, 12 Mar 2003 11:51:49 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10431 for ; Wed, 12 Mar 2003 11:37:17 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h2CGd5Td009698 for ; Wed, 12 Mar 2003 09:39:05 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA22213 for ; Wed, 12 Mar 2003 09:39:25 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 10:39:25 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE4A@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , Singh Ajoy-ASINGH1 , Govind.Krishnamurthi@nokia.com, kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:39:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Unfortunately, it is still rather subjective what "sufficient" overlap means in order to "not have any problems". It highly depends on your notion of "sufficient overlap", the mobility pattern of the mobile involved and the topology of your system, i.e., the experienced delay for L2-L3 requests. We need simulations and best current practices demonstrating how to set up the system properly for certain environments. These evaluations could also reveal how to prevent situations (if they are preventable) in which the probability of a seamless first handoff is actually damn close to zero (i.e., identifying pathological situations). AJOY-> By sufficient overlap, I mean overlap required to support fast handoff or any seamless handoff. BTW, without overlapping coverage area it is not possible to support any seamless handoff in real world. Again please note that AR cache is updated when the new L2 ID is detected based upon link layer scanning. The new link layer id should be detected prior to initiation of any L2 handoff. I mean MN won't until the link layer connection with current AR is being lost to update the discovery of new AP id. -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 12, 2003 9:02 AM To: Ajoy Singh; Govind.Krishnamurthi@nokia.com; kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi Ajoy, > Plus, as the DT draft points out, it does not guarantee that the >request made to a server will get back in time for the MN anyways. >Even in the DT scheme, any non cache answered case is not guaranteed. >dycard has a way to make the first handover seamless in a >probabilistic >sense also, but in all honestly I don't think that one >handover is that big of a deal, >compared to putting up a server. > >AJOY->This is not correct and should be removed from design >team draft. Whenever >there is sufficient overlap between coverage area of adjacent >ARs, server based >approach should not have any problem. Unfortunately, it is still rather subjective what "sufficient" overlap means in order to "not have any problems". It highly depends on your notion of "sufficient overlap", the mobility pattern of the mobile involved and the topology of your system, i.e., the experienced delay for L2-L3 requests. We need simulations and best current practices demonstrating how to set up the system properly for certain environments. These evaluations could also reveal how to prevent situations (if they are preventable) in which the probability of a seamless first handoff is actually damn close to zero (i.e., identifying pathological situations). It all boils down to the fact that it is unclear right now how the claimed P(failure of timely delivery of answer)=1 with "proper configuration" is actually achieved in the server approach. Until then, P(.) less than one is a valid assumption until proven otherwise, and the question remains whether or not it is worth going through the whole server thing for this. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 11:39:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10495 for ; Wed, 12 Mar 2003 11:39:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGqtO26079; Wed, 12 Mar 2003 11:52:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGpnO26012 for ; Wed, 12 Mar 2003 11:51:49 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10431 for ; Wed, 12 Mar 2003 11:37:17 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h2CGd5Td009698 for ; Wed, 12 Mar 2003 09:39:05 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA22213 for ; Wed, 12 Mar 2003 09:39:25 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 10:39:25 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE4A@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , Singh Ajoy-ASINGH1 , Govind.Krishnamurthi@nokia.com, kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:39:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Unfortunately, it is still rather subjective what "sufficient" overlap means in order to "not have any problems". It highly depends on your notion of "sufficient overlap", the mobility pattern of the mobile involved and the topology of your system, i.e., the experienced delay for L2-L3 requests. We need simulations and best current practices demonstrating how to set up the system properly for certain environments. These evaluations could also reveal how to prevent situations (if they are preventable) in which the probability of a seamless first handoff is actually damn close to zero (i.e., identifying pathological situations). AJOY-> By sufficient overlap, I mean overlap required to support fast handoff or any seamless handoff. BTW, without overlapping coverage area it is not possible to support any seamless handoff in real world. Again please note that AR cache is updated when the new L2 ID is detected based upon link layer scanning. The new link layer id should be detected prior to initiation of any L2 handoff. I mean MN won't until the link layer connection with current AR is being lost to update the discovery of new AP id. -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Wednesday, March 12, 2003 9:02 AM To: Ajoy Singh; Govind.Krishnamurthi@nokia.com; kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi Ajoy, > Plus, as the DT draft points out, it does not guarantee that the >request made to a server will get back in time for the MN anyways. >Even in the DT scheme, any non cache answered case is not guaranteed. >dycard has a way to make the first handover seamless in a >probabilistic >sense also, but in all honestly I don't think that one >handover is that big of a deal, >compared to putting up a server. > >AJOY->This is not correct and should be removed from design >team draft. Whenever >there is sufficient overlap between coverage area of adjacent >ARs, server based >approach should not have any problem. Unfortunately, it is still rather subjective what "sufficient" overlap means in order to "not have any problems". It highly depends on your notion of "sufficient overlap", the mobility pattern of the mobile involved and the topology of your system, i.e., the experienced delay for L2-L3 requests. We need simulations and best current practices demonstrating how to set up the system properly for certain environments. These evaluations could also reveal how to prevent situations (if they are preventable) in which the probability of a seamless first handoff is actually damn close to zero (i.e., identifying pathological situations). It all boils down to the fact that it is unclear right now how the claimed P(failure of timely delivery of answer)=1 with "proper configuration" is actually achieved in the server approach. Until then, P(.) less than one is a valid assumption until proven otherwise, and the question remains whether or not it is worth going through the whole server thing for this. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 12:08:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11533 for ; Wed, 12 Mar 2003 12:08:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CHMSh28590 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 12:22:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHMRO28587 for ; Wed, 12 Mar 2003 12:22:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11500 for ; Wed, 12 Mar 2003 12:07:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHMHO28576; Wed, 12 Mar 2003 12:22:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CH4ZO26572 for ; Wed, 12 Mar 2003 12:04:35 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10721 for ; Wed, 12 Mar 2003 11:50:02 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CGq8829089 for ; Wed, 12 Mar 2003 10:52:08 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 10:52:07 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 10:52:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 11:52:05 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLotf49WlSHiWMGSASpxPYtNwNNyAAAJU6Q To: , , , , X-OriginalArrivalTime: 12 Mar 2003 16:52:06.0961 (UTC) FILETIME=[B72CA210:01C2E8B7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CH4ZO26573 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 12, 2003 11:39 AM >To: Trossen Dirk (NRC/Boston); Singh Ajoy-ASINGH1; >Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; >eunsoo@nec-labs.com; seamoby@ietf.org >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > >Unfortunately, it is still rather subjective what "sufficient" >overlap means >in order to "not have any problems". It highly depends on your >notion of >"sufficient overlap", the mobility pattern of the mobile >involved and the >topology >of your system, i.e., the experienced delay for L2-L3 requests. We need >simulations and >best current practices demonstrating how to set up the system >properly for >certain environments. >These evaluations could also reveal how to prevent situations >(if they are >preventable) in which >the probability of a seamless first handoff is actually damn >close to zero >(i.e., identifying pathological >situations). > >AJOY-> By sufficient overlap, I mean overlap required to support fast >handoff or any seamless handoff. And that's exactly the point. The "sufficient overlap" you need to support fast handoff as such is different from the "sufficient overlap" you need in order to perform the server-based L2-L3 mapping before, followed by said fast handoff. So you require a different "sufficient overlap" than in the plain fast handoff. How much more overlap is that? How would you minimize this additional overlap? As a consequence, your "sufficient" still doesn't tell me enough to dimension my system correctly. What are the design principles you would give to your engineering department that deploys the server-based system in order to ensure the seamless handoff (with your CARD solution) in any case, as you claim?? For that, you usually apply models or simulations for network planning that gives you details about where to place the server in order to achieve what you claim. "Sufficient overlap" is certainly not a design guideline that the engineering guys would accept for their network planning. As long as these design guidelines are not available, it is fair to assume that there is still a probability of failure since I might misdimension my system due to the lack of said design guideline. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 12:09:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11558 for ; Wed, 12 Mar 2003 12:09:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHMHO28576; Wed, 12 Mar 2003 12:22:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CH4ZO26572 for ; Wed, 12 Mar 2003 12:04:35 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10721 for ; Wed, 12 Mar 2003 11:50:02 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CGq8829089 for ; Wed, 12 Mar 2003 10:52:08 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 10:52:07 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 10:52:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 11:52:05 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLotf49WlSHiWMGSASpxPYtNwNNyAAAJU6Q To: , , , , X-OriginalArrivalTime: 12 Mar 2003 16:52:06.0961 (UTC) FILETIME=[B72CA210:01C2E8B7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CH4ZO26573 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit >-----Original Message----- >From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] >Sent: Wednesday, March 12, 2003 11:39 AM >To: Trossen Dirk (NRC/Boston); Singh Ajoy-ASINGH1; >Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; >eunsoo@nec-labs.com; seamoby@ietf.org >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > >Unfortunately, it is still rather subjective what "sufficient" >overlap means >in order to "not have any problems". It highly depends on your >notion of >"sufficient overlap", the mobility pattern of the mobile >involved and the >topology >of your system, i.e., the experienced delay for L2-L3 requests. We need >simulations and >best current practices demonstrating how to set up the system >properly for >certain environments. >These evaluations could also reveal how to prevent situations >(if they are >preventable) in which >the probability of a seamless first handoff is actually damn >close to zero >(i.e., identifying pathological >situations). > >AJOY-> By sufficient overlap, I mean overlap required to support fast >handoff or any seamless handoff. And that's exactly the point. The "sufficient overlap" you need to support fast handoff as such is different from the "sufficient overlap" you need in order to perform the server-based L2-L3 mapping before, followed by said fast handoff. So you require a different "sufficient overlap" than in the plain fast handoff. How much more overlap is that? How would you minimize this additional overlap? As a consequence, your "sufficient" still doesn't tell me enough to dimension my system correctly. What are the design principles you would give to your engineering department that deploys the server-based system in order to ensure the seamless handoff (with your CARD solution) in any case, as you claim?? For that, you usually apply models or simulations for network planning that gives you details about where to place the server in order to achieve what you claim. "Sufficient overlap" is certainly not a design guideline that the engineering guys would accept for their network planning. As long as these design guidelines are not available, it is fair to assume that there is still a probability of failure since I might misdimension my system due to the lack of said design guideline. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 12:13:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11717 for ; Wed, 12 Mar 2003 12:13:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CHR4R28884 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 12:27:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHR4O28881 for ; Wed, 12 Mar 2003 12:27:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11680 for ; Wed, 12 Mar 2003 12:12:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHQmO28777; Wed, 12 Mar 2003 12:26:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CH5gO26628 for ; Wed, 12 Mar 2003 12:05:42 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10754 for ; Wed, 12 Mar 2003 11:51:10 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2CGrIXR023018 for ; Wed, 12 Mar 2003 09:53:19 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA01472 for ; Wed, 12 Mar 2003 09:53:18 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 10:53:19 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE4B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , Singh Ajoy-ASINGH1 , kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:53:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Wednesday, March 12, 2003 7:37 AM To: Ajoy Singh; kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf. org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > AJOY-> The cache is not permanent so whenever there is > loss of cached information, dycard will not be able to support > fast handoff. > [Govind] I agree that cache entries have a lifetime. I think handovers are enough to update these entries. Handovers will happen in real life. > Plus, as the DT draft points out, it does not guarantee that the > request made to a server will get back in time for the MN anyways. > Even in the DT scheme, any non cache answered case is not guaranteed. > dycard has a way to make the first handover seamless in a > probabilistic > sense also, but in all honestly I don't think that one > handover is that big of a deal, > compared to putting up a server. > > AJOY->This is not correct and should be removed from design > team draft. Whenever > there is sufficient overlap between coverage area of adjacent > ARs, server based > approach should not have any problem. [Govind] Writing up a spec that is constrained on the assumptions on the physical layer scenario is not the correct approach IMO. But, lets leave this at that. I think you say it can be guaranteed most of the time, while I don't think so. AJOY-> Please note that fast handoff work is based on this fact. We are proposing something to help fast handoff . In CARD, the update message is sent as soon the a new L2 id is detected during L2 scan. It does not wait till the L2 handoff is imminent. Whereas in fast handoff, L3 handoff is initiated when mobile node or AR detects that L2 handoff is imminent based upon some L2 trigger. So, CARD is done prior to initiation of L3 handoff. If you believe in fast handoff work, then I am having hard time to digest your comment in this context. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 12:13:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11793 for ; Wed, 12 Mar 2003 12:13:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHQmO28777; Wed, 12 Mar 2003 12:26:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CH5gO26628 for ; Wed, 12 Mar 2003 12:05:42 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10754 for ; Wed, 12 Mar 2003 11:51:10 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2CGrIXR023018 for ; Wed, 12 Mar 2003 09:53:19 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA01472 for ; Wed, 12 Mar 2003 09:53:18 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 10:53:19 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE4B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Govind.Krishnamurthi@nokia.com'" , Singh Ajoy-ASINGH1 , kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:53:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Wednesday, March 12, 2003 7:37 AM To: Ajoy Singh; kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf. org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > AJOY-> The cache is not permanent so whenever there is > loss of cached information, dycard will not be able to support > fast handoff. > [Govind] I agree that cache entries have a lifetime. I think handovers are enough to update these entries. Handovers will happen in real life. > Plus, as the DT draft points out, it does not guarantee that the > request made to a server will get back in time for the MN anyways. > Even in the DT scheme, any non cache answered case is not guaranteed. > dycard has a way to make the first handover seamless in a > probabilistic > sense also, but in all honestly I don't think that one > handover is that big of a deal, > compared to putting up a server. > > AJOY->This is not correct and should be removed from design > team draft. Whenever > there is sufficient overlap between coverage area of adjacent > ARs, server based > approach should not have any problem. [Govind] Writing up a spec that is constrained on the assumptions on the physical layer scenario is not the correct approach IMO. But, lets leave this at that. I think you say it can be guaranteed most of the time, while I don't think so. AJOY-> Please note that fast handoff work is based on this fact. We are proposing something to help fast handoff . In CARD, the update message is sent as soon the a new L2 id is detected during L2 scan. It does not wait till the L2 handoff is imminent. Whereas in fast handoff, L3 handoff is initiated when mobile node or AR detects that L2 handoff is imminent based upon some L2 trigger. So, CARD is done prior to initiation of L3 handoff. If you believe in fast handoff work, then I am having hard time to digest your comment in this context. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 12:20:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12022 for ; Wed, 12 Mar 2003 12:20:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CHY8V29334 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 12:34:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHY8O29331 for ; Wed, 12 Mar 2003 12:34:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11997 for ; Wed, 12 Mar 2003 12:19:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHXsO29301; Wed, 12 Mar 2003 12:33:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHUFO29062 for ; Wed, 12 Mar 2003 12:30:15 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11856 for ; Wed, 12 Mar 2003 12:15:42 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CHHn806366 for ; Wed, 12 Mar 2003 11:17:49 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 11:17:48 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 09:17:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 12:17:37 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLouAx+UuWhPTldSHyBPB4XNpgI9gAASQfA To: , , , X-OriginalArrivalTime: 12 Mar 2003 17:17:39.0189 (UTC) FILETIME=[48741250:01C2E8BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CHUFO29063 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ajoy, > AJOY-> Please note that fast handoff work is based on this > fact. We are > proposing > something to help fast handoff . In CARD, the update message > is sent as > soon the > a new L2 id is detected during L2 scan. It does not wait till the L2 > handoff is imminent. > Whereas in fast handoff, L3 handoff is initiated when mobile > node or AR > detects that L2 handoff > is imminent based upon some L2 trigger. So, CARD is done prior to > initiation of L3 handoff. If you believe > in fast handoff work, then I am having hard time to digest > your comment in > this > context. [Govind] All I pointed out was that it takes more time to get information from the cache than from the server. The server will probably be busy, right since this is an important part of your protocol. If it is busy answering queries from all ARs, apart from time sharing with other functions depending on what you are time sharing with, it will take time to respond, because there is just one per domain. Your claim is that there is sufficient time inspite of all this, always!. Well I beg to differ and I don't think it is true in all cases. On a related note, if the server is very lightly loaded whenever you are accessing it then would'nt it mean that the server is not contacted most of the time, which again begs the discussion why would you need it? All these points seemingly attempt to justify the servers because it is deemed necessary. The original point of this topic is why need a servre when you can get comparable service in an alternative scheme without one? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 12:20:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12044 for ; Wed, 12 Mar 2003 12:20:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHXsO29301; Wed, 12 Mar 2003 12:33:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHUFO29062 for ; Wed, 12 Mar 2003 12:30:15 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11856 for ; Wed, 12 Mar 2003 12:15:42 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CHHn806366 for ; Wed, 12 Mar 2003 11:17:49 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 11:17:48 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 09:17:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 12:17:37 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLouAx+UuWhPTldSHyBPB4XNpgI9gAASQfA To: , , , X-OriginalArrivalTime: 12 Mar 2003 17:17:39.0189 (UTC) FILETIME=[48741250:01C2E8BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CHUFO29063 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ajoy, > AJOY-> Please note that fast handoff work is based on this > fact. We are > proposing > something to help fast handoff . In CARD, the update message > is sent as > soon the > a new L2 id is detected during L2 scan. It does not wait till the L2 > handoff is imminent. > Whereas in fast handoff, L3 handoff is initiated when mobile > node or AR > detects that L2 handoff > is imminent based upon some L2 trigger. So, CARD is done prior to > initiation of L3 handoff. If you believe > in fast handoff work, then I am having hard time to digest > your comment in > this > context. [Govind] All I pointed out was that it takes more time to get information from the cache than from the server. The server will probably be busy, right since this is an important part of your protocol. If it is busy answering queries from all ARs, apart from time sharing with other functions depending on what you are time sharing with, it will take time to respond, because there is just one per domain. Your claim is that there is sufficient time inspite of all this, always!. Well I beg to differ and I don't think it is true in all cases. On a related note, if the server is very lightly loaded whenever you are accessing it then would'nt it mean that the server is not contacted most of the time, which again begs the discussion why would you need it? All these points seemingly attempt to justify the servers because it is deemed necessary. The original point of this topic is why need a servre when you can get comparable service in an alternative scheme without one? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 12:23:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12188 for ; Wed, 12 Mar 2003 12:23:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CHbrU30243 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 12:37:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHbrO30240 for ; Wed, 12 Mar 2003 12:37:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12178 for ; Wed, 12 Mar 2003 12:23:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHbhO30188; Wed, 12 Mar 2003 12:37:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHYCO29348 for ; Wed, 12 Mar 2003 12:34:12 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12002 for ; Wed, 12 Mar 2003 12:19:38 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2CHLgZj021093 for ; Wed, 12 Mar 2003 10:21:42 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA06684 for ; Wed, 12 Mar 2003 10:19:45 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 11:20:59 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE4C@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Singh Ajoy-ASINGH1 , Govind.Krishnamurthi@nokia.com, kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 11:20:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Hemant, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 12, 2003 10:23 AM To: Ajoy Singh; Govind.Krishnamurthi@nokia.com; kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi Ajoy: One comment below, DT hat off. -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Tuesday, March 11, 2003 6:59 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; eunsoo@nec- labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, March 11, 2003 5:39 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi James, > > Why are these approaches mutually exclusive? [Govind] As I pointed out in my first email, I don't think they are mutually exclusive. One approach works with just a cache, second with a cache and server. > > One of the drawbacks of Dycard is that it needs a learning > period. [Govind] dycard, as is in the 01 draft now, needs one handover between ARs. I would rather put it that way than open ended as "learning period". In a real life scenario, this handover will happen quite soon. In the future, if there are pico- cellular environments I would guess it may be more frequent. Note, until a handover happens you don't need to know about the other AR. Once a handover happens you will know about the other AR in dycard. AJOY-> I am not sure even this is acceptable for voice user. The correct choice of lifetimes of cache entries should be able to take care of the rest. AJOY-> What is the correct choice of lifetime? Because if you have longer lifetime, the probability of fast handoff failure due to cache timeout is minimized, but you have other problem due to cache contamination. >Naturally, > the ISP can hire somebody to walk around and seed the cache, > but that's > expensive. [Govind] I don't think the ISP really needs to do it. I don't think the loss of ability to provide one seamless handover between ARs is a big deal in the long run. AJOY-> The cache is not permanent so whenever there is loss of cached information, dycard will not be able to support fast handoff. Hemant -> I am trying to do some back of the envelope calculation here. There are two ARs and first handoff happens between them. Let us say cache lifetime is few hours. If another handoff occurs during those few hours, cache gets refreshed for another few hours. If no handoff occurs between those two ARs in few hours, why do we need to care of about seamlessness in the first place. Probably ARs are placed in the middle of the ocean. Of course assumption is that AR geographical closeness is static over few hours time scale. Plus, as the DT draft points out, it does not guarantee that the request made to a server will get back in time for the MN anyways. Even in the DT scheme, any non cache answered case is not guaranteed. dycard has a way to make the first handover seamless in a probabilistic sense also, but in all honestly I don't think that one handover is that big of a deal, compared to putting up a server. AJOY->This is not correct and should be removed from design team draft. Whenever there is sufficient overlap between coverage area of adjacent ARs, server based approach should not have any problem. >A server could prime the cache in the router with > a collection of > AP/AR mappings that may not be geographically adjacent, but > over time the ones > that aren't would drop out. [Govind] Well this causes an increase in traffic between ARs that are not GAARs (using a defunct term) which I think is more problematic than loosing one handover. I'm not saying that in dycard you cannot have incorrect entries in the cache. This is an issue that both the protocols need to address in detail. But dycard handles this quite similarly. The other issue is how easy it is to get these entries into the AR's cache in either scheme. This is something that probably needs some more thought. >Thus, the ISP would not have to > go through the > timeconsuming task of classifying whether they APs are > geographically adjacent. [Govind] I don't know what you are implying by this statement. But if you are stating that ISPs need to do this in dycard, then it is incorrect. If you are talking about the scope-id approach which would need some classification, I agree. > > After the server has been used to initially populate the > cache, any changes > would be propagated directly by CARD. [Govind] I don't think we need a server initially to propagate the cache. I think handovers between ARs, that will happen anyways, can be used to maintain the cache. We have done some study in this scenario and in the steady state the chances of a cache miss is quite low, even with incorporating some of the security schemes to prevent contamination of cache. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 12:24:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12229 for ; Wed, 12 Mar 2003 12:24:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHbhO30188; Wed, 12 Mar 2003 12:37:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHYCO29348 for ; Wed, 12 Mar 2003 12:34:12 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12002 for ; Wed, 12 Mar 2003 12:19:38 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2CHLgZj021093 for ; Wed, 12 Mar 2003 10:21:42 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA06684 for ; Wed, 12 Mar 2003 10:19:45 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 11:20:59 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE4C@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Singh Ajoy-ASINGH1 , Govind.Krishnamurthi@nokia.com, kempf@docomolabs-usa.com, eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 11:20:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Hemant, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 12, 2003 10:23 AM To: Ajoy Singh; Govind.Krishnamurthi@nokia.com; kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi Ajoy: One comment below, DT hat off. -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Tuesday, March 11, 2003 6:59 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; eunsoo@nec- labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Govind, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, March 11, 2003 5:39 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi James, > > Why are these approaches mutually exclusive? [Govind] As I pointed out in my first email, I don't think they are mutually exclusive. One approach works with just a cache, second with a cache and server. > > One of the drawbacks of Dycard is that it needs a learning > period. [Govind] dycard, as is in the 01 draft now, needs one handover between ARs. I would rather put it that way than open ended as "learning period". In a real life scenario, this handover will happen quite soon. In the future, if there are pico- cellular environments I would guess it may be more frequent. Note, until a handover happens you don't need to know about the other AR. Once a handover happens you will know about the other AR in dycard. AJOY-> I am not sure even this is acceptable for voice user. The correct choice of lifetimes of cache entries should be able to take care of the rest. AJOY-> What is the correct choice of lifetime? Because if you have longer lifetime, the probability of fast handoff failure due to cache timeout is minimized, but you have other problem due to cache contamination. >Naturally, > the ISP can hire somebody to walk around and seed the cache, > but that's > expensive. [Govind] I don't think the ISP really needs to do it. I don't think the loss of ability to provide one seamless handover between ARs is a big deal in the long run. AJOY-> The cache is not permanent so whenever there is loss of cached information, dycard will not be able to support fast handoff. Hemant -> I am trying to do some back of the envelope calculation here. There are two ARs and first handoff happens between them. Let us say cache lifetime is few hours. If another handoff occurs during those few hours, cache gets refreshed for another few hours. If no handoff occurs between those two ARs in few hours, why do we need to care of about seamlessness in the first place. Probably ARs are placed in the middle of the ocean. Of course assumption is that AR geographical closeness is static over few hours time scale. Plus, as the DT draft points out, it does not guarantee that the request made to a server will get back in time for the MN anyways. Even in the DT scheme, any non cache answered case is not guaranteed. dycard has a way to make the first handover seamless in a probabilistic sense also, but in all honestly I don't think that one handover is that big of a deal, compared to putting up a server. AJOY->This is not correct and should be removed from design team draft. Whenever there is sufficient overlap between coverage area of adjacent ARs, server based approach should not have any problem. >A server could prime the cache in the router with > a collection of > AP/AR mappings that may not be geographically adjacent, but > over time the ones > that aren't would drop out. [Govind] Well this causes an increase in traffic between ARs that are not GAARs (using a defunct term) which I think is more problematic than loosing one handover. I'm not saying that in dycard you cannot have incorrect entries in the cache. This is an issue that both the protocols need to address in detail. But dycard handles this quite similarly. The other issue is how easy it is to get these entries into the AR's cache in either scheme. This is something that probably needs some more thought. >Thus, the ISP would not have to > go through the > timeconsuming task of classifying whether they APs are > geographically adjacent. [Govind] I don't know what you are implying by this statement. But if you are stating that ISPs need to do this in dycard, then it is incorrect. If you are talking about the scope-id approach which would need some classification, I agree. > > After the server has been used to initially populate the > cache, any changes > would be propagated directly by CARD. [Govind] I don't think we need a server initially to propagate the cache. I think handovers between ARs, that will happen anyways, can be used to maintain the cache. We have done some study in this scenario and in the steady state the chances of a cache miss is quite low, even with incorporating some of the security schemes to prevent contamination of cache. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 12:49:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13347 for ; Wed, 12 Mar 2003 12:49:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CI3vV31540 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 13:03:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CI3vO31537 for ; Wed, 12 Mar 2003 13:03:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13326 for ; Wed, 12 Mar 2003 12:49:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CI3lO31518; Wed, 12 Mar 2003 13:03:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CI0DO31308 for ; Wed, 12 Mar 2003 13:00:13 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13183 for ; Wed, 12 Mar 2003 12:45:40 -0500 (EST) Message-ID: <011201c2e8bf$470f7c70$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Marco Liebsch" , Cc: References: <3E6F1344.4080005@ccrle.nec.de> <003a01c2e8cc$04a3a0c0$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 09:44:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eunsoo, > [eunsoo] The question I raised was what is the server's function. You have > not specified what the server function is. Can you please specify what the > server function is if it is different from what James mentioned, that is, > initial population of the cache? > Also please note that the cache population requires reports from MN in both > approaches. In the server approach, MN reports L2 address of BS to the > current AR. In Dycard, MN reports IP address of the previous AR to the > current AR. You may say the number of bytes in the report in Dycard is > larger than the server approach. Well, I don't think the difference is so > significant in the overall performace of the air link. Thus I don't think > Dycard is more expensive than the server approach. > Your opinions are interesting, but numbers are the way to answer this question. How about coming up with a byte count of the number of bytes needed over the air for Dycard v.s. the DT approach? That would help the WG judge which approach is more spectrally efficient. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 12:50:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13421 for ; Wed, 12 Mar 2003 12:50:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CI3lO31518; Wed, 12 Mar 2003 13:03:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CI0DO31308 for ; Wed, 12 Mar 2003 13:00:13 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13183 for ; Wed, 12 Mar 2003 12:45:40 -0500 (EST) Message-ID: <011201c2e8bf$470f7c70$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Marco Liebsch" , Cc: References: <3E6F1344.4080005@ccrle.nec.de> <003a01c2e8cc$04a3a0c0$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 09:44:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eunsoo, > [eunsoo] The question I raised was what is the server's function. You have > not specified what the server function is. Can you please specify what the > server function is if it is different from what James mentioned, that is, > initial population of the cache? > Also please note that the cache population requires reports from MN in both > approaches. In the server approach, MN reports L2 address of BS to the > current AR. In Dycard, MN reports IP address of the previous AR to the > current AR. You may say the number of bytes in the report in Dycard is > larger than the server approach. Well, I don't think the difference is so > significant in the overall performace of the air link. Thus I don't think > Dycard is more expensive than the server approach. > Your opinions are interesting, but numbers are the way to answer this question. How about coming up with a byte count of the number of bytes needed over the air for Dycard v.s. the DT approach? That would help the WG judge which approach is more spectrally efficient. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 13:02:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14002 for ; Wed, 12 Mar 2003 13:02:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CIG4Y00569 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 13:16:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIG4O00566 for ; Wed, 12 Mar 2003 13:16:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13996 for ; Wed, 12 Mar 2003 13:01:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIFlO00514; Wed, 12 Mar 2003 13:15:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIC7O00373 for ; Wed, 12 Mar 2003 13:12:07 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13776 for ; Wed, 12 Mar 2003 12:57:33 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 12:59:42 -0500 Message-ID: <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 13:00:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 17:59:42.0501 (UTC) FILETIME=[2876ED50:01C2E8C1] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Why are these approaches mutually exclusive? > > One of the drawbacks of Dycard is that it needs a learning period. Naturally, > the ISP can hire somebody to walk around and seed the cache, but that's > expensive. A server could prime the cache in the router with a collection of > AP/AR mappings that may not be geographically adjacent, but over time the ones > that aren't would drop out. Thus, the ISP would not have to go through the > timeconsuming task of classifying whether they APs are geographically adjacent. > > After the server has been used to initially populate the cache, any changes > would be propagated directly by CARD. > [eunsoo] As Govind and Dirk pointed out, the first handoff between two ARs leads to populating the cache with an entry for the newly discovered CAR in Dycard. If you claim that the server will be used only for initial populating the cache at ARs, please clarify difference from the DT draft. The DT draft does not say each AR will download a bunch of L2-L3 mapping information from the server in the beginning of its operation. It will download one by one as MN requests the mapping or reports a new BS L2 address. The only difference between Dycard and the server approach in the learning period is that MN may be able to do fast handoff for the very first handoff between two ARs in the server approach while MN will have to do slow handoff in Dycard. Well, if we are talking about ISP, I don't think they just install a box and start commercial services. They will go through many stages of network tests including roaming support. So most likely initial discoveries will be done during the process and thus they would not feel any concern for the impact of the learning period for consumers. If we are talking about more ad-hoc and casual network deployment, I am not sure the slow handoff for the very first handoff is such a big concern, let say, for corporate networks or campus networks. I don't think it justifies introducing a sever. Also even if an ISP wants populating the cache by the information from the server, they cannot tell exactly which entry should be inserted into a cache unless they know exactly the radio map of the base stations. Well, all this work is to remove such requirement. Then what they do only is just copying a bunch of entries from the server to the cache as you suggested. If really they want to do such a thing, they can use many existing tools. For example, we can simply define MIB for CARD and they can use SNMP for setting the values for CARD. This should not affect the fundamental structure of the protocol. Actually it should be independent of the CARD protocol. Thus it should not be a part of the CARD protocol except MIB definitions. Defining MIB does not bring in any need of a server, of course. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 13:02:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14020 for ; Wed, 12 Mar 2003 13:02:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIFlO00514; Wed, 12 Mar 2003 13:15:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIC7O00373 for ; Wed, 12 Mar 2003 13:12:07 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13776 for ; Wed, 12 Mar 2003 12:57:33 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 12:59:42 -0500 Message-ID: <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 13:00:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 17:59:42.0501 (UTC) FILETIME=[2876ED50:01C2E8C1] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Why are these approaches mutually exclusive? > > One of the drawbacks of Dycard is that it needs a learning period. Naturally, > the ISP can hire somebody to walk around and seed the cache, but that's > expensive. A server could prime the cache in the router with a collection of > AP/AR mappings that may not be geographically adjacent, but over time the ones > that aren't would drop out. Thus, the ISP would not have to go through the > timeconsuming task of classifying whether they APs are geographically adjacent. > > After the server has been used to initially populate the cache, any changes > would be propagated directly by CARD. > [eunsoo] As Govind and Dirk pointed out, the first handoff between two ARs leads to populating the cache with an entry for the newly discovered CAR in Dycard. If you claim that the server will be used only for initial populating the cache at ARs, please clarify difference from the DT draft. The DT draft does not say each AR will download a bunch of L2-L3 mapping information from the server in the beginning of its operation. It will download one by one as MN requests the mapping or reports a new BS L2 address. The only difference between Dycard and the server approach in the learning period is that MN may be able to do fast handoff for the very first handoff between two ARs in the server approach while MN will have to do slow handoff in Dycard. Well, if we are talking about ISP, I don't think they just install a box and start commercial services. They will go through many stages of network tests including roaming support. So most likely initial discoveries will be done during the process and thus they would not feel any concern for the impact of the learning period for consumers. If we are talking about more ad-hoc and casual network deployment, I am not sure the slow handoff for the very first handoff is such a big concern, let say, for corporate networks or campus networks. I don't think it justifies introducing a sever. Also even if an ISP wants populating the cache by the information from the server, they cannot tell exactly which entry should be inserted into a cache unless they know exactly the radio map of the base stations. Well, all this work is to remove such requirement. Then what they do only is just copying a bunch of entries from the server to the cache as you suggested. If really they want to do such a thing, they can use many existing tools. For example, we can simply define MIB for CARD and they can use SNMP for setting the values for CARD. This should not affect the fundamental structure of the protocol. Actually it should be independent of the CARD protocol. Thus it should not be a part of the CARD protocol except MIB definitions. Defining MIB does not bring in any need of a server, of course. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 13:06:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14113 for ; Wed, 12 Mar 2003 13:06:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CIKt700762 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 13:20:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIKtO00759 for ; Wed, 12 Mar 2003 13:20:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14099 for ; Wed, 12 Mar 2003 13:06:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIKeO00737; Wed, 12 Mar 2003 13:20:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIJAO00663 for ; Wed, 12 Mar 2003 13:19:10 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14064 for ; Wed, 12 Mar 2003 13:04:36 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 13:06:45 -0500 Message-ID: <00e401c2e8db$7687d350$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: Subject: [SeaMoby] Topic #3: Cache contamination Date: Wed, 12 Mar 2003 13:08:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 18:06:45.0478 (UTC) FILETIME=[24941860:01C2E8C2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Since we don't have much time until the IETF meeting next week, I think it would be better to check important points in the mailing list before off-line discussion for a short time during the meeting. As always pointed out, security is a big concern. It was pointed out there was no way to prevent cache contamination in the server approach. Scope-ID was claimed as a solution but it was not really explained in my understanding. I look forward to an explanation of how cache contamination can be prevented in the server approach. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 13:08:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14170 for ; Wed, 12 Mar 2003 13:08:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIKeO00737; Wed, 12 Mar 2003 13:20:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIJAO00663 for ; Wed, 12 Mar 2003 13:19:10 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14064 for ; Wed, 12 Mar 2003 13:04:36 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 13:06:45 -0500 Message-ID: <00e401c2e8db$7687d350$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: Subject: [SeaMoby] Topic #3: Cache contamination Date: Wed, 12 Mar 2003 13:08:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 18:06:45.0478 (UTC) FILETIME=[24941860:01C2E8C2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Since we don't have much time until the IETF meeting next week, I think it would be better to check important points in the mailing list before off-line discussion for a short time during the meeting. As always pointed out, security is a big concern. It was pointed out there was no way to prevent cache contamination in the server approach. Scope-ID was claimed as a solution but it was not really explained in my understanding. I look forward to an explanation of how cache contamination can be prevented in the server approach. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 13:15:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14404 for ; Wed, 12 Mar 2003 13:15:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CIT8h01251 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 13:29:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIT8O01248 for ; Wed, 12 Mar 2003 13:29:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14383 for ; Wed, 12 Mar 2003 13:14:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CISwO01232; Wed, 12 Mar 2003 13:28:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIOuO01019 for ; Wed, 12 Mar 2003 13:24:56 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14274 for ; Wed, 12 Mar 2003 13:10:21 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 13:12:30 -0500 Message-ID: <00eb01c2e8dc$44302410$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , "Marco Liebsch" , Cc: References: <3E6F1344.4080005@ccrle.nec.de> <003a01c2e8cc$04a3a0c0$e26b0f8a@eunsoo> <011201c2e8bf$470f7c70$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 13:13:45 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 18:12:30.0533 (UTC) FILETIME=[F23F4F50:01C2E8C2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > [eunsoo] The question I raised was what is the server's function. You have > > not specified what the server function is. Can you please specify what the > > server function is if it is different from what James mentioned, that is, > > initial population of the cache? > > Also please note that the cache population requires reports from MN in both > > approaches. In the server approach, MN reports L2 address of BS to the > > current AR. In Dycard, MN reports IP address of the previous AR to the > > current AR. You may say the number of bytes in the report in Dycard is > > larger than the server approach. Well, I don't think the difference is so > > significant in the overall performace of the air link. Thus I don't think > > Dycard is more expensive than the server approach. > > > > Your opinions are interesting, but numbers are the way to answer this question. > How about coming up with a byte count of the number of bytes needed over the air > for Dycard v.s. the DT approach? That would help the WG judge which approach is > more spectrally efficient. > [eunsoo] I don't think you want to judge any protocol by just simply counting the number of bytes transmitted over the air. Are you suggesting that the need for the server is to reduce the number of bytes over the air? If we want to count the number of bytes seriously, we should list all the messages and count the sizes and how often each message should be transmitted. If everything else is the same between the two approaches, the server approach sends L2 address to the AR and Dycard sends L2 address and IP address to the AR. So we are talking about the size of one IP address in a message which is sent once per handoff. What is your numerical criteria in judging a protocol with the number of bytes? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 13:15:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14444 for ; Wed, 12 Mar 2003 13:15:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CISwO01232; Wed, 12 Mar 2003 13:28:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIOuO01019 for ; Wed, 12 Mar 2003 13:24:56 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14274 for ; Wed, 12 Mar 2003 13:10:21 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 13:12:30 -0500 Message-ID: <00eb01c2e8dc$44302410$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , "Marco Liebsch" , Cc: References: <3E6F1344.4080005@ccrle.nec.de> <003a01c2e8cc$04a3a0c0$e26b0f8a@eunsoo> <011201c2e8bf$470f7c70$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 13:13:45 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 18:12:30.0533 (UTC) FILETIME=[F23F4F50:01C2E8C2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > [eunsoo] The question I raised was what is the server's function. You have > > not specified what the server function is. Can you please specify what the > > server function is if it is different from what James mentioned, that is, > > initial population of the cache? > > Also please note that the cache population requires reports from MN in both > > approaches. In the server approach, MN reports L2 address of BS to the > > current AR. In Dycard, MN reports IP address of the previous AR to the > > current AR. You may say the number of bytes in the report in Dycard is > > larger than the server approach. Well, I don't think the difference is so > > significant in the overall performace of the air link. Thus I don't think > > Dycard is more expensive than the server approach. > > > > Your opinions are interesting, but numbers are the way to answer this question. > How about coming up with a byte count of the number of bytes needed over the air > for Dycard v.s. the DT approach? That would help the WG judge which approach is > more spectrally efficient. > [eunsoo] I don't think you want to judge any protocol by just simply counting the number of bytes transmitted over the air. Are you suggesting that the need for the server is to reduce the number of bytes over the air? If we want to count the number of bytes seriously, we should list all the messages and count the sizes and how often each message should be transmitted. If everything else is the same between the two approaches, the server approach sends L2 address to the AR and Dycard sends L2 address and IP address to the AR. So we are talking about the size of one IP address in a message which is sent once per handoff. What is your numerical criteria in judging a protocol with the number of bytes? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 13:30:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15051 for ; Wed, 12 Mar 2003 13:30:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CIix703051 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 13:44:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIixO03048 for ; Wed, 12 Mar 2003 13:44:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15022 for ; Wed, 12 Mar 2003 13:30:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIiTO03019; Wed, 12 Mar 2003 13:44:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIh4O02900 for ; Wed, 12 Mar 2003 13:43:04 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14906 for ; Wed, 12 Mar 2003 13:28:29 -0500 (EST) Message-ID: <018801c2e8c5$42aeaba0$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Marco Liebsch" , Cc: References: <3E6F1344.4080005@ccrle.nec.de> <003a01c2e8cc$04a3a0c0$e26b0f8a@eunsoo> <011201c2e8bf$470f7c70$286015ac@T23KEMPF> <00eb01c2e8dc$44302410$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:29:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am not suggesting anything about which approach is better. I am saying that there is an opinion being expressed here by you, namely that bytes don't matter. Putting on my operator hat, operators pay lots of money for spectrum and to us, bytes do matter. A protocol that minimizes the number of bytes over the air is important. Even for free spectrum like 802.11, it is not possible to overprovision the air. Putting more access points into a room after a certain point only leads to more interference. So reducing the load on the wireless link is always a concern. Removing my operator hat and putting on my WG co-chair hat, the way to resolve the question is for someone to come up with some numbers about how many bytes it takes for the Dycard approach v.s. the DT approach. That should be entered into the discussion about which approach is better. Thus, some of the handwaving that I am seeing around this issue from both sides (DT and Dycard) will be removed. The number of bytes won't of course be the only concern, but it will be an important one. If you don't want to do that calculation, perhaps someone from the DT or someone else in the WG would like to do it? jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Marco Liebsch" ; Cc: Sent: Wednesday, March 12, 2003 1:13 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > [eunsoo] The question I raised was what is the server's function. You > have > > > not specified what the server function is. Can you please specify what > the > > > server function is if it is different from what James mentioned, that > is, > > > initial population of the cache? > > > Also please note that the cache population requires reports from MN in > both > > > approaches. In the server approach, MN reports L2 address of BS to the > > > current AR. In Dycard, MN reports IP address of the previous AR to the > > > current AR. You may say the number of bytes in the report in Dycard is > > > larger than the server approach. Well, I don't think the difference is > so > > > significant in the overall performace of the air link. Thus I don't > think > > > Dycard is more expensive than the server approach. > > > > > > > Your opinions are interesting, but numbers are the way to answer this > question. > > How about coming up with a byte count of the number of bytes needed over > the air > > for Dycard v.s. the DT approach? That would help the WG judge which > approach is > > more spectrally efficient. > > > [eunsoo] I don't think you want to judge any protocol by just simply > counting the number of bytes transmitted over the air. Are you suggesting > that the need for the server is to reduce the number of bytes over the air? > If we want to count the number of bytes seriously, we should list all the > messages and count the sizes and how often each message should be > transmitted. If everything else is the same between the two approaches, the > server approach sends L2 address to the AR and Dycard sends L2 address and > IP address to the AR. So we are talking about the size of one IP address in > a message which is sent once per handoff. What is your numerical criteria in > judging a protocol with the number of bytes? > > Eunsoo > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 13:31:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15076 for ; Wed, 12 Mar 2003 13:31:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CIjPq03120 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 13:45:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIjPO03117 for ; Wed, 12 Mar 2003 13:45:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15046 for ; Wed, 12 Mar 2003 13:30:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIj2O03087; Wed, 12 Mar 2003 13:45:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIicO03036 for ; Wed, 12 Mar 2003 13:44:38 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14999 for ; Wed, 12 Mar 2003 13:30:03 -0500 (EST) Message-ID: <019001c2e8c5$7cb82740$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:30:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The server will allow an AR to determine which APs are authorized. The dycard draft has nothing about this. This is an important security measure, though not directly related to exchanging the CAR information. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Wednesday, March 12, 2003 1:00 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > Why are these approaches mutually exclusive? > > > > One of the drawbacks of Dycard is that it needs a learning period. > Naturally, > > the ISP can hire somebody to walk around and seed the cache, but that's > > expensive. A server could prime the cache in the router with a collection > of > > AP/AR mappings that may not be geographically adjacent, but over time the > ones > > that aren't would drop out. Thus, the ISP would not have to go through the > > timeconsuming task of classifying whether they APs are geographically > adjacent. > > > > After the server has been used to initially populate the cache, any > changes > > would be propagated directly by CARD. > > > > [eunsoo] As Govind and Dirk pointed out, the first handoff between two ARs > leads to populating the cache with an entry for the newly discovered CAR in > Dycard. > If you claim that the server will be used only for initial populating the > cache at ARs, please clarify difference from the DT draft. The DT draft does > not say each AR will download a bunch of L2-L3 mapping information from the > server in the beginning of its operation. It will download one by one as MN > requests the mapping or reports a new BS L2 address. > > The only difference between Dycard and the server approach in the learning > period is that MN may be able to do fast handoff for the very first handoff > between two ARs in the server approach while MN will have to do slow handoff > in Dycard. Well, if we are talking about ISP, I don't think they just > install a box and start commercial services. They will go through many > stages of network tests including roaming support. So most likely initial > discoveries will be done during the process and thus they would not feel any > concern for the impact of the learning period for consumers. If we are > talking about more ad-hoc and casual network deployment, I am not sure the > slow handoff for the very first handoff is such a big concern, let say, for > corporate networks or campus networks. I don't think it justifies > introducing a sever. > > Also even if an ISP wants populating the cache by the information from the > server, they cannot tell exactly which entry should be inserted into a cache > unless they know exactly the radio map of the base stations. Well, all this > work is to remove such requirement. Then what they do only is just copying a > bunch of entries from the server to the cache as you suggested. If really > they want to do such a thing, they can use many existing tools. For example, > we can simply define MIB for CARD and they can use SNMP for setting the > values for CARD. This should not affect the fundamental structure of the > protocol. Actually it should be independent of the CARD protocol. Thus it > should not be a part of the CARD protocol except MIB definitions. Defining > MIB does not bring in any need of a server, of course. > > Eunsoo > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 13:31:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15090 for ; Wed, 12 Mar 2003 13:31:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIiTO03019; Wed, 12 Mar 2003 13:44:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIh4O02900 for ; Wed, 12 Mar 2003 13:43:04 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14906 for ; Wed, 12 Mar 2003 13:28:29 -0500 (EST) Message-ID: <018801c2e8c5$42aeaba0$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Marco Liebsch" , Cc: References: <3E6F1344.4080005@ccrle.nec.de> <003a01c2e8cc$04a3a0c0$e26b0f8a@eunsoo> <011201c2e8bf$470f7c70$286015ac@T23KEMPF> <00eb01c2e8dc$44302410$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:29:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I am not suggesting anything about which approach is better. I am saying that there is an opinion being expressed here by you, namely that bytes don't matter. Putting on my operator hat, operators pay lots of money for spectrum and to us, bytes do matter. A protocol that minimizes the number of bytes over the air is important. Even for free spectrum like 802.11, it is not possible to overprovision the air. Putting more access points into a room after a certain point only leads to more interference. So reducing the load on the wireless link is always a concern. Removing my operator hat and putting on my WG co-chair hat, the way to resolve the question is for someone to come up with some numbers about how many bytes it takes for the Dycard approach v.s. the DT approach. That should be entered into the discussion about which approach is better. Thus, some of the handwaving that I am seeing around this issue from both sides (DT and Dycard) will be removed. The number of bytes won't of course be the only concern, but it will be an important one. If you don't want to do that calculation, perhaps someone from the DT or someone else in the WG would like to do it? jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Marco Liebsch" ; Cc: Sent: Wednesday, March 12, 2003 1:13 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > [eunsoo] The question I raised was what is the server's function. You > have > > > not specified what the server function is. Can you please specify what > the > > > server function is if it is different from what James mentioned, that > is, > > > initial population of the cache? > > > Also please note that the cache population requires reports from MN in > both > > > approaches. In the server approach, MN reports L2 address of BS to the > > > current AR. In Dycard, MN reports IP address of the previous AR to the > > > current AR. You may say the number of bytes in the report in Dycard is > > > larger than the server approach. Well, I don't think the difference is > so > > > significant in the overall performace of the air link. Thus I don't > think > > > Dycard is more expensive than the server approach. > > > > > > > Your opinions are interesting, but numbers are the way to answer this > question. > > How about coming up with a byte count of the number of bytes needed over > the air > > for Dycard v.s. the DT approach? That would help the WG judge which > approach is > > more spectrally efficient. > > > [eunsoo] I don't think you want to judge any protocol by just simply > counting the number of bytes transmitted over the air. Are you suggesting > that the need for the server is to reduce the number of bytes over the air? > If we want to count the number of bytes seriously, we should list all the > messages and count the sizes and how often each message should be > transmitted. If everything else is the same between the two approaches, the > server approach sends L2 address to the AR and Dycard sends L2 address and > IP address to the AR. So we are talking about the size of one IP address in > a message which is sent once per handoff. What is your numerical criteria in > judging a protocol with the number of bytes? > > Eunsoo > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 13:31:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15109 for ; Wed, 12 Mar 2003 13:31:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIj2O03087; Wed, 12 Mar 2003 13:45:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIicO03036 for ; Wed, 12 Mar 2003 13:44:38 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14999 for ; Wed, 12 Mar 2003 13:30:03 -0500 (EST) Message-ID: <019001c2e8c5$7cb82740$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 10:30:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The server will allow an AR to determine which APs are authorized. The dycard draft has nothing about this. This is an important security measure, though not directly related to exchanging the CAR information. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Wednesday, March 12, 2003 1:00 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > Why are these approaches mutually exclusive? > > > > One of the drawbacks of Dycard is that it needs a learning period. > Naturally, > > the ISP can hire somebody to walk around and seed the cache, but that's > > expensive. A server could prime the cache in the router with a collection > of > > AP/AR mappings that may not be geographically adjacent, but over time the > ones > > that aren't would drop out. Thus, the ISP would not have to go through the > > timeconsuming task of classifying whether they APs are geographically > adjacent. > > > > After the server has been used to initially populate the cache, any > changes > > would be propagated directly by CARD. > > > > [eunsoo] As Govind and Dirk pointed out, the first handoff between two ARs > leads to populating the cache with an entry for the newly discovered CAR in > Dycard. > If you claim that the server will be used only for initial populating the > cache at ARs, please clarify difference from the DT draft. The DT draft does > not say each AR will download a bunch of L2-L3 mapping information from the > server in the beginning of its operation. It will download one by one as MN > requests the mapping or reports a new BS L2 address. > > The only difference between Dycard and the server approach in the learning > period is that MN may be able to do fast handoff for the very first handoff > between two ARs in the server approach while MN will have to do slow handoff > in Dycard. Well, if we are talking about ISP, I don't think they just > install a box and start commercial services. They will go through many > stages of network tests including roaming support. So most likely initial > discoveries will be done during the process and thus they would not feel any > concern for the impact of the learning period for consumers. If we are > talking about more ad-hoc and casual network deployment, I am not sure the > slow handoff for the very first handoff is such a big concern, let say, for > corporate networks or campus networks. I don't think it justifies > introducing a sever. > > Also even if an ISP wants populating the cache by the information from the > server, they cannot tell exactly which entry should be inserted into a cache > unless they know exactly the radio map of the base stations. Well, all this > work is to remove such requirement. Then what they do only is just copying a > bunch of entries from the server to the cache as you suggested. If really > they want to do such a thing, they can use many existing tools. For example, > we can simply define MIB for CARD and they can use SNMP for setting the > values for CARD. This should not affect the fundamental structure of the > protocol. Actually it should be independent of the CARD protocol. Thus it > should not be a part of the CARD protocol except MIB definitions. Defining > MIB does not bring in any need of a server, of course. > > Eunsoo > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 13:49:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15979 for ; Wed, 12 Mar 2003 13:49:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CJ43E04116 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 14:04:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJ42O04113 for ; Wed, 12 Mar 2003 14:04:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15951 for ; Wed, 12 Mar 2003 13:49:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJ3mO04074; Wed, 12 Mar 2003 14:03:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIx8O03850 for ; Wed, 12 Mar 2003 13:59:08 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15868 for ; Wed, 12 Mar 2003 13:44:33 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 13:46:43 -0500 Message-ID: <014201c2e8e1$0b978440$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> <019001c2e8c5$7cb82740$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 13:47:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 18:46:43.0193 (UTC) FILETIME=[B9BA5E90:01C2E8C7] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The server will allow an AR to determine which APs are authorized. The dycard > draft has nothing about this. This is an important security measure, though not > directly related to exchanging the CAR information. > [eunsoo] The routing protocol (for the wired Internet) has a similar problem. They want to know whether a router is authorized to participate in the route discovery. So for intra-domain routing protocols, usually shared secret is proposed. Also Dycard assumes it in the expression that there should be a security association between ARs. If we consider only intra-domain communication between ARs, shared secret would be sufficient for authorization and message authentication. If you consider central NMS system that allows remote configuration of ARs, it would be very easy to configure the shared secret among ARs. If there is no such thing, people do the configuration by remotely logging into ARs. This one time configuration removes concerns about scalability and reliability. You don't need a server running up 24/7 for this authorization since you don't expect a new AR that often. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 13:50:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16042 for ; Wed, 12 Mar 2003 13:50:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJ3mO04074; Wed, 12 Mar 2003 14:03:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIx8O03850 for ; Wed, 12 Mar 2003 13:59:08 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15868 for ; Wed, 12 Mar 2003 13:44:33 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 13:46:43 -0500 Message-ID: <014201c2e8e1$0b978440$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> <019001c2e8c5$7cb82740$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 13:47:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 18:46:43.0193 (UTC) FILETIME=[B9BA5E90:01C2E8C7] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > The server will allow an AR to determine which APs are authorized. The dycard > draft has nothing about this. This is an important security measure, though not > directly related to exchanging the CAR information. > [eunsoo] The routing protocol (for the wired Internet) has a similar problem. They want to know whether a router is authorized to participate in the route discovery. So for intra-domain routing protocols, usually shared secret is proposed. Also Dycard assumes it in the expression that there should be a security association between ARs. If we consider only intra-domain communication between ARs, shared secret would be sufficient for authorization and message authentication. If you consider central NMS system that allows remote configuration of ARs, it would be very easy to configure the shared secret among ARs. If there is no such thing, people do the configuration by remotely logging into ARs. This one time configuration removes concerns about scalability and reliability. You don't need a server running up 24/7 for this authorization since you don't expect a new AR that often. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 15:03:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18736 for ; Wed, 12 Mar 2003 15:03:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKHVS09928 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 15:17:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKHVO09925 for ; Wed, 12 Mar 2003 15:17:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18680 for ; Wed, 12 Mar 2003 15:02:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKHGO09914; Wed, 12 Mar 2003 15:17:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKGLO09872 for ; Wed, 12 Mar 2003 15:16:21 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18656 for ; Wed, 12 Mar 2003 15:01:44 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CK3r820468 for ; Wed, 12 Mar 2003 14:03:53 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 14:03:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:03:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:03:48 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoxdeKQ3h0zIf9RxerD5Sxwr1UjgACpuoQ To: , , X-OriginalArrivalTime: 12 Mar 2003 20:03:53.0093 (UTC) FILETIME=[815D0B50:01C2E8D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKGLO09873 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, If you read the dycard draft carefully you would notice that dycard assumes that a list of authorized APs are available at each AR. Checks are made to compare L2 ids reported w.r.t authorized L2 ids. The L2 ids put in the cache comes from other trusted ARs. Why can't we assume that they know what L2 devices are connected to the ARs? We don't discuss how this authorized list is put there explicitly. This could be by any existing network management procedure. If Iam not wrong, in the DT draft, I think some L2 mechanism is assumed to exist that lets the AR know about its APs and this is conveyed to the server. Can't the same L2 mechanism be used? Having said that no L2 mechanism is assumed in dycard. It is a learning procedure too. But if something can be assumed for this we can do the same. Thanks, Govind. > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 12, 2003 1:31 PM > To: Eunsoo Shim; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > The server will allow an AR to determine which APs are > authorized. The dycard > draft has nothing about this. This is an important security > measure, though not > directly related to exchanging the CAR information. > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Wednesday, March 12, 2003 1:00 PM > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > Why are these approaches mutually exclusive? > > > > > > One of the drawbacks of Dycard is that it needs a learning period. > > Naturally, > > > the ISP can hire somebody to walk around and seed the > cache, but that's > > > expensive. A server could prime the cache in the router > with a collection > > of > > > AP/AR mappings that may not be geographically adjacent, > but over time the > > ones > > > that aren't would drop out. Thus, the ISP would not have > to go through the > > > timeconsuming task of classifying whether they APs are > geographically > > adjacent. > > > > > > After the server has been used to initially populate the > cache, any > > changes > > > would be propagated directly by CARD. > > > > > > > [eunsoo] As Govind and Dirk pointed out, the first handoff > between two ARs > > leads to populating the cache with an entry for the newly > discovered CAR in > > Dycard. > > If you claim that the server will be used only for initial > populating the > > cache at ARs, please clarify difference from the DT draft. > The DT draft does > > not say each AR will download a bunch of L2-L3 mapping > information from the > > server in the beginning of its operation. It will download > one by one as MN > > requests the mapping or reports a new BS L2 address. > > > > The only difference between Dycard and the server approach > in the learning > > period is that MN may be able to do fast handoff for the > very first handoff > > between two ARs in the server approach while MN will have > to do slow handoff > > in Dycard. Well, if we are talking about ISP, I don't think > they just > > install a box and start commercial services. They will go > through many > > stages of network tests including roaming support. So most > likely initial > > discoveries will be done during the process and thus they > would not feel any > > concern for the impact of the learning period for > consumers. If we are > > talking about more ad-hoc and casual network deployment, I > am not sure the > > slow handoff for the very first handoff is such a big > concern, let say, for > > corporate networks or campus networks. I don't think it justifies > > introducing a sever. > > > > Also even if an ISP wants populating the cache by the > information from the > > server, they cannot tell exactly which entry should be > inserted into a cache > > unless they know exactly the radio map of the base > stations. Well, all this > > work is to remove such requirement. Then what they do only > is just copying a > > bunch of entries from the server to the cache as you > suggested. If really > > they want to do such a thing, they can use many existing > tools. For example, > > we can simply define MIB for CARD and they can use SNMP for > setting the > > values for CARD. This should not affect the fundamental > structure of the > > protocol. Actually it should be independent of the CARD > protocol. Thus it > > should not be a part of the CARD protocol except MIB > definitions. Defining > > MIB does not bring in any need of a server, of course. > > > > Eunsoo > > > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 15:03:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18821 for ; Wed, 12 Mar 2003 15:03:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKHGO09914; Wed, 12 Mar 2003 15:17:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKGLO09872 for ; Wed, 12 Mar 2003 15:16:21 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18656 for ; Wed, 12 Mar 2003 15:01:44 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CK3r820468 for ; Wed, 12 Mar 2003 14:03:53 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 14:03:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:03:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:03:48 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoxdeKQ3h0zIf9RxerD5Sxwr1UjgACpuoQ To: , , X-OriginalArrivalTime: 12 Mar 2003 20:03:53.0093 (UTC) FILETIME=[815D0B50:01C2E8D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKGLO09873 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, If you read the dycard draft carefully you would notice that dycard assumes that a list of authorized APs are available at each AR. Checks are made to compare L2 ids reported w.r.t authorized L2 ids. The L2 ids put in the cache comes from other trusted ARs. Why can't we assume that they know what L2 devices are connected to the ARs? We don't discuss how this authorized list is put there explicitly. This could be by any existing network management procedure. If Iam not wrong, in the DT draft, I think some L2 mechanism is assumed to exist that lets the AR know about its APs and this is conveyed to the server. Can't the same L2 mechanism be used? Having said that no L2 mechanism is assumed in dycard. It is a learning procedure too. But if something can be assumed for this we can do the same. Thanks, Govind. > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 12, 2003 1:31 PM > To: Eunsoo Shim; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > The server will allow an AR to determine which APs are > authorized. The dycard > draft has nothing about this. This is an important security > measure, though not > directly related to exchanging the CAR information. > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Wednesday, March 12, 2003 1:00 PM > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > Why are these approaches mutually exclusive? > > > > > > One of the drawbacks of Dycard is that it needs a learning period. > > Naturally, > > > the ISP can hire somebody to walk around and seed the > cache, but that's > > > expensive. A server could prime the cache in the router > with a collection > > of > > > AP/AR mappings that may not be geographically adjacent, > but over time the > > ones > > > that aren't would drop out. Thus, the ISP would not have > to go through the > > > timeconsuming task of classifying whether they APs are > geographically > > adjacent. > > > > > > After the server has been used to initially populate the > cache, any > > changes > > > would be propagated directly by CARD. > > > > > > > [eunsoo] As Govind and Dirk pointed out, the first handoff > between two ARs > > leads to populating the cache with an entry for the newly > discovered CAR in > > Dycard. > > If you claim that the server will be used only for initial > populating the > > cache at ARs, please clarify difference from the DT draft. > The DT draft does > > not say each AR will download a bunch of L2-L3 mapping > information from the > > server in the beginning of its operation. It will download > one by one as MN > > requests the mapping or reports a new BS L2 address. > > > > The only difference between Dycard and the server approach > in the learning > > period is that MN may be able to do fast handoff for the > very first handoff > > between two ARs in the server approach while MN will have > to do slow handoff > > in Dycard. Well, if we are talking about ISP, I don't think > they just > > install a box and start commercial services. They will go > through many > > stages of network tests including roaming support. So most > likely initial > > discoveries will be done during the process and thus they > would not feel any > > concern for the impact of the learning period for > consumers. If we are > > talking about more ad-hoc and casual network deployment, I > am not sure the > > slow handoff for the very first handoff is such a big > concern, let say, for > > corporate networks or campus networks. I don't think it justifies > > introducing a sever. > > > > Also even if an ISP wants populating the cache by the > information from the > > server, they cannot tell exactly which entry should be > inserted into a cache > > unless they know exactly the radio map of the base > stations. Well, all this > > work is to remove such requirement. Then what they do only > is just copying a > > bunch of entries from the server to the cache as you > suggested. If really > > they want to do such a thing, they can use many existing > tools. For example, > > we can simply define MIB for CARD and they can use SNMP for > setting the > > values for CARD. This should not affect the fundamental > structure of the > > protocol. Actually it should be independent of the CARD > protocol. Thus it > > should not be a part of the CARD protocol except MIB > definitions. Defining > > MIB does not bring in any need of a server, of course. > > > > Eunsoo > > > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 15:22:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20642 for ; Wed, 12 Mar 2003 15:22:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKaPv11097 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 15:36:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKaPO11094 for ; Wed, 12 Mar 2003 15:36:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20635 for ; Wed, 12 Mar 2003 15:21:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKa5O11080; Wed, 12 Mar 2003 15:36:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKZwO11018 for ; Wed, 12 Mar 2003 15:35:58 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20604 for ; Wed, 12 Mar 2003 15:21:19 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CKNT824766 for ; Wed, 12 Mar 2003 14:23:29 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 14:23:28 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:22:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:22:24 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoyHDwsfTwyDW7SMytIqmi/AJxPwADBUFQ To: , , X-OriginalArrivalTime: 12 Mar 2003 20:22:33.0811 (UTC) FILETIME=[1D5D0A30:01C2E8D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKZwO11019 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi: There seems to be some disconnect. The current DT draft does NOT intend solve the problem of enabling AR to determine which APs are authorized. APs are brought up/down and connected to/disconnected from AR. Some L2 layer mechanism between AR-AP enables AR to learn about new/removed AP. AR reports that AP is up/down to CARD server and CARD server stores the mapping. In other words, AR is in control of knowing what APs are attached to it and CARD server relies on information provided by AR regarding this. Hemant -----Original Message----- From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Wednesday, March 12, 2003 4:48 PM To: James Kempf; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > The server will allow an AR to determine which APs are authorized. The dycard > draft has nothing about this. This is an important security measure, though not > directly related to exchanging the CAR information. > [eunsoo] The routing protocol (for the wired Internet) has a similar problem. They want to know whether a router is authorized to participate in the route discovery. So for intra-domain routing protocols, usually shared secret is proposed. Also Dycard assumes it in the expression that there should be a security association between ARs. If we consider only intra-domain communication between ARs, shared secret would be sufficient for authorization and message authentication. If you consider central NMS system that allows remote configuration of ARs, it would be very easy to configure the shared secret among ARs. If there is no such thing, people do the configuration by remotely logging into ARs. This one time configuration removes concerns about scalability and reliability. You don't need a server running up 24/7 for this authorization since you don't expect a new AR that often. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 15:24:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20710 for ; Wed, 12 Mar 2003 15:24:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKa5O11080; Wed, 12 Mar 2003 15:36:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKZwO11018 for ; Wed, 12 Mar 2003 15:35:58 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20604 for ; Wed, 12 Mar 2003 15:21:19 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CKNT824766 for ; Wed, 12 Mar 2003 14:23:29 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 14:23:28 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:22:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:22:24 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoyHDwsfTwyDW7SMytIqmi/AJxPwADBUFQ To: , , X-OriginalArrivalTime: 12 Mar 2003 20:22:33.0811 (UTC) FILETIME=[1D5D0A30:01C2E8D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKZwO11019 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi: There seems to be some disconnect. The current DT draft does NOT intend solve the problem of enabling AR to determine which APs are authorized. APs are brought up/down and connected to/disconnected from AR. Some L2 layer mechanism between AR-AP enables AR to learn about new/removed AP. AR reports that AP is up/down to CARD server and CARD server stores the mapping. In other words, AR is in control of knowing what APs are attached to it and CARD server relies on information provided by AR regarding this. Hemant -----Original Message----- From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Wednesday, March 12, 2003 4:48 PM To: James Kempf; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > The server will allow an AR to determine which APs are authorized. The dycard > draft has nothing about this. This is an important security measure, though not > directly related to exchanging the CAR information. > [eunsoo] The routing protocol (for the wired Internet) has a similar problem. They want to know whether a router is authorized to participate in the route discovery. So for intra-domain routing protocols, usually shared secret is proposed. Also Dycard assumes it in the expression that there should be a security association between ARs. If we consider only intra-domain communication between ARs, shared secret would be sufficient for authorization and message authentication. If you consider central NMS system that allows remote configuration of ARs, it would be very easy to configure the shared secret among ARs. If there is no such thing, people do the configuration by remotely logging into ARs. This one time configuration removes concerns about scalability and reliability. You don't need a server running up 24/7 for this authorization since you don't expect a new AR that often. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 15:31:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20954 for ; Wed, 12 Mar 2003 15:31:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKjHE12412 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 15:45:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKjHO12409 for ; Wed, 12 Mar 2003 15:45:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20940 for ; Wed, 12 Mar 2003 15:30:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKj5O12380; Wed, 12 Mar 2003 15:45:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKi2O12300 for ; Wed, 12 Mar 2003 15:44:02 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20883 for ; Wed, 12 Mar 2003 15:29:23 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CKVYa24261 for ; Wed, 12 Mar 2003 14:31:34 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 14:31:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:31:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:31:29 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoxdq6SNOR2nBYSuGdDy+RTE16RAAD+IFA To: , , , Cc: X-OriginalArrivalTime: 12 Mar 2003 20:31:31.0692 (UTC) FILETIME=[5DF72AC0:01C2E8D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKi2O12303 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: Numbers are good way to analyze. (DT hat off), for dyCARD it is easy calculation. Sending one piggybacked message (= at least 126 bytes for IPv6 address + few header bytes) is the overhead per handoff on uplink. Here I make similar assumption to server based approach (AR knows its APs via L2 mechanisms). This does not matter at all for 802.11. For paid spectrum technologies argument can be made either way. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 12, 2003 1:29 PM To: Eunsoo Shim; Marco Liebsch; Krishnamurthi Govind (NRC/Boston) Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD I am not suggesting anything about which approach is better. I am saying that there is an opinion being expressed here by you, namely that bytes don't matter. Putting on my operator hat, operators pay lots of money for spectrum and to us, bytes do matter. A protocol that minimizes the number of bytes over the air is important. Even for free spectrum like 802.11, it is not possible to overprovision the air. Putting more access points into a room after a certain point only leads to more interference. So reducing the load on the wireless link is always a concern. Removing my operator hat and putting on my WG co-chair hat, the way to resolve the question is for someone to come up with some numbers about how many bytes it takes for the Dycard approach v.s. the DT approach. That should be entered into the discussion about which approach is better. Thus, some of the handwaving that I am seeing around this issue from both sides (DT and Dycard) will be removed. The number of bytes won't of course be the only concern, but it will be an important one. If you don't want to do that calculation, perhaps someone from the DT or someone else in the WG would like to do it? jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Marco Liebsch" ; Cc: Sent: Wednesday, March 12, 2003 1:13 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > [eunsoo] The question I raised was what is the server's function. You > have > > > not specified what the server function is. Can you please specify what > the > > > server function is if it is different from what James mentioned, that > is, > > > initial population of the cache? > > > Also please note that the cache population requires reports from MN in > both > > > approaches. In the server approach, MN reports L2 address of BS to the > > > current AR. In Dycard, MN reports IP address of the previous AR to the > > > current AR. You may say the number of bytes in the report in Dycard is > > > larger than the server approach. Well, I don't think the difference is > so > > > significant in the overall performace of the air link. Thus I don't > think > > > Dycard is more expensive than the server approach. > > > > > > > Your opinions are interesting, but numbers are the way to answer this > question. > > How about coming up with a byte count of the number of bytes needed over > the air > > for Dycard v.s. the DT approach? That would help the WG judge which > approach is > > more spectrally efficient. > > > [eunsoo] I don't think you want to judge any protocol by just simply > counting the number of bytes transmitted over the air. Are you suggesting > that the need for the server is to reduce the number of bytes over the air? > If we want to count the number of bytes seriously, we should list all the > messages and count the sizes and how often each message should be > transmitted. If everything else is the same between the two approaches, the > server approach sends L2 address to the AR and Dycard sends L2 address and > IP address to the AR. So we are talking about the size of one IP address in > a message which is sent once per handoff. What is your numerical criteria in > judging a protocol with the number of bytes? > > Eunsoo > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 15:31:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20974 for ; Wed, 12 Mar 2003 15:31:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKj5O12380; Wed, 12 Mar 2003 15:45:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKi2O12300 for ; Wed, 12 Mar 2003 15:44:02 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20883 for ; Wed, 12 Mar 2003 15:29:23 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CKVYa24261 for ; Wed, 12 Mar 2003 14:31:34 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 14:31:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:31:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:31:29 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoxdq6SNOR2nBYSuGdDy+RTE16RAAD+IFA To: , , , Cc: X-OriginalArrivalTime: 12 Mar 2003 20:31:31.0692 (UTC) FILETIME=[5DF72AC0:01C2E8D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKi2O12303 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: Numbers are good way to analyze. (DT hat off), for dyCARD it is easy calculation. Sending one piggybacked message (= at least 126 bytes for IPv6 address + few header bytes) is the overhead per handoff on uplink. Here I make similar assumption to server based approach (AR knows its APs via L2 mechanisms). This does not matter at all for 802.11. For paid spectrum technologies argument can be made either way. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 12, 2003 1:29 PM To: Eunsoo Shim; Marco Liebsch; Krishnamurthi Govind (NRC/Boston) Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD I am not suggesting anything about which approach is better. I am saying that there is an opinion being expressed here by you, namely that bytes don't matter. Putting on my operator hat, operators pay lots of money for spectrum and to us, bytes do matter. A protocol that minimizes the number of bytes over the air is important. Even for free spectrum like 802.11, it is not possible to overprovision the air. Putting more access points into a room after a certain point only leads to more interference. So reducing the load on the wireless link is always a concern. Removing my operator hat and putting on my WG co-chair hat, the way to resolve the question is for someone to come up with some numbers about how many bytes it takes for the Dycard approach v.s. the DT approach. That should be entered into the discussion about which approach is better. Thus, some of the handwaving that I am seeing around this issue from both sides (DT and Dycard) will be removed. The number of bytes won't of course be the only concern, but it will be an important one. If you don't want to do that calculation, perhaps someone from the DT or someone else in the WG would like to do it? jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Marco Liebsch" ; Cc: Sent: Wednesday, March 12, 2003 1:13 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > [eunsoo] The question I raised was what is the server's function. You > have > > > not specified what the server function is. Can you please specify what > the > > > server function is if it is different from what James mentioned, that > is, > > > initial population of the cache? > > > Also please note that the cache population requires reports from MN in > both > > > approaches. In the server approach, MN reports L2 address of BS to the > > > current AR. In Dycard, MN reports IP address of the previous AR to the > > > current AR. You may say the number of bytes in the report in Dycard is > > > larger than the server approach. Well, I don't think the difference is > so > > > significant in the overall performace of the air link. Thus I don't > think > > > Dycard is more expensive than the server approach. > > > > > > > Your opinions are interesting, but numbers are the way to answer this > question. > > How about coming up with a byte count of the number of bytes needed over > the air > > for Dycard v.s. the DT approach? That would help the WG judge which > approach is > > more spectrally efficient. > > > [eunsoo] I don't think you want to judge any protocol by just simply > counting the number of bytes transmitted over the air. Are you suggesting > that the need for the server is to reduce the number of bytes over the air? > If we want to count the number of bytes seriously, we should list all the > messages and count the sizes and how often each message should be > transmitted. If everything else is the same between the two approaches, the > server approach sends L2 address to the AR and Dycard sends L2 address and > IP address to the AR. So we are talking about the size of one IP address in > a message which is sent once per handoff. What is your numerical criteria in > judging a protocol with the number of bytes? > > Eunsoo > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 15:37:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21203 for ; Wed, 12 Mar 2003 15:37:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKpQA12789 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 15:51:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKpQO12786 for ; Wed, 12 Mar 2003 15:51:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21124 for ; Wed, 12 Mar 2003 15:36:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKpAO12684; Wed, 12 Mar 2003 15:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKmcO12541 for ; Wed, 12 Mar 2003 15:48:38 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21020 for ; Wed, 12 Mar 2003 15:33:59 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CKaCa25558 for ; Wed, 12 Mar 2003 14:36:12 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Mar 2003 14:36:09 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 12:36:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:36:03 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoxdeKQ3h0zIf9RxerD5Sxwr1UjgACpuoQAAFtwyA= To: X-OriginalArrivalTime: 12 Mar 2003 20:36:09.0192 (UTC) FILETIME=[035E4E80:01C2E8D7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKmcO12542 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Having said that no L2 mechanism is assumed in dycard. > It is a learning procedure too. But if something can be > assumed for this we can do the same. Just to clarify this earlier sentence in my earlier email. dycard assumes an authorized list of APs exist at each AR that determines which APs are allowed to connect to the AR. However no L2 mechanism is assumed to tell the AR which APs are currently connected. Soft states are maintained for AP information also, and MN updates are used to figure this out. We use this to take care of AP failures and change in topology etc.. However, if an L2 mechanism exists that allows the AR to know which APs are currently connected we can reuse that here too. Sorry for any confusion. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 15:37:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21215 for ; Wed, 12 Mar 2003 15:37:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKpRO12805 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 15:51:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKpQO12802 for ; Wed, 12 Mar 2003 15:51:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21126 for ; Wed, 12 Mar 2003 15:36:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKp8O12668; Wed, 12 Mar 2003 15:51:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKlWO12522 for ; Wed, 12 Mar 2003 15:47:32 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21015 for ; Wed, 12 Mar 2003 15:32:53 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CKZ6a25409 for ; Wed, 12 Mar 2003 14:35:06 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 14:35:03 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:35:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:35:01 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoxdq6SNOR2nBYSuGdDy+RTE16RAAD+IFAAAA/xmA= To: , , , , Cc: X-OriginalArrivalTime: 12 Mar 2003 20:35:03.0258 (UTC) FILETIME=[DC1193A0:01C2E8D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKlWO12523 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sorry, it was 128 bit for IPv6 address. I don't know what I was smoking. ;-) Hemant -----Original Message----- From: ext Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 12, 2003 3:31 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; Marco.Liebsch@ccrle.nec.de; Krishnamurthi Govind (NRC/Boston) Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi James: Numbers are good way to analyze. (DT hat off), for dyCARD it is easy calculation. Sending one piggybacked message (= at least 126 bytes for IPv6 address + few header bytes) is the overhead per handoff on uplink. Here I make similar assumption to server based approach (AR knows its APs via L2 mechanisms). This does not matter at all for 802.11. For paid spectrum technologies argument can be made either way. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 12, 2003 1:29 PM To: Eunsoo Shim; Marco Liebsch; Krishnamurthi Govind (NRC/Boston) Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD I am not suggesting anything about which approach is better. I am saying that there is an opinion being expressed here by you, namely that bytes don't matter. Putting on my operator hat, operators pay lots of money for spectrum and to us, bytes do matter. A protocol that minimizes the number of bytes over the air is important. Even for free spectrum like 802.11, it is not possible to overprovision the air. Putting more access points into a room after a certain point only leads to more interference. So reducing the load on the wireless link is always a concern. Removing my operator hat and putting on my WG co-chair hat, the way to resolve the question is for someone to come up with some numbers about how many bytes it takes for the Dycard approach v.s. the DT approach. That should be entered into the discussion about which approach is better. Thus, some of the handwaving that I am seeing around this issue from both sides (DT and Dycard) will be removed. The number of bytes won't of course be the only concern, but it will be an important one. If you don't want to do that calculation, perhaps someone from the DT or someone else in the WG would like to do it? jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Marco Liebsch" ; Cc: Sent: Wednesday, March 12, 2003 1:13 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > [eunsoo] The question I raised was what is the server's function. You > have > > > not specified what the server function is. Can you please specify what > the > > > server function is if it is different from what James mentioned, that > is, > > > initial population of the cache? > > > Also please note that the cache population requires reports from MN in > both > > > approaches. In the server approach, MN reports L2 address of BS to the > > > current AR. In Dycard, MN reports IP address of the previous AR to the > > > current AR. You may say the number of bytes in the report in Dycard is > > > larger than the server approach. Well, I don't think the difference is > so > > > significant in the overall performace of the air link. Thus I don't > think > > > Dycard is more expensive than the server approach. > > > > > > > Your opinions are interesting, but numbers are the way to answer this > question. > > How about coming up with a byte count of the number of bytes needed over > the air > > for Dycard v.s. the DT approach? That would help the WG judge which > approach is > > more spectrally efficient. > > > [eunsoo] I don't think you want to judge any protocol by just simply > counting the number of bytes transmitted over the air. Are you suggesting > that the need for the server is to reduce the number of bytes over the air? > If we want to count the number of bytes seriously, we should list all the > messages and count the sizes and how often each message should be > transmitted. If everything else is the same between the two approaches, the > server approach sends L2 address to the AR and Dycard sends L2 address and > IP address to the AR. So we are talking about the size of one IP address in > a message which is sent once per handoff. What is your numerical criteria in > judging a protocol with the number of bytes? > > Eunsoo > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 15:37:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21233 for ; Wed, 12 Mar 2003 15:37:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKpAO12684; Wed, 12 Mar 2003 15:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKmcO12541 for ; Wed, 12 Mar 2003 15:48:38 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21020 for ; Wed, 12 Mar 2003 15:33:59 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CKaCa25558 for ; Wed, 12 Mar 2003 14:36:12 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Mar 2003 14:36:09 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 12:36:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:36:03 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoxdeKQ3h0zIf9RxerD5Sxwr1UjgACpuoQAAFtwyA= To: X-OriginalArrivalTime: 12 Mar 2003 20:36:09.0192 (UTC) FILETIME=[035E4E80:01C2E8D7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKmcO12542 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Having said that no L2 mechanism is assumed in dycard. > It is a learning procedure too. But if something can be > assumed for this we can do the same. Just to clarify this earlier sentence in my earlier email. dycard assumes an authorized list of APs exist at each AR that determines which APs are allowed to connect to the AR. However no L2 mechanism is assumed to tell the AR which APs are currently connected. Soft states are maintained for AP information also, and MN updates are used to figure this out. We use this to take care of AP failures and change in topology etc.. However, if an L2 mechanism exists that allows the AR to know which APs are currently connected we can reuse that here too. Sorry for any confusion. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 15:37:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21248 for ; Wed, 12 Mar 2003 15:37:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKp8O12668; Wed, 12 Mar 2003 15:51:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKlWO12522 for ; Wed, 12 Mar 2003 15:47:32 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21015 for ; Wed, 12 Mar 2003 15:32:53 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CKZ6a25409 for ; Wed, 12 Mar 2003 14:35:06 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 14:35:03 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 14:35:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 15:35:01 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLoxdq6SNOR2nBYSuGdDy+RTE16RAAD+IFAAAA/xmA= To: , , , , Cc: X-OriginalArrivalTime: 12 Mar 2003 20:35:03.0258 (UTC) FILETIME=[DC1193A0:01C2E8D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CKlWO12523 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Sorry, it was 128 bit for IPv6 address. I don't know what I was smoking. ;-) Hemant -----Original Message----- From: ext Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Wednesday, March 12, 2003 3:31 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; Marco.Liebsch@ccrle.nec.de; Krishnamurthi Govind (NRC/Boston) Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi James: Numbers are good way to analyze. (DT hat off), for dyCARD it is easy calculation. Sending one piggybacked message (= at least 126 bytes for IPv6 address + few header bytes) is the overhead per handoff on uplink. Here I make similar assumption to server based approach (AR knows its APs via L2 mechanisms). This does not matter at all for 802.11. For paid spectrum technologies argument can be made either way. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 12, 2003 1:29 PM To: Eunsoo Shim; Marco Liebsch; Krishnamurthi Govind (NRC/Boston) Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD I am not suggesting anything about which approach is better. I am saying that there is an opinion being expressed here by you, namely that bytes don't matter. Putting on my operator hat, operators pay lots of money for spectrum and to us, bytes do matter. A protocol that minimizes the number of bytes over the air is important. Even for free spectrum like 802.11, it is not possible to overprovision the air. Putting more access points into a room after a certain point only leads to more interference. So reducing the load on the wireless link is always a concern. Removing my operator hat and putting on my WG co-chair hat, the way to resolve the question is for someone to come up with some numbers about how many bytes it takes for the Dycard approach v.s. the DT approach. That should be entered into the discussion about which approach is better. Thus, some of the handwaving that I am seeing around this issue from both sides (DT and Dycard) will be removed. The number of bytes won't of course be the only concern, but it will be an important one. If you don't want to do that calculation, perhaps someone from the DT or someone else in the WG would like to do it? jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Marco Liebsch" ; Cc: Sent: Wednesday, March 12, 2003 1:13 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > [eunsoo] The question I raised was what is the server's function. You > have > > > not specified what the server function is. Can you please specify what > the > > > server function is if it is different from what James mentioned, that > is, > > > initial population of the cache? > > > Also please note that the cache population requires reports from MN in > both > > > approaches. In the server approach, MN reports L2 address of BS to the > > > current AR. In Dycard, MN reports IP address of the previous AR to the > > > current AR. You may say the number of bytes in the report in Dycard is > > > larger than the server approach. Well, I don't think the difference is > so > > > significant in the overall performace of the air link. Thus I don't > think > > > Dycard is more expensive than the server approach. > > > > > > > Your opinions are interesting, but numbers are the way to answer this > question. > > How about coming up with a byte count of the number of bytes needed over > the air > > for Dycard v.s. the DT approach? That would help the WG judge which > approach is > > more spectrally efficient. > > > [eunsoo] I don't think you want to judge any protocol by just simply > counting the number of bytes transmitted over the air. Are you suggesting > that the need for the server is to reduce the number of bytes over the air? > If we want to count the number of bytes seriously, we should list all the > messages and count the sizes and how often each message should be > transmitted. If everything else is the same between the two approaches, the > server approach sends L2 address to the AR and Dycard sends L2 address and > IP address to the AR. So we are talking about the size of one IP address in > a message which is sent once per handoff. What is your numerical criteria in > judging a protocol with the number of bytes? > > Eunsoo > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 15:49:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21614 for ; Wed, 12 Mar 2003 15:49:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CL3Kp13269 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 16:03:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CL3KO13266 for ; Wed, 12 Mar 2003 16:03:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21602 for ; Wed, 12 Mar 2003 15:48:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CL39O13243; Wed, 12 Mar 2003 16:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CL2tO13228 for ; Wed, 12 Mar 2003 16:02:55 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21585 for ; Wed, 12 Mar 2003 15:48:17 -0500 (EST) Message-ID: <01e101c2e8d8$cc8a9790$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> <019001c2e8c5$7cb82740$286015ac@T23KEMPF> <014201c2e8e1$0b978440$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 12:48:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I obviously did not make myself clear. There is need for some mechanism, independent of any interrouter exchange of information, for a router to determine whether a particular AP is, in fact, authorized. This mechanism functions as a trust root, if you will. That is what I was referring to. Or were you proposing a protocol between APs and ARs to allow the AR to validate whether an AP is authorized? jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Wednesday, March 12, 2003 1:47 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > The server will allow an AR to determine which APs are authorized. The > dycard > > draft has nothing about this. This is an important security measure, > though not > > directly related to exchanging the CAR information. > > > [eunsoo] The routing protocol (for the wired Internet) has a similar > problem. They want to know whether a router is authorized to participate in > the route discovery. So for intra-domain routing protocols, usually shared > secret is proposed. Also Dycard assumes it in the expression that there > should be a security association between ARs. If we consider only > intra-domain communication between ARs, shared secret would be sufficient > for authorization and message authentication. If you consider central NMS > system that allows remote configuration of ARs, it would be very easy to > configure the shared secret among ARs. If there is no such thing, people do > the configuration by remotely logging into ARs. This one time configuration > removes concerns about scalability and reliability. You don't need a server > running up 24/7 for this authorization since you don't expect a new AR that > often. > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 15:49:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21635 for ; Wed, 12 Mar 2003 15:49:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CL39O13243; Wed, 12 Mar 2003 16:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CL2tO13228 for ; Wed, 12 Mar 2003 16:02:55 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21585 for ; Wed, 12 Mar 2003 15:48:17 -0500 (EST) Message-ID: <01e101c2e8d8$cc8a9790$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> <019001c2e8c5$7cb82740$286015ac@T23KEMPF> <014201c2e8e1$0b978440$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 12:48:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I obviously did not make myself clear. There is need for some mechanism, independent of any interrouter exchange of information, for a router to determine whether a particular AP is, in fact, authorized. This mechanism functions as a trust root, if you will. That is what I was referring to. Or were you proposing a protocol between APs and ARs to allow the AR to validate whether an AP is authorized? jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Wednesday, March 12, 2003 1:47 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > The server will allow an AR to determine which APs are authorized. The > dycard > > draft has nothing about this. This is an important security measure, > though not > > directly related to exchanging the CAR information. > > > [eunsoo] The routing protocol (for the wired Internet) has a similar > problem. They want to know whether a router is authorized to participate in > the route discovery. So for intra-domain routing protocols, usually shared > secret is proposed. Also Dycard assumes it in the expression that there > should be a security association between ARs. If we consider only > intra-domain communication between ARs, shared secret would be sufficient > for authorization and message authentication. If you consider central NMS > system that allows remote configuration of ARs, it would be very easy to > configure the shared secret among ARs. If there is no such thing, people do > the configuration by remotely logging into ARs. This one time configuration > removes concerns about scalability and reliability. You don't need a server > running up 24/7 for this authorization since you don't expect a new AR that > often. > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 15:59:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22198 for ; Wed, 12 Mar 2003 15:59:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLDUv14728 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 16:13:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLDTO14725 for ; Wed, 12 Mar 2003 16:13:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22136 for ; Wed, 12 Mar 2003 15:58:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLD8O14673; Wed, 12 Mar 2003 16:13:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLCBO14600 for ; Wed, 12 Mar 2003 16:12:11 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21986 for ; Wed, 12 Mar 2003 15:57:32 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 15:59:42 -0500 Message-ID: <01aa01c2e8f3$9f1bc750$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> <019001c2e8c5$7cb82740$286015ac@T23KEMPF> <014201c2e8e1$0b978440$e26b0f8a@eunsoo> <01e101c2e8d8$cc8a9790$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:00:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 20:59:42.0130 (UTC) FILETIME=[4D8B8920:01C2E8DA] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, I do not propose any protocol between AP and AR for authorization check at this moment, In general, AP is a L2 device and communication between AP and AR is L2 communication thus such a protocol would be specific to each L2 technology unless we assume AP has an IP address. For checking AP authorization, I'd say it is sufficient to have static configuration for the list of authorized and associated APs at each AR as Govind mentioned. Also please note that Hemant pointed out the server is not meant to provide authorization of APs. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; Sent: Wednesday, March 12, 2003 12:48 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > I obviously did not make myself clear. > > There is need for some mechanism, independent of any interrouter exchange of > information, for a router to determine whether a particular AP is, in fact, > authorized. This mechanism functions as a trust root, if you will. That is what > I was referring to. > > Or were you proposing a protocol between APs and ARs to allow the AR to validate > whether an AP is authorized? > > jak > > > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Wednesday, March 12, 2003 1:47 PM > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > The server will allow an AR to determine which APs are authorized. The > > dycard > > > draft has nothing about this. This is an important security measure, > > though not > > > directly related to exchanging the CAR information. > > > > > [eunsoo] The routing protocol (for the wired Internet) has a similar > > problem. They want to know whether a router is authorized to participate in > > the route discovery. So for intra-domain routing protocols, usually shared > > secret is proposed. Also Dycard assumes it in the expression that there > > should be a security association between ARs. If we consider only > > intra-domain communication between ARs, shared secret would be sufficient > > for authorization and message authentication. If you consider central NMS > > system that allows remote configuration of ARs, it would be very easy to > > configure the shared secret among ARs. If there is no such thing, people do > > the configuration by remotely logging into ARs. This one time configuration > > removes concerns about scalability and reliability. You don't need a server > > running up 24/7 for this authorization since you don't expect a new AR that > > often. > > > > Eunsoo > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 15:59:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22214 for ; Wed, 12 Mar 2003 15:59:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLDVa14745 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 16:13:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLDVO14741 for ; Wed, 12 Mar 2003 16:13:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22138 for ; Wed, 12 Mar 2003 15:58:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLDCO14691; Wed, 12 Mar 2003 16:13:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLCvO14642 for ; Wed, 12 Mar 2003 16:12:57 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22046 for ; Wed, 12 Mar 2003 15:58:17 -0500 (EST) Message-ID: <020a01c2e8da$322d4f60$286015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 12:56:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It's that assumption I am questioning. For that to be made, there needs to be some reasonable idea of mechanism, otherwise, the protocol is not deployable. I'm suggesting that a server is one possible approach to providing the mechanism. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 12, 2003 12:03 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Jim, > If you read the dycard draft carefully you would notice that dycard assumes that a list of authorized APs > are available at each AR. Checks are made to compare L2 ids reported w.r.t authorized L2 ids. > The L2 ids put in the cache comes from other trusted ARs. Why can't we assume that they know > what L2 devices are connected to the ARs? > We don't discuss how this authorized list is put there explicitly. > This could be by any existing network management procedure. > > If Iam not wrong, in the DT draft, I think some L2 mechanism is assumed to exist that lets > the AR know about its APs and this is conveyed to the server. Can't the same > L2 mechanism be used? > > Having said that no L2 mechanism is assumed in dycard. > It is a learning procedure too. But if something can be assumed for this we can do the same. > > > Thanks, > Govind. > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, March 12, 2003 1:31 PM > > To: Eunsoo Shim; seamoby@ietf.org > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > The server will allow an AR to determine which APs are > > authorized. The dycard > > draft has nothing about this. This is an important security > > measure, though not > > directly related to exchanging the CAR information. > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "James Kempf" ; > > Sent: Wednesday, March 12, 2003 1:00 PM > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > > > > > > Why are these approaches mutually exclusive? > > > > > > > > One of the drawbacks of Dycard is that it needs a learning period. > > > Naturally, > > > > the ISP can hire somebody to walk around and seed the > > cache, but that's > > > > expensive. A server could prime the cache in the router > > with a collection > > > of > > > > AP/AR mappings that may not be geographically adjacent, > > but over time the > > > ones > > > > that aren't would drop out. Thus, the ISP would not have > > to go through the > > > > timeconsuming task of classifying whether they APs are > > geographically > > > adjacent. > > > > > > > > After the server has been used to initially populate the > > cache, any > > > changes > > > > would be propagated directly by CARD. > > > > > > > > > > [eunsoo] As Govind and Dirk pointed out, the first handoff > > between two ARs > > > leads to populating the cache with an entry for the newly > > discovered CAR in > > > Dycard. > > > If you claim that the server will be used only for initial > > populating the > > > cache at ARs, please clarify difference from the DT draft. > > The DT draft does > > > not say each AR will download a bunch of L2-L3 mapping > > information from the > > > server in the beginning of its operation. It will download > > one by one as MN > > > requests the mapping or reports a new BS L2 address. > > > > > > The only difference between Dycard and the server approach > > in the learning > > > period is that MN may be able to do fast handoff for the > > very first handoff > > > between two ARs in the server approach while MN will have > > to do slow handoff > > > in Dycard. Well, if we are talking about ISP, I don't think > > they just > > > install a box and start commercial services. They will go > > through many > > > stages of network tests including roaming support. So most > > likely initial > > > discoveries will be done during the process and thus they > > would not feel any > > > concern for the impact of the learning period for > > consumers. If we are > > > talking about more ad-hoc and casual network deployment, I > > am not sure the > > > slow handoff for the very first handoff is such a big > > concern, let say, for > > > corporate networks or campus networks. I don't think it justifies > > > introducing a sever. > > > > > > Also even if an ISP wants populating the cache by the > > information from the > > > server, they cannot tell exactly which entry should be > > inserted into a cache > > > unless they know exactly the radio map of the base > > stations. Well, all this > > > work is to remove such requirement. Then what they do only > > is just copying a > > > bunch of entries from the server to the cache as you > > suggested. If really > > > they want to do such a thing, they can use many existing > > tools. For example, > > > we can simply define MIB for CARD and they can use SNMP for > > setting the > > > values for CARD. This should not affect the fundamental > > structure of the > > > protocol. Actually it should be independent of the CARD > > protocol. Thus it > > > should not be a part of the CARD protocol except MIB > > definitions. Defining > > > MIB does not bring in any need of a server, of course. > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 15:59:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22247 for ; Wed, 12 Mar 2003 15:59:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLD8O14673; Wed, 12 Mar 2003 16:13:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLCBO14600 for ; Wed, 12 Mar 2003 16:12:11 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21986 for ; Wed, 12 Mar 2003 15:57:32 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 15:59:42 -0500 Message-ID: <01aa01c2e8f3$9f1bc750$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <012501c2e820$3a2117c0$e26b0f8a@eunsoo> <035c01c2e81f$08cae4e0$156015ac@T23KEMPF> <00d401c2e8da$7a6f1510$e26b0f8a@eunsoo> <019001c2e8c5$7cb82740$286015ac@T23KEMPF> <014201c2e8e1$0b978440$e26b0f8a@eunsoo> <01e101c2e8d8$cc8a9790$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:00:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 12 Mar 2003 20:59:42.0130 (UTC) FILETIME=[4D8B8920:01C2E8DA] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well, I do not propose any protocol between AP and AR for authorization check at this moment, In general, AP is a L2 device and communication between AP and AR is L2 communication thus such a protocol would be specific to each L2 technology unless we assume AP has an IP address. For checking AP authorization, I'd say it is sufficient to have static configuration for the list of authorized and associated APs at each AR as Govind mentioned. Also please note that Hemant pointed out the server is not meant to provide authorization of APs. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; Sent: Wednesday, March 12, 2003 12:48 PM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > I obviously did not make myself clear. > > There is need for some mechanism, independent of any interrouter exchange of > information, for a router to determine whether a particular AP is, in fact, > authorized. This mechanism functions as a trust root, if you will. That is what > I was referring to. > > Or were you proposing a protocol between APs and ARs to allow the AR to validate > whether an AP is authorized? > > jak > > > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Wednesday, March 12, 2003 1:47 PM > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > The server will allow an AR to determine which APs are authorized. The > > dycard > > > draft has nothing about this. This is an important security measure, > > though not > > > directly related to exchanging the CAR information. > > > > > [eunsoo] The routing protocol (for the wired Internet) has a similar > > problem. They want to know whether a router is authorized to participate in > > the route discovery. So for intra-domain routing protocols, usually shared > > secret is proposed. Also Dycard assumes it in the expression that there > > should be a security association between ARs. If we consider only > > intra-domain communication between ARs, shared secret would be sufficient > > for authorization and message authentication. If you consider central NMS > > system that allows remote configuration of ARs, it would be very easy to > > configure the shared secret among ARs. If there is no such thing, people do > > the configuration by remotely logging into ARs. This one time configuration > > removes concerns about scalability and reliability. You don't need a server > > running up 24/7 for this authorization since you don't expect a new AR that > > often. > > > > Eunsoo > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 16:00:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22357 for ; Wed, 12 Mar 2003 16:00:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLEdL14881 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 16:14:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLEdO14878 for ; Wed, 12 Mar 2003 16:14:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22290 for ; Wed, 12 Mar 2003 16:00:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLETO14861; Wed, 12 Mar 2003 16:14:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLDxO14774 for ; Wed, 12 Mar 2003 16:13:59 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22196 for ; Wed, 12 Mar 2003 15:59:21 -0500 (EST) Message-ID: <021401c2e8da$58595800$286015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 12:58:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit No disconnect. My point was, this is a deficiency with both drafts. It is an issue we need to resolve before we can consider the design complete. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 12, 2003 12:22 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Hi: > > There seems to be some disconnect. The current DT draft does NOT intend solve the problem of enabling AR to determine which APs are authorized. APs are brought up/down and connected to/disconnected from AR. Some L2 layer mechanism between AR-AP enables AR to learn about new/removed AP. AR reports that AP is up/down to CARD server and CARD server stores the mapping. In other words, AR is in control of knowing what APs are attached to it and CARD server relies on information provided by AR regarding this. > > Hemant > > -----Original Message----- > From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > Sent: Wednesday, March 12, 2003 4:48 PM > To: James Kempf; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > The server will allow an AR to determine which APs are authorized. The > dycard > > draft has nothing about this. This is an important security measure, > though not > > directly related to exchanging the CAR information. > > > [eunsoo] The routing protocol (for the wired Internet) has a similar > problem. They want to know whether a router is authorized to participate in > the route discovery. So for intra-domain routing protocols, usually shared > secret is proposed. Also Dycard assumes it in the expression that there > should be a security association between ARs. If we consider only > intra-domain communication between ARs, shared secret would be sufficient > for authorization and message authentication. If you consider central NMS > system that allows remote configuration of ARs, it would be very easy to > configure the shared secret among ARs. If there is no such thing, people do > the configuration by remotely logging into ARs. This one time configuration > removes concerns about scalability and reliability. You don't need a server > running up 24/7 for this authorization since you don't expect a new AR that > often. > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 16:00:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22386 for ; Wed, 12 Mar 2003 16:00:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLDCO14691; Wed, 12 Mar 2003 16:13:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLCvO14642 for ; Wed, 12 Mar 2003 16:12:57 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22046 for ; Wed, 12 Mar 2003 15:58:17 -0500 (EST) Message-ID: <020a01c2e8da$322d4f60$286015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 12:56:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It's that assumption I am questioning. For that to be made, there needs to be some reasonable idea of mechanism, otherwise, the protocol is not deployable. I'm suggesting that a server is one possible approach to providing the mechanism. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 12, 2003 12:03 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Jim, > If you read the dycard draft carefully you would notice that dycard assumes that a list of authorized APs > are available at each AR. Checks are made to compare L2 ids reported w.r.t authorized L2 ids. > The L2 ids put in the cache comes from other trusted ARs. Why can't we assume that they know > what L2 devices are connected to the ARs? > We don't discuss how this authorized list is put there explicitly. > This could be by any existing network management procedure. > > If Iam not wrong, in the DT draft, I think some L2 mechanism is assumed to exist that lets > the AR know about its APs and this is conveyed to the server. Can't the same > L2 mechanism be used? > > Having said that no L2 mechanism is assumed in dycard. > It is a learning procedure too. But if something can be assumed for this we can do the same. > > > Thanks, > Govind. > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, March 12, 2003 1:31 PM > > To: Eunsoo Shim; seamoby@ietf.org > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > The server will allow an AR to determine which APs are > > authorized. The dycard > > draft has nothing about this. This is an important security > > measure, though not > > directly related to exchanging the CAR information. > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "James Kempf" ; > > Sent: Wednesday, March 12, 2003 1:00 PM > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > > > > > > Why are these approaches mutually exclusive? > > > > > > > > One of the drawbacks of Dycard is that it needs a learning period. > > > Naturally, > > > > the ISP can hire somebody to walk around and seed the > > cache, but that's > > > > expensive. A server could prime the cache in the router > > with a collection > > > of > > > > AP/AR mappings that may not be geographically adjacent, > > but over time the > > > ones > > > > that aren't would drop out. Thus, the ISP would not have > > to go through the > > > > timeconsuming task of classifying whether they APs are > > geographically > > > adjacent. > > > > > > > > After the server has been used to initially populate the > > cache, any > > > changes > > > > would be propagated directly by CARD. > > > > > > > > > > [eunsoo] As Govind and Dirk pointed out, the first handoff > > between two ARs > > > leads to populating the cache with an entry for the newly > > discovered CAR in > > > Dycard. > > > If you claim that the server will be used only for initial > > populating the > > > cache at ARs, please clarify difference from the DT draft. > > The DT draft does > > > not say each AR will download a bunch of L2-L3 mapping > > information from the > > > server in the beginning of its operation. It will download > > one by one as MN > > > requests the mapping or reports a new BS L2 address. > > > > > > The only difference between Dycard and the server approach > > in the learning > > > period is that MN may be able to do fast handoff for the > > very first handoff > > > between two ARs in the server approach while MN will have > > to do slow handoff > > > in Dycard. Well, if we are talking about ISP, I don't think > > they just > > > install a box and start commercial services. They will go > > through many > > > stages of network tests including roaming support. So most > > likely initial > > > discoveries will be done during the process and thus they > > would not feel any > > > concern for the impact of the learning period for > > consumers. If we are > > > talking about more ad-hoc and casual network deployment, I > > am not sure the > > > slow handoff for the very first handoff is such a big > > concern, let say, for > > > corporate networks or campus networks. I don't think it justifies > > > introducing a sever. > > > > > > Also even if an ISP wants populating the cache by the > > information from the > > > server, they cannot tell exactly which entry should be > > inserted into a cache > > > unless they know exactly the radio map of the base > > stations. Well, all this > > > work is to remove such requirement. Then what they do only > > is just copying a > > > bunch of entries from the server to the cache as you > > suggested. If really > > > they want to do such a thing, they can use many existing > > tools. For example, > > > we can simply define MIB for CARD and they can use SNMP for > > setting the > > > values for CARD. This should not affect the fundamental > > structure of the > > > protocol. Actually it should be independent of the CARD > > protocol. Thus it > > > should not be a part of the CARD protocol except MIB > > definitions. Defining > > > MIB does not bring in any need of a server, of course. > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 16:00:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22407 for ; Wed, 12 Mar 2003 16:00:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLETO14861; Wed, 12 Mar 2003 16:14:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLDxO14774 for ; Wed, 12 Mar 2003 16:13:59 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22196 for ; Wed, 12 Mar 2003 15:59:21 -0500 (EST) Message-ID: <021401c2e8da$58595800$286015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 12:58:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit No disconnect. My point was, this is a deficiency with both drafts. It is an issue we need to resolve before we can consider the design complete. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 12, 2003 12:22 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Hi: > > There seems to be some disconnect. The current DT draft does NOT intend solve the problem of enabling AR to determine which APs are authorized. APs are brought up/down and connected to/disconnected from AR. Some L2 layer mechanism between AR-AP enables AR to learn about new/removed AP. AR reports that AP is up/down to CARD server and CARD server stores the mapping. In other words, AR is in control of knowing what APs are attached to it and CARD server relies on information provided by AR regarding this. > > Hemant > > -----Original Message----- > From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > Sent: Wednesday, March 12, 2003 4:48 PM > To: James Kempf; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > The server will allow an AR to determine which APs are authorized. The > dycard > > draft has nothing about this. This is an important security measure, > though not > > directly related to exchanging the CAR information. > > > [eunsoo] The routing protocol (for the wired Internet) has a similar > problem. They want to know whether a router is authorized to participate in > the route discovery. So for intra-domain routing protocols, usually shared > secret is proposed. Also Dycard assumes it in the expression that there > should be a security association between ARs. If we consider only > intra-domain communication between ARs, shared secret would be sufficient > for authorization and message authentication. If you consider central NMS > system that allows remote configuration of ARs, it would be very easy to > configure the shared secret among ARs. If there is no such thing, people do > the configuration by remotely logging into ARs. This one time configuration > removes concerns about scalability and reliability. You don't need a server > running up 24/7 for this authorization since you don't expect a new AR that > often. > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 16:07:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22862 for ; Wed, 12 Mar 2003 16:07:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLLIK15481 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 16:21:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLLIO15478 for ; Wed, 12 Mar 2003 16:21:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22811 for ; Wed, 12 Mar 2003 16:06:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLL5O15428; Wed, 12 Mar 2003 16:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLKOO15378 for ; Wed, 12 Mar 2003 16:20:24 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22753 for ; Wed, 12 Mar 2003 16:05:45 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CL7r804749 for ; Wed, 12 Mar 2003 15:07:53 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 15:07:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:07:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:07:01 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2qr20rzcppIeRU2uEERm/4p1GAAABqOg To: , , , X-OriginalArrivalTime: 12 Mar 2003 21:07:12.0923 (UTC) FILETIME=[5A3D16B0:01C2E8DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CLKOO15379 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, I'm surprised to suddenly see AP authentication in the scope of CAR discovery. Where does this change of scope come from? If a network operator requires AP authentication for each AR, network management tools can be used to download the list of APs to the AR. I don't see anything in the issue draft putting this on the table of CAR discovery (we would have called it CAR and local AP discovery then). So if you want to address this, let's define MIB entries and push mechanisms to download said AP entries to the AR MIB, and we're done. Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Wednesday, March 12, 2003 3:58 PM >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >No disconnect. > >My point was, this is a deficiency with both drafts. It is an >issue we need to >resolve before we can consider the design complete. > > jak > >----- Original Message ----- >From: >To: ; ; > >Sent: Wednesday, March 12, 2003 12:22 PM >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > >> Hi: >> >> There seems to be some disconnect. The current DT draft does >NOT intend solve >the problem of enabling AR to determine which APs are >authorized. APs are >brought up/down and connected to/disconnected from AR. Some L2 >layer mechanism >between AR-AP enables AR to learn about new/removed AP. AR >reports that AP is >up/down to CARD server and CARD server stores the mapping. In >other words, AR is >in control of knowing what APs are attached to it and CARD >server relies on >information provided by AR regarding this. >> >> Hemant >> >> -----Original Message----- >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] >> Sent: Wednesday, March 12, 2003 4:48 PM >> To: James Kempf; seamoby@ietf.org >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> >> >> >> >> > The server will allow an AR to determine which APs are >authorized. The >> dycard >> > draft has nothing about this. This is an important >security measure, >> though not >> > directly related to exchanging the CAR information. >> > >> [eunsoo] The routing protocol (for the wired Internet) has a similar >> problem. They want to know whether a router is authorized to >participate in >> the route discovery. So for intra-domain routing protocols, >usually shared >> secret is proposed. Also Dycard assumes it in the expression >that there >> should be a security association between ARs. If we consider only >> intra-domain communication between ARs, shared secret would >be sufficient >> for authorization and message authentication. If you >consider central NMS >> system that allows remote configuration of ARs, it would be >very easy to >> configure the shared secret among ARs. If there is no such >thing, people do >> the configuration by remotely logging into ARs. This one >time configuration >> removes concerns about scalability and reliability. You >don't need a server >> running up 24/7 for this authorization since you don't >expect a new AR that >> often. >> >> Eunsoo >> >> _______________________________________________ >> Seamoby mailing list >> Seamoby@ietf.org >> https://www1.ietf.org/mailman/listinfo/seamoby >> >> > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 16:07:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22904 for ; Wed, 12 Mar 2003 16:07:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLL5O15428; Wed, 12 Mar 2003 16:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLKOO15378 for ; Wed, 12 Mar 2003 16:20:24 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22753 for ; Wed, 12 Mar 2003 16:05:45 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CL7r804749 for ; Wed, 12 Mar 2003 15:07:53 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 15:07:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:07:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:07:01 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2qr20rzcppIeRU2uEERm/4p1GAAABqOg To: , , , X-OriginalArrivalTime: 12 Mar 2003 21:07:12.0923 (UTC) FILETIME=[5A3D16B0:01C2E8DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CLKOO15379 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, I'm surprised to suddenly see AP authentication in the scope of CAR discovery. Where does this change of scope come from? If a network operator requires AP authentication for each AR, network management tools can be used to download the list of APs to the AR. I don't see anything in the issue draft putting this on the table of CAR discovery (we would have called it CAR and local AP discovery then). So if you want to address this, let's define MIB entries and push mechanisms to download said AP entries to the AR MIB, and we're done. Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Wednesday, March 12, 2003 3:58 PM >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >No disconnect. > >My point was, this is a deficiency with both drafts. It is an >issue we need to >resolve before we can consider the design complete. > > jak > >----- Original Message ----- >From: >To: ; ; > >Sent: Wednesday, March 12, 2003 12:22 PM >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > >> Hi: >> >> There seems to be some disconnect. The current DT draft does >NOT intend solve >the problem of enabling AR to determine which APs are >authorized. APs are >brought up/down and connected to/disconnected from AR. Some L2 >layer mechanism >between AR-AP enables AR to learn about new/removed AP. AR >reports that AP is >up/down to CARD server and CARD server stores the mapping. In >other words, AR is >in control of knowing what APs are attached to it and CARD >server relies on >information provided by AR regarding this. >> >> Hemant >> >> -----Original Message----- >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] >> Sent: Wednesday, March 12, 2003 4:48 PM >> To: James Kempf; seamoby@ietf.org >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> >> >> >> >> > The server will allow an AR to determine which APs are >authorized. The >> dycard >> > draft has nothing about this. This is an important >security measure, >> though not >> > directly related to exchanging the CAR information. >> > >> [eunsoo] The routing protocol (for the wired Internet) has a similar >> problem. They want to know whether a router is authorized to >participate in >> the route discovery. So for intra-domain routing protocols, >usually shared >> secret is proposed. Also Dycard assumes it in the expression >that there >> should be a security association between ARs. If we consider only >> intra-domain communication between ARs, shared secret would >be sufficient >> for authorization and message authentication. If you >consider central NMS >> system that allows remote configuration of ARs, it would be >very easy to >> configure the shared secret among ARs. If there is no such >thing, people do >> the configuration by remotely logging into ARs. This one >time configuration >> removes concerns about scalability and reliability. You >don't need a server >> running up 24/7 for this authorization since you don't >expect a new AR that >> often. >> >> Eunsoo >> >> _______________________________________________ >> Seamoby mailing list >> Seamoby@ietf.org >> https://www1.ietf.org/mailman/listinfo/seamoby >> >> > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 16:11:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23037 for ; Wed, 12 Mar 2003 16:11:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLPLZ15742 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 16:25:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLPLO15739 for ; Wed, 12 Mar 2003 16:25:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23005 for ; Wed, 12 Mar 2003 16:10:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLP9O15699; Wed, 12 Mar 2003 16:25:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLNrO15597 for ; Wed, 12 Mar 2003 16:23:53 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22951 for ; Wed, 12 Mar 2003 16:09:14 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CLBO805540 for ; Wed, 12 Mar 2003 15:11:24 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 15:11:24 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:11:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:11:22 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2R1TQosBGtBLQfCJ1N7g6LQZRQAAFHrw To: , , X-OriginalArrivalTime: 12 Mar 2003 21:11:24.0395 (UTC) FILETIME=[F020ABB0:01C2E8DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CLNrO15600 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > > There is need for some mechanism, independent of any > interrouter exchange of > information, for a router to determine whether a particular > AP is, in fact, > authorized. This mechanism functions as a trust root, if you > will. That is what > I was referring to. [Govind] Why is this an issue that has to be considered at the IETF? Isn't this the function of the L2 mechanism or some other management mechanism to ensure this. The DT draft also, I believe, clearly states that this is out of scope. Hemant's recent mail also attests to this. > Or were you proposing a protocol between APs and ARs to allow > the AR to validate > whether an AP is authorized? > [Govind] dycard does not. Neither does the DT draft, I believe. Both assume that this information is available. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 16:11:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23058 for ; Wed, 12 Mar 2003 16:11:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLP9O15699; Wed, 12 Mar 2003 16:25:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLNrO15597 for ; Wed, 12 Mar 2003 16:23:53 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22951 for ; Wed, 12 Mar 2003 16:09:14 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CLBO805540 for ; Wed, 12 Mar 2003 15:11:24 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 15:11:24 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:11:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:11:22 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2R1TQosBGtBLQfCJ1N7g6LQZRQAAFHrw To: , , X-OriginalArrivalTime: 12 Mar 2003 21:11:24.0395 (UTC) FILETIME=[F020ABB0:01C2E8DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CLNrO15600 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > > There is need for some mechanism, independent of any > interrouter exchange of > information, for a router to determine whether a particular > AP is, in fact, > authorized. This mechanism functions as a trust root, if you > will. That is what > I was referring to. [Govind] Why is this an issue that has to be considered at the IETF? Isn't this the function of the L2 mechanism or some other management mechanism to ensure this. The DT draft also, I believe, clearly states that this is out of scope. Hemant's recent mail also attests to this. > Or were you proposing a protocol between APs and ARs to allow > the AR to validate > whether an AP is authorized? > [Govind] dycard does not. Neither does the DT draft, I believe. Both assume that this information is available. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 16:16:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23280 for ; Wed, 12 Mar 2003 16:16:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLUHL16079 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 16:30:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLUHO16076 for ; Wed, 12 Mar 2003 16:30:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23243 for ; Wed, 12 Mar 2003 16:15:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLU3O16065; Wed, 12 Mar 2003 16:30:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLSsO15954 for ; Wed, 12 Mar 2003 16:28:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23166 for ; Wed, 12 Mar 2003 16:14:14 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CLGL806582 for ; Wed, 12 Mar 2003 15:16:21 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 15:16:21 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:16:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:16:13 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2nuObao7aVAdQHyNf/aNZi+cxQAAY0Gw To: , , X-OriginalArrivalTime: 12 Mar 2003 21:16:21.0243 (UTC) FILETIME=[A11014B0:01C2E8DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CLSsO15955 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit James, I agree that this is an important issue, but not a difficult issue. Several tools exist already to do this, SNMP for example. In cellular networks, adding APs (base stations) is operator controlled too and it is quite easy for this to be accomplished. Arbitrarily people cant introduce APs into a network domain. Since both the APs and ARs are under operator control, any one of these existing tools can be used to maintain this list. -Govind > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 12, 2003 3:57 PM > To: Krishnamurthi Govind (NRC/Boston); eunsoo@nec-labs.com; > seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > It's that assumption I am questioning. > > For that to be made, there needs to be some reasonable idea > of mechanism, > otherwise, the protocol is not deployable. > > I'm suggesting that a server is one possible approach to providing the > mechanism. > > jak > > ----- Original Message ----- > From: > To: ; ; > > Sent: Wednesday, March 12, 2003 12:03 PM > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > Jim, > > If you read the dycard draft carefully you would notice > that dycard assumes > that a list of authorized APs > > are available at each AR. Checks are made to compare L2 > ids reported w.r.t > authorized L2 ids. > > The L2 ids put in the cache comes from other trusted ARs. > Why can't we assume > that they know > > what L2 devices are connected to the ARs? > > We don't discuss how this authorized list is put there explicitly. > > This could be by any existing network management procedure. > > > > If Iam not wrong, in the DT draft, I think some L2 > mechanism is assumed to > exist that lets > > the AR know about its APs and this is conveyed to the > server. Can't the same > > L2 mechanism be used? > > > > Having said that no L2 mechanism is assumed in dycard. > > It is a learning procedure too. But if something can be > assumed for this we > can do the same. > > > > > > Thanks, > > Govind. > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Wednesday, March 12, 2003 1:31 PM > > > To: Eunsoo Shim; seamoby@ietf.org > > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > The server will allow an AR to determine which APs are > > > authorized. The dycard > > > draft has nothing about this. This is an important security > > > measure, though not > > > directly related to exchanging the CAR information. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Eunsoo Shim" > > > To: "James Kempf" ; > > > Sent: Wednesday, March 12, 2003 1:00 PM > > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > > > > > > > > > > > Why are these approaches mutually exclusive? > > > > > > > > > > One of the drawbacks of Dycard is that it needs a > learning period. > > > > Naturally, > > > > > the ISP can hire somebody to walk around and seed the > > > cache, but that's > > > > > expensive. A server could prime the cache in the router > > > with a collection > > > > of > > > > > AP/AR mappings that may not be geographically adjacent, > > > but over time the > > > > ones > > > > > that aren't would drop out. Thus, the ISP would not have > > > to go through the > > > > > timeconsuming task of classifying whether they APs are > > > geographically > > > > adjacent. > > > > > > > > > > After the server has been used to initially populate the > > > cache, any > > > > changes > > > > > would be propagated directly by CARD. > > > > > > > > > > > > > [eunsoo] As Govind and Dirk pointed out, the first handoff > > > between two ARs > > > > leads to populating the cache with an entry for the newly > > > discovered CAR in > > > > Dycard. > > > > If you claim that the server will be used only for initial > > > populating the > > > > cache at ARs, please clarify difference from the DT draft. > > > The DT draft does > > > > not say each AR will download a bunch of L2-L3 mapping > > > information from the > > > > server in the beginning of its operation. It will download > > > one by one as MN > > > > requests the mapping or reports a new BS L2 address. > > > > > > > > The only difference between Dycard and the server approach > > > in the learning > > > > period is that MN may be able to do fast handoff for the > > > very first handoff > > > > between two ARs in the server approach while MN will have > > > to do slow handoff > > > > in Dycard. Well, if we are talking about ISP, I don't think > > > they just > > > > install a box and start commercial services. They will go > > > through many > > > > stages of network tests including roaming support. So most > > > likely initial > > > > discoveries will be done during the process and thus they > > > would not feel any > > > > concern for the impact of the learning period for > > > consumers. If we are > > > > talking about more ad-hoc and casual network deployment, I > > > am not sure the > > > > slow handoff for the very first handoff is such a big > > > concern, let say, for > > > > corporate networks or campus networks. I don't think it > justifies > > > > introducing a sever. > > > > > > > > Also even if an ISP wants populating the cache by the > > > information from the > > > > server, they cannot tell exactly which entry should be > > > inserted into a cache > > > > unless they know exactly the radio map of the base > > > stations. Well, all this > > > > work is to remove such requirement. Then what they do only > > > is just copying a > > > > bunch of entries from the server to the cache as you > > > suggested. If really > > > > they want to do such a thing, they can use many existing > > > tools. For example, > > > > we can simply define MIB for CARD and they can use SNMP for > > > setting the > > > > values for CARD. This should not affect the fundamental > > > structure of the > > > > protocol. Actually it should be independent of the CARD > > > protocol. Thus it > > > > should not be a part of the CARD protocol except MIB > > > definitions. Defining > > > > MIB does not bring in any need of a server, of course. > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 16:16:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23298 for ; Wed, 12 Mar 2003 16:16:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLU3O16065; Wed, 12 Mar 2003 16:30:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLSsO15954 for ; Wed, 12 Mar 2003 16:28:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23166 for ; Wed, 12 Mar 2003 16:14:14 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CLGL806582 for ; Wed, 12 Mar 2003 15:16:21 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 15:16:21 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:16:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:16:13 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2nuObao7aVAdQHyNf/aNZi+cxQAAY0Gw To: , , X-OriginalArrivalTime: 12 Mar 2003 21:16:21.0243 (UTC) FILETIME=[A11014B0:01C2E8DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CLSsO15955 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, I agree that this is an important issue, but not a difficult issue. Several tools exist already to do this, SNMP for example. In cellular networks, adding APs (base stations) is operator controlled too and it is quite easy for this to be accomplished. Arbitrarily people cant introduce APs into a network domain. Since both the APs and ARs are under operator control, any one of these existing tools can be used to maintain this list. -Govind > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 12, 2003 3:57 PM > To: Krishnamurthi Govind (NRC/Boston); eunsoo@nec-labs.com; > seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > It's that assumption I am questioning. > > For that to be made, there needs to be some reasonable idea > of mechanism, > otherwise, the protocol is not deployable. > > I'm suggesting that a server is one possible approach to providing the > mechanism. > > jak > > ----- Original Message ----- > From: > To: ; ; > > Sent: Wednesday, March 12, 2003 12:03 PM > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > Jim, > > If you read the dycard draft carefully you would notice > that dycard assumes > that a list of authorized APs > > are available at each AR. Checks are made to compare L2 > ids reported w.r.t > authorized L2 ids. > > The L2 ids put in the cache comes from other trusted ARs. > Why can't we assume > that they know > > what L2 devices are connected to the ARs? > > We don't discuss how this authorized list is put there explicitly. > > This could be by any existing network management procedure. > > > > If Iam not wrong, in the DT draft, I think some L2 > mechanism is assumed to > exist that lets > > the AR know about its APs and this is conveyed to the > server. Can't the same > > L2 mechanism be used? > > > > Having said that no L2 mechanism is assumed in dycard. > > It is a learning procedure too. But if something can be > assumed for this we > can do the same. > > > > > > Thanks, > > Govind. > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Wednesday, March 12, 2003 1:31 PM > > > To: Eunsoo Shim; seamoby@ietf.org > > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > The server will allow an AR to determine which APs are > > > authorized. The dycard > > > draft has nothing about this. This is an important security > > > measure, though not > > > directly related to exchanging the CAR information. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Eunsoo Shim" > > > To: "James Kempf" ; > > > Sent: Wednesday, March 12, 2003 1:00 PM > > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > > > > > > > > > > > Why are these approaches mutually exclusive? > > > > > > > > > > One of the drawbacks of Dycard is that it needs a > learning period. > > > > Naturally, > > > > > the ISP can hire somebody to walk around and seed the > > > cache, but that's > > > > > expensive. A server could prime the cache in the router > > > with a collection > > > > of > > > > > AP/AR mappings that may not be geographically adjacent, > > > but over time the > > > > ones > > > > > that aren't would drop out. Thus, the ISP would not have > > > to go through the > > > > > timeconsuming task of classifying whether they APs are > > > geographically > > > > adjacent. > > > > > > > > > > After the server has been used to initially populate the > > > cache, any > > > > changes > > > > > would be propagated directly by CARD. > > > > > > > > > > > > > [eunsoo] As Govind and Dirk pointed out, the first handoff > > > between two ARs > > > > leads to populating the cache with an entry for the newly > > > discovered CAR in > > > > Dycard. > > > > If you claim that the server will be used only for initial > > > populating the > > > > cache at ARs, please clarify difference from the DT draft. > > > The DT draft does > > > > not say each AR will download a bunch of L2-L3 mapping > > > information from the > > > > server in the beginning of its operation. It will download > > > one by one as MN > > > > requests the mapping or reports a new BS L2 address. > > > > > > > > The only difference between Dycard and the server approach > > > in the learning > > > > period is that MN may be able to do fast handoff for the > > > very first handoff > > > > between two ARs in the server approach while MN will have > > > to do slow handoff > > > > in Dycard. Well, if we are talking about ISP, I don't think > > > they just > > > > install a box and start commercial services. They will go > > > through many > > > > stages of network tests including roaming support. So most > > > likely initial > > > > discoveries will be done during the process and thus they > > > would not feel any > > > > concern for the impact of the learning period for > > > consumers. If we are > > > > talking about more ad-hoc and casual network deployment, I > > > am not sure the > > > > slow handoff for the very first handoff is such a big > > > concern, let say, for > > > > corporate networks or campus networks. I don't think it > justifies > > > > introducing a sever. > > > > > > > > Also even if an ISP wants populating the cache by the > > > information from the > > > > server, they cannot tell exactly which entry should be > > > inserted into a cache > > > > unless they know exactly the radio map of the base > > > stations. Well, all this > > > > work is to remove such requirement. Then what they do only > > > is just copying a > > > > bunch of entries from the server to the cache as you > > > suggested. If really > > > > they want to do such a thing, they can use many existing > > > tools. For example, > > > > we can simply define MIB for CARD and they can use SNMP for > > > setting the > > > > values for CARD. This should not affect the fundamental > > > structure of the > > > > protocol. Actually it should be independent of the CARD > > > protocol. Thus it > > > > should not be a part of the CARD protocol except MIB > > > definitions. Defining > > > > MIB does not bring in any need of a server, of course. > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 16:25:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23647 for ; Wed, 12 Mar 2003 16:25:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLdGI17276 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 16:39:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLdGO17273 for ; Wed, 12 Mar 2003 16:39:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23618 for ; Wed, 12 Mar 2003 16:24:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLd6O17247; Wed, 12 Mar 2003 16:39:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLbiO17063 for ; Wed, 12 Mar 2003 16:37:44 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23525 for ; Wed, 12 Mar 2003 16:23:05 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CLPE808323 for ; Wed, 12 Mar 2003 15:25:14 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 15:25:13 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:24:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:23:44 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2qrSB5OeFNntSl6nY3MMpWucnwAAlECg To: , , X-OriginalArrivalTime: 12 Mar 2003 21:24:24.0264 (UTC) FILETIME=[C0F73C80:01C2E8DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CLbiO17064 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: In certain environments, let us say 3G, connecting base station to access network is quite an involved job. This cannot be done casually without operator's co-operation. So, here authorization can be done via physical means - operator will not open doors of the room where AR is located to connect AP wire to it. In some 802.11 which provides no physical level control, anybody can connect AP to AR. In others, where premium service is provided, Ethernet wires won't be run accessible to passerby. Of course, L2 layer digital authorization mechanism is also possible. In summary, the mechanisms for this can be varied ranging from (practical) physical security to digital security. Also, this is L2-layer issue. IMHO, this does not belong in CARD scope. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 12, 2003 3:58 PM To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD No disconnect. My point was, this is a deficiency with both drafts. It is an issue we need to resolve before we can consider the design complete. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 12, 2003 12:22 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Hi: > > There seems to be some disconnect. The current DT draft does NOT intend solve the problem of enabling AR to determine which APs are authorized. APs are brought up/down and connected to/disconnected from AR. Some L2 layer mechanism between AR-AP enables AR to learn about new/removed AP. AR reports that AP is up/down to CARD server and CARD server stores the mapping. In other words, AR is in control of knowing what APs are attached to it and CARD server relies on information provided by AR regarding this. > > Hemant > > -----Original Message----- > From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > Sent: Wednesday, March 12, 2003 4:48 PM > To: James Kempf; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > The server will allow an AR to determine which APs are authorized. The > dycard > > draft has nothing about this. This is an important security measure, > though not > > directly related to exchanging the CAR information. > > > [eunsoo] The routing protocol (for the wired Internet) has a similar > problem. They want to know whether a router is authorized to participate in > the route discovery. So for intra-domain routing protocols, usually shared > secret is proposed. Also Dycard assumes it in the expression that there > should be a security association between ARs. If we consider only > intra-domain communication between ARs, shared secret would be sufficient > for authorization and message authentication. If you consider central NMS > system that allows remote configuration of ARs, it would be very easy to > configure the shared secret among ARs. If there is no such thing, people do > the configuration by remotely logging into ARs. This one time configuration > removes concerns about scalability and reliability. You don't need a server > running up 24/7 for this authorization since you don't expect a new AR that > often. > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 16:25:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23677 for ; Wed, 12 Mar 2003 16:25:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLd6O17247; Wed, 12 Mar 2003 16:39:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLbiO17063 for ; Wed, 12 Mar 2003 16:37:44 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23525 for ; Wed, 12 Mar 2003 16:23:05 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CLPE808323 for ; Wed, 12 Mar 2003 15:25:14 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 15:25:13 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 15:24:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 16:23:44 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2qrSB5OeFNntSl6nY3MMpWucnwAAlECg To: , , X-OriginalArrivalTime: 12 Mar 2003 21:24:24.0264 (UTC) FILETIME=[C0F73C80:01C2E8DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CLbiO17064 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: In certain environments, let us say 3G, connecting base station to access network is quite an involved job. This cannot be done casually without operator's co-operation. So, here authorization can be done via physical means - operator will not open doors of the room where AR is located to connect AP wire to it. In some 802.11 which provides no physical level control, anybody can connect AP to AR. In others, where premium service is provided, Ethernet wires won't be run accessible to passerby. Of course, L2 layer digital authorization mechanism is also possible. In summary, the mechanisms for this can be varied ranging from (practical) physical security to digital security. Also, this is L2-layer issue. IMHO, this does not belong in CARD scope. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 12, 2003 3:58 PM To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD No disconnect. My point was, this is a deficiency with both drafts. It is an issue we need to resolve before we can consider the design complete. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 12, 2003 12:22 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Hi: > > There seems to be some disconnect. The current DT draft does NOT intend solve the problem of enabling AR to determine which APs are authorized. APs are brought up/down and connected to/disconnected from AR. Some L2 layer mechanism between AR-AP enables AR to learn about new/removed AP. AR reports that AP is up/down to CARD server and CARD server stores the mapping. In other words, AR is in control of knowing what APs are attached to it and CARD server relies on information provided by AR regarding this. > > Hemant > > -----Original Message----- > From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > Sent: Wednesday, March 12, 2003 4:48 PM > To: James Kempf; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > The server will allow an AR to determine which APs are authorized. The > dycard > > draft has nothing about this. This is an important security measure, > though not > > directly related to exchanging the CAR information. > > > [eunsoo] The routing protocol (for the wired Internet) has a similar > problem. They want to know whether a router is authorized to participate in > the route discovery. So for intra-domain routing protocols, usually shared > secret is proposed. Also Dycard assumes it in the expression that there > should be a security association between ARs. If we consider only > intra-domain communication between ARs, shared secret would be sufficient > for authorization and message authentication. If you consider central NMS > system that allows remote configuration of ARs, it would be very easy to > configure the shared secret among ARs. If there is no such thing, people do > the configuration by remotely logging into ARs. This one time configuration > removes concerns about scalability and reliability. You don't need a server > running up 24/7 for this authorization since you don't expect a new AR that > often. > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 17:58:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27291 for ; Wed, 12 Mar 2003 17:58:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CNCDp24138 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 18:12:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNCDO24135 for ; Wed, 12 Mar 2003 18:12:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27260 for ; Wed, 12 Mar 2003 17:57:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNBpO24080; Wed, 12 Mar 2003 18:11:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNAaO24004 for ; Wed, 12 Mar 2003 18:10:36 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27230 for ; Wed, 12 Mar 2003 17:55:56 -0500 (EST) Message-ID: <027801c2e8ea$9fe4d2c0$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 14:52:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dirk, You're right. This is a significant gap in our requirements. We will have to recall them from the IESG and include it. It is an unacceptable security hole for there to be no requirement that APs be authorized. I'm suprised Steve Bellovin didn't find this. Thanx for pointing out this serious hole. jak ----- Original Message ----- From: To: ; ; ; Sent: Wednesday, March 12, 2003 1:07 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Hi James, > > I'm surprised to suddenly see AP authentication in the scope of CAR discovery. Where does this change of > scope come from? If a network operator requires AP authentication for each AR, network management > tools can be used to download the list of APs to the AR. I don't see anything in the issue draft putting > this on the table of CAR discovery (we would have called it CAR and local AP discovery then). > > So if you want to address this, let's define MIB entries and push mechanisms to download said AP entries to > the AR MIB, and we're done. > > Dirk > > >-----Original Message----- > >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > >Sent: Wednesday, March 12, 2003 3:58 PM > >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org > >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > >No disconnect. > > > >My point was, this is a deficiency with both drafts. It is an > >issue we need to > >resolve before we can consider the design complete. > > > > jak > > > >----- Original Message ----- > >From: > >To: ; ; > > > >Sent: Wednesday, March 12, 2003 12:22 PM > >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > >> Hi: > >> > >> There seems to be some disconnect. The current DT draft does > >NOT intend solve > >the problem of enabling AR to determine which APs are > >authorized. APs are > >brought up/down and connected to/disconnected from AR. Some L2 > >layer mechanism > >between AR-AP enables AR to learn about new/removed AP. AR > >reports that AP is > >up/down to CARD server and CARD server stores the mapping. In > >other words, AR is > >in control of knowing what APs are attached to it and CARD > >server relies on > >information provided by AR regarding this. > >> > >> Hemant > >> > >> -----Original Message----- > >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > >> Sent: Wednesday, March 12, 2003 4:48 PM > >> To: James Kempf; seamoby@ietf.org > >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > >> > >> > >> > >> > >> > The server will allow an AR to determine which APs are > >authorized. The > >> dycard > >> > draft has nothing about this. This is an important > >security measure, > >> though not > >> > directly related to exchanging the CAR information. > >> > > >> [eunsoo] The routing protocol (for the wired Internet) has a similar > >> problem. They want to know whether a router is authorized to > >participate in > >> the route discovery. So for intra-domain routing protocols, > >usually shared > >> secret is proposed. Also Dycard assumes it in the expression > >that there > >> should be a security association between ARs. If we consider only > >> intra-domain communication between ARs, shared secret would > >be sufficient > >> for authorization and message authentication. If you > >consider central NMS > >> system that allows remote configuration of ARs, it would be > >very easy to > >> configure the shared secret among ARs. If there is no such > >thing, people do > >> the configuration by remotely logging into ARs. This one > >time configuration > >> removes concerns about scalability and reliability. You > >don't need a server > >> running up 24/7 for this authorization since you don't > >expect a new AR that > >> often. > >> > >> Eunsoo > >> > >> _______________________________________________ > >> Seamoby mailing list > >> Seamoby@ietf.org > >> https://www1.ietf.org/mailman/listinfo/seamoby > >> > >> > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 17:58:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27315 for ; Wed, 12 Mar 2003 17:58:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNBpO24080; Wed, 12 Mar 2003 18:11:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNAaO24004 for ; Wed, 12 Mar 2003 18:10:36 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27230 for ; Wed, 12 Mar 2003 17:55:56 -0500 (EST) Message-ID: <027801c2e8ea$9fe4d2c0$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 14:52:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dirk, You're right. This is a significant gap in our requirements. We will have to recall them from the IESG and include it. It is an unacceptable security hole for there to be no requirement that APs be authorized. I'm suprised Steve Bellovin didn't find this. Thanx for pointing out this serious hole. jak ----- Original Message ----- From: To: ; ; ; Sent: Wednesday, March 12, 2003 1:07 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Hi James, > > I'm surprised to suddenly see AP authentication in the scope of CAR discovery. Where does this change of > scope come from? If a network operator requires AP authentication for each AR, network management > tools can be used to download the list of APs to the AR. I don't see anything in the issue draft putting > this on the table of CAR discovery (we would have called it CAR and local AP discovery then). > > So if you want to address this, let's define MIB entries and push mechanisms to download said AP entries to > the AR MIB, and we're done. > > Dirk > > >-----Original Message----- > >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > >Sent: Wednesday, March 12, 2003 3:58 PM > >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org > >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > >No disconnect. > > > >My point was, this is a deficiency with both drafts. It is an > >issue we need to > >resolve before we can consider the design complete. > > > > jak > > > >----- Original Message ----- > >From: > >To: ; ; > > > >Sent: Wednesday, March 12, 2003 12:22 PM > >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > >> Hi: > >> > >> There seems to be some disconnect. The current DT draft does > >NOT intend solve > >the problem of enabling AR to determine which APs are > >authorized. APs are > >brought up/down and connected to/disconnected from AR. Some L2 > >layer mechanism > >between AR-AP enables AR to learn about new/removed AP. AR > >reports that AP is > >up/down to CARD server and CARD server stores the mapping. In > >other words, AR is > >in control of knowing what APs are attached to it and CARD > >server relies on > >information provided by AR regarding this. > >> > >> Hemant > >> > >> -----Original Message----- > >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > >> Sent: Wednesday, March 12, 2003 4:48 PM > >> To: James Kempf; seamoby@ietf.org > >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > >> > >> > >> > >> > >> > The server will allow an AR to determine which APs are > >authorized. The > >> dycard > >> > draft has nothing about this. This is an important > >security measure, > >> though not > >> > directly related to exchanging the CAR information. > >> > > >> [eunsoo] The routing protocol (for the wired Internet) has a similar > >> problem. They want to know whether a router is authorized to > >participate in > >> the route discovery. So for intra-domain routing protocols, > >usually shared > >> secret is proposed. Also Dycard assumes it in the expression > >that there > >> should be a security association between ARs. If we consider only > >> intra-domain communication between ARs, shared secret would > >be sufficient > >> for authorization and message authentication. If you > >consider central NMS > >> system that allows remote configuration of ARs, it would be > >very easy to > >> configure the shared secret among ARs. If there is no such > >thing, people do > >> the configuration by remotely logging into ARs. This one > >time configuration > >> removes concerns about scalability and reliability. You > >don't need a server > >> running up 24/7 for this authorization since you don't > >expect a new AR that > >> often. > >> > >> Eunsoo > >> > >> _______________________________________________ > >> Seamoby mailing list > >> Seamoby@ietf.org > >> https://www1.ietf.org/mailman/listinfo/seamoby > >> > >> > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 19:21:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01255 for ; Wed, 12 Mar 2003 19:21:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D0ZYa29488 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 19:35:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D0ZYO29485 for ; Wed, 12 Mar 2003 19:35:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01246 for ; Wed, 12 Mar 2003 19:20:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D0ZGO29471; Wed, 12 Mar 2003 19:35:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D0Y7O29379 for ; Wed, 12 Mar 2003 19:34:07 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01190 for ; Wed, 12 Mar 2003 19:19:25 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2D0LW818856 for ; Wed, 12 Mar 2003 18:21:33 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 18:21:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 16:21:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 19:21:31 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo6w9/xlG0hvZ2RyuB/LB6eX35yAACK+/g To: , , , , X-OriginalArrivalTime: 13 Mar 2003 00:21:32.0505 (UTC) FILETIME=[7FE41C90:01C2E8F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2D0Y8O29380 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, I honestly don't think we need to revisit the requirements again. First, there is no unacceptable security hole as you point out. The drafts have acknowledged that an authorized list of APs is needed, but have said that this has to be made available and it is out of scope for them. So once this is made available, in some way shape or form, where is the security hole? We have spent enough time on the requirements and Issues draft and they have passed WG last call. Calling it back is just going to delay the process unnecessarily. Further, I don't think the current state of the protocol design warrants this. I think both the protocols under question acknowledge that APs need to be authorized and they defer it to the admin to use existing protocols to get this authorized list down to the ARs or the server. I think a statement to that effect in the final protocol spec is more than enough. I draw a parallel to the FMIPv6 work, where they assume that someone provides the L2-L3 mapping. Why isn't this similar? Clearly if the L2-L3 mapping is not provided in a secure fashion FMIPv6 will fail is it not? I don't think Dirk was referring to the requirements draft in his email. I think he was pointing out the issues draft. I don't understand why you think he alluded to the requirements draft. Maybe Dirk can correct me on this. I don't think this problem is in the scope of CARD. This deals with L2 devices of different technologies and to get a common way to get this authorized APs list in different technologies should be and is beyond the scope of CARD. This is as if saying that CARD now should re-invent IKE to make sure that ARs have an SA. My 2 cents, Govind. > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 12, 2003 5:52 PM > To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); > eunsoo@nec-labs.com; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > Dirk, > > You're right. This is a significant gap in our requirements. > > We will have to recall them from the IESG and include it. It > is an unacceptable > security hole for there to be no requirement that APs be > authorized. I'm > suprised Steve Bellovin didn't find this. > > Thanx for pointing out this serious hole. > > jak > > ----- Original Message ----- > From: > To: ; ; > ; > Sent: Wednesday, March 12, 2003 1:07 PM > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > Hi James, > > > > I'm surprised to suddenly see AP authentication in the > scope of CAR discovery. > Where does this change of > > scope come from? If a network operator requires AP > authentication for each AR, > network management > > tools can be used to download the list of APs to the AR. I > don't see anything > in the issue draft putting > > this on the table of CAR discovery (we would have called it > CAR and local AP > discovery then). > > > > So if you want to address this, let's define MIB entries > and push mechanisms > to download said AP entries to > > the AR MIB, and we're done. > > > > Dirk > > > > >-----Original Message----- > > >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > >Sent: Wednesday, March 12, 2003 3:58 PM > > >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; > seamoby@ietf.org > > >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > >No disconnect. > > > > > >My point was, this is a deficiency with both drafts. It is an > > >issue we need to > > >resolve before we can consider the design complete. > > > > > > jak > > > > > >----- Original Message ----- > > >From: > > >To: ; ; > > > > > >Sent: Wednesday, March 12, 2003 12:22 PM > > >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > >> Hi: > > >> > > >> There seems to be some disconnect. The current DT draft does > > >NOT intend solve > > >the problem of enabling AR to determine which APs are > > >authorized. APs are > > >brought up/down and connected to/disconnected from AR. Some L2 > > >layer mechanism > > >between AR-AP enables AR to learn about new/removed AP. AR > > >reports that AP is > > >up/down to CARD server and CARD server stores the mapping. In > > >other words, AR is > > >in control of knowing what APs are attached to it and CARD > > >server relies on > > >information provided by AR regarding this. > > >> > > >> Hemant > > >> > > >> -----Original Message----- > > >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > > >> Sent: Wednesday, March 12, 2003 4:48 PM > > >> To: James Kempf; seamoby@ietf.org > > >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >> > > >> > > >> > > >> > > >> > The server will allow an AR to determine which APs are > > >authorized. The > > >> dycard > > >> > draft has nothing about this. This is an important > > >security measure, > > >> though not > > >> > directly related to exchanging the CAR information. > > >> > > > >> [eunsoo] The routing protocol (for the wired Internet) > has a similar > > >> problem. They want to know whether a router is authorized to > > >participate in > > >> the route discovery. So for intra-domain routing protocols, > > >usually shared > > >> secret is proposed. Also Dycard assumes it in the expression > > >that there > > >> should be a security association between ARs. If we consider only > > >> intra-domain communication between ARs, shared secret would > > >be sufficient > > >> for authorization and message authentication. If you > > >consider central NMS > > >> system that allows remote configuration of ARs, it would be > > >very easy to > > >> configure the shared secret among ARs. If there is no such > > >thing, people do > > >> the configuration by remotely logging into ARs. This one > > >time configuration > > >> removes concerns about scalability and reliability. You > > >don't need a server > > >> running up 24/7 for this authorization since you don't > > >expect a new AR that > > >> often. > > >> > > >> Eunsoo > > >> > > >> _______________________________________________ > > >> Seamoby mailing list > > >> Seamoby@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/seamoby > > >> > > >> > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 19:21:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01269 for ; Wed, 12 Mar 2003 19:21:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D0ZGO29471; Wed, 12 Mar 2003 19:35:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D0Y7O29379 for ; Wed, 12 Mar 2003 19:34:07 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01190 for ; Wed, 12 Mar 2003 19:19:25 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2D0LW818856 for ; Wed, 12 Mar 2003 18:21:33 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Mar 2003 18:21:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Mar 2003 16:21:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 19:21:31 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo6w9/xlG0hvZ2RyuB/LB6eX35yAACK+/g To: , , , , X-OriginalArrivalTime: 13 Mar 2003 00:21:32.0505 (UTC) FILETIME=[7FE41C90:01C2E8F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2D0Y8O29380 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, I honestly don't think we need to revisit the requirements again. First, there is no unacceptable security hole as you point out. The drafts have acknowledged that an authorized list of APs is needed, but have said that this has to be made available and it is out of scope for them. So once this is made available, in some way shape or form, where is the security hole? We have spent enough time on the requirements and Issues draft and they have passed WG last call. Calling it back is just going to delay the process unnecessarily. Further, I don't think the current state of the protocol design warrants this. I think both the protocols under question acknowledge that APs need to be authorized and they defer it to the admin to use existing protocols to get this authorized list down to the ARs or the server. I think a statement to that effect in the final protocol spec is more than enough. I draw a parallel to the FMIPv6 work, where they assume that someone provides the L2-L3 mapping. Why isn't this similar? Clearly if the L2-L3 mapping is not provided in a secure fashion FMIPv6 will fail is it not? I don't think Dirk was referring to the requirements draft in his email. I think he was pointing out the issues draft. I don't understand why you think he alluded to the requirements draft. Maybe Dirk can correct me on this. I don't think this problem is in the scope of CARD. This deals with L2 devices of different technologies and to get a common way to get this authorized APs list in different technologies should be and is beyond the scope of CARD. This is as if saying that CARD now should re-invent IKE to make sure that ARs have an SA. My 2 cents, Govind. > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 12, 2003 5:52 PM > To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); > eunsoo@nec-labs.com; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > Dirk, > > You're right. This is a significant gap in our requirements. > > We will have to recall them from the IESG and include it. It > is an unacceptable > security hole for there to be no requirement that APs be > authorized. I'm > suprised Steve Bellovin didn't find this. > > Thanx for pointing out this serious hole. > > jak > > ----- Original Message ----- > From: > To: ; ; > ; > Sent: Wednesday, March 12, 2003 1:07 PM > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > Hi James, > > > > I'm surprised to suddenly see AP authentication in the > scope of CAR discovery. > Where does this change of > > scope come from? If a network operator requires AP > authentication for each AR, > network management > > tools can be used to download the list of APs to the AR. I > don't see anything > in the issue draft putting > > this on the table of CAR discovery (we would have called it > CAR and local AP > discovery then). > > > > So if you want to address this, let's define MIB entries > and push mechanisms > to download said AP entries to > > the AR MIB, and we're done. > > > > Dirk > > > > >-----Original Message----- > > >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > >Sent: Wednesday, March 12, 2003 3:58 PM > > >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; > seamoby@ietf.org > > >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > >No disconnect. > > > > > >My point was, this is a deficiency with both drafts. It is an > > >issue we need to > > >resolve before we can consider the design complete. > > > > > > jak > > > > > >----- Original Message ----- > > >From: > > >To: ; ; > > > > > >Sent: Wednesday, March 12, 2003 12:22 PM > > >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > >> Hi: > > >> > > >> There seems to be some disconnect. The current DT draft does > > >NOT intend solve > > >the problem of enabling AR to determine which APs are > > >authorized. APs are > > >brought up/down and connected to/disconnected from AR. Some L2 > > >layer mechanism > > >between AR-AP enables AR to learn about new/removed AP. AR > > >reports that AP is > > >up/down to CARD server and CARD server stores the mapping. In > > >other words, AR is > > >in control of knowing what APs are attached to it and CARD > > >server relies on > > >information provided by AR regarding this. > > >> > > >> Hemant > > >> > > >> -----Original Message----- > > >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > > >> Sent: Wednesday, March 12, 2003 4:48 PM > > >> To: James Kempf; seamoby@ietf.org > > >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >> > > >> > > >> > > >> > > >> > The server will allow an AR to determine which APs are > > >authorized. The > > >> dycard > > >> > draft has nothing about this. This is an important > > >security measure, > > >> though not > > >> > directly related to exchanging the CAR information. > > >> > > > >> [eunsoo] The routing protocol (for the wired Internet) > has a similar > > >> problem. They want to know whether a router is authorized to > > >participate in > > >> the route discovery. So for intra-domain routing protocols, > > >usually shared > > >> secret is proposed. Also Dycard assumes it in the expression > > >that there > > >> should be a security association between ARs. If we consider only > > >> intra-domain communication between ARs, shared secret would > > >be sufficient > > >> for authorization and message authentication. If you > > >consider central NMS > > >> system that allows remote configuration of ARs, it would be > > >very easy to > > >> configure the shared secret among ARs. If there is no such > > >thing, people do > > >> the configuration by remotely logging into ARs. This one > > >time configuration > > >> removes concerns about scalability and reliability. You > > >don't need a server > > >> running up 24/7 for this authorization since you don't > > >expect a new AR that > > >> often. > > >> > > >> Eunsoo > > >> > > >> _______________________________________________ > > >> Seamoby mailing list > > >> Seamoby@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/seamoby > > >> > > >> > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 12 20:53:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03538 for ; Wed, 12 Mar 2003 20:53:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D27cZ03736 for seamoby-archive@odin.ietf.org; Wed, 12 Mar 2003 21:07:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D27cO03733 for ; Wed, 12 Mar 2003 21:07:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03531 for ; Wed, 12 Mar 2003 20:52:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D27RO03684; Wed, 12 Mar 2003 21:07:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D263O02855 for ; Wed, 12 Mar 2003 21:06:03 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03495 for ; Wed, 12 Mar 2003 20:51:19 -0500 (EST) Date: Wed, 12 Mar 2003 17:51:26 -0800 From: Daichi Funato To: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD In-Reply-To: References: Message-Id: <20030312174925.3349.FUNATO@docomolabs-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hemant, > Hemant -> I am trying to do some back of the envelope calculation > here. There are two ARs and first handoff happens between them. > Let us say cache lifetime is few hours. If another handoff occurs > during those few hours, cache gets refreshed for another few hours. > If no handoff occurs between those two ARs in few hours, why do > we need to care of about seamlessness in the first place. I don't think this calculation is enough... A server is necessary to save the initial handover failures. Let me show you another caluculation. Suppose there is an AR, which has a hexagon shape coverage. If we surround this AR with other AR hexagons, there will be 7 ARs. In this case, the total adjacent edges, which equals to the total CAR entries, are 12. This means we need 12 learning reports from MNs with 12 handover failures in learning-based approach. If we continue surrounding this, we can get the numbers by simple calculations. #Surrounds, #ARs, #TotalEdges(CARs) 1, 7, 12 2, 19, 42 3, 37, 90 4, 61, 156 5, 91, 240 6, 127, 342 According to this results, if an operator deploys 127 ARs, the operator possibly receives 342 call-miss complaints from customers. They might include important emergency call handover misses. This is a nightmare to the operator. No one knows one call is less important than the other calls. Who can say this is not a big deal? If we take learning-based approach, we can't avoid this problem by nature. The server-based approach can provide a way to greatly improve this. Placing a server will save hundreds of handover failures in initial stage. Also the server will be used to save handover failures every time a CAR cache in an AR expires as well. It's not a trivial matter. Operators won't take a solution, which doesn't provide a way to improve quality to customers. Moreover, operators won't take any way, which sacrifices users to improve their network operation efficiency. The burden should not be shared with customers. Regards, Daichi _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 12 20:53:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03560 for ; Wed, 12 Mar 2003 20:53:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D27RO03684; Wed, 12 Mar 2003 21:07:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D263O02855 for ; Wed, 12 Mar 2003 21:06:03 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03495 for ; Wed, 12 Mar 2003 20:51:19 -0500 (EST) Date: Wed, 12 Mar 2003 17:51:26 -0800 From: Daichi Funato To: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD In-Reply-To: References: Message-Id: <20030312174925.3349.FUNATO@docomolabs-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hemant, > Hemant -> I am trying to do some back of the envelope calculation > here. There are two ARs and first handoff happens between them. > Let us say cache lifetime is few hours. If another handoff occurs > during those few hours, cache gets refreshed for another few hours. > If no handoff occurs between those two ARs in few hours, why do > we need to care of about seamlessness in the first place. I don't think this calculation is enough... A server is necessary to save the initial handover failures. Let me show you another caluculation. Suppose there is an AR, which has a hexagon shape coverage. If we surround this AR with other AR hexagons, there will be 7 ARs. In this case, the total adjacent edges, which equals to the total CAR entries, are 12. This means we need 12 learning reports from MNs with 12 handover failures in learning-based approach. If we continue surrounding this, we can get the numbers by simple calculations. #Surrounds, #ARs, #TotalEdges(CARs) 1, 7, 12 2, 19, 42 3, 37, 90 4, 61, 156 5, 91, 240 6, 127, 342 According to this results, if an operator deploys 127 ARs, the operator possibly receives 342 call-miss complaints from customers. They might include important emergency call handover misses. This is a nightmare to the operator. No one knows one call is less important than the other calls. Who can say this is not a big deal? If we take learning-based approach, we can't avoid this problem by nature. The server-based approach can provide a way to greatly improve this. Placing a server will save hundreds of handover failures in initial stage. Also the server will be used to save handover failures every time a CAR cache in an AR expires as well. It's not a trivial matter. Operators won't take a solution, which doesn't provide a way to improve quality to customers. Moreover, operators won't take any way, which sacrifices users to improve their network operation efficiency. The burden should not be shared with customers. Regards, Daichi _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 00:07:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08507 for ; Thu, 13 Mar 2003 00:07:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D5LW915555 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 00:21:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D5LWO15552 for ; Thu, 13 Mar 2003 00:21:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08490 for ; Thu, 13 Mar 2003 00:06:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D5LJO15534; Thu, 13 Mar 2003 00:21:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D5KrO15507 for ; Thu, 13 Mar 2003 00:20:53 -0500 Received: from slb-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08482 for ; Thu, 13 Mar 2003 00:06:06 -0500 (EST) Received: from blv-av-02.boeing.com ([192.42.227.217]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id VAA24688; Wed, 12 Mar 2003 21:07:52 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id VAA21436; Wed, 12 Mar 2003 21:08:06 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2D585M29208; Wed, 12 Mar 2003 21:08:06 -0800 (PST) Received: from XCH-NW-05.nw.nos.boeing.com ([192.42.226.70]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Mar 2003 21:08:05 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 21:08:05 -0800 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2R1TQosBGtBLQfCJ1N7g6LQZRQAAFHrwAA1pheA= From: "Paine, Richard H" To: , , , Cc: "Fleischman, Eric" X-OriginalArrivalTime: 13 Mar 2003 05:08:05.0783 (UTC) FILETIME=[87E22270:01C2E91E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2D5KrO15508 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit In fact there is a secure layer 2 mechanism for communicating between APs and it is, in effect, a context transfer protocol; 802.11f. You can even define the context. Richard H. Paine Success is getting what you want, happiness is liking what you get! Work: 425-865-4921 Pager: 206-797-4580 Cell: 206-854-8199 IPPhone: 206-766-5808 Email: richard.h.paine@boeing.com -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Wednesday, March 12, 2003 1:11 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > There is need for some mechanism, independent of any > interrouter exchange of > information, for a router to determine whether a particular > AP is, in fact, > authorized. This mechanism functions as a trust root, if you > will. That is what > I was referring to. [Govind] Why is this an issue that has to be considered at the IETF? Isn't this the function of the L2 mechanism or some other management mechanism to ensure this. The DT draft also, I believe, clearly states that this is out of scope. Hemant's recent mail also attests to this. > Or were you proposing a protocol between APs and ARs to allow > the AR to validate > whether an AP is authorized? > [Govind] dycard does not. Neither does the DT draft, I believe. Both assume that this information is available. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 00:07:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08520 for ; Thu, 13 Mar 2003 00:07:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D5LJO15534; Thu, 13 Mar 2003 00:21:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D5KrO15507 for ; Thu, 13 Mar 2003 00:20:53 -0500 Received: from slb-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08482 for ; Thu, 13 Mar 2003 00:06:06 -0500 (EST) Received: from blv-av-02.boeing.com ([192.42.227.217]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id VAA24688; Wed, 12 Mar 2003 21:07:52 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id VAA21436; Wed, 12 Mar 2003 21:08:06 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2D585M29208; Wed, 12 Mar 2003 21:08:06 -0800 (PST) Received: from XCH-NW-05.nw.nos.boeing.com ([192.42.226.70]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Mar 2003 21:08:05 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Wed, 12 Mar 2003 21:08:05 -0800 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo2R1TQosBGtBLQfCJ1N7g6LQZRQAAFHrwAA1pheA= From: "Paine, Richard H" To: , , , Cc: "Fleischman, Eric" X-OriginalArrivalTime: 13 Mar 2003 05:08:05.0783 (UTC) FILETIME=[87E22270:01C2E91E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2D5KrO15508 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit In fact there is a secure layer 2 mechanism for communicating between APs and it is, in effect, a context transfer protocol; 802.11f. You can even define the context. Richard H. Paine Success is getting what you want, happiness is liking what you get! Work: 425-865-4921 Pager: 206-797-4580 Cell: 206-854-8199 IPPhone: 206-766-5808 Email: richard.h.paine@boeing.com -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Wednesday, March 12, 2003 1:11 PM To: kempf@docomolabs-usa.com; eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > There is need for some mechanism, independent of any > interrouter exchange of > information, for a router to determine whether a particular > AP is, in fact, > authorized. This mechanism functions as a trust root, if you > will. That is what > I was referring to. [Govind] Why is this an issue that has to be considered at the IETF? Isn't this the function of the L2 mechanism or some other management mechanism to ensure this. The DT draft also, I believe, clearly states that this is out of scope. Hemant's recent mail also attests to this. > Or were you proposing a protocol between APs and ARs to allow > the AR to validate > whether an AP is authorized? > [Govind] dycard does not. Neither does the DT draft, I believe. Both assume that this information is available. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 09:45:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02310 for ; Thu, 13 Mar 2003 09:45:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DExa900839 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 09:59:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DExZO00836 for ; Thu, 13 Mar 2003 09:59:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02291 for ; Thu, 13 Mar 2003 09:44:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DExLO00797; Thu, 13 Mar 2003 09:59:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEw2O00722 for ; Thu, 13 Mar 2003 09:58:02 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02216 for ; Thu, 13 Mar 2003 09:43:02 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DEjA807568 for ; Thu, 13 Mar 2003 08:45:10 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 08:45:10 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 06:44:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 09:44:17 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo6uBRoL5qWtyTSMKujYShS/QlrgAg1pGA To: , , , X-OriginalArrivalTime: 13 Mar 2003 14:44:22.0973 (UTC) FILETIME=[097E9ED0:01C2E96F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DEw2O00723 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, thanks for giving me the merits for discovering this "security hole", but you greatly misinterpret my intentions. Local AP-AR authentication is a problem concerned with security, and this will remain the only common point in our both thinking. Beyond this, I do not believe that this is within the scope of CAR discovery. There exist easy solutions to solve this problem (as pointed out by other emails), and both discussed solutions (dycard and DT draft) assume the existence of these mechanisms. I start wondering what you want to achieve by recalling requirements (and consequently issues) draft from the IESG. This call comes a bit too early and too quickly for me so that I'm wondering whether you actually have the progress of the CAR work in mind when you propose something like this. Thanks, Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Wednesday, March 12, 2003 5:52 PM >To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); >eunsoo@nec-labs.com; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >Dirk, > >You're right. This is a significant gap in our requirements. > >We will have to recall them from the IESG and include it. It >is an unacceptable >security hole for there to be no requirement that APs be >authorized. I'm >suprised Steve Bellovin didn't find this. > >Thanx for pointing out this serious hole. > > jak > >----- Original Message ----- >From: >To: ; ; >; >Sent: Wednesday, March 12, 2003 1:07 PM >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > >> Hi James, >> >> I'm surprised to suddenly see AP authentication in the scope >of CAR discovery. >Where does this change of >> scope come from? If a network operator requires AP >authentication for each AR, >network management >> tools can be used to download the list of APs to the AR. I >don't see anything >in the issue draft putting >> this on the table of CAR discovery (we would have called it >CAR and local AP >discovery then). >> >> So if you want to address this, let's define MIB entries and >push mechanisms >to download said AP entries to >> the AR MIB, and we're done. >> >> Dirk >> >> >-----Original Message----- >> >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >> >Sent: Wednesday, March 12, 2003 3:58 PM >> >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; >seamoby@ietf.org >> >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> > >> > >> >No disconnect. >> > >> >My point was, this is a deficiency with both drafts. It is an >> >issue we need to >> >resolve before we can consider the design complete. >> > >> > jak >> > >> >----- Original Message ----- >> >From: >> >To: ; ; >> > >> >Sent: Wednesday, March 12, 2003 12:22 PM >> >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD >> > >> > >> >> Hi: >> >> >> >> There seems to be some disconnect. The current DT draft does >> >NOT intend solve >> >the problem of enabling AR to determine which APs are >> >authorized. APs are >> >brought up/down and connected to/disconnected from AR. Some L2 >> >layer mechanism >> >between AR-AP enables AR to learn about new/removed AP. AR >> >reports that AP is >> >up/down to CARD server and CARD server stores the mapping. In >> >other words, AR is >> >in control of knowing what APs are attached to it and CARD >> >server relies on >> >information provided by AR regarding this. >> >> >> >> Hemant >> >> >> >> -----Original Message----- >> >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] >> >> Sent: Wednesday, March 12, 2003 4:48 PM >> >> To: James Kempf; seamoby@ietf.org >> >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> >> >> >> >> >> >> >> >> >> > The server will allow an AR to determine which APs are >> >authorized. The >> >> dycard >> >> > draft has nothing about this. This is an important >> >security measure, >> >> though not >> >> > directly related to exchanging the CAR information. >> >> > >> >> [eunsoo] The routing protocol (for the wired Internet) >has a similar >> >> problem. They want to know whether a router is authorized to >> >participate in >> >> the route discovery. So for intra-domain routing protocols, >> >usually shared >> >> secret is proposed. Also Dycard assumes it in the expression >> >that there >> >> should be a security association between ARs. If we consider only >> >> intra-domain communication between ARs, shared secret would >> >be sufficient >> >> for authorization and message authentication. If you >> >consider central NMS >> >> system that allows remote configuration of ARs, it would be >> >very easy to >> >> configure the shared secret among ARs. If there is no such >> >thing, people do >> >> the configuration by remotely logging into ARs. This one >> >time configuration >> >> removes concerns about scalability and reliability. You >> >don't need a server >> >> running up 24/7 for this authorization since you don't >> >expect a new AR that >> >> often. >> >> >> >> Eunsoo >> >> >> >> _______________________________________________ >> >> Seamoby mailing list >> >> Seamoby@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/seamoby >> >> >> >> >> > >> >_______________________________________________ >> >Seamoby mailing list >> >Seamoby@ietf.org >> >https://www1.ietf.org/mailman/listinfo/seamoby >> > >> >> > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 09:45:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02328 for ; Thu, 13 Mar 2003 09:45:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DExLO00797; Thu, 13 Mar 2003 09:59:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEw2O00722 for ; Thu, 13 Mar 2003 09:58:02 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02216 for ; Thu, 13 Mar 2003 09:43:02 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DEjA807568 for ; Thu, 13 Mar 2003 08:45:10 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 08:45:10 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 06:44:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 09:44:17 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLo6uBRoL5qWtyTSMKujYShS/QlrgAg1pGA To: , , , X-OriginalArrivalTime: 13 Mar 2003 14:44:22.0973 (UTC) FILETIME=[097E9ED0:01C2E96F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DEw2O00723 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, thanks for giving me the merits for discovering this "security hole", but you greatly misinterpret my intentions. Local AP-AR authentication is a problem concerned with security, and this will remain the only common point in our both thinking. Beyond this, I do not believe that this is within the scope of CAR discovery. There exist easy solutions to solve this problem (as pointed out by other emails), and both discussed solutions (dycard and DT draft) assume the existence of these mechanisms. I start wondering what you want to achieve by recalling requirements (and consequently issues) draft from the IESG. This call comes a bit too early and too quickly for me so that I'm wondering whether you actually have the progress of the CAR work in mind when you propose something like this. Thanks, Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Wednesday, March 12, 2003 5:52 PM >To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); >eunsoo@nec-labs.com; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >Dirk, > >You're right. This is a significant gap in our requirements. > >We will have to recall them from the IESG and include it. It >is an unacceptable >security hole for there to be no requirement that APs be >authorized. I'm >suprised Steve Bellovin didn't find this. > >Thanx for pointing out this serious hole. > > jak > >----- Original Message ----- >From: >To: ; ; >; >Sent: Wednesday, March 12, 2003 1:07 PM >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > >> Hi James, >> >> I'm surprised to suddenly see AP authentication in the scope >of CAR discovery. >Where does this change of >> scope come from? If a network operator requires AP >authentication for each AR, >network management >> tools can be used to download the list of APs to the AR. I >don't see anything >in the issue draft putting >> this on the table of CAR discovery (we would have called it >CAR and local AP >discovery then). >> >> So if you want to address this, let's define MIB entries and >push mechanisms >to download said AP entries to >> the AR MIB, and we're done. >> >> Dirk >> >> >-----Original Message----- >> >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >> >Sent: Wednesday, March 12, 2003 3:58 PM >> >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; >seamoby@ietf.org >> >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> > >> > >> >No disconnect. >> > >> >My point was, this is a deficiency with both drafts. It is an >> >issue we need to >> >resolve before we can consider the design complete. >> > >> > jak >> > >> >----- Original Message ----- >> >From: >> >To: ; ; >> > >> >Sent: Wednesday, March 12, 2003 12:22 PM >> >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD >> > >> > >> >> Hi: >> >> >> >> There seems to be some disconnect. The current DT draft does >> >NOT intend solve >> >the problem of enabling AR to determine which APs are >> >authorized. APs are >> >brought up/down and connected to/disconnected from AR. Some L2 >> >layer mechanism >> >between AR-AP enables AR to learn about new/removed AP. AR >> >reports that AP is >> >up/down to CARD server and CARD server stores the mapping. In >> >other words, AR is >> >in control of knowing what APs are attached to it and CARD >> >server relies on >> >information provided by AR regarding this. >> >> >> >> Hemant >> >> >> >> -----Original Message----- >> >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] >> >> Sent: Wednesday, March 12, 2003 4:48 PM >> >> To: James Kempf; seamoby@ietf.org >> >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> >> >> >> >> >> >> >> >> >> > The server will allow an AR to determine which APs are >> >authorized. The >> >> dycard >> >> > draft has nothing about this. This is an important >> >security measure, >> >> though not >> >> > directly related to exchanging the CAR information. >> >> > >> >> [eunsoo] The routing protocol (for the wired Internet) >has a similar >> >> problem. They want to know whether a router is authorized to >> >participate in >> >> the route discovery. So for intra-domain routing protocols, >> >usually shared >> >> secret is proposed. Also Dycard assumes it in the expression >> >that there >> >> should be a security association between ARs. If we consider only >> >> intra-domain communication between ARs, shared secret would >> >be sufficient >> >> for authorization and message authentication. If you >> >consider central NMS >> >> system that allows remote configuration of ARs, it would be >> >very easy to >> >> configure the shared secret among ARs. If there is no such >> >thing, people do >> >> the configuration by remotely logging into ARs. This one >> >time configuration >> >> removes concerns about scalability and reliability. You >> >don't need a server >> >> running up 24/7 for this authorization since you don't >> >expect a new AR that >> >> often. >> >> >> >> Eunsoo >> >> >> >> _______________________________________________ >> >> Seamoby mailing list >> >> Seamoby@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/seamoby >> >> >> >> >> > >> >_______________________________________________ >> >Seamoby mailing list >> >Seamoby@ietf.org >> >https://www1.ietf.org/mailman/listinfo/seamoby >> > >> >> > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 10:04:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03441 for ; Thu, 13 Mar 2003 10:04:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DFJ1k02881 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 10:19:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFJ1O02878 for ; Thu, 13 Mar 2003 10:19:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03368 for ; Thu, 13 Mar 2003 10:04:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFIhO02839; Thu, 13 Mar 2003 10:18:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFGIO02630 for ; Thu, 13 Mar 2003 10:16:18 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03182 for ; Thu, 13 Mar 2003 10:01:18 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DF3Ua05237 for ; Thu, 13 Mar 2003 09:03:30 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 09:03:28 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 09:03:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 10:03:26 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLpA5W/zN6nd3PNRcuubgwmEn2T7AAbXvTQ To: , X-OriginalArrivalTime: 13 Mar 2003 15:03:27.0890 (UTC) FILETIME=[B3EB1720:01C2E971] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DFGIO02631 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Daichi, >According to this results, if an operator deploys 127 ARs, the >operator possibly receives 342 call-miss complaints from customers. >They might include important emergency call handover misses. >This is a nightmare to the operator. >No one knows one call is less important than the other calls. >Who can say this is not a big deal? So the failure of CAR implies a failure of the entire handover, i.e., it results in a call miss? I guess handover people in MIP WG will not like to hear this reasoning regarding the dependence of handover on CAR discovery ;-) What we are talking about is that learning-based approach's first handover is a break before make handover. But still, the handover will happen eventually. More concretely, we talk about having a glitch in our first handover of a cell compared to a probability of not having this glitch in the first handover. We believe that the removal of said glitch is not worth the overhead of a server in the solution. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 10:04:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03481 for ; Thu, 13 Mar 2003 10:04:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFIhO02839; Thu, 13 Mar 2003 10:18:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFGIO02630 for ; Thu, 13 Mar 2003 10:16:18 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03182 for ; Thu, 13 Mar 2003 10:01:18 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DF3Ua05237 for ; Thu, 13 Mar 2003 09:03:30 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 09:03:28 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 09:03:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 10:03:26 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLpA5W/zN6nd3PNRcuubgwmEn2T7AAbXvTQ To: , X-OriginalArrivalTime: 13 Mar 2003 15:03:27.0890 (UTC) FILETIME=[B3EB1720:01C2E971] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DFGIO02631 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Daichi, >According to this results, if an operator deploys 127 ARs, the >operator possibly receives 342 call-miss complaints from customers. >They might include important emergency call handover misses. >This is a nightmare to the operator. >No one knows one call is less important than the other calls. >Who can say this is not a big deal? So the failure of CAR implies a failure of the entire handover, i.e., it results in a call miss? I guess handover people in MIP WG will not like to hear this reasoning regarding the dependence of handover on CAR discovery ;-) What we are talking about is that learning-based approach's first handover is a break before make handover. But still, the handover will happen eventually. More concretely, we talk about having a glitch in our first handover of a cell compared to a probability of not having this glitch in the first handover. We believe that the removal of said glitch is not worth the overhead of a server in the solution. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 10:55:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06517 for ; Thu, 13 Mar 2003 10:55:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DGAOi07566 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 11:10:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGAOO07563 for ; Thu, 13 Mar 2003 11:10:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06502 for ; Thu, 13 Mar 2003 10:55:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGA8O07516; Thu, 13 Mar 2003 11:10:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DG9FO07456 for ; Thu, 13 Mar 2003 11:09:15 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06417 for ; Thu, 13 Mar 2003 10:54:13 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2DFuIZj026895 for ; Thu, 13 Mar 2003 08:56:18 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA11787 for ; Thu, 13 Mar 2003 08:54:20 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Mar 2003 09:56:22 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE4E@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , funato@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 09:56:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , What we are talking about is that learning-based approach's first handover is a break before make handover. But still, the handover will happen eventually. AJOY-> BTW, standard MIP handover may not acceptable for a voice user. -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Thursday, March 13, 2003 9:03 AM To: funato@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi Daichi, >According to this results, if an operator deploys 127 ARs, the >operator possibly receives 342 call-miss complaints from customers. >They might include important emergency call handover misses. >This is a nightmare to the operator. >No one knows one call is less important than the other calls. >Who can say this is not a big deal? So the failure of CAR implies a failure of the entire handover, i.e., it results in a call miss? I guess handover people in MIP WG will not like to hear this reasoning regarding the dependence of handover on CAR discovery ;-) What we are talking about is that learning-based approach's first handover is a break before make handover. But still, the handover will happen eventually. More concretely, we talk about having a glitch in our first handover of a cell compared to a probability of not having this glitch in the first handover. We believe that the removal of said glitch is not worth the overhead of a server in the solution. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 10:56:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06537 for ; Thu, 13 Mar 2003 10:56:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGA8O07516; Thu, 13 Mar 2003 11:10:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DG9FO07456 for ; Thu, 13 Mar 2003 11:09:15 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06417 for ; Thu, 13 Mar 2003 10:54:13 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2DFuIZj026895 for ; Thu, 13 Mar 2003 08:56:18 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA11787 for ; Thu, 13 Mar 2003 08:54:20 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Mar 2003 09:56:22 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE4E@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , funato@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 09:56:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , What we are talking about is that learning-based approach's first handover is a break before make handover. But still, the handover will happen eventually. AJOY-> BTW, standard MIP handover may not acceptable for a voice user. -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Thursday, March 13, 2003 9:03 AM To: funato@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Hi Daichi, >According to this results, if an operator deploys 127 ARs, the >operator possibly receives 342 call-miss complaints from customers. >They might include important emergency call handover misses. >This is a nightmare to the operator. >No one knows one call is less important than the other calls. >Who can say this is not a big deal? So the failure of CAR implies a failure of the entire handover, i.e., it results in a call miss? I guess handover people in MIP WG will not like to hear this reasoning regarding the dependence of handover on CAR discovery ;-) What we are talking about is that learning-based approach's first handover is a break before make handover. But still, the handover will happen eventually. More concretely, we talk about having a glitch in our first handover of a cell compared to a probability of not having this glitch in the first handover. We believe that the removal of said glitch is not worth the overhead of a server in the solution. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 11:02:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06753 for ; Thu, 13 Mar 2003 11:02:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DGGbI07868 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 11:16:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGGbO07865 for ; Thu, 13 Mar 2003 11:16:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06728 for ; Thu, 13 Mar 2003 11:01:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGGMO07832; Thu, 13 Mar 2003 11:16:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGDVO07705 for ; Thu, 13 Mar 2003 11:13:31 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06613 for ; Thu, 13 Mar 2003 10:58:29 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DG0d826156 for ; Thu, 13 Mar 2003 10:00:39 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 10:00:33 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 08:00:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 11:00:30 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLpA5WoGLjaQvwfRsKJcm03GhybVgAdQ+oQ To: , X-OriginalArrivalTime: 13 Mar 2003 16:00:33.0078 (UTC) FILETIME=[AD7D4D60:01C2E979] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DGDVO07706 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Daichi: (DT hat off) Well, I can do another calculation and show you that this is not a big deal (definitely not a nightmare). The underline is that - first handoff between two ARs is not seamless (does not mean a failure). Also, you have not factored in issues like radio degradation, congestion on radio signaling channels etc. in this calculation. Then you have not considered the probability of first handoff between ARs being an emergency call. And then you have not considered the probability that server is loaded or down during emergency call in current protocol. Hemant -----Original Message----- From: ext Daichi Funato [mailto:funato@docomolabs-usa.com] Sent: Wednesday, March 12, 2003 8:51 PM To: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Hi Hemant, > Hemant -> I am trying to do some back of the envelope calculation > here. There are two ARs and first handoff happens between them. > Let us say cache lifetime is few hours. If another handoff occurs > during those few hours, cache gets refreshed for another few hours. > If no handoff occurs between those two ARs in few hours, why do > we need to care of about seamlessness in the first place. I don't think this calculation is enough... A server is necessary to save the initial handover failures. Let me show you another caluculation. Suppose there is an AR, which has a hexagon shape coverage. If we surround this AR with other AR hexagons, there will be 7 ARs. In this case, the total adjacent edges, which equals to the total CAR entries, are 12. This means we need 12 learning reports from MNs with 12 handover failures in learning-based approach. If we continue surrounding this, we can get the numbers by simple calculations. #Surrounds, #ARs, #TotalEdges(CARs) 1, 7, 12 2, 19, 42 3, 37, 90 4, 61, 156 5, 91, 240 6, 127, 342 According to this results, if an operator deploys 127 ARs, the operator possibly receives 342 call-miss complaints from customers. They might include important emergency call handover misses. This is a nightmare to the operator. No one knows one call is less important than the other calls. Who can say this is not a big deal? If we take learning-based approach, we can't avoid this problem by nature. The server-based approach can provide a way to greatly improve this. Placing a server will save hundreds of handover failures in initial stage. Also the server will be used to save handover failures every time a CAR cache in an AR expires as well. It's not a trivial matter. Operators won't take a solution, which doesn't provide a way to improve quality to customers. Moreover, operators won't take any way, which sacrifices users to improve their network operation efficiency. The burden should not be shared with customers. Regards, Daichi _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 11:02:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06798 for ; Thu, 13 Mar 2003 11:02:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGGMO07832; Thu, 13 Mar 2003 11:16:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGDVO07705 for ; Thu, 13 Mar 2003 11:13:31 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06613 for ; Thu, 13 Mar 2003 10:58:29 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DG0d826156 for ; Thu, 13 Mar 2003 10:00:39 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 10:00:33 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 08:00:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 11:00:30 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLpA5WoGLjaQvwfRsKJcm03GhybVgAdQ+oQ To: , X-OriginalArrivalTime: 13 Mar 2003 16:00:33.0078 (UTC) FILETIME=[AD7D4D60:01C2E979] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DGDVO07706 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Daichi: (DT hat off) Well, I can do another calculation and show you that this is not a big deal (definitely not a nightmare). The underline is that - first handoff between two ARs is not seamless (does not mean a failure). Also, you have not factored in issues like radio degradation, congestion on radio signaling channels etc. in this calculation. Then you have not considered the probability of first handoff between ARs being an emergency call. And then you have not considered the probability that server is loaded or down during emergency call in current protocol. Hemant -----Original Message----- From: ext Daichi Funato [mailto:funato@docomolabs-usa.com] Sent: Wednesday, March 12, 2003 8:51 PM To: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Hi Hemant, > Hemant -> I am trying to do some back of the envelope calculation > here. There are two ARs and first handoff happens between them. > Let us say cache lifetime is few hours. If another handoff occurs > during those few hours, cache gets refreshed for another few hours. > If no handoff occurs between those two ARs in few hours, why do > we need to care of about seamlessness in the first place. I don't think this calculation is enough... A server is necessary to save the initial handover failures. Let me show you another caluculation. Suppose there is an AR, which has a hexagon shape coverage. If we surround this AR with other AR hexagons, there will be 7 ARs. In this case, the total adjacent edges, which equals to the total CAR entries, are 12. This means we need 12 learning reports from MNs with 12 handover failures in learning-based approach. If we continue surrounding this, we can get the numbers by simple calculations. #Surrounds, #ARs, #TotalEdges(CARs) 1, 7, 12 2, 19, 42 3, 37, 90 4, 61, 156 5, 91, 240 6, 127, 342 According to this results, if an operator deploys 127 ARs, the operator possibly receives 342 call-miss complaints from customers. They might include important emergency call handover misses. This is a nightmare to the operator. No one knows one call is less important than the other calls. Who can say this is not a big deal? If we take learning-based approach, we can't avoid this problem by nature. The server-based approach can provide a way to greatly improve this. Placing a server will save hundreds of handover failures in initial stage. Also the server will be used to save handover failures every time a CAR cache in an AR expires as well. It's not a trivial matter. Operators won't take a solution, which doesn't provide a way to improve quality to customers. Moreover, operators won't take any way, which sacrifices users to improve their network operation efficiency. The burden should not be shared with customers. Regards, Daichi _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 11:25:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07664 for ; Thu, 13 Mar 2003 11:25:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DGdWH09835 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 11:39:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGdWO09832 for ; Thu, 13 Mar 2003 11:39:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07653 for ; Thu, 13 Mar 2003 11:24:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGdFO09821; Thu, 13 Mar 2003 11:39:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGZqO08924 for ; Thu, 13 Mar 2003 11:35:52 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07563 for ; Thu, 13 Mar 2003 11:20:50 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DGMv802792 for ; Thu, 13 Mar 2003 10:22:57 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 10:22:57 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 10:22:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 11:22:56 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLpA5WZ+onpFIdUQuKix815dV1W0wAbFHoQ To: , X-OriginalArrivalTime: 13 Mar 2003 16:22:57.0592 (UTC) FILETIME=[CEE1DB80:01C2E97C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DGZqO08925 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Daichi, My responses embedded. > Suppose there is an AR, which has a hexagon shape coverage. > If we surround this AR with other AR hexagons, there will be > 7 ARs. In this case, the total adjacent edges, which equals to > the total CAR entries, are 12. This means we need 12 learning > reports from MNs with 12 handover failures in learning-based > approach. First, can you explain to me why if you don't do CARD it is a handover failure? Are you saying that calls will be dropped if there is no seamless handovers? Do you have any basis for this argument? A couple of years ago, we implemented a buffering protocol where most of the packets got through, with base Mobile IPv6, even when we did a manual handover, i.e. disconnecting the wire from one router and plugging it into another router. No CARD here, and probably lossless too. Second, are you guaranteeing seamless handovers always with the server approach, inspite of all that has been pointed out in the mailing list? Lastly, as Eunsoo pointed out if the network is tested during operator trials before getting it out to the customers the caches will anyways be filled up, before the network gets to the customers is it not? > > If we continue surrounding this, we can get the numbers by > simple calculations. > > #Surrounds, #ARs, #TotalEdges(CARs) > 1, 7, 12 > 2, 19, 42 > 3, 37, 90 > 4, 61, 156 > 5, 91, 240 > 6, 127, 342 > > According to this results, if an operator deploys 127 ARs, the > operator possibly receives 342 call-miss complaints from customers. > They might include important emergency call handover misses. > This is a nightmare to the operator. > No one knows one call is less important than the other calls. > Who can say this is not a big deal? > [Govind] You don't point out the success ratio at all. I think that might be the main thing to consider. Loosing "hundreds" of seamless handovers over time, wherein millions and possibly billions of seamless handovers are made is actually not a big deal, IMHO. Because, handovers can fail even when everything works right from the protocol point of view, due to the physical layer that we are talking about. Maybe success ratio is the criteria that could be the benchmark, success ratio in steady state. To put up a server for "hundreds" of calls is not anything a service provider, though I don't have any service provider hat to put on, will buy either. > If we take learning-based approach, we can't avoid this > problem by nature. > The server-based approach can provide a way to greatly improve this. [Govind] Can you give us some numbers for this? > Placing a server will save hundreds of handover failures in > initial stage. > Also the server will be used to save handover failures every time a > CAR cache in an AR expires as well. It's not a trivial matter. [Govind] I don't think the point that the server saves handover failures during CAR cache expirations can be validated very easily. If we are designing a protocol for handovers, once they happen caches will be refreshed automatically. Further, you are missing an important point of extensibility to inter-domains. Though it is a SHOULD now in the requirements, I would think this is a very important feature of dycard. I don't think having servers is feasible in inter-domain handovers. Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 11:25:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07682 for ; Thu, 13 Mar 2003 11:25:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGdFO09821; Thu, 13 Mar 2003 11:39:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DGZqO08924 for ; Thu, 13 Mar 2003 11:35:52 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07563 for ; Thu, 13 Mar 2003 11:20:50 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DGMv802792 for ; Thu, 13 Mar 2003 10:22:57 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 10:22:57 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 10:22:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 11:22:56 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLpA5WZ+onpFIdUQuKix815dV1W0wAbFHoQ To: , X-OriginalArrivalTime: 13 Mar 2003 16:22:57.0592 (UTC) FILETIME=[CEE1DB80:01C2E97C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DGZqO08925 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Daichi, My responses embedded. > Suppose there is an AR, which has a hexagon shape coverage. > If we surround this AR with other AR hexagons, there will be > 7 ARs. In this case, the total adjacent edges, which equals to > the total CAR entries, are 12. This means we need 12 learning > reports from MNs with 12 handover failures in learning-based > approach. First, can you explain to me why if you don't do CARD it is a handover failure? Are you saying that calls will be dropped if there is no seamless handovers? Do you have any basis for this argument? A couple of years ago, we implemented a buffering protocol where most of the packets got through, with base Mobile IPv6, even when we did a manual handover, i.e. disconnecting the wire from one router and plugging it into another router. No CARD here, and probably lossless too. Second, are you guaranteeing seamless handovers always with the server approach, inspite of all that has been pointed out in the mailing list? Lastly, as Eunsoo pointed out if the network is tested during operator trials before getting it out to the customers the caches will anyways be filled up, before the network gets to the customers is it not? > > If we continue surrounding this, we can get the numbers by > simple calculations. > > #Surrounds, #ARs, #TotalEdges(CARs) > 1, 7, 12 > 2, 19, 42 > 3, 37, 90 > 4, 61, 156 > 5, 91, 240 > 6, 127, 342 > > According to this results, if an operator deploys 127 ARs, the > operator possibly receives 342 call-miss complaints from customers. > They might include important emergency call handover misses. > This is a nightmare to the operator. > No one knows one call is less important than the other calls. > Who can say this is not a big deal? > [Govind] You don't point out the success ratio at all. I think that might be the main thing to consider. Loosing "hundreds" of seamless handovers over time, wherein millions and possibly billions of seamless handovers are made is actually not a big deal, IMHO. Because, handovers can fail even when everything works right from the protocol point of view, due to the physical layer that we are talking about. Maybe success ratio is the criteria that could be the benchmark, success ratio in steady state. To put up a server for "hundreds" of calls is not anything a service provider, though I don't have any service provider hat to put on, will buy either. > If we take learning-based approach, we can't avoid this > problem by nature. > The server-based approach can provide a way to greatly improve this. [Govind] Can you give us some numbers for this? > Placing a server will save hundreds of handover failures in > initial stage. > Also the server will be used to save handover failures every time a > CAR cache in an AR expires as well. It's not a trivial matter. [Govind] I don't think the point that the server saves handover failures during CAR cache expirations can be validated very easily. If we are designing a protocol for handovers, once they happen caches will be refreshed automatically. Further, you are missing an important point of extensibility to inter-domains. Though it is a SHOULD now in the requirements, I would think this is a very important feature of dycard. I don't think having servers is feasible in inter-domain handovers. Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 12:46:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10251 for ; Thu, 13 Mar 2003 12:46:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DI0mJ15800 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 13:00:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DI0mO15797 for ; Thu, 13 Mar 2003 13:00:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10237 for ; Thu, 13 Mar 2003 12:45:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DI0TO15772; Thu, 13 Mar 2003 13:00:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DHxTO15705 for ; Thu, 13 Mar 2003 12:59:29 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10200 for ; Thu, 13 Mar 2003 12:44:25 -0500 (EST) Message-ID: <013201c2e988$46bada70$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 09:45:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dirk, The issue isn't whether there are easy solutions, the issue is that a solution MUST be specified. If the solutions are easy, then specifying them should be as well, no? jak ----- Original Message ----- From: To: ; ; ; Sent: Thursday, March 13, 2003 6:44 AM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Hi James, > > thanks for giving me the merits for discovering this "security hole", but you greatly misinterpret my intentions. > Local AP-AR authentication is a problem concerned with security, and this will remain the only common point > in our both thinking. > > Beyond this, I do not believe that this is within the scope of CAR discovery. There exist easy solutions to solve this > problem (as pointed out by other emails), and both discussed solutions (dycard and DT draft) assume the existence of these > mechanisms. > > I start wondering what you want to achieve by recalling requirements (and consequently issues) draft from the IESG. This > call comes a bit too early and too quickly for me so that I'm wondering whether you actually have the progress of the CAR > work in mind when you propose something like this. > > Thanks, > > Dirk > > >-----Original Message----- > >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > >Sent: Wednesday, March 12, 2003 5:52 PM > >To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); > >eunsoo@nec-labs.com; seamoby@ietf.org > >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > >Dirk, > > > >You're right. This is a significant gap in our requirements. > > > >We will have to recall them from the IESG and include it. It > >is an unacceptable > >security hole for there to be no requirement that APs be > >authorized. I'm > >suprised Steve Bellovin didn't find this. > > > >Thanx for pointing out this serious hole. > > > > jak > > > >----- Original Message ----- > >From: > >To: ; ; > >; > >Sent: Wednesday, March 12, 2003 1:07 PM > >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > >> Hi James, > >> > >> I'm surprised to suddenly see AP authentication in the scope > >of CAR discovery. > >Where does this change of > >> scope come from? If a network operator requires AP > >authentication for each AR, > >network management > >> tools can be used to download the list of APs to the AR. I > >don't see anything > >in the issue draft putting > >> this on the table of CAR discovery (we would have called it > >CAR and local AP > >discovery then). > >> > >> So if you want to address this, let's define MIB entries and > >push mechanisms > >to download said AP entries to > >> the AR MIB, and we're done. > >> > >> Dirk > >> > >> >-----Original Message----- > >> >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > >> >Sent: Wednesday, March 12, 2003 3:58 PM > >> >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; > >seamoby@ietf.org > >> >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > >> > > >> > > >> >No disconnect. > >> > > >> >My point was, this is a deficiency with both drafts. It is an > >> >issue we need to > >> >resolve before we can consider the design complete. > >> > > >> > jak > >> > > >> >----- Original Message ----- > >> >From: > >> >To: ; ; > >> > > >> >Sent: Wednesday, March 12, 2003 12:22 PM > >> >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > >> > > >> > > >> >> Hi: > >> >> > >> >> There seems to be some disconnect. The current DT draft does > >> >NOT intend solve > >> >the problem of enabling AR to determine which APs are > >> >authorized. APs are > >> >brought up/down and connected to/disconnected from AR. Some L2 > >> >layer mechanism > >> >between AR-AP enables AR to learn about new/removed AP. AR > >> >reports that AP is > >> >up/down to CARD server and CARD server stores the mapping. In > >> >other words, AR is > >> >in control of knowing what APs are attached to it and CARD > >> >server relies on > >> >information provided by AR regarding this. > >> >> > >> >> Hemant > >> >> > >> >> -----Original Message----- > >> >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > >> >> Sent: Wednesday, March 12, 2003 4:48 PM > >> >> To: James Kempf; seamoby@ietf.org > >> >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > >> >> > >> >> > >> >> > >> >> > >> >> > The server will allow an AR to determine which APs are > >> >authorized. The > >> >> dycard > >> >> > draft has nothing about this. This is an important > >> >security measure, > >> >> though not > >> >> > directly related to exchanging the CAR information. > >> >> > > >> >> [eunsoo] The routing protocol (for the wired Internet) > >has a similar > >> >> problem. They want to know whether a router is authorized to > >> >participate in > >> >> the route discovery. So for intra-domain routing protocols, > >> >usually shared > >> >> secret is proposed. Also Dycard assumes it in the expression > >> >that there > >> >> should be a security association between ARs. If we consider only > >> >> intra-domain communication between ARs, shared secret would > >> >be sufficient > >> >> for authorization and message authentication. If you > >> >consider central NMS > >> >> system that allows remote configuration of ARs, it would be > >> >very easy to > >> >> configure the shared secret among ARs. If there is no such > >> >thing, people do > >> >> the configuration by remotely logging into ARs. This one > >> >time configuration > >> >> removes concerns about scalability and reliability. You > >> >don't need a server > >> >> running up 24/7 for this authorization since you don't > >> >expect a new AR that > >> >> often. > >> >> > >> >> Eunsoo > >> >> > >> >> _______________________________________________ > >> >> Seamoby mailing list > >> >> Seamoby@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/seamoby > >> >> > >> >> > >> > > >> >_______________________________________________ > >> >Seamoby mailing list > >> >Seamoby@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/seamoby > >> > > >> > >> > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 12:46:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10265 for ; Thu, 13 Mar 2003 12:46:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DI0TO15772; Thu, 13 Mar 2003 13:00:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DHxTO15705 for ; Thu, 13 Mar 2003 12:59:29 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10200 for ; Thu, 13 Mar 2003 12:44:25 -0500 (EST) Message-ID: <013201c2e988$46bada70$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 09:45:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dirk, The issue isn't whether there are easy solutions, the issue is that a solution MUST be specified. If the solutions are easy, then specifying them should be as well, no? jak ----- Original Message ----- From: To: ; ; ; Sent: Thursday, March 13, 2003 6:44 AM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > Hi James, > > thanks for giving me the merits for discovering this "security hole", but you greatly misinterpret my intentions. > Local AP-AR authentication is a problem concerned with security, and this will remain the only common point > in our both thinking. > > Beyond this, I do not believe that this is within the scope of CAR discovery. There exist easy solutions to solve this > problem (as pointed out by other emails), and both discussed solutions (dycard and DT draft) assume the existence of these > mechanisms. > > I start wondering what you want to achieve by recalling requirements (and consequently issues) draft from the IESG. This > call comes a bit too early and too quickly for me so that I'm wondering whether you actually have the progress of the CAR > work in mind when you propose something like this. > > Thanks, > > Dirk > > >-----Original Message----- > >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > >Sent: Wednesday, March 12, 2003 5:52 PM > >To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); > >eunsoo@nec-labs.com; seamoby@ietf.org > >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > >Dirk, > > > >You're right. This is a significant gap in our requirements. > > > >We will have to recall them from the IESG and include it. It > >is an unacceptable > >security hole for there to be no requirement that APs be > >authorized. I'm > >suprised Steve Bellovin didn't find this. > > > >Thanx for pointing out this serious hole. > > > > jak > > > >----- Original Message ----- > >From: > >To: ; ; > >; > >Sent: Wednesday, March 12, 2003 1:07 PM > >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > >> Hi James, > >> > >> I'm surprised to suddenly see AP authentication in the scope > >of CAR discovery. > >Where does this change of > >> scope come from? If a network operator requires AP > >authentication for each AR, > >network management > >> tools can be used to download the list of APs to the AR. I > >don't see anything > >in the issue draft putting > >> this on the table of CAR discovery (we would have called it > >CAR and local AP > >discovery then). > >> > >> So if you want to address this, let's define MIB entries and > >push mechanisms > >to download said AP entries to > >> the AR MIB, and we're done. > >> > >> Dirk > >> > >> >-----Original Message----- > >> >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > >> >Sent: Wednesday, March 12, 2003 3:58 PM > >> >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; > >seamoby@ietf.org > >> >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > >> > > >> > > >> >No disconnect. > >> > > >> >My point was, this is a deficiency with both drafts. It is an > >> >issue we need to > >> >resolve before we can consider the design complete. > >> > > >> > jak > >> > > >> >----- Original Message ----- > >> >From: > >> >To: ; ; > >> > > >> >Sent: Wednesday, March 12, 2003 12:22 PM > >> >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > >> > > >> > > >> >> Hi: > >> >> > >> >> There seems to be some disconnect. The current DT draft does > >> >NOT intend solve > >> >the problem of enabling AR to determine which APs are > >> >authorized. APs are > >> >brought up/down and connected to/disconnected from AR. Some L2 > >> >layer mechanism > >> >between AR-AP enables AR to learn about new/removed AP. AR > >> >reports that AP is > >> >up/down to CARD server and CARD server stores the mapping. In > >> >other words, AR is > >> >in control of knowing what APs are attached to it and CARD > >> >server relies on > >> >information provided by AR regarding this. > >> >> > >> >> Hemant > >> >> > >> >> -----Original Message----- > >> >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] > >> >> Sent: Wednesday, March 12, 2003 4:48 PM > >> >> To: James Kempf; seamoby@ietf.org > >> >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > >> >> > >> >> > >> >> > >> >> > >> >> > The server will allow an AR to determine which APs are > >> >authorized. The > >> >> dycard > >> >> > draft has nothing about this. This is an important > >> >security measure, > >> >> though not > >> >> > directly related to exchanging the CAR information. > >> >> > > >> >> [eunsoo] The routing protocol (for the wired Internet) > >has a similar > >> >> problem. They want to know whether a router is authorized to > >> >participate in > >> >> the route discovery. So for intra-domain routing protocols, > >> >usually shared > >> >> secret is proposed. Also Dycard assumes it in the expression > >> >that there > >> >> should be a security association between ARs. If we consider only > >> >> intra-domain communication between ARs, shared secret would > >> >be sufficient > >> >> for authorization and message authentication. If you > >> >consider central NMS > >> >> system that allows remote configuration of ARs, it would be > >> >very easy to > >> >> configure the shared secret among ARs. If there is no such > >> >thing, people do > >> >> the configuration by remotely logging into ARs. This one > >> >time configuration > >> >> removes concerns about scalability and reliability. You > >> >don't need a server > >> >> running up 24/7 for this authorization since you don't > >> >expect a new AR that > >> >> often. > >> >> > >> >> Eunsoo > >> >> > >> >> _______________________________________________ > >> >> Seamoby mailing list > >> >> Seamoby@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/seamoby > >> >> > >> >> > >> > > >> >_______________________________________________ > >> >Seamoby mailing list > >> >Seamoby@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/seamoby > >> > > >> > >> > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 13:21:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11574 for ; Thu, 13 Mar 2003 13:21:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DIaNu18391 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 13:36:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIaMO18388 for ; Thu, 13 Mar 2003 13:36:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11532 for ; Thu, 13 Mar 2003 13:21:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIa7O18374; Thu, 13 Mar 2003 13:36:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIZUO18334 for ; Thu, 13 Mar 2003 13:35:30 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11485 for ; Thu, 13 Mar 2003 13:20:16 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DIM4802487 for ; Thu, 13 Mar 2003 12:22:14 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 12:21:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 10:21:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 13:21:38 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLpiIywoGuTLfNYQZGvlsk1UVGxdQABCzTg To: , , , X-OriginalArrivalTime: 13 Mar 2003 18:21:39.0593 (UTC) FILETIME=[63ECF790:01C2E98D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DIZVO18335 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, my point is not about easy or not. It is whether AP authentication is something that is in scope of CAR or not. Whether or not APs are authenticated towards their router is not a particular problem of CAR, hence I argue for "out of scope". If you want to address the problem, bring it up, define the scope of the problem, and the applicability of a solution and go ahead. In the meanwhile, we can continue with the current work of CAR since both CAR solutions assume the existence of a solution for AP authentication. Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Thursday, March 13, 2003 12:45 PM >To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); >eunsoo@nec-labs.com; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >Dirk, > >The issue isn't whether there are easy solutions, the issue is >that a solution >MUST be specified. If the solutions are easy, then specifying >them should be as >well, no? > > jak > >----- Original Message ----- >From: >To: ; ; >; >Sent: Thursday, March 13, 2003 6:44 AM >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > >> Hi James, >> >> thanks for giving me the merits for discovering this >"security hole", but you >greatly misinterpret my intentions. >> Local AP-AR authentication is a problem concerned with >security, and this will >remain the only common point >> in our both thinking. >> >> Beyond this, I do not believe that this is within the scope >of CAR discovery. >There exist easy solutions to solve this >> problem (as pointed out by other emails), and both discussed >solutions (dycard >and DT draft) assume the existence of these >> mechanisms. >> >> I start wondering what you want to achieve by recalling >requirements (and >consequently issues) draft from the IESG. This >> call comes a bit too early and too quickly for me so that >I'm wondering >whether you actually have the progress of the CAR >> work in mind when you propose something like this. >> >> Thanks, >> >> Dirk >> >> >-----Original Message----- >> >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >> >Sent: Wednesday, March 12, 2003 5:52 PM >> >To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); >> >eunsoo@nec-labs.com; seamoby@ietf.org >> >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> > >> > >> >Dirk, >> > >> >You're right. This is a significant gap in our requirements. >> > >> >We will have to recall them from the IESG and include it. It >> >is an unacceptable >> >security hole for there to be no requirement that APs be >> >authorized. I'm >> >suprised Steve Bellovin didn't find this. >> > >> >Thanx for pointing out this serious hole. >> > >> > jak >> > >> >----- Original Message ----- >> >From: >> >To: ; ; >> >; >> >Sent: Wednesday, March 12, 2003 1:07 PM >> >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD >> > >> > >> >> Hi James, >> >> >> >> I'm surprised to suddenly see AP authentication in the scope >> >of CAR discovery. >> >Where does this change of >> >> scope come from? If a network operator requires AP >> >authentication for each AR, >> >network management >> >> tools can be used to download the list of APs to the AR. I >> >don't see anything >> >in the issue draft putting >> >> this on the table of CAR discovery (we would have called it >> >CAR and local AP >> >discovery then). >> >> >> >> So if you want to address this, let's define MIB entries and >> >push mechanisms >> >to download said AP entries to >> >> the AR MIB, and we're done. >> >> >> >> Dirk >> >> >> >> >-----Original Message----- >> >> >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >> >> >Sent: Wednesday, March 12, 2003 3:58 PM >> >> >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; >> >seamoby@ietf.org >> >> >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> >> > >> >> > >> >> >No disconnect. >> >> > >> >> >My point was, this is a deficiency with both drafts. It is an >> >> >issue we need to >> >> >resolve before we can consider the design complete. >> >> > >> >> > jak >> >> > >> >> >----- Original Message ----- >> >> >From: >> >> >To: ; ; >> >> > >> >> >Sent: Wednesday, March 12, 2003 12:22 PM >> >> >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD >> >> > >> >> > >> >> >> Hi: >> >> >> >> >> >> There seems to be some disconnect. The current DT draft does >> >> >NOT intend solve >> >> >the problem of enabling AR to determine which APs are >> >> >authorized. APs are >> >> >brought up/down and connected to/disconnected from AR. Some L2 >> >> >layer mechanism >> >> >between AR-AP enables AR to learn about new/removed AP. AR >> >> >reports that AP is >> >> >up/down to CARD server and CARD server stores the mapping. In >> >> >other words, AR is >> >> >in control of knowing what APs are attached to it and CARD >> >> >server relies on >> >> >information provided by AR regarding this. >> >> >> >> >> >> Hemant >> >> >> >> >> >> -----Original Message----- >> >> >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] >> >> >> Sent: Wednesday, March 12, 2003 4:48 PM >> >> >> To: James Kempf; seamoby@ietf.org >> >> >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > The server will allow an AR to determine which APs are >> >> >authorized. The >> >> >> dycard >> >> >> > draft has nothing about this. This is an important >> >> >security measure, >> >> >> though not >> >> >> > directly related to exchanging the CAR information. >> >> >> > >> >> >> [eunsoo] The routing protocol (for the wired Internet) >> >has a similar >> >> >> problem. They want to know whether a router is authorized to >> >> >participate in >> >> >> the route discovery. So for intra-domain routing protocols, >> >> >usually shared >> >> >> secret is proposed. Also Dycard assumes it in the expression >> >> >that there >> >> >> should be a security association between ARs. If we >consider only >> >> >> intra-domain communication between ARs, shared secret would >> >> >be sufficient >> >> >> for authorization and message authentication. If you >> >> >consider central NMS >> >> >> system that allows remote configuration of ARs, it would be >> >> >very easy to >> >> >> configure the shared secret among ARs. If there is no such >> >> >thing, people do >> >> >> the configuration by remotely logging into ARs. This one >> >> >time configuration >> >> >> removes concerns about scalability and reliability. You >> >> >don't need a server >> >> >> running up 24/7 for this authorization since you don't >> >> >expect a new AR that >> >> >> often. >> >> >> >> >> >> Eunsoo >> >> >> >> >> >> _______________________________________________ >> >> >> Seamoby mailing list >> >> >> Seamoby@ietf.org >> >> >> https://www1.ietf.org/mailman/listinfo/seamoby >> >> >> >> >> >> >> >> > >> >> >_______________________________________________ >> >> >Seamoby mailing list >> >> >Seamoby@ietf.org >> >> >https://www1.ietf.org/mailman/listinfo/seamoby >> >> > >> >> >> >> >> > >> > >> >> > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 13:22:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11599 for ; Thu, 13 Mar 2003 13:22:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIa7O18374; Thu, 13 Mar 2003 13:36:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIZUO18334 for ; Thu, 13 Mar 2003 13:35:30 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11485 for ; Thu, 13 Mar 2003 13:20:16 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DIM4802487 for ; Thu, 13 Mar 2003 12:22:14 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 12:21:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 10:21:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 13:21:38 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #2:Do we need a server for CARD Thread-Index: AcLpiIywoGuTLfNYQZGvlsk1UVGxdQABCzTg To: , , , X-OriginalArrivalTime: 13 Mar 2003 18:21:39.0593 (UTC) FILETIME=[63ECF790:01C2E98D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DIZVO18335 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, my point is not about easy or not. It is whether AP authentication is something that is in scope of CAR or not. Whether or not APs are authenticated towards their router is not a particular problem of CAR, hence I argue for "out of scope". If you want to address the problem, bring it up, define the scope of the problem, and the applicability of a solution and go ahead. In the meanwhile, we can continue with the current work of CAR since both CAR solutions assume the existence of a solution for AP authentication. Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Thursday, March 13, 2003 12:45 PM >To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); >eunsoo@nec-labs.com; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > >Dirk, > >The issue isn't whether there are easy solutions, the issue is >that a solution >MUST be specified. If the solutions are easy, then specifying >them should be as >well, no? > > jak > >----- Original Message ----- >From: >To: ; ; >; >Sent: Thursday, March 13, 2003 6:44 AM >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > >> Hi James, >> >> thanks for giving me the merits for discovering this >"security hole", but you >greatly misinterpret my intentions. >> Local AP-AR authentication is a problem concerned with >security, and this will >remain the only common point >> in our both thinking. >> >> Beyond this, I do not believe that this is within the scope >of CAR discovery. >There exist easy solutions to solve this >> problem (as pointed out by other emails), and both discussed >solutions (dycard >and DT draft) assume the existence of these >> mechanisms. >> >> I start wondering what you want to achieve by recalling >requirements (and >consequently issues) draft from the IESG. This >> call comes a bit too early and too quickly for me so that >I'm wondering >whether you actually have the progress of the CAR >> work in mind when you propose something like this. >> >> Thanks, >> >> Dirk >> >> >-----Original Message----- >> >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >> >Sent: Wednesday, March 12, 2003 5:52 PM >> >To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); >> >eunsoo@nec-labs.com; seamoby@ietf.org >> >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> > >> > >> >Dirk, >> > >> >You're right. This is a significant gap in our requirements. >> > >> >We will have to recall them from the IESG and include it. It >> >is an unacceptable >> >security hole for there to be no requirement that APs be >> >authorized. I'm >> >suprised Steve Bellovin didn't find this. >> > >> >Thanx for pointing out this serious hole. >> > >> > jak >> > >> >----- Original Message ----- >> >From: >> >To: ; ; >> >; >> >Sent: Wednesday, March 12, 2003 1:07 PM >> >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD >> > >> > >> >> Hi James, >> >> >> >> I'm surprised to suddenly see AP authentication in the scope >> >of CAR discovery. >> >Where does this change of >> >> scope come from? If a network operator requires AP >> >authentication for each AR, >> >network management >> >> tools can be used to download the list of APs to the AR. I >> >don't see anything >> >in the issue draft putting >> >> this on the table of CAR discovery (we would have called it >> >CAR and local AP >> >discovery then). >> >> >> >> So if you want to address this, let's define MIB entries and >> >push mechanisms >> >to download said AP entries to >> >> the AR MIB, and we're done. >> >> >> >> Dirk >> >> >> >> >-----Original Message----- >> >> >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >> >> >Sent: Wednesday, March 12, 2003 3:58 PM >> >> >To: Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; >> >seamoby@ietf.org >> >> >Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> >> > >> >> > >> >> >No disconnect. >> >> > >> >> >My point was, this is a deficiency with both drafts. It is an >> >> >issue we need to >> >> >resolve before we can consider the design complete. >> >> > >> >> > jak >> >> > >> >> >----- Original Message ----- >> >> >From: >> >> >To: ; ; >> >> > >> >> >Sent: Wednesday, March 12, 2003 12:22 PM >> >> >Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD >> >> > >> >> > >> >> >> Hi: >> >> >> >> >> >> There seems to be some disconnect. The current DT draft does >> >> >NOT intend solve >> >> >the problem of enabling AR to determine which APs are >> >> >authorized. APs are >> >> >brought up/down and connected to/disconnected from AR. Some L2 >> >> >layer mechanism >> >> >between AR-AP enables AR to learn about new/removed AP. AR >> >> >reports that AP is >> >> >up/down to CARD server and CARD server stores the mapping. In >> >> >other words, AR is >> >> >in control of knowing what APs are attached to it and CARD >> >> >server relies on >> >> >information provided by AR regarding this. >> >> >> >> >> >> Hemant >> >> >> >> >> >> -----Original Message----- >> >> >> From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] >> >> >> Sent: Wednesday, March 12, 2003 4:48 PM >> >> >> To: James Kempf; seamoby@ietf.org >> >> >> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > The server will allow an AR to determine which APs are >> >> >authorized. The >> >> >> dycard >> >> >> > draft has nothing about this. This is an important >> >> >security measure, >> >> >> though not >> >> >> > directly related to exchanging the CAR information. >> >> >> > >> >> >> [eunsoo] The routing protocol (for the wired Internet) >> >has a similar >> >> >> problem. They want to know whether a router is authorized to >> >> >participate in >> >> >> the route discovery. So for intra-domain routing protocols, >> >> >usually shared >> >> >> secret is proposed. Also Dycard assumes it in the expression >> >> >that there >> >> >> should be a security association between ARs. If we >consider only >> >> >> intra-domain communication between ARs, shared secret would >> >> >be sufficient >> >> >> for authorization and message authentication. If you >> >> >consider central NMS >> >> >> system that allows remote configuration of ARs, it would be >> >> >very easy to >> >> >> configure the shared secret among ARs. If there is no such >> >> >thing, people do >> >> >> the configuration by remotely logging into ARs. This one >> >> >time configuration >> >> >> removes concerns about scalability and reliability. You >> >> >don't need a server >> >> >> running up 24/7 for this authorization since you don't >> >> >expect a new AR that >> >> >> often. >> >> >> >> >> >> Eunsoo >> >> >> >> >> >> _______________________________________________ >> >> >> Seamoby mailing list >> >> >> Seamoby@ietf.org >> >> >> https://www1.ietf.org/mailman/listinfo/seamoby >> >> >> >> >> >> >> >> > >> >> >_______________________________________________ >> >> >Seamoby mailing list >> >> >Seamoby@ietf.org >> >> >https://www1.ietf.org/mailman/listinfo/seamoby >> >> > >> >> >> >> >> > >> > >> >> > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 16:49:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20699 for ; Thu, 13 Mar 2003 16:49:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DM3c103105 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 17:03:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DM3cO03102 for ; Thu, 13 Mar 2003 17:03:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20658 for ; Thu, 13 Mar 2003 16:48:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DM3PO03064; Thu, 13 Mar 2003 17:03:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DM1UO02745 for ; Thu, 13 Mar 2003 17:01:30 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20470 for ; Thu, 13 Mar 2003 16:46:21 -0500 (EST) Message-ID: <028001c2e9aa$135c1870$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <00e401c2e8db$7687d350$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 13:46:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cache contamination is only an issue if it results in an MN getting a wrong mapping, where a wrong mapping means that the MN presents the AR with an AP address for an AP that it is hearing, and it gets back an presumptive AR address that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a legitimate MN always presents an AP address that it is hearing, then the AP is a GAAP (Geographically Adjacent AP). If the source of the mapping information (either interrouter ala dycard or backend database ala DT draft) always returns a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a router that is not a GAAR or a valid AR. The issue of nonGAAR mappings consuming cache space can be handled by aging out cache entries. If the probability that a cache entry is dropped depends on the number of MNs that report the AP, then attacks will be quickly flushed. For example, suppose that the probability that a cache entry gets dropped at time T is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then if a single MN mounts an attack, its bogus cache entry is flushed every time. Thus, the cache need only be sized slightly large than the expected number of GAAP to GAAR entries. In short, a properly specified cache timeout algorithm, together with an authoritative source of AP to AR mappings should handle it. jak ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Wednesday, March 12, 2003 1:08 PM Subject: [SeaMoby] Topic #3: Cache contamination > Hi, > > Since we don't have much time until the IETF meeting next week, I think it > would be better to check important points in the mailing list before > off-line discussion for a short time during the meeting. > As always pointed out, security is a big concern. > It was pointed out there was no way to prevent cache contamination in the > server approach. Scope-ID was claimed as a solution but it was not really > explained in my understanding. > I look forward to an explanation of how cache contamination can be prevented > in the server approach. > Regards, > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 16:52:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20857 for ; Thu, 13 Mar 2003 16:52:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DM3PO03064; Thu, 13 Mar 2003 17:03:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DM1UO02745 for ; Thu, 13 Mar 2003 17:01:30 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20470 for ; Thu, 13 Mar 2003 16:46:21 -0500 (EST) Message-ID: <028001c2e9aa$135c1870$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <00e401c2e8db$7687d350$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 13:46:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cache contamination is only an issue if it results in an MN getting a wrong mapping, where a wrong mapping means that the MN presents the AR with an AP address for an AP that it is hearing, and it gets back an presumptive AR address that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a legitimate MN always presents an AP address that it is hearing, then the AP is a GAAP (Geographically Adjacent AP). If the source of the mapping information (either interrouter ala dycard or backend database ala DT draft) always returns a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a router that is not a GAAR or a valid AR. The issue of nonGAAR mappings consuming cache space can be handled by aging out cache entries. If the probability that a cache entry is dropped depends on the number of MNs that report the AP, then attacks will be quickly flushed. For example, suppose that the probability that a cache entry gets dropped at time T is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then if a single MN mounts an attack, its bogus cache entry is flushed every time. Thus, the cache need only be sized slightly large than the expected number of GAAP to GAAR entries. In short, a properly specified cache timeout algorithm, together with an authoritative source of AP to AR mappings should handle it. jak ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Wednesday, March 12, 2003 1:08 PM Subject: [SeaMoby] Topic #3: Cache contamination > Hi, > > Since we don't have much time until the IETF meeting next week, I think it > would be better to check important points in the mailing list before > off-line discussion for a short time during the meeting. > As always pointed out, security is a big concern. > It was pointed out there was no way to prevent cache contamination in the > server approach. Scope-ID was claimed as a solution but it was not really > explained in my understanding. > I look forward to an explanation of how cache contamination can be prevented > in the server approach. > Regards, > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 16:59:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21104 for ; Thu, 13 Mar 2003 16:59:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DMEIN04407 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 17:14:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMEIO04404 for ; Thu, 13 Mar 2003 17:14:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21089 for ; Thu, 13 Mar 2003 16:59:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DME8O04391; Thu, 13 Mar 2003 17:14:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMDKO04346 for ; Thu, 13 Mar 2003 17:13:20 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21075 for ; Thu, 13 Mar 2003 16:58:11 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DM0Na28343 for ; Thu, 13 Mar 2003 16:00:23 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 16:00:10 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 15:59:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 16:59:45 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLpquh7W4jRiyW0R42V0bqI8ViaOQAALrsg To: , , X-OriginalArrivalTime: 13 Mar 2003 21:59:46.0600 (UTC) FILETIME=[DC63C280:01C2E9AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DMDKO04347 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Bogus entries in cache also means that AR indulges in inter-AR capability and update exchange with bogus ARs, and hence, it has bearing on router processing overhead. I do not know if this matters a lot as there are no numbers available on frequency and size of those capability updates. - Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, March 13, 2003 4:47 PM To: Eunsoo Shim; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Cache contamination is only an issue if it results in an MN getting a wrong mapping, where a wrong mapping means that the MN presents the AR with an AP address for an AP that it is hearing, and it gets back an presumptive AR address that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a legitimate MN always presents an AP address that it is hearing, then the AP is a GAAP (Geographically Adjacent AP). If the source of the mapping information (either interrouter ala dycard or backend database ala DT draft) always returns a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a router that is not a GAAR or a valid AR. The issue of nonGAAR mappings consuming cache space can be handled by aging out cache entries. If the probability that a cache entry is dropped depends on the number of MNs that report the AP, then attacks will be quickly flushed. For example, suppose that the probability that a cache entry gets dropped at time T is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then if a single MN mounts an attack, its bogus cache entry is flushed every time. Thus, the cache need only be sized slightly large than the expected number of GAAP to GAAR entries. In short, a properly specified cache timeout algorithm, together with an authoritative source of AP to AR mappings should handle it. jak ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Wednesday, March 12, 2003 1:08 PM Subject: [SeaMoby] Topic #3: Cache contamination > Hi, > > Since we don't have much time until the IETF meeting next week, I think it > would be better to check important points in the mailing list before > off-line discussion for a short time during the meeting. > As always pointed out, security is a big concern. > It was pointed out there was no way to prevent cache contamination in the > server approach. Scope-ID was claimed as a solution but it was not really > explained in my understanding. > I look forward to an explanation of how cache contamination can be prevented > in the server approach. > Regards, > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 16:59:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21119 for ; Thu, 13 Mar 2003 16:59:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DME8O04391; Thu, 13 Mar 2003 17:14:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMDKO04346 for ; Thu, 13 Mar 2003 17:13:20 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21075 for ; Thu, 13 Mar 2003 16:58:11 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DM0Na28343 for ; Thu, 13 Mar 2003 16:00:23 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 16:00:10 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 15:59:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 16:59:45 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLpquh7W4jRiyW0R42V0bqI8ViaOQAALrsg To: , , X-OriginalArrivalTime: 13 Mar 2003 21:59:46.0600 (UTC) FILETIME=[DC63C280:01C2E9AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DMDKO04347 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Bogus entries in cache also means that AR indulges in inter-AR capability and update exchange with bogus ARs, and hence, it has bearing on router processing overhead. I do not know if this matters a lot as there are no numbers available on frequency and size of those capability updates. - Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, March 13, 2003 4:47 PM To: Eunsoo Shim; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Cache contamination is only an issue if it results in an MN getting a wrong mapping, where a wrong mapping means that the MN presents the AR with an AP address for an AP that it is hearing, and it gets back an presumptive AR address that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a legitimate MN always presents an AP address that it is hearing, then the AP is a GAAP (Geographically Adjacent AP). If the source of the mapping information (either interrouter ala dycard or backend database ala DT draft) always returns a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a router that is not a GAAR or a valid AR. The issue of nonGAAR mappings consuming cache space can be handled by aging out cache entries. If the probability that a cache entry is dropped depends on the number of MNs that report the AP, then attacks will be quickly flushed. For example, suppose that the probability that a cache entry gets dropped at time T is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then if a single MN mounts an attack, its bogus cache entry is flushed every time. Thus, the cache need only be sized slightly large than the expected number of GAAP to GAAR entries. In short, a properly specified cache timeout algorithm, together with an authoritative source of AP to AR mappings should handle it. jak ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Wednesday, March 12, 2003 1:08 PM Subject: [SeaMoby] Topic #3: Cache contamination > Hi, > > Since we don't have much time until the IETF meeting next week, I think it > would be better to check important points in the mailing list before > off-line discussion for a short time during the meeting. > As always pointed out, security is a big concern. > It was pointed out there was no way to prevent cache contamination in the > server approach. Scope-ID was claimed as a solution but it was not really > explained in my understanding. > I look forward to an explanation of how cache contamination can be prevented > in the server approach. > Regards, > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 17:43:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22366 for ; Thu, 13 Mar 2003 17:43:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DMwMX06918 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 17:58:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMwMO06915 for ; Thu, 13 Mar 2003 17:58:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22346 for ; Thu, 13 Mar 2003 17:43:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMwAO06903; Thu, 13 Mar 2003 17:58:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMvZO06876 for ; Thu, 13 Mar 2003 17:57:35 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22336 for ; Thu, 13 Mar 2003 17:42:26 -0500 (EST) Message-ID: <02cc01c2e9b1$e7e28320$286015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 13 Mar 2003 14:43:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD Issues List Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've made up a list of issues on CARD. It is available at: http://www.geocities.com/kempf42/CARD_Issues_List.htm The issues are divided into Requirements, Architecture, Protocol Design, and Editorial (about the Protocol document). Each issue has a number, a short description, and a hyperlink to a longer description and any proposals or resolutions (very few issues are resolved). Issues can be in the state of: Open: the issue is identified and there are either no or multiple proposed solutions. Proposal: there is a single proposal, discussion is underway, but there seems to be concensus around the proposal Resolved: the WG has agreed to a resolution (or, in the case of editorial issues, the resolution is trivial). I've tried to represent the various proposals fairly, if I've missed anything or got it wrong, please send me email and let me know. Also, if there are any additional issues that people have, please send email to the list clearly identifying the issue and any proposed resolution. Also, please continue discussion on the existing issues, we are far from resolving them. However, I'd also like to hear from people on the list who don't have an intellectual investment in one of the existing proposals (dycard or DT). The conversation last few days has been too much like a rugby match, and playing referee has been too time consuming. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 17:43:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22395 for ; Thu, 13 Mar 2003 17:43:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMwAO06903; Thu, 13 Mar 2003 17:58:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMvZO06876 for ; Thu, 13 Mar 2003 17:57:35 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22336 for ; Thu, 13 Mar 2003 17:42:26 -0500 (EST) Message-ID: <02cc01c2e9b1$e7e28320$286015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 13 Mar 2003 14:43:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD Issues List Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I've made up a list of issues on CARD. It is available at: http://www.geocities.com/kempf42/CARD_Issues_List.htm The issues are divided into Requirements, Architecture, Protocol Design, and Editorial (about the Protocol document). Each issue has a number, a short description, and a hyperlink to a longer description and any proposals or resolutions (very few issues are resolved). Issues can be in the state of: Open: the issue is identified and there are either no or multiple proposed solutions. Proposal: there is a single proposal, discussion is underway, but there seems to be concensus around the proposal Resolved: the WG has agreed to a resolution (or, in the case of editorial issues, the resolution is trivial). I've tried to represent the various proposals fairly, if I've missed anything or got it wrong, please send me email and let me know. Also, if there are any additional issues that people have, please send email to the list clearly identifying the issue and any proposed resolution. Also, please continue discussion on the existing issues, we are far from resolving them. However, I'd also like to hear from people on the list who don't have an intellectual investment in one of the existing proposals (dycard or DT). The conversation last few days has been too much like a rugby match, and playing referee has been too time consuming. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 18:00:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22890 for ; Thu, 13 Mar 2003 18:00:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DNFWh08436 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 18:15:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNFWO08433 for ; Thu, 13 Mar 2003 18:15:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22870 for ; Thu, 13 Mar 2003 18:00:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNFFO08413; Thu, 13 Mar 2003 18:15:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNEIO08375 for ; Thu, 13 Mar 2003 18:14:18 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22805 for ; Thu, 13 Mar 2003 17:59:09 -0500 (EST) Message-ID: <02fd01c2e9b4$3de7ed30$286015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 14:58:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Bogus entries in cache also means that AR indulges in inter-AR capability and update exchange with bogus ARs, and hence, it has bearing on router processing overhead. I do not know if this matters a lot as there are no numbers available on frequency and size of those capability updates. I'm not sure I understand the attack. If an attacker sends a completely bogus AP, the AR compares against the AAPL (Authorized AP List) and rejects. If an attacker sends an AP that is not bogus but is not a GAAP, then it will pass the AAPL test but it will remain in the cache for one iteration and be flushed aftewards. So, I don't see how interrouter capability and update exchange are affected. jak > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 13, 2003 4:47 PM > To: Eunsoo Shim; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > Cache contamination is only an issue if it results in an MN getting a wrong > mapping, where a wrong mapping means that the MN presents the AR with an AP > address for an AP that it is hearing, and it gets back an presumptive AR address > that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a > legitimate MN always presents an AP address that it is hearing, then the AP is a > GAAP (Geographically Adjacent AP). If the source of the mapping information > (either interrouter ala dycard or backend database ala DT draft) always returns > a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a > router that is not a GAAR or a valid AR. > > > > The issue of nonGAAR mappings consuming cache space can be handled by aging out > cache entries. If the probability that a cache entry is dropped depends on the > number of MNs that report the AP, then attacks will be quickly flushed. For > example, suppose that the probability that a cache entry gets dropped at time T > is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then > if a single MN mounts an attack, its bogus cache entry is flushed every time. > Thus, the cache need only be sized slightly large than the expected number of > GAAP to GAAR entries. > > > > In short, a properly specified cache timeout algorithm, together with an > authoritative source of AP to AR mappings should handle it. > > > > jak > > > > > > ----- Original Message ----- > From: "Eunsoo Shim" > To: > Sent: Wednesday, March 12, 2003 1:08 PM > Subject: [SeaMoby] Topic #3: Cache contamination > > > > Hi, > > > > Since we don't have much time until the IETF meeting next week, I think it > > would be better to check important points in the mailing list before > > off-line discussion for a short time during the meeting. > > As always pointed out, security is a big concern. > > It was pointed out there was no way to prevent cache contamination in the > > server approach. Scope-ID was claimed as a solution but it was not really > > explained in my understanding. > > I look forward to an explanation of how cache contamination can be prevented > > in the server approach. > > Regards, > > > > Eunsoo > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 18:01:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22913 for ; Thu, 13 Mar 2003 18:01:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNFFO08413; Thu, 13 Mar 2003 18:15:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNEIO08375 for ; Thu, 13 Mar 2003 18:14:18 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22805 for ; Thu, 13 Mar 2003 17:59:09 -0500 (EST) Message-ID: <02fd01c2e9b4$3de7ed30$286015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 14:58:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Bogus entries in cache also means that AR indulges in inter-AR capability and update exchange with bogus ARs, and hence, it has bearing on router processing overhead. I do not know if this matters a lot as there are no numbers available on frequency and size of those capability updates. I'm not sure I understand the attack. If an attacker sends a completely bogus AP, the AR compares against the AAPL (Authorized AP List) and rejects. If an attacker sends an AP that is not bogus but is not a GAAP, then it will pass the AAPL test but it will remain in the cache for one iteration and be flushed aftewards. So, I don't see how interrouter capability and update exchange are affected. jak > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 13, 2003 4:47 PM > To: Eunsoo Shim; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > Cache contamination is only an issue if it results in an MN getting a wrong > mapping, where a wrong mapping means that the MN presents the AR with an AP > address for an AP that it is hearing, and it gets back an presumptive AR address > that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a > legitimate MN always presents an AP address that it is hearing, then the AP is a > GAAP (Geographically Adjacent AP). If the source of the mapping information > (either interrouter ala dycard or backend database ala DT draft) always returns > a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a > router that is not a GAAR or a valid AR. > > > > The issue of nonGAAR mappings consuming cache space can be handled by aging out > cache entries. If the probability that a cache entry is dropped depends on the > number of MNs that report the AP, then attacks will be quickly flushed. For > example, suppose that the probability that a cache entry gets dropped at time T > is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then > if a single MN mounts an attack, its bogus cache entry is flushed every time. > Thus, the cache need only be sized slightly large than the expected number of > GAAP to GAAR entries. > > > > In short, a properly specified cache timeout algorithm, together with an > authoritative source of AP to AR mappings should handle it. > > > > jak > > > > > > ----- Original Message ----- > From: "Eunsoo Shim" > To: > Sent: Wednesday, March 12, 2003 1:08 PM > Subject: [SeaMoby] Topic #3: Cache contamination > > > > Hi, > > > > Since we don't have much time until the IETF meeting next week, I think it > > would be better to check important points in the mailing list before > > off-line discussion for a short time during the meeting. > > As always pointed out, security is a big concern. > > It was pointed out there was no way to prevent cache contamination in the > > server approach. Scope-ID was claimed as a solution but it was not really > > explained in my understanding. > > I look forward to an explanation of how cache contamination can be prevented > > in the server approach. > > Regards, > > > > Eunsoo > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 18:43:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25509 for ; Thu, 13 Mar 2003 18:43:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DNwOR10733 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 18:58:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNwOO10730 for ; Thu, 13 Mar 2003 18:58:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25504 for ; Thu, 13 Mar 2003 18:43:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNwDO10720; Thu, 13 Mar 2003 18:58:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNvCO10682 for ; Thu, 13 Mar 2003 18:57:12 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25488 for ; Thu, 13 Mar 2003 18:41:52 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DNhd819876 for ; Thu, 13 Mar 2003 17:43:50 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 17:43:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 17:43:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 18:43:38 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLptKWRHoUpGzPKRpK34v4f6CI4cwAANuLw To: , , , X-OriginalArrivalTime: 13 Mar 2003 23:43:39.0461 (UTC) FILETIME=[5F76DF50:01C2E9BA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DNvDO10683 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > I'm not sure I understand the attack. > > If an attacker sends a completely bogus AP, the AR compares > against the AAPL > (Authorized AP List) and rejects. > If an attacker sends an AP that is not bogus but is not a > GAAP, then it will > pass the AAPL test but it will remain in the cache for one > iteration and be > flushed aftewards. [Govind] This is assuming a particular cache replacement policy and assumes the server approach. I think we should first settle whether the server is needed or not before coming to cache contamination and other cache related issues. However, if we are not going to do that, then we should propose how any scheme involving protecting the cache works in either of the proposed solutions. > > So, I don't see how interrouter capability and update > exchange are affected. [Govind] First thoughts about this cache replacement policy. I will think about this replacement policy more later.. Its been a long day already, so sorry if I'm wrong :) If the number of malicious MNs increase, then wouldn't you have an increase of the number of entries? Also, they might not be removed from the cache. More such entries and more the unnecessary capability messages. Note, if we are using the server scheme, each MN has the possibility of reporting a large number of such non-GAAPs. Consider this scenario, 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that each AP is assigned to a different AR. Further assume that you have a limit of 100 reports per MN. In your scheme, the chance of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of non GAARs are in the cache after each flush. So the current AR will communicate unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities exchanged you do have an unnecessary burden on the ARs. You will never be able to detect this and yet keep exchanging messages between non-CARs. Another point, by flipping a coin as you suggest based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you keep relying on the server, thus increasing the average response time. Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes to remove bad entries may be a better approach. I'm not saying that this is a bad cache replacement scheme yet but I'll think about this tomorrow. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 18:43:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25522 for ; Thu, 13 Mar 2003 18:43:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNwDO10720; Thu, 13 Mar 2003 18:58:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DNvCO10682 for ; Thu, 13 Mar 2003 18:57:12 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25488 for ; Thu, 13 Mar 2003 18:41:52 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DNhd819876 for ; Thu, 13 Mar 2003 17:43:50 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Mar 2003 17:43:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 17:43:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 18:43:38 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLptKWRHoUpGzPKRpK34v4f6CI4cwAANuLw To: , , , X-OriginalArrivalTime: 13 Mar 2003 23:43:39.0461 (UTC) FILETIME=[5F76DF50:01C2E9BA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DNvDO10683 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > I'm not sure I understand the attack. > > If an attacker sends a completely bogus AP, the AR compares > against the AAPL > (Authorized AP List) and rejects. > If an attacker sends an AP that is not bogus but is not a > GAAP, then it will > pass the AAPL test but it will remain in the cache for one > iteration and be > flushed aftewards. [Govind] This is assuming a particular cache replacement policy and assumes the server approach. I think we should first settle whether the server is needed or not before coming to cache contamination and other cache related issues. However, if we are not going to do that, then we should propose how any scheme involving protecting the cache works in either of the proposed solutions. > > So, I don't see how interrouter capability and update > exchange are affected. [Govind] First thoughts about this cache replacement policy. I will think about this replacement policy more later.. Its been a long day already, so sorry if I'm wrong :) If the number of malicious MNs increase, then wouldn't you have an increase of the number of entries? Also, they might not be removed from the cache. More such entries and more the unnecessary capability messages. Note, if we are using the server scheme, each MN has the possibility of reporting a large number of such non-GAAPs. Consider this scenario, 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that each AP is assigned to a different AR. Further assume that you have a limit of 100 reports per MN. In your scheme, the chance of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of non GAARs are in the cache after each flush. So the current AR will communicate unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities exchanged you do have an unnecessary burden on the ARs. You will never be able to detect this and yet keep exchanging messages between non-CARs. Another point, by flipping a coin as you suggest based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you keep relying on the server, thus increasing the average response time. Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes to remove bad entries may be a better approach. I'm not saying that this is a bad cache replacement scheme yet but I'll think about this tomorrow. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 20:47:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28780 for ; Thu, 13 Mar 2003 20:47:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E22a518980 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 21:02:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E22aO18977 for ; Thu, 13 Mar 2003 21:02:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28768 for ; Thu, 13 Mar 2003 20:47:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E22OO18953; Thu, 13 Mar 2003 21:02:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E21lO18937 for ; Thu, 13 Mar 2003 21:01:47 -0500 Received: from ns.sait.samsung.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28754 for ; Thu, 13 Mar 2003 20:46:33 -0500 (EST) Received: from icebright (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.8/8.12.1) with SMTP id h2E1m93X023483; Fri, 14 Mar 2003 10:48:15 +0900 (KST) From: "Xiaoming Wang" To: "Daichi Funato" , Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 10:48:15 +0900 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030312174925.3349.FUNATO@docomolabs-usa.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit please find the inline comment. > > Hemant -> I am trying to do some back of the envelope calculation > > here. There are two ARs and first handoff happens between them. > > Let us say cache lifetime is few hours. If another handoff occurs > > during those few hours, cache gets refreshed for another few hours. > > If no handoff occurs between those two ARs in few hours, why do > > we need to care of about seamlessness in the first place. > > I don't think this calculation is enough... > A server is necessary to save the initial handover failures. > Let me show you another caluculation. > > Suppose there is an AR, which has a hexagon shape coverage. > If we surround this AR with other AR hexagons, there will be > 7 ARs. In this case, the total adjacent edges, which equals to > the total CAR entries, are 12. This means we need 12 learning > reports from MNs with 12 handover failures in learning-based > approach. > > If we continue surrounding this, we can get the numbers by > simple calculations. > > #Surrounds, #ARs, #TotalEdges(CARs) > 1, 7, 12 > 2, 19, 42 > 3, 37, 90 > 4, 61, 156 > 5, 91, 240 > 6, 127, 342 > > According to this results, if an operator deploys 127 ARs, the > operator possibly receives 342 call-miss complaints from customers. > They might include important emergency call handover misses. > This is a nightmare to the operator. > No one knows one call is less important than the other calls. > Who can say this is not a big deal? > > If we take learning-based approach, we can't avoid this problem by nature. > The server-based approach can provide a way to greatly improve this. > Placing a server will save hundreds of handover failures in initial stage. > Also the server will be used to save handover failures every time a > CAR cache in an AR expires as well. It's not a trivial matter. > > Operators won't take a solution, which doesn't provide a way to > improve quality to customers. Moreover, operators won't take any way, > which sacrifices users to improve their network operation efficiency. > The burden should not be shared with customers. > [xiaoming] I think this can be improved by static configuration at the initial stage. Initial data can be computed with the geographical and topological information of access network, which is used during the network planning and construction stage. Based on it, learning-based approach will not experience failure at the initial stage and will learn by itself dynamically when there is a change of the topology of the access network, and thus performs well at any time. xiaoming _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 20:48:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28798 for ; Thu, 13 Mar 2003 20:48:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E22OO18953; Thu, 13 Mar 2003 21:02:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E21lO18937 for ; Thu, 13 Mar 2003 21:01:47 -0500 Received: from ns.sait.samsung.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28754 for ; Thu, 13 Mar 2003 20:46:33 -0500 (EST) Received: from icebright (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.8/8.12.1) with SMTP id h2E1m93X023483; Fri, 14 Mar 2003 10:48:15 +0900 (KST) From: "Xiaoming Wang" To: "Daichi Funato" , Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 10:48:15 +0900 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030312174925.3349.FUNATO@docomolabs-usa.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit please find the inline comment. > > Hemant -> I am trying to do some back of the envelope calculation > > here. There are two ARs and first handoff happens between them. > > Let us say cache lifetime is few hours. If another handoff occurs > > during those few hours, cache gets refreshed for another few hours. > > If no handoff occurs between those two ARs in few hours, why do > > we need to care of about seamlessness in the first place. > > I don't think this calculation is enough... > A server is necessary to save the initial handover failures. > Let me show you another caluculation. > > Suppose there is an AR, which has a hexagon shape coverage. > If we surround this AR with other AR hexagons, there will be > 7 ARs. In this case, the total adjacent edges, which equals to > the total CAR entries, are 12. This means we need 12 learning > reports from MNs with 12 handover failures in learning-based > approach. > > If we continue surrounding this, we can get the numbers by > simple calculations. > > #Surrounds, #ARs, #TotalEdges(CARs) > 1, 7, 12 > 2, 19, 42 > 3, 37, 90 > 4, 61, 156 > 5, 91, 240 > 6, 127, 342 > > According to this results, if an operator deploys 127 ARs, the > operator possibly receives 342 call-miss complaints from customers. > They might include important emergency call handover misses. > This is a nightmare to the operator. > No one knows one call is less important than the other calls. > Who can say this is not a big deal? > > If we take learning-based approach, we can't avoid this problem by nature. > The server-based approach can provide a way to greatly improve this. > Placing a server will save hundreds of handover failures in initial stage. > Also the server will be used to save handover failures every time a > CAR cache in an AR expires as well. It's not a trivial matter. > > Operators won't take a solution, which doesn't provide a way to > improve quality to customers. Moreover, operators won't take any way, > which sacrifices users to improve their network operation efficiency. > The burden should not be shared with customers. > [xiaoming] I think this can be improved by static configuration at the initial stage. Initial data can be computed with the geographical and topological information of access network, which is used during the network planning and construction stage. Based on it, learning-based approach will not experience failure at the initial stage and will learn by itself dynamically when there is a change of the topology of the access network, and thus performs well at any time. xiaoming _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 23:12:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02196 for ; Thu, 13 Mar 2003 23:12:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E4QtA28546 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 23:26:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4QtO28543 for ; Thu, 13 Mar 2003 23:26:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02173 for ; Thu, 13 Mar 2003 23:11:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4QUO28516; Thu, 13 Mar 2003 23:26:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4O7O28363 for ; Thu, 13 Mar 2003 23:24:07 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02111 for ; Thu, 13 Mar 2003 23:08:50 -0500 (EST) Message-ID: <002701c2e9df$822d4960$516015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 20:09:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > I'm not sure I understand the attack. > > > > If an attacker sends a completely bogus AP, the AR compares > > against the AAPL > > (Authorized AP List) and rejects. > > If an attacker sends an AP that is not bogus but is not a > > GAAP, then it will > > pass the AAPL test but it will remain in the cache for one > > iteration and be > > flushed aftewards. > [Govind] This is assuming a particular cache replacement policy and assumes > the server approach. I think we should first settle whether the server is needed > or not before coming to cache contamination and other cache related issues. > However, if we are not going to do that, then we should propose how any > scheme involving protecting the cache works in either of the proposed solutions. Why do you say it assumes the server approach? The AAPL could be programmed into the router through a Web page. It doesn't have to come from a server. Something like the AAPL will even be needed in Dycard, else how does a router know that an access point connected to it is authorized? > > > > So, I don't see how interrouter capability and update > > exchange are affected. > [Govind] First thoughts about this cache replacement policy. I will think about this replacement > policy more later.. Its been a long day already, so sorry if I'm wrong :) > > If the number of malicious MNs increase, then wouldn't you have an increase of the number > of entries? Right, the assumption here is that the probability of an attack decreases according to the number of MNs involved. Remember, for an MN to even get on the link, it must be auth/authz-ed. So, multiple MNs means a bunch of the operator's authorized customers decided to get together and attack. Maybe not such a completely outlandish idea these days, but a much lower probablity event than one lone customer who is having a bad day and decides to cause some mischief. >Also, they might not be removed from the cache. More such entries and more > the unnecessary capability messages. Note, if we are using the server scheme, each MN has > the possibility of reporting a large number of such non-GAAPs. Why do you assume the server scheme? The cache state would need to be timed out for Dycard as well. >Consider this scenario, > 10 malicious MNs each report say 100 genuine non-GAAPs. If I, as an operator, have 10 malicious customers, then I'm pretty bad off. After that attack, they get their service cancelled forthwith. >Also assume that > each AP is assigned to a different AR. >Further assume that > you have a limit of 100 reports per MN. In your scheme, the chance > of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of > non GAARs are in the cache after each flush. So the current AR will communicate > unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities > exchanged you do have an unnecessary burden on the ARs. You will never be able > to detect this and yet keep exchanging messages between non-CARs. > OK, so its a hundred. How big is a cache entry? Let's be conservative and say it's 1K (actually, it's probably a lot smaller). that's still only 100K. Given Moore's law, that costs nothing. The point is, it's not a million. The attack becomes less probable and easier to detect the more entries. It is all a matter of matching the threat. The highest probability threat, in this case, is a single MN having a bad day and deciding to try some mischief. Now if an average MN reports, say 2 or three APs and suddenly the router starts to get a report of 100, it knows something is amiss. If 10 MNs each start reporting 100, it's time to call the Department of Homeland Security. :-) > Another point, by flipping a coin as you suggest > based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability > of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you > keep relying on the server, thus increasing the average response time. > Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes > to remove bad entries may be a better approach. I'm not saying that this is a bad > cache replacement scheme yet but I'll think about this tomorrow. > Sure. There are always false positives. But typically any one GAAP will be seen by more than one MN. And, there are other ways to reduce the probability of flushing good entries, for example, using a weighed moving average of reports. That way, if the cell suddenly empties out after having been full, the cache entries will stick around for a while. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 23:12:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02209 for ; Thu, 13 Mar 2003 23:12:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4QUO28516; Thu, 13 Mar 2003 23:26:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4O7O28363 for ; Thu, 13 Mar 2003 23:24:07 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02111 for ; Thu, 13 Mar 2003 23:08:50 -0500 (EST) Message-ID: <002701c2e9df$822d4960$516015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Thu, 13 Mar 2003 20:09:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > I'm not sure I understand the attack. > > > > If an attacker sends a completely bogus AP, the AR compares > > against the AAPL > > (Authorized AP List) and rejects. > > If an attacker sends an AP that is not bogus but is not a > > GAAP, then it will > > pass the AAPL test but it will remain in the cache for one > > iteration and be > > flushed aftewards. > [Govind] This is assuming a particular cache replacement policy and assumes > the server approach. I think we should first settle whether the server is needed > or not before coming to cache contamination and other cache related issues. > However, if we are not going to do that, then we should propose how any > scheme involving protecting the cache works in either of the proposed solutions. Why do you say it assumes the server approach? The AAPL could be programmed into the router through a Web page. It doesn't have to come from a server. Something like the AAPL will even be needed in Dycard, else how does a router know that an access point connected to it is authorized? > > > > So, I don't see how interrouter capability and update > > exchange are affected. > [Govind] First thoughts about this cache replacement policy. I will think about this replacement > policy more later.. Its been a long day already, so sorry if I'm wrong :) > > If the number of malicious MNs increase, then wouldn't you have an increase of the number > of entries? Right, the assumption here is that the probability of an attack decreases according to the number of MNs involved. Remember, for an MN to even get on the link, it must be auth/authz-ed. So, multiple MNs means a bunch of the operator's authorized customers decided to get together and attack. Maybe not such a completely outlandish idea these days, but a much lower probablity event than one lone customer who is having a bad day and decides to cause some mischief. >Also, they might not be removed from the cache. More such entries and more > the unnecessary capability messages. Note, if we are using the server scheme, each MN has > the possibility of reporting a large number of such non-GAAPs. Why do you assume the server scheme? The cache state would need to be timed out for Dycard as well. >Consider this scenario, > 10 malicious MNs each report say 100 genuine non-GAAPs. If I, as an operator, have 10 malicious customers, then I'm pretty bad off. After that attack, they get their service cancelled forthwith. >Also assume that > each AP is assigned to a different AR. >Further assume that > you have a limit of 100 reports per MN. In your scheme, the chance > of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of > non GAARs are in the cache after each flush. So the current AR will communicate > unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities > exchanged you do have an unnecessary burden on the ARs. You will never be able > to detect this and yet keep exchanging messages between non-CARs. > OK, so its a hundred. How big is a cache entry? Let's be conservative and say it's 1K (actually, it's probably a lot smaller). that's still only 100K. Given Moore's law, that costs nothing. The point is, it's not a million. The attack becomes less probable and easier to detect the more entries. It is all a matter of matching the threat. The highest probability threat, in this case, is a single MN having a bad day and deciding to try some mischief. Now if an average MN reports, say 2 or three APs and suddenly the router starts to get a report of 100, it knows something is amiss. If 10 MNs each start reporting 100, it's time to call the Department of Homeland Security. :-) > Another point, by flipping a coin as you suggest > based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability > of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you > keep relying on the server, thus increasing the average response time. > Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes > to remove bad entries may be a better approach. I'm not saying that this is a bad > cache replacement scheme yet but I'll think about this tomorrow. > Sure. There are always false positives. But typically any one GAAP will be seen by more than one MN. And, there are other ways to reduce the probability of flushing good entries, for example, using a weighed moving average of reports. That way, if the cell suddenly empties out after having been full, the cache entries will stick around for a while. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 23:26:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02531 for ; Thu, 13 Mar 2003 23:26:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E4fIT29997 for seamoby-archive@odin.ietf.org; Thu, 13 Mar 2003 23:41:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4fIO29994 for ; Thu, 13 Mar 2003 23:41:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02526 for ; Thu, 13 Mar 2003 23:26:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4f6O29973; Thu, 13 Mar 2003 23:41:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4evO29959 for ; Thu, 13 Mar 2003 23:40:57 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02521 for ; Thu, 13 Mar 2003 23:25:40 -0500 (EST) Message-ID: <008201c2e9e1$dcacc9e0$516015ac@T23KEMPF> From: "James Kempf" To: "Xiaoming Wang" , "Daichi Funato" , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 20:26:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xiaoming, > [xiaoming] I think this can be improved by static configuration at the > initial stage. Initial data can be computed with the geographical and > topological information of access network, which is used during the network > planning and construction stage. Based on it, learning-based approach will > not experience failure at the initial stage and will learn by itself > dynamically when there is a change of the topology of the access network, > and thus performs well at any time. > Where does the router get the static information from? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 23:26:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02544 for ; Thu, 13 Mar 2003 23:26:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4f6O29973; Thu, 13 Mar 2003 23:41:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4evO29959 for ; Thu, 13 Mar 2003 23:40:57 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02521 for ; Thu, 13 Mar 2003 23:25:40 -0500 (EST) Message-ID: <008201c2e9e1$dcacc9e0$516015ac@T23KEMPF> From: "James Kempf" To: "Xiaoming Wang" , "Daichi Funato" , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Thu, 13 Mar 2003 20:26:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Xiaoming, > [xiaoming] I think this can be improved by static configuration at the > initial stage. Initial data can be computed with the geographical and > topological information of access network, which is used during the network > planning and construction stage. Based on it, learning-based approach will > not experience failure at the initial stage and will learn by itself > dynamically when there is a change of the topology of the access network, > and thus performs well at any time. > Where does the router get the static information from? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 13 23:48:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02972 for ; Thu, 13 Mar 2003 23:48:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E53Fa30786 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 00:03:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E53FO30783 for ; Fri, 14 Mar 2003 00:03:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02962 for ; Thu, 13 Mar 2003 23:47:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E534O30763; Fri, 14 Mar 2003 00:03:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E52tO30743 for ; Fri, 14 Mar 2003 00:02:55 -0500 Received: from ns.sait.samsung.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02954 for ; Thu, 13 Mar 2003 23:47:37 -0500 (EST) Received: from icebright (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.8/8.12.1) with SMTP id h2E4nh3X007721; Fri, 14 Mar 2003 13:49:44 +0900 (KST) From: "Xiaoming Wang" To: "James Kempf" , "Daichi Funato" , Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 13:49:49 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <008201c2e9e1$dcacc9e0$516015ac@T23KEMPF> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, > > [xiaoming] I think this can be improved by static configuration at the > > initial stage. Initial data can be computed with the geographical and > > topological information of access network, which is used during > the network > > planning and construction stage. Based on it, learning-based > approach will > > not experience failure at the initial stage and will learn by itself > > dynamically when there is a change of the topology of the > access network, > > and thus performs well at any time. > > > > Where does the router get the static information from? > These static information can be defined as profile for configuation, which can be maitained by management entity. It is as natural as initial configuration of routing table from some predefined information. xiaoming _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 13 23:48:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02986 for ; Thu, 13 Mar 2003 23:48:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E534O30763; Fri, 14 Mar 2003 00:03:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E52tO30743 for ; Fri, 14 Mar 2003 00:02:55 -0500 Received: from ns.sait.samsung.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02954 for ; Thu, 13 Mar 2003 23:47:37 -0500 (EST) Received: from icebright (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.8/8.12.1) with SMTP id h2E4nh3X007721; Fri, 14 Mar 2003 13:49:44 +0900 (KST) From: "Xiaoming Wang" To: "James Kempf" , "Daichi Funato" , Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 13:49:49 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <008201c2e9e1$dcacc9e0$516015ac@T23KEMPF> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, > > [xiaoming] I think this can be improved by static configuration at the > > initial stage. Initial data can be computed with the geographical and > > topological information of access network, which is used during > the network > > planning and construction stage. Based on it, learning-based > approach will > > not experience failure at the initial stage and will learn by itself > > dynamically when there is a change of the topology of the > access network, > > and thus performs well at any time. > > > > Where does the router get the static information from? > These static information can be defined as profile for configuation, which can be maitained by management entity. It is as natural as initial configuration of routing table from some predefined information. xiaoming _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 04:20:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19898 for ; Fri, 14 Mar 2003 04:20:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E9ZLQ27624 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 04:35:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E9ZLO27621 for ; Fri, 14 Mar 2003 04:35:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19854 for ; Fri, 14 Mar 2003 04:19:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E9Z3O27594; Fri, 14 Mar 2003 04:35:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E9XAO27483 for ; Fri, 14 Mar 2003 04:33:10 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19824 for ; Fri, 14 Mar 2003 04:17:47 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2E9NRF25864 for ; Fri, 14 Mar 2003 11:23:27 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 11:19:50 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 11:19:47 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 11:19:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Question on CTSR Date: Fri, 14 Mar 2003 11:19:46 +0200 Message-ID: Thread-Topic: [Seamoby] Question on CTSR Thread-Index: AcLnJ1Q3oxZw0OpcTe6Op3NHx3sOlAC4t2lQ To: , Cc: X-OriginalArrivalTime: 14 Mar 2003 09:19:47.0075 (UTC) FILETIME=[DB5E2D30:01C2EA0A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2E9XAO27492 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit James, > Then perhaps someone on the DT could tell me the point of having this message be > separate from signaling from the MN that triggers the handover? Currently, if one looks at the requirements, there are the following requirements: 4.7 The context transfer solution MUST support context transfer before, during and after handover. 4.13 The context transfer solution MUST include methods for interworking with any IETF IP mobility solutions. 4.14 The context transfer solution MAY include methods for interworking with non-IETF mobility solutions. Which seem to seperate a tight-coupling of the Context Transfer signaling with the MN handover signaling. My feeling was that we are working on a generalized context transfer protocol. Consideration for specific mobile handover signaling, should either be placed in an appendix or seperate draft. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 04:20:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19912 for ; Fri, 14 Mar 2003 04:20:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E9Z3O27594; Fri, 14 Mar 2003 04:35:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E9XAO27483 for ; Fri, 14 Mar 2003 04:33:10 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19824 for ; Fri, 14 Mar 2003 04:17:47 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2E9NRF25864 for ; Fri, 14 Mar 2003 11:23:27 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 11:19:50 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 11:19:47 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 11:19:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Question on CTSR Date: Fri, 14 Mar 2003 11:19:46 +0200 Message-ID: Thread-Topic: [Seamoby] Question on CTSR Thread-Index: AcLnJ1Q3oxZw0OpcTe6Op3NHx3sOlAC4t2lQ To: , Cc: X-OriginalArrivalTime: 14 Mar 2003 09:19:47.0075 (UTC) FILETIME=[DB5E2D30:01C2EA0A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2E9XAO27492 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, > Then perhaps someone on the DT could tell me the point of having this message be > separate from signaling from the MN that triggers the handover? Currently, if one looks at the requirements, there are the following requirements: 4.7 The context transfer solution MUST support context transfer before, during and after handover. 4.13 The context transfer solution MUST include methods for interworking with any IETF IP mobility solutions. 4.14 The context transfer solution MAY include methods for interworking with non-IETF mobility solutions. Which seem to seperate a tight-coupling of the Context Transfer signaling with the MN handover signaling. My feeling was that we are working on a generalized context transfer protocol. Consideration for specific mobile handover signaling, should either be placed in an appendix or seperate draft. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 08:10:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24368 for ; Fri, 14 Mar 2003 08:10:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EDPIF09617 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 08:25:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDPIO09614 for ; Fri, 14 Mar 2003 08:25:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24347 for ; Fri, 14 Mar 2003 08:09:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDOwO09588; Fri, 14 Mar 2003 08:24:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDJQO09379 for ; Fri, 14 Mar 2003 08:19:26 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24281 for ; Fri, 14 Mar 2003 08:03:59 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ED60a10394 for ; Fri, 14 Mar 2003 07:06:00 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 07:05:57 -0600 Received: from Beethoven ([172.21.194.122]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 07:05:55 -0600 Reply-To: From: "Dirk Trossen" To: "ext James Kempf" , , , Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 08:05:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <02fd01c2e9b4$3de7ed30$286015ac@T23KEMPF> X-OriginalArrivalTime: 14 Mar 2003 13:05:56.0346 (UTC) FILETIME=[73489DA0:01C2EA2A] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi James, I'm not sure I understand the attack. If an attacker sends a completely bogus AP, the AR compares against the AAPL (Authorized AP List) and rejects. If an attacker sends an AP that is not bogus but is not a GAAP, then it will pass the AAPL test but it will remain in the cache for one iteration and be flushed aftewards. [DOT] Isn't it the issue how the AAPL (we have a new term now??) is determined? In the server approach, one entry after another is retrieved from the server (including some retrievals that are not successful or unnecessary, i.e., bogus APs). In the dycard approach, the list is generated through learning. The only way to have no interaction beyond the server in order to compare AP against AAPL after receiving AP id is to entirely download all possible APs of the GAARs a priori to the AR. That's what I said a few days ago, and it basically results in a administrator approach. However, the administrator is not only required for the authentication of the APs (this is done already today) but for the determination of what ARs are adjacent, something I though we want to avoid, when I recall the issues draft correctly. Dirk > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 13, 2003 4:47 PM > To: Eunsoo Shim; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > Cache contamination is only an issue if it results in an MN getting a wrong > mapping, where a wrong mapping means that the MN presents the AR with an AP > address for an AP that it is hearing, and it gets back an presumptive AR address > that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a > legitimate MN always presents an AP address that it is hearing, then the AP is a > GAAP (Geographically Adjacent AP). If the source of the mapping information > (either interrouter ala dycard or backend database ala DT draft) always returns > a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a > router that is not a GAAR or a valid AR. > > > > The issue of nonGAAR mappings consuming cache space can be handled by aging out > cache entries. If the probability that a cache entry is dropped depends on the > number of MNs that report the AP, then attacks will be quickly flushed. For > example, suppose that the probability that a cache entry gets dropped at time T > is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then > if a single MN mounts an attack, its bogus cache entry is flushed every time. > Thus, the cache need only be sized slightly large than the expected number of > GAAP to GAAR entries. > > > > In short, a properly specified cache timeout algorithm, together with an > authoritative source of AP to AR mappings should handle it. > > > > jak > > > > > > ----- Original Message ----- > From: "Eunsoo Shim" > To: > Sent: Wednesday, March 12, 2003 1:08 PM > Subject: [SeaMoby] Topic #3: Cache contamination > > > > Hi, > > > > Since we don't have much time until the IETF meeting next week, I think it > > would be better to check important points in the mailing list before > > off-line discussion for a short time during the meeting. > > As always pointed out, security is a big concern. > > It was pointed out there was no way to prevent cache contamination in the > > server approach. Scope-ID was claimed as a solution but it was not really > > explained in my understanding. > > I look forward to an explanation of how cache contamination can be prevented > > in the server approach. > > Regards, > > > > Eunsoo > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 08:10:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24391 for ; Fri, 14 Mar 2003 08:10:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDOwO09588; Fri, 14 Mar 2003 08:24:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDJQO09379 for ; Fri, 14 Mar 2003 08:19:26 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24281 for ; Fri, 14 Mar 2003 08:03:59 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ED60a10394 for ; Fri, 14 Mar 2003 07:06:00 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 07:05:57 -0600 Received: from Beethoven ([172.21.194.122]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 07:05:55 -0600 Reply-To: From: "Dirk Trossen" To: "ext James Kempf" , , , Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 08:05:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <02fd01c2e9b4$3de7ed30$286015ac@T23KEMPF> X-OriginalArrivalTime: 14 Mar 2003 13:05:56.0346 (UTC) FILETIME=[73489DA0:01C2EA2A] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi James, I'm not sure I understand the attack. If an attacker sends a completely bogus AP, the AR compares against the AAPL (Authorized AP List) and rejects. If an attacker sends an AP that is not bogus but is not a GAAP, then it will pass the AAPL test but it will remain in the cache for one iteration and be flushed aftewards. [DOT] Isn't it the issue how the AAPL (we have a new term now??) is determined? In the server approach, one entry after another is retrieved from the server (including some retrievals that are not successful or unnecessary, i.e., bogus APs). In the dycard approach, the list is generated through learning. The only way to have no interaction beyond the server in order to compare AP against AAPL after receiving AP id is to entirely download all possible APs of the GAARs a priori to the AR. That's what I said a few days ago, and it basically results in a administrator approach. However, the administrator is not only required for the authentication of the APs (this is done already today) but for the determination of what ARs are adjacent, something I though we want to avoid, when I recall the issues draft correctly. Dirk > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 13, 2003 4:47 PM > To: Eunsoo Shim; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > Cache contamination is only an issue if it results in an MN getting a wrong > mapping, where a wrong mapping means that the MN presents the AR with an AP > address for an AP that it is hearing, and it gets back an presumptive AR address > that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a > legitimate MN always presents an AP address that it is hearing, then the AP is a > GAAP (Geographically Adjacent AP). If the source of the mapping information > (either interrouter ala dycard or backend database ala DT draft) always returns > a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a > router that is not a GAAR or a valid AR. > > > > The issue of nonGAAR mappings consuming cache space can be handled by aging out > cache entries. If the probability that a cache entry is dropped depends on the > number of MNs that report the AP, then attacks will be quickly flushed. For > example, suppose that the probability that a cache entry gets dropped at time T > is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then > if a single MN mounts an attack, its bogus cache entry is flushed every time. > Thus, the cache need only be sized slightly large than the expected number of > GAAP to GAAR entries. > > > > In short, a properly specified cache timeout algorithm, together with an > authoritative source of AP to AR mappings should handle it. > > > > jak > > > > > > ----- Original Message ----- > From: "Eunsoo Shim" > To: > Sent: Wednesday, March 12, 2003 1:08 PM > Subject: [SeaMoby] Topic #3: Cache contamination > > > > Hi, > > > > Since we don't have much time until the IETF meeting next week, I think it > > would be better to check important points in the mailing list before > > off-line discussion for a short time during the meeting. > > As always pointed out, security is a big concern. > > It was pointed out there was no way to prevent cache contamination in the > > server approach. Scope-ID was claimed as a solution but it was not really > > explained in my understanding. > > I look forward to an explanation of how cache contamination can be prevented > > in the server approach. > > Regards, > > > > Eunsoo > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 08:11:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24439 for ; Fri, 14 Mar 2003 08:11:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EDQEu09695 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 08:26:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDQEO09692 for ; Fri, 14 Mar 2003 08:26:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24411 for ; Fri, 14 Mar 2003 08:10:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDQ2O09665; Fri, 14 Mar 2003 08:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDOsO09582 for ; Fri, 14 Mar 2003 08:24:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24340 for ; Fri, 14 Mar 2003 08:09:27 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EDBU819443 for ; Fri, 14 Mar 2003 07:11:30 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 07:11:30 -0600 Received: from Beethoven ([172.21.194.122]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 07:11:28 -0600 Reply-To: From: "Dirk Trossen" To: "ext Xiaoming Wang" , "Daichi Funato" , Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 08:11:23 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 14 Mar 2003 13:11:29.0132 (UTC) FILETIME=[39A3BAC0:01C2EA2B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Xiaoming, -----Original Message----- From: seamoby-admin@ietf.org [mailto:seamoby-admin@ietf.org]On Behalf Of ext Xiaoming Wang Sent: Thursday, March 13, 2003 8:48 PM To: Daichi Funato; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD please find the inline comment. > > Hemant -> I am trying to do some back of the envelope calculation > > here. There are two ARs and first handoff happens between them. > > Let us say cache lifetime is few hours. If another handoff occurs > > during those few hours, cache gets refreshed for another few hours. > > If no handoff occurs between those two ARs in few hours, why do > > we need to care of about seamlessness in the first place. > > I don't think this calculation is enough... > A server is necessary to save the initial handover failures. > Let me show you another caluculation. > > Suppose there is an AR, which has a hexagon shape coverage. > If we surround this AR with other AR hexagons, there will be > 7 ARs. In this case, the total adjacent edges, which equals to > the total CAR entries, are 12. This means we need 12 learning > reports from MNs with 12 handover failures in learning-based > approach. > > If we continue surrounding this, we can get the numbers by > simple calculations. > > #Surrounds, #ARs, #TotalEdges(CARs) > 1, 7, 12 > 2, 19, 42 > 3, 37, 90 > 4, 61, 156 > 5, 91, 240 > 6, 127, 342 > > According to this results, if an operator deploys 127 ARs, the > operator possibly receives 342 call-miss complaints from customers. > They might include important emergency call handover misses. > This is a nightmare to the operator. > No one knows one call is less important than the other calls. > Who can say this is not a big deal? > > If we take learning-based approach, we can't avoid this problem by nature. > The server-based approach can provide a way to greatly improve this. > Placing a server will save hundreds of handover failures in initial stage. > Also the server will be used to save handover failures every time a > CAR cache in an AR expires as well. It's not a trivial matter. > > Operators won't take a solution, which doesn't provide a way to > improve quality to customers. Moreover, operators won't take any way, > which sacrifices users to improve their network operation efficiency. > The burden should not be shared with customers. > [xiaoming] I think this can be improved by static configuration at the initial stage. Initial data can be computed with the geographical and topological information of access network, which is used during the network planning and construction stage. Based on it, learning-based approach will not experience failure at the initial stage and will learn by itself dynamically when there is a change of the topology of the access network, and thus performs well at any time. xiaoming [DOT] We never assumed this, since as I explained also to James, we did not assume an operator knowledge and configuration of the ARs regarding the exact overlapping coverage areas. This is even more important since dycard always targetted intra- as well as inter-domain CAR. Even though we want to make the latter case forgotten by defining it out of scope, we have to keep in mind that the learning works for inter-domain as well. [DOT] However, if we assumed such knowledge and pre-configuration of the routers by the operator, we could at least have a certain initial state for the domain (in inter-domain, entries could still be missing) as you explained, if we downloaded the appropriate information as cache entries to the ARs during booting. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 08:13:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24479 for ; Fri, 14 Mar 2003 08:13:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDQ2O09665; Fri, 14 Mar 2003 08:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EDOsO09582 for ; Fri, 14 Mar 2003 08:24:54 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24340 for ; Fri, 14 Mar 2003 08:09:27 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EDBU819443 for ; Fri, 14 Mar 2003 07:11:30 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 07:11:30 -0600 Received: from Beethoven ([172.21.194.122]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 07:11:28 -0600 Reply-To: From: "Dirk Trossen" To: "ext Xiaoming Wang" , "Daichi Funato" , Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 08:11:23 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 14 Mar 2003 13:11:29.0132 (UTC) FILETIME=[39A3BAC0:01C2EA2B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Xiaoming, -----Original Message----- From: seamoby-admin@ietf.org [mailto:seamoby-admin@ietf.org]On Behalf Of ext Xiaoming Wang Sent: Thursday, March 13, 2003 8:48 PM To: Daichi Funato; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD please find the inline comment. > > Hemant -> I am trying to do some back of the envelope calculation > > here. There are two ARs and first handoff happens between them. > > Let us say cache lifetime is few hours. If another handoff occurs > > during those few hours, cache gets refreshed for another few hours. > > If no handoff occurs between those two ARs in few hours, why do > > we need to care of about seamlessness in the first place. > > I don't think this calculation is enough... > A server is necessary to save the initial handover failures. > Let me show you another caluculation. > > Suppose there is an AR, which has a hexagon shape coverage. > If we surround this AR with other AR hexagons, there will be > 7 ARs. In this case, the total adjacent edges, which equals to > the total CAR entries, are 12. This means we need 12 learning > reports from MNs with 12 handover failures in learning-based > approach. > > If we continue surrounding this, we can get the numbers by > simple calculations. > > #Surrounds, #ARs, #TotalEdges(CARs) > 1, 7, 12 > 2, 19, 42 > 3, 37, 90 > 4, 61, 156 > 5, 91, 240 > 6, 127, 342 > > According to this results, if an operator deploys 127 ARs, the > operator possibly receives 342 call-miss complaints from customers. > They might include important emergency call handover misses. > This is a nightmare to the operator. > No one knows one call is less important than the other calls. > Who can say this is not a big deal? > > If we take learning-based approach, we can't avoid this problem by nature. > The server-based approach can provide a way to greatly improve this. > Placing a server will save hundreds of handover failures in initial stage. > Also the server will be used to save handover failures every time a > CAR cache in an AR expires as well. It's not a trivial matter. > > Operators won't take a solution, which doesn't provide a way to > improve quality to customers. Moreover, operators won't take any way, > which sacrifices users to improve their network operation efficiency. > The burden should not be shared with customers. > [xiaoming] I think this can be improved by static configuration at the initial stage. Initial data can be computed with the geographical and topological information of access network, which is used during the network planning and construction stage. Based on it, learning-based approach will not experience failure at the initial stage and will learn by itself dynamically when there is a change of the topology of the access network, and thus performs well at any time. xiaoming [DOT] We never assumed this, since as I explained also to James, we did not assume an operator knowledge and configuration of the ARs regarding the exact overlapping coverage areas. This is even more important since dycard always targetted intra- as well as inter-domain CAR. Even though we want to make the latter case forgotten by defining it out of scope, we have to keep in mind that the learning works for inter-domain as well. [DOT] However, if we assumed such knowledge and pre-configuration of the routers by the operator, we could at least have a certain initial state for the domain (in inter-domain, entries could still be missing) as you explained, if we downloaded the appropriate information as cache entries to the ARs during booting. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 10:20:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28879 for ; Fri, 14 Mar 2003 10:20:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EFZrM17611 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 10:35:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFZrO17608 for ; Fri, 14 Mar 2003 10:35:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28864 for ; Fri, 14 Mar 2003 10:20:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFZXO17565; Fri, 14 Mar 2003 10:35:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFWkO17406 for ; Fri, 14 Mar 2003 10:32:46 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28806 for ; Fri, 14 Mar 2003 10:17:16 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EFJP819074 for ; Fri, 14 Mar 2003 09:19:25 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 09:19:25 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 09:19:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 10:19:21 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLp38E1W+8aJrWNRlO1pvRQMXkO7QAW1OGg To: , , , X-OriginalArrivalTime: 14 Mar 2003 15:19:22.0839 (UTC) FILETIME=[17867E70:01C2EA3D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EFWkO17407 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit James, [snip] > Why do you say it assumes the server approach? The AAPL could > be programmed into > the router through a Web page. It doesn't have to come from a > server. Something > like the AAPL will even be needed in Dycard, else how does a > router know that an > access point connected to it is authorized? > [Govind] This is because the cache population schemes are different in the schemes. Therefore, the effectiveness of any cache contamination scheme is different. [snip] > Right, the assumption here is that the probability of an > attack decreases > according to the number of MNs involved. Remember, for an MN > to even get on the > link, it must be auth/authz-ed. So, multiple MNs means a > bunch of the operator's > authorized customers decided to get together and attack. > Maybe not such a > completely outlandish idea these days, but a much lower > probablity event than > one lone customer who is having a bad day and decides to > cause some mischief. [Govind] I agree that the probability of more than one malicious user is lesser than one malicious user. However, if this is an inherent deficiency in a scheme that protects the protocol, then I believe in no time will more there be more than one hacker trying to bring down the system. > > >Also, they might not be removed from the cache. More such > entries and more > > the unnecessary capability messages. Note, if we are using > the server scheme, > each MN has > > the possibility of reporting a large number of such non-GAAPs. > > Why do you assume the server scheme? The cache state would > need to be timed out > for Dycard as well. > [Govind] Because you have talked about adding cache entries based on APs sent in by the MN. > >Consider this scenario, > > 10 malicious MNs each report say 100 genuine non-GAAPs. > > If I, as an operator, have 10 malicious customers, then I'm > pretty bad off. > After that attack, they get their service cancelled forthwith. [Govind] There is no way you can recognize the fact that they are doing something malicious as they are reporting APs that are valid and authorized. > > OK, so its a hundred. How big is a cache entry? Let's be > conservative and say > it's 1K (actually, it's probably a lot smaller). that's still > only 100K. Given > Moore's law, that costs nothing. [Govind] You have no control on what the cache size is yet. This depends on what capabilities are transferred, and their respective sizes. But cache size is not the attack, increase in inter-AR communication and subsequent processing is the problem. > > The point is, it's not a million. The attack becomes less > probable and easier to > detect the more entries. > [Govind] My point is even a 100 depending what capabilities are is a lot of unnecessary processing. Remember, the ARs are not there just for CARD They are involved in other work too. > It is all a matter of matching the threat. The highest > probability threat, in > this case, is a single MN having a bad day and deciding to > try some mischief. > Now if an average MN reports, say 2 or three APs and suddenly > the router starts > to get a report of 100, it knows something is amiss. [Govind] The number of legal APs (including those from other domains) that a MN reports depends on the size of the "cell" as well as the population of APs of other operators. By making an unnecessary restriction on the number of APs we are just compromising the protocol needlessly. If 10 > MNs each start > reporting 100, it's time to call the Department of Homeland > Security. :-) [Govind] Since you can't control the number of legal APs around, any ratelimiting has to be set to a resonably high number (whatever that may be). Otherwise, you stand a chance of MNs just reporting APs out of your domain and the network rejecting the its own AP info sent in by the MN. Thats why I said initially that ratelimiting in the server based scheme is more difficult. [Govind] > Sure. There are always false positives. But typically any one > GAAP will be seen > by more than one MN. And, there are other ways to reduce the > probability of > flushing good entries, for example, using a weighed moving > average of reports. [Govind] Clearly this fails as the number of malicious MNs increase. -Govind _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 10:21:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28893 for ; Fri, 14 Mar 2003 10:21:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFZXO17565; Fri, 14 Mar 2003 10:35:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFWkO17406 for ; Fri, 14 Mar 2003 10:32:46 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28806 for ; Fri, 14 Mar 2003 10:17:16 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EFJP819074 for ; Fri, 14 Mar 2003 09:19:25 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 09:19:25 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 09:19:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 10:19:21 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLp38E1W+8aJrWNRlO1pvRQMXkO7QAW1OGg To: , , , X-OriginalArrivalTime: 14 Mar 2003 15:19:22.0839 (UTC) FILETIME=[17867E70:01C2EA3D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EFWkO17407 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, [snip] > Why do you say it assumes the server approach? The AAPL could > be programmed into > the router through a Web page. It doesn't have to come from a > server. Something > like the AAPL will even be needed in Dycard, else how does a > router know that an > access point connected to it is authorized? > [Govind] This is because the cache population schemes are different in the schemes. Therefore, the effectiveness of any cache contamination scheme is different. [snip] > Right, the assumption here is that the probability of an > attack decreases > according to the number of MNs involved. Remember, for an MN > to even get on the > link, it must be auth/authz-ed. So, multiple MNs means a > bunch of the operator's > authorized customers decided to get together and attack. > Maybe not such a > completely outlandish idea these days, but a much lower > probablity event than > one lone customer who is having a bad day and decides to > cause some mischief. [Govind] I agree that the probability of more than one malicious user is lesser than one malicious user. However, if this is an inherent deficiency in a scheme that protects the protocol, then I believe in no time will more there be more than one hacker trying to bring down the system. > > >Also, they might not be removed from the cache. More such > entries and more > > the unnecessary capability messages. Note, if we are using > the server scheme, > each MN has > > the possibility of reporting a large number of such non-GAAPs. > > Why do you assume the server scheme? The cache state would > need to be timed out > for Dycard as well. > [Govind] Because you have talked about adding cache entries based on APs sent in by the MN. > >Consider this scenario, > > 10 malicious MNs each report say 100 genuine non-GAAPs. > > If I, as an operator, have 10 malicious customers, then I'm > pretty bad off. > After that attack, they get their service cancelled forthwith. [Govind] There is no way you can recognize the fact that they are doing something malicious as they are reporting APs that are valid and authorized. > > OK, so its a hundred. How big is a cache entry? Let's be > conservative and say > it's 1K (actually, it's probably a lot smaller). that's still > only 100K. Given > Moore's law, that costs nothing. [Govind] You have no control on what the cache size is yet. This depends on what capabilities are transferred, and their respective sizes. But cache size is not the attack, increase in inter-AR communication and subsequent processing is the problem. > > The point is, it's not a million. The attack becomes less > probable and easier to > detect the more entries. > [Govind] My point is even a 100 depending what capabilities are is a lot of unnecessary processing. Remember, the ARs are not there just for CARD They are involved in other work too. > It is all a matter of matching the threat. The highest > probability threat, in > this case, is a single MN having a bad day and deciding to > try some mischief. > Now if an average MN reports, say 2 or three APs and suddenly > the router starts > to get a report of 100, it knows something is amiss. [Govind] The number of legal APs (including those from other domains) that a MN reports depends on the size of the "cell" as well as the population of APs of other operators. By making an unnecessary restriction on the number of APs we are just compromising the protocol needlessly. If 10 > MNs each start > reporting 100, it's time to call the Department of Homeland > Security. :-) [Govind] Since you can't control the number of legal APs around, any ratelimiting has to be set to a resonably high number (whatever that may be). Otherwise, you stand a chance of MNs just reporting APs out of your domain and the network rejecting the its own AP info sent in by the MN. Thats why I said initially that ratelimiting in the server based scheme is more difficult. [Govind] > Sure. There are always false positives. But typically any one > GAAP will be seen > by more than one MN. And, there are other ways to reduce the > probability of > flushing good entries, for example, using a weighed moving > average of reports. [Govind] Clearly this fails as the number of malicious MNs increase. -Govind _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 10:36:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29557 for ; Fri, 14 Mar 2003 10:36:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EFphQ19285 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 10:51:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFpgO19282 for ; Fri, 14 Mar 2003 10:51:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29523 for ; Fri, 14 Mar 2003 10:36:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFpJO19273; Fri, 14 Mar 2003 10:51:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFoFO19242 for ; Fri, 14 Mar 2003 10:50:15 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29425 for ; Fri, 14 Mar 2003 10:34:44 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EFas824431 for ; Fri, 14 Mar 2003 09:36:54 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 09:36:54 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 07:36:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 10:36:48 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLptKWRHoUpGzPKRpK34v4f6CI4cwAANuLwACJzLbA= To: , , , X-OriginalArrivalTime: 14 Mar 2003 15:36:49.0575 (UTC) FILETIME=[876DBB70:01C2EA3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EFoFO19243 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 13, 2003 6:44 PM To: kempf@docomolabs-usa.com; Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination > I'm not sure I understand the attack. > > If an attacker sends a completely bogus AP, the AR compares > against the AAPL > (Authorized AP List) and rejects. > If an attacker sends an AP that is not bogus but is not a > GAAP, then it will > pass the AAPL test but it will remain in the cache for one > iteration and be > flushed aftewards. [Govind] This is assuming a particular cache replacement policy and assumes the server approach. I think we should first settle whether the server is needed or not before coming to cache contamination and other cache related issues. However, if we are not going to do that, then we should propose how any scheme involving protecting the cache works in either of the proposed solutions. > > So, I don't see how interrouter capability and update > exchange are affected. [Govind] First thoughts about this cache replacement policy. I will think about this replacement policy more later.. Its been a long day already, so sorry if I'm wrong :) If the number of malicious MNs increase, then wouldn't you have an increase of the number of entries? Also, they might not be removed from the cache. More such entries and more the unnecessary capability messages. Note, if we are using the server scheme, each MN has the possibility of reporting a large number of such non-GAAPs. Consider this scenario, 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that each AP is assigned to a different AR. Further assume that you have a limit of 100 reports per MN. In your scheme, the chance of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of non GAARs are in the cache after each flush. So the current AR will communicate unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities exchanged you do have an unnecessary burden on the ARs. You will never be able to detect this and yet keep exchanging messages between non-CARs. Another point, by flipping a coin as you suggest based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you keep relying on the server, thus increasing the average response time. Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes to remove bad entries may be a better approach. I'm not saying that this is a bad cache replacement scheme yet but I'll think about this tomorrow. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 10:37:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29613 for ; Fri, 14 Mar 2003 10:37:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFpJO19273; Fri, 14 Mar 2003 10:51:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFoFO19242 for ; Fri, 14 Mar 2003 10:50:15 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29425 for ; Fri, 14 Mar 2003 10:34:44 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EFas824431 for ; Fri, 14 Mar 2003 09:36:54 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 09:36:54 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 07:36:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 10:36:48 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLptKWRHoUpGzPKRpK34v4f6CI4cwAANuLwACJzLbA= To: , , , X-OriginalArrivalTime: 14 Mar 2003 15:36:49.0575 (UTC) FILETIME=[876DBB70:01C2EA3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EFoFO19243 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant -----Original Message----- From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Thursday, March 13, 2003 6:44 PM To: kempf@docomolabs-usa.com; Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination > I'm not sure I understand the attack. > > If an attacker sends a completely bogus AP, the AR compares > against the AAPL > (Authorized AP List) and rejects. > If an attacker sends an AP that is not bogus but is not a > GAAP, then it will > pass the AAPL test but it will remain in the cache for one > iteration and be > flushed aftewards. [Govind] This is assuming a particular cache replacement policy and assumes the server approach. I think we should first settle whether the server is needed or not before coming to cache contamination and other cache related issues. However, if we are not going to do that, then we should propose how any scheme involving protecting the cache works in either of the proposed solutions. > > So, I don't see how interrouter capability and update > exchange are affected. [Govind] First thoughts about this cache replacement policy. I will think about this replacement policy more later.. Its been a long day already, so sorry if I'm wrong :) If the number of malicious MNs increase, then wouldn't you have an increase of the number of entries? Also, they might not be removed from the cache. More such entries and more the unnecessary capability messages. Note, if we are using the server scheme, each MN has the possibility of reporting a large number of such non-GAAPs. Consider this scenario, 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that each AP is assigned to a different AR. Further assume that you have a limit of 100 reports per MN. In your scheme, the chance of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of non GAARs are in the cache after each flush. So the current AR will communicate unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities exchanged you do have an unnecessary burden on the ARs. You will never be able to detect this and yet keep exchanging messages between non-CARs. Another point, by flipping a coin as you suggest based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you keep relying on the server, thus increasing the average response time. Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes to remove bad entries may be a better approach. I'm not saying that this is a bad cache replacement scheme yet but I'll think about this tomorrow. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 11:36:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01554 for ; Fri, 14 Mar 2003 11:36:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EGp7P23675 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 11:51:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGp6O23672 for ; Fri, 14 Mar 2003 11:51:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01545 for ; Fri, 14 Mar 2003 11:35:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGopO23661; Fri, 14 Mar 2003 11:50:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGntO23612 for ; Fri, 14 Mar 2003 11:49:55 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01497 for ; Fri, 14 Mar 2003 11:34:23 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EGaaa06494 for ; Fri, 14 Mar 2003 10:36:36 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 10:36:33 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 10:36:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD Issues List Date: Fri, 14 Mar 2003 11:36:32 -0500 Message-ID: Thread-Topic: [Seamoby] CARD Issues List Thread-Index: AcLpskE9ihjRL8UXSwev5wv7JO3dlwAjhseQ To: , X-OriginalArrivalTime: 14 Mar 2003 16:36:33.0555 (UTC) FILETIME=[DFA5AE30:01C2EA47] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EGntO23613 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit James, Thanks for taking the time to putup a website. It will help us follow the discussion better. Here are my comments. Issue 1: You haven't mentioned the general WG opinion (including people from the DT) that this issue is out of scope. We may be dealing with non-IP addressable devices here of different technologies, and as pointed out by a slew of email, and that there are existing methods to take care of this. So would this be a good statement for an alternative proposal for Issue 1? Proposal 2: Problem is important, but is out-of-scope of CARD. We can use the following statement in the final spec. The operator/ISP MUST provide an authorized list of AP beacons that can be attached to each AR. Issue 2: Proposal 2: If you remove the server from the base draft, how is this base draft going to address the AP-AR mapping. This is not clear to me. Maybe I'm missing something. Issue 3: Though I'm not against putting explicit text in, I don't think explicit text is necessary. If the "cache protection" scheme is designed well this kind of rate limiting will automatically happen. Rate limiting may be difficult when used in the DT scheme, as MNs may report APs from other domains. Issue 4: Proposal 2: Apart from what is written, this should be added to the proposal. The scheme also uses a third party verified unique MN id and tags it with each cache entry. The number of cache entries created per MN is this limited. Proposal 3: I have illustrated the problems associated with Proposal 3. This is not very secure against attacks by multiple malicious MNs, particularly when used in conjunction with the DT approach. I haven't looked at the proposal's efficiency when used with the cache population scheme described in dycard. I think Proposal 2 works fine with dycard and we don't need proposal 3. Issue 5: Again, I think the points raised in the mailing list are missing here. I think we shouldn't really do what is being proposed here. I think CARD is not just for FMIPv6. Issues 6 - 9: These issues may not exist when you have finished tackling prior issues. Apart from these issues, here is an issue that was brought up in the mailing list: Issue 12: Non-conformance with Requirement that deals with ARs with private and site-local addresses: DT draft currently does not address this. Proposal: One possible approach is presented in dycard. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 11:36:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01573 for ; Fri, 14 Mar 2003 11:36:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGopO23661; Fri, 14 Mar 2003 11:50:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGntO23612 for ; Fri, 14 Mar 2003 11:49:55 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01497 for ; Fri, 14 Mar 2003 11:34:23 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EGaaa06494 for ; Fri, 14 Mar 2003 10:36:36 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 10:36:33 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 10:36:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD Issues List Date: Fri, 14 Mar 2003 11:36:32 -0500 Message-ID: Thread-Topic: [Seamoby] CARD Issues List Thread-Index: AcLpskE9ihjRL8UXSwev5wv7JO3dlwAjhseQ To: , X-OriginalArrivalTime: 14 Mar 2003 16:36:33.0555 (UTC) FILETIME=[DFA5AE30:01C2EA47] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EGntO23613 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, Thanks for taking the time to putup a website. It will help us follow the discussion better. Here are my comments. Issue 1: You haven't mentioned the general WG opinion (including people from the DT) that this issue is out of scope. We may be dealing with non-IP addressable devices here of different technologies, and as pointed out by a slew of email, and that there are existing methods to take care of this. So would this be a good statement for an alternative proposal for Issue 1? Proposal 2: Problem is important, but is out-of-scope of CARD. We can use the following statement in the final spec. The operator/ISP MUST provide an authorized list of AP beacons that can be attached to each AR. Issue 2: Proposal 2: If you remove the server from the base draft, how is this base draft going to address the AP-AR mapping. This is not clear to me. Maybe I'm missing something. Issue 3: Though I'm not against putting explicit text in, I don't think explicit text is necessary. If the "cache protection" scheme is designed well this kind of rate limiting will automatically happen. Rate limiting may be difficult when used in the DT scheme, as MNs may report APs from other domains. Issue 4: Proposal 2: Apart from what is written, this should be added to the proposal. The scheme also uses a third party verified unique MN id and tags it with each cache entry. The number of cache entries created per MN is this limited. Proposal 3: I have illustrated the problems associated with Proposal 3. This is not very secure against attacks by multiple malicious MNs, particularly when used in conjunction with the DT approach. I haven't looked at the proposal's efficiency when used with the cache population scheme described in dycard. I think Proposal 2 works fine with dycard and we don't need proposal 3. Issue 5: Again, I think the points raised in the mailing list are missing here. I think we shouldn't really do what is being proposed here. I think CARD is not just for FMIPv6. Issues 6 - 9: These issues may not exist when you have finished tackling prior issues. Apart from these issues, here is an issue that was brought up in the mailing list: Issue 12: Non-conformance with Requirement that deals with ARs with private and site-local addresses: DT draft currently does not address this. Proposal: One possible approach is presented in dycard. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 11:38:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01700 for ; Fri, 14 Mar 2003 11:38:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EGrHx23783 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 11:53:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGrHO23780 for ; Fri, 14 Mar 2003 11:53:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01680 for ; Fri, 14 Mar 2003 11:37:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGr4O23745; Fri, 14 Mar 2003 11:53:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGqBO23713 for ; Fri, 14 Mar 2003 11:52:11 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01611 for ; Fri, 14 Mar 2003 11:36:39 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 11:38:50 -0500 Message-ID: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Xiaoming Wang" , "James Kempf" , "Daichi Funato" , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 11:40:05 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 16:38:50.0542 (UTC) FILETIME=[314C3CE0:01C2EA48] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So far, what I heard about the necessity of the server for CARD were two things: 1) Initial population of the cache 2) AP authorization 1) Initial population of the cache There are lots of arguments about whether we really need such initial population of the cache. Personally I doubt the need. Anyway, as Xiaoming and other folks already pointed out, if it is really necessary, such initial population can be done using any existing management tool. We don't need to reinvent the wheel for initial router configuration. That is, we don't need to introduce any server or protocol for that. 2) AP authorization AP authorization is a very general problem. I think this should be handled separately from CARD. How AP should be authorized is a L2 issue and thus is not even in the scope of the IETF. We cannot devise a general protocol based on IP for AP-AR since such communication depends on the L2 technology and we cannot assume IP between AP and AR. What we can do is we assume each AR knows the list of APs associated with it. Such information can be configured at each AR also using any existing management tool. Thus again, I don't think we need to introduce the server of the DT draft for this purpose either. Was there any other item as the necessity of the server for CARD? Or does anyone want to propose anything else? Eunsoo ----- Original Message ----- From: "Xiaoming Wang" To: "James Kempf" ; "Daichi Funato" ; Sent: Thursday, March 13, 2003 8:49 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > James, > > > > [xiaoming] I think this can be improved by static configuration at the > > > initial stage. Initial data can be computed with the geographical and > > > topological information of access network, which is used during > > the network > > > planning and construction stage. Based on it, learning-based > > approach will > > > not experience failure at the initial stage and will learn by itself > > > dynamically when there is a change of the topology of the > > access network, > > > and thus performs well at any time. > > > > > > > Where does the router get the static information from? > > > > These static information can be defined as profile for configuation, which > can be maitained by management entity. It is as natural as initial > configuration of routing table from some predefined information. > > xiaoming > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 11:38:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01723 for ; Fri, 14 Mar 2003 11:38:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGr4O23745; Fri, 14 Mar 2003 11:53:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EGqBO23713 for ; Fri, 14 Mar 2003 11:52:11 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01611 for ; Fri, 14 Mar 2003 11:36:39 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 11:38:50 -0500 Message-ID: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Xiaoming Wang" , "James Kempf" , "Daichi Funato" , References: Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 11:40:05 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 16:38:50.0542 (UTC) FILETIME=[314C3CE0:01C2EA48] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So far, what I heard about the necessity of the server for CARD were two things: 1) Initial population of the cache 2) AP authorization 1) Initial population of the cache There are lots of arguments about whether we really need such initial population of the cache. Personally I doubt the need. Anyway, as Xiaoming and other folks already pointed out, if it is really necessary, such initial population can be done using any existing management tool. We don't need to reinvent the wheel for initial router configuration. That is, we don't need to introduce any server or protocol for that. 2) AP authorization AP authorization is a very general problem. I think this should be handled separately from CARD. How AP should be authorized is a L2 issue and thus is not even in the scope of the IETF. We cannot devise a general protocol based on IP for AP-AR since such communication depends on the L2 technology and we cannot assume IP between AP and AR. What we can do is we assume each AR knows the list of APs associated with it. Such information can be configured at each AR also using any existing management tool. Thus again, I don't think we need to introduce the server of the DT draft for this purpose either. Was there any other item as the necessity of the server for CARD? Or does anyone want to propose anything else? Eunsoo ----- Original Message ----- From: "Xiaoming Wang" To: "James Kempf" ; "Daichi Funato" ; Sent: Thursday, March 13, 2003 8:49 PM Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > James, > > > > [xiaoming] I think this can be improved by static configuration at the > > > initial stage. Initial data can be computed with the geographical and > > > topological information of access network, which is used during > > the network > > > planning and construction stage. Based on it, learning-based > > approach will > > > not experience failure at the initial stage and will learn by itself > > > dynamically when there is a change of the topology of the > > access network, > > > and thus performs well at any time. > > > > > > > Where does the router get the static information from? > > > > These static information can be defined as profile for configuation, which > can be maitained by management entity. It is as natural as initial > configuration of routing table from some predefined information. > > xiaoming > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 12:04:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02808 for ; Fri, 14 Mar 2003 12:04:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EHJWg26091 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 12:19:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHJVO26088 for ; Fri, 14 Mar 2003 12:19:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02803 for ; Fri, 14 Mar 2003 12:03:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHJJO26077; Fri, 14 Mar 2003 12:19:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHIEO26032 for ; Fri, 14 Mar 2003 12:18:14 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02738 for ; Fri, 14 Mar 2003 12:02:41 -0500 (EST) Message-ID: <005d01c2ea4b$9d868200$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 09:03:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dirk, > [DOT] Isn't it the issue how the AAPL (we have a new term now??) is > determined? > In the server approach, one entry after another is retrieved from the > server (including > some retrievals that are not successful or unnecessary, i.e., bogus > APs). In the dycard > approach, the list is generated through learning. The only way to have > no interaction beyond > the server in order to compare AP against AAPL after receiving AP id > is to entirely download all possible APs of the GAARs a priori to the > AR. That's what I said a few days ago, and it basically results in a > administrator approach. However, the administrator is not only > required for the authentication of the APs (this is done already > today) but for the determination of what ARs are adjacent, something I > though we want to avoid, when I recall the issues draft correctly. > Even with Dycard there will need to be some authoritative source of information about which APs are on the AAPL. I quote from the Dycard draft (pg. 5): First, nAP must be authorized as one of nAR's local access points. This can be achieved through a managed list of APs currently attached to nAR, or by a larger set of APs that could possibly be attached over a given period of time. The size and variability of this authorization list is controlled by the ARs administrator. A larger set of authorized APs provides a higher level of reconfigurability, but also increases the possibility of malicious MNs polluting the AR's PNC. The list could be maintained on a server and pushed periodically, just as in the so-called server based approach. The difference between the server approach (I don't like that name, but let's use it for now) and Dycard is that in Dycard, the AR validates its own APs against the list, whereas in the server approach, the AR validates the GAAP against a list of allowed APs in some localized area. The issue of memory size, which some have brought up, appears irrelevant because even in Dycard the list can be larger than the set of authorized APs, as the above text indicates. Or am I missing something? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 12:04:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02835 for ; Fri, 14 Mar 2003 12:04:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHJJO26077; Fri, 14 Mar 2003 12:19:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHIEO26032 for ; Fri, 14 Mar 2003 12:18:14 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02738 for ; Fri, 14 Mar 2003 12:02:41 -0500 (EST) Message-ID: <005d01c2ea4b$9d868200$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 09:03:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dirk, > [DOT] Isn't it the issue how the AAPL (we have a new term now??) is > determined? > In the server approach, one entry after another is retrieved from the > server (including > some retrievals that are not successful or unnecessary, i.e., bogus > APs). In the dycard > approach, the list is generated through learning. The only way to have > no interaction beyond > the server in order to compare AP against AAPL after receiving AP id > is to entirely download all possible APs of the GAARs a priori to the > AR. That's what I said a few days ago, and it basically results in a > administrator approach. However, the administrator is not only > required for the authentication of the APs (this is done already > today) but for the determination of what ARs are adjacent, something I > though we want to avoid, when I recall the issues draft correctly. > Even with Dycard there will need to be some authoritative source of information about which APs are on the AAPL. I quote from the Dycard draft (pg. 5): First, nAP must be authorized as one of nAR's local access points. This can be achieved through a managed list of APs currently attached to nAR, or by a larger set of APs that could possibly be attached over a given period of time. The size and variability of this authorization list is controlled by the ARs administrator. A larger set of authorized APs provides a higher level of reconfigurability, but also increases the possibility of malicious MNs polluting the AR's PNC. The list could be maintained on a server and pushed periodically, just as in the so-called server based approach. The difference between the server approach (I don't like that name, but let's use it for now) and Dycard is that in Dycard, the AR validates its own APs against the list, whereas in the server approach, the AR validates the GAAP against a list of allowed APs in some localized area. The issue of memory size, which some have brought up, appears irrelevant because even in Dycard the list can be larger than the set of authorized APs, as the above text indicates. Or am I missing something? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 12:17:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03100 for ; Fri, 14 Mar 2003 12:17:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EHWjA26635 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 12:32:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHWjO26632 for ; Fri, 14 Mar 2003 12:32:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03090 for ; Fri, 14 Mar 2003 12:17:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHWOO26608; Fri, 14 Mar 2003 12:32:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHVgO26550 for ; Fri, 14 Mar 2003 12:31:42 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03079 for ; Fri, 14 Mar 2003 12:16:08 -0500 (EST) Message-ID: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 09:16:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Govind, I'm not convinced Dycard would do any better. As the number of malicious MNs increases, the number of PNE messages will increase. Thus, the load on the routers increases in any event. If there are several millions of malicious MNs bombarding the router with RM messages, the backhaul will fill with PNE messages as far as I can tell. I assume Dycard is using a cache for confirmed APs also, so that no PNE message would be sent if the RM resulted in a hit with a known, good GAAP. Or am I misunderstanding how Dycard works? You mentioned previously you had done a simulation on this. Could you or another of the Dyhard Dycard Team provide some information about what the numbers look like, or a URL to a published paper? jak ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 7:19 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > James, > > > [snip] > > Why do you say it assumes the server approach? The AAPL could > > be programmed into > > the router through a Web page. It doesn't have to come from a > > server. Something > > like the AAPL will even be needed in Dycard, else how does a > > router know that an > > access point connected to it is authorized? > > > [Govind] This is because the cache population schemes are different in the schemes. Therefore, > the effectiveness of any cache contamination scheme is different. > > [snip] > > Right, the assumption here is that the probability of an > > attack decreases > > according to the number of MNs involved. Remember, for an MN > > to even get on the > > link, it must be auth/authz-ed. So, multiple MNs means a > > bunch of the operator's > > authorized customers decided to get together and attack. > > Maybe not such a > > completely outlandish idea these days, but a much lower > > probablity event than > > one lone customer who is having a bad day and decides to > > cause some mischief. > > [Govind] I agree that the probability of more than one malicious user is lesser than one malicious user. > However, if this is an inherent deficiency in a scheme that protects the protocol, > then I believe in no time will more there be more than one hacker trying to bring down the system. > > > > > >Also, they might not be removed from the cache. More such > > entries and more > > > the unnecessary capability messages. Note, if we are using > > the server scheme, > > each MN has > > > the possibility of reporting a large number of such non-GAAPs. > > > > Why do you assume the server scheme? The cache state would > > need to be timed out > > for Dycard as well. > > > [Govind] Because you have talked about adding cache entries based on APs > sent in by the MN. > > > >Consider this scenario, > > > 10 malicious MNs each report say 100 genuine non-GAAPs. > > > > If I, as an operator, have 10 malicious customers, then I'm > > pretty bad off. > > After that attack, they get their service cancelled forthwith. > [Govind] There is no way you can recognize the fact that they are > doing something malicious as they are reporting APs that > are valid and authorized. > > > > > OK, so its a hundred. How big is a cache entry? Let's be > > conservative and say > > it's 1K (actually, it's probably a lot smaller). that's still > > only 100K. Given > > Moore's law, that costs nothing. > [Govind] You have no control on what the cache size is yet. This depends on > what capabilities are transferred, and their respective sizes. But > cache size is not the attack, increase in inter-AR communication > and subsequent processing is the problem. > > > > > The point is, it's not a million. The attack becomes less > > probable and easier to > > detect the more entries. > > > [Govind] My point is even a 100 depending what capabilities are > is a lot of unnecessary processing. Remember, the ARs are not there just for CARD > They are involved in other work too. > > > It is all a matter of matching the threat. The highest > > probability threat, in > > this case, is a single MN having a bad day and deciding to > > try some mischief. > > Now if an average MN reports, say 2 or three APs and suddenly > > the router starts > > to get a report of 100, it knows something is amiss. > [Govind] The number of legal APs (including those from other domains) that a > MN reports depends on the size of the "cell" as well as the population of APs of > other operators. By making > an unnecessary restriction on the number of APs we are just compromising > the protocol needlessly. > > If 10 > > MNs each start > > reporting 100, it's time to call the Department of Homeland > > Security. :-) > > [Govind] Since you can't control the number of legal APs around, any ratelimiting > has to be set to a resonably high number (whatever that may be). Otherwise, > you stand a chance of MNs just reporting APs out of your domain and the network > rejecting the its own AP info sent in by the MN. Thats why I said initially that > ratelimiting in the server based scheme is more difficult. > > [Govind] > > Sure. There are always false positives. But typically any one > > GAAP will be seen > > by more than one MN. And, there are other ways to reduce the > > probability of > > flushing good entries, for example, using a weighed moving > > average of reports. > [Govind] Clearly this fails as the number of malicious MNs increase. > > -Govind > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 12:18:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03122 for ; Fri, 14 Mar 2003 12:18:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHWOO26608; Fri, 14 Mar 2003 12:32:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHVgO26550 for ; Fri, 14 Mar 2003 12:31:42 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03079 for ; Fri, 14 Mar 2003 12:16:08 -0500 (EST) Message-ID: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 09:16:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Govind, I'm not convinced Dycard would do any better. As the number of malicious MNs increases, the number of PNE messages will increase. Thus, the load on the routers increases in any event. If there are several millions of malicious MNs bombarding the router with RM messages, the backhaul will fill with PNE messages as far as I can tell. I assume Dycard is using a cache for confirmed APs also, so that no PNE message would be sent if the RM resulted in a hit with a known, good GAAP. Or am I misunderstanding how Dycard works? You mentioned previously you had done a simulation on this. Could you or another of the Dyhard Dycard Team provide some information about what the numbers look like, or a URL to a published paper? jak ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 7:19 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > James, > > > [snip] > > Why do you say it assumes the server approach? The AAPL could > > be programmed into > > the router through a Web page. It doesn't have to come from a > > server. Something > > like the AAPL will even be needed in Dycard, else how does a > > router know that an > > access point connected to it is authorized? > > > [Govind] This is because the cache population schemes are different in the schemes. Therefore, > the effectiveness of any cache contamination scheme is different. > > [snip] > > Right, the assumption here is that the probability of an > > attack decreases > > according to the number of MNs involved. Remember, for an MN > > to even get on the > > link, it must be auth/authz-ed. So, multiple MNs means a > > bunch of the operator's > > authorized customers decided to get together and attack. > > Maybe not such a > > completely outlandish idea these days, but a much lower > > probablity event than > > one lone customer who is having a bad day and decides to > > cause some mischief. > > [Govind] I agree that the probability of more than one malicious user is lesser than one malicious user. > However, if this is an inherent deficiency in a scheme that protects the protocol, > then I believe in no time will more there be more than one hacker trying to bring down the system. > > > > > >Also, they might not be removed from the cache. More such > > entries and more > > > the unnecessary capability messages. Note, if we are using > > the server scheme, > > each MN has > > > the possibility of reporting a large number of such non-GAAPs. > > > > Why do you assume the server scheme? The cache state would > > need to be timed out > > for Dycard as well. > > > [Govind] Because you have talked about adding cache entries based on APs > sent in by the MN. > > > >Consider this scenario, > > > 10 malicious MNs each report say 100 genuine non-GAAPs. > > > > If I, as an operator, have 10 malicious customers, then I'm > > pretty bad off. > > After that attack, they get their service cancelled forthwith. > [Govind] There is no way you can recognize the fact that they are > doing something malicious as they are reporting APs that > are valid and authorized. > > > > > OK, so its a hundred. How big is a cache entry? Let's be > > conservative and say > > it's 1K (actually, it's probably a lot smaller). that's still > > only 100K. Given > > Moore's law, that costs nothing. > [Govind] You have no control on what the cache size is yet. This depends on > what capabilities are transferred, and their respective sizes. But > cache size is not the attack, increase in inter-AR communication > and subsequent processing is the problem. > > > > > The point is, it's not a million. The attack becomes less > > probable and easier to > > detect the more entries. > > > [Govind] My point is even a 100 depending what capabilities are > is a lot of unnecessary processing. Remember, the ARs are not there just for CARD > They are involved in other work too. > > > It is all a matter of matching the threat. The highest > > probability threat, in > > this case, is a single MN having a bad day and deciding to > > try some mischief. > > Now if an average MN reports, say 2 or three APs and suddenly > > the router starts > > to get a report of 100, it knows something is amiss. > [Govind] The number of legal APs (including those from other domains) that a > MN reports depends on the size of the "cell" as well as the population of APs of > other operators. By making > an unnecessary restriction on the number of APs we are just compromising > the protocol needlessly. > > If 10 > > MNs each start > > reporting 100, it's time to call the Department of Homeland > > Security. :-) > > [Govind] Since you can't control the number of legal APs around, any ratelimiting > has to be set to a resonably high number (whatever that may be). Otherwise, > you stand a chance of MNs just reporting APs out of your domain and the network > rejecting the its own AP info sent in by the MN. Thats why I said initially that > ratelimiting in the server based scheme is more difficult. > > [Govind] > > Sure. There are always false positives. But typically any one > > GAAP will be seen > > by more than one MN. And, there are other ways to reduce the > > probability of > > flushing good entries, for example, using a weighed moving > > average of reports. > [Govind] Clearly this fails as the number of malicious MNs increase. > > -Govind > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 12:23:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03224 for ; Fri, 14 Mar 2003 12:23:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EHcGJ27623 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 12:38:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHcGO27620 for ; Fri, 14 Mar 2003 12:38:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03207 for ; Fri, 14 Mar 2003 12:22:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHc4O27611; Fri, 14 Mar 2003 12:38:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHbWO27493 for ; Fri, 14 Mar 2003 12:37:32 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03197 for ; Fri, 14 Mar 2003 12:21:59 -0500 (EST) Message-ID: <009801c2ea4e$4ff10760$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 09:22:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hemant, I don't understand. If an attacking MN reports something that is not a GAAP, then sure, maybe it gets some junk, but so what? If the MN wants to be so antisocial, then it gets to deal with the results. As for wireless bandwidth, I assume the wireless network is enforcing the MN's QoS so it only gets the amount of bandwidth it paid for. As for the router, as mentioned in Issue 3 on the issues Web page, the protocol should include a provision for rate limiting and a provision allowing the router to selectively drop packets in order to deal with a spike in service requests. jak ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 7:36 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Thursday, March 13, 2003 6:44 PM > To: kempf@docomolabs-usa.com; Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > > > > I'm not sure I understand the attack. > > > > If an attacker sends a completely bogus AP, the AR compares > > against the AAPL > > (Authorized AP List) and rejects. > > If an attacker sends an AP that is not bogus but is not a > > GAAP, then it will > > pass the AAPL test but it will remain in the cache for one > > iteration and be > > flushed aftewards. > [Govind] This is assuming a particular cache replacement policy and assumes > the server approach. I think we should first settle whether the server is needed > or not before coming to cache contamination and other cache related issues. > However, if we are not going to do that, then we should propose how any > scheme involving protecting the cache works in either of the proposed solutions. > > > > So, I don't see how interrouter capability and update > > exchange are affected. > [Govind] First thoughts about this cache replacement policy. I will think about this replacement > policy more later.. Its been a long day already, so sorry if I'm wrong :) > > If the number of malicious MNs increase, then wouldn't you have an increase of the number > of entries? Also, they might not be removed from the cache. More such entries and more > the unnecessary capability messages. Note, if we are using the server scheme, each MN has > the possibility of reporting a large number of such non-GAAPs. Consider this scenario, > 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that > each AP is assigned to a different AR. Further assume that > you have a limit of 100 reports per MN. In your scheme, the chance > of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of > non GAARs are in the cache after each flush. So the current AR will communicate > unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities > exchanged you do have an unnecessary burden on the ARs. You will never be able > to detect this and yet keep exchanging messages between non-CARs. > > Another point, by flipping a coin as you suggest > based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability > of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you > keep relying on the server, thus increasing the average response time. > Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes > to remove bad entries may be a better approach. I'm not saying that this is a bad > cache replacement scheme yet but I'll think about this tomorrow. > > > -Govind. > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 12:23:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03249 for ; Fri, 14 Mar 2003 12:23:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHc4O27611; Fri, 14 Mar 2003 12:38:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EHbWO27493 for ; Fri, 14 Mar 2003 12:37:32 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03197 for ; Fri, 14 Mar 2003 12:21:59 -0500 (EST) Message-ID: <009801c2ea4e$4ff10760$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 09:22:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hemant, I don't understand. If an attacking MN reports something that is not a GAAP, then sure, maybe it gets some junk, but so what? If the MN wants to be so antisocial, then it gets to deal with the results. As for wireless bandwidth, I assume the wireless network is enforcing the MN's QoS so it only gets the amount of bandwidth it paid for. As for the router, as mentioned in Issue 3 on the issues Web page, the protocol should include a provision for rate limiting and a provision allowing the router to selectively drop packets in order to deal with a spike in service requests. jak ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 7:36 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Thursday, March 13, 2003 6:44 PM > To: kempf@docomolabs-usa.com; Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > > > > I'm not sure I understand the attack. > > > > If an attacker sends a completely bogus AP, the AR compares > > against the AAPL > > (Authorized AP List) and rejects. > > If an attacker sends an AP that is not bogus but is not a > > GAAP, then it will > > pass the AAPL test but it will remain in the cache for one > > iteration and be > > flushed aftewards. > [Govind] This is assuming a particular cache replacement policy and assumes > the server approach. I think we should first settle whether the server is needed > or not before coming to cache contamination and other cache related issues. > However, if we are not going to do that, then we should propose how any > scheme involving protecting the cache works in either of the proposed solutions. > > > > So, I don't see how interrouter capability and update > > exchange are affected. > [Govind] First thoughts about this cache replacement policy. I will think about this replacement > policy more later.. Its been a long day already, so sorry if I'm wrong :) > > If the number of malicious MNs increase, then wouldn't you have an increase of the number > of entries? Also, they might not be removed from the cache. More such entries and more > the unnecessary capability messages. Note, if we are using the server scheme, each MN has > the possibility of reporting a large number of such non-GAAPs. Consider this scenario, > 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that > each AP is assigned to a different AR. Further assume that > you have a limit of 100 reports per MN. In your scheme, the chance > of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of > non GAARs are in the cache after each flush. So the current AR will communicate > unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities > exchanged you do have an unnecessary burden on the ARs. You will never be able > to detect this and yet keep exchanging messages between non-CARs. > > Another point, by flipping a coin as you suggest > based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability > of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you > keep relying on the server, thus increasing the average response time. > Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes > to remove bad entries may be a better approach. I'm not saying that this is a bad > cache replacement scheme yet but I'll think about this tomorrow. > > > -Govind. > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 13:01:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04193 for ; Fri, 14 Mar 2003 13:01:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EIGVY29952 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 13:16:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIGVO29949 for ; Fri, 14 Mar 2003 13:16:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04180 for ; Fri, 14 Mar 2003 13:00:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIGGO29936; Fri, 14 Mar 2003 13:16:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIFIO29902 for ; Fri, 14 Mar 2003 13:15:18 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04135 for ; Fri, 14 Mar 2003 12:59:46 -0500 (EST) Message-ID: <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 10:00:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eunsoo, So as I understand your argument: 1) How the cache gets filled is irrelevent to the router to node CARD, 2) How the router authorizes what is an authorized GAAP or not is irrelevent to the router to node CARD. Is that right? If so, I accept your argument. Furthermore, I would add: 3) How a router determines what is and is not an *authorized* GAAP is intimately intertwined with what is or is not a GAAP, since a GAAP that is not on the AAPL MUST not be used by the router. This will differ depending on the deployment situation. For example, in my home network, I want to be able to use a Web page to configure the routers with a list of authorized GAAPs, and not have to use a server *or* not have to deal with PNE messages flying around my network. On the other hand, operators like Docomo want to have easy centralized managment of many APs and ARs, so a server. Enterprise networks might want to have easy self configuration, so Dycard's PNE messages. Like Xiaoming said, the configuration information can come from anywhere. This suggests splitting the protocol into to separate parts: 1) A router to node protocol that provides an MN with CARD information and allows the MN to report potential GAAPs, 2) Configuration and validation of authorized GAAPs. How 2) is done can be the subject of a separate specification. This is the point of Issue 2, Proposal 2, but perhaps we should separate this out into a different issue. jak ----- Original Message ----- From: "Eunsoo Shim" To: "Xiaoming Wang" ; "James Kempf" ; "Daichi Funato" ; Sent: Friday, March 14, 2003 11:40 AM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > So far, what I heard about the necessity of the server for CARD were two > things: > 1) Initial population of the cache > 2) AP authorization > > 1) Initial population of the cache > There are lots of arguments about whether we really need such initial > population of the cache. Personally I doubt the need. > Anyway, as Xiaoming and other folks already pointed out, if it is really > necessary, such initial population can be done using any existing management > tool. We don't need to reinvent the wheel for initial router configuration. > That is, we don't need to introduce any server or protocol for that. > > 2) AP authorization > AP authorization is a very general problem. I think this should be handled > separately from CARD. How AP should be authorized is a L2 issue and thus is > not even in the scope of the IETF. We cannot devise a general protocol based > on IP for AP-AR since such communication depends on the L2 technology and we > cannot assume IP between AP and AR. What we can do is we assume each AR > knows the list of APs associated with it. Such information can be configured > at each AR also using any existing management tool. Thus again, I don't > think we need to introduce the server of the DT draft for this purpose > either. > > Was there any other item as the necessity of the server for CARD? > Or does anyone want to propose anything else? > > Eunsoo > > ----- Original Message ----- > From: "Xiaoming Wang" > To: "James Kempf" ; "Daichi Funato" > ; > Sent: Thursday, March 13, 2003 8:49 PM > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > James, > > > > > > [xiaoming] I think this can be improved by static configuration at the > > > > initial stage. Initial data can be computed with the geographical and > > > > topological information of access network, which is used during > > > the network > > > > planning and construction stage. Based on it, learning-based > > > approach will > > > > not experience failure at the initial stage and will learn by itself > > > > dynamically when there is a change of the topology of the > > > access network, > > > > and thus performs well at any time. > > > > > > > > > > Where does the router get the static information from? > > > > > > > These static information can be defined as profile for configuation, which > > can be maitained by management entity. It is as natural as initial > > configuration of routing table from some predefined information. > > > > xiaoming > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 13:01:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04206 for ; Fri, 14 Mar 2003 13:01:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIGGO29936; Fri, 14 Mar 2003 13:16:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIFIO29902 for ; Fri, 14 Mar 2003 13:15:18 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04135 for ; Fri, 14 Mar 2003 12:59:46 -0500 (EST) Message-ID: <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Fri, 14 Mar 2003 10:00:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eunsoo, So as I understand your argument: 1) How the cache gets filled is irrelevent to the router to node CARD, 2) How the router authorizes what is an authorized GAAP or not is irrelevent to the router to node CARD. Is that right? If so, I accept your argument. Furthermore, I would add: 3) How a router determines what is and is not an *authorized* GAAP is intimately intertwined with what is or is not a GAAP, since a GAAP that is not on the AAPL MUST not be used by the router. This will differ depending on the deployment situation. For example, in my home network, I want to be able to use a Web page to configure the routers with a list of authorized GAAPs, and not have to use a server *or* not have to deal with PNE messages flying around my network. On the other hand, operators like Docomo want to have easy centralized managment of many APs and ARs, so a server. Enterprise networks might want to have easy self configuration, so Dycard's PNE messages. Like Xiaoming said, the configuration information can come from anywhere. This suggests splitting the protocol into to separate parts: 1) A router to node protocol that provides an MN with CARD information and allows the MN to report potential GAAPs, 2) Configuration and validation of authorized GAAPs. How 2) is done can be the subject of a separate specification. This is the point of Issue 2, Proposal 2, but perhaps we should separate this out into a different issue. jak ----- Original Message ----- From: "Eunsoo Shim" To: "Xiaoming Wang" ; "James Kempf" ; "Daichi Funato" ; Sent: Friday, March 14, 2003 11:40 AM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > So far, what I heard about the necessity of the server for CARD were two > things: > 1) Initial population of the cache > 2) AP authorization > > 1) Initial population of the cache > There are lots of arguments about whether we really need such initial > population of the cache. Personally I doubt the need. > Anyway, as Xiaoming and other folks already pointed out, if it is really > necessary, such initial population can be done using any existing management > tool. We don't need to reinvent the wheel for initial router configuration. > That is, we don't need to introduce any server or protocol for that. > > 2) AP authorization > AP authorization is a very general problem. I think this should be handled > separately from CARD. How AP should be authorized is a L2 issue and thus is > not even in the scope of the IETF. We cannot devise a general protocol based > on IP for AP-AR since such communication depends on the L2 technology and we > cannot assume IP between AP and AR. What we can do is we assume each AR > knows the list of APs associated with it. Such information can be configured > at each AR also using any existing management tool. Thus again, I don't > think we need to introduce the server of the DT draft for this purpose > either. > > Was there any other item as the necessity of the server for CARD? > Or does anyone want to propose anything else? > > Eunsoo > > ----- Original Message ----- > From: "Xiaoming Wang" > To: "James Kempf" ; "Daichi Funato" > ; > Sent: Thursday, March 13, 2003 8:49 PM > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > James, > > > > > > [xiaoming] I think this can be improved by static configuration at the > > > > initial stage. Initial data can be computed with the geographical and > > > > topological information of access network, which is used during > > > the network > > > > planning and construction stage. Based on it, learning-based > > > approach will > > > > not experience failure at the initial stage and will learn by itself > > > > dynamically when there is a change of the topology of the > > > access network, > > > > and thus performs well at any time. > > > > > > > > > > Where does the router get the static information from? > > > > > > > These static information can be defined as profile for configuation, which > > can be maitained by management entity. It is as natural as initial > > configuration of routing table from some predefined information. > > > > xiaoming > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 13:03:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04262 for ; Fri, 14 Mar 2003 13:03:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EIIEg30027 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 13:18:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIIEO30024 for ; Fri, 14 Mar 2003 13:18:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04253 for ; Fri, 14 Mar 2003 13:02:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EII2O30010; Fri, 14 Mar 2003 13:18:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIHUO29978 for ; Fri, 14 Mar 2003 13:17:30 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04220 for ; Fri, 14 Mar 2003 13:01:58 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EI46802395 for ; Fri, 14 Mar 2003 12:04:07 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 12:04:06 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 12:03:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:03:17 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqTcFEztjs5OWoQdCGEL0w53z+NgAAaeOw To: , , , X-OriginalArrivalTime: 14 Mar 2003 18:03:18.0278 (UTC) FILETIME=[FDE76260:01C2EA53] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EIHUO29979 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, > Govind, > > I'm not convinced Dycard would do any better. [Govind] The discussion in this thread had nothing to do with dycard. It was discussing the cache management scheme you had proposed w.r.t to its applicability as a cache management scheme for the DT draft. I was merely pointing out that it has significant problems when used in conjunction with the DT draft as it is now. > > As the number of malicious MNs increases, the number of PNE > messages will > increase. Thus, the load on the routers increases in any > event. [Govind] I think you should read some of the old threads, where I have pointed out how this can be handled. In short, we restrict entries per MN, identified by its identity. Second, if an MN sends more than one RI message it is clearly malicious and not the case with a MN sending more than one APids as I have pointed out in my example in a previous email. Note, I am not saying that you don't have to handle case of cache contamination in dycard, I am just saying it can be handled differently and even the scheme that you proposed may work better with dycard than with the DT scheme, but I haven't analysed it yet. The simple logic in dycard, using my previous example, is that if you have 10 colluding malicious MNs you would be able to create at max [10* (limit on entries per MN)] in the cache by sending RIs. In our simulations, if you have a large number of MNs (which is there anyways) in the system, limiting to just one entry per MN is quite good. The MNs would have to be able to show that they handed over from non-CARs. This is quite difficult to achieve rather than how you populate caches in the DT scheme, IMO. I think we are going in circles, as this was pointed out previously too. If you read the draft carefully and you don't think this has been explained well then we are willing to address that and make it clearer. If there are > several millions of malicious MNs bombarding the router with > RM messages, the > backhaul will fill with PNE messages as far as I can tell. [Govind] RM messages don't launch PNEs. I > assume Dycard is > using a cache for confirmed APs also, so that no PNE message > would be sent if > the RM resulted in a hit with a known, good GAAP. Or am I > misunderstanding how > Dycard works? [Govind] I think you have a misunderstanding on how dycard works. PNE messages are sent based on new AR reports in RI messages, provided the limit is not reached for the reporting MN. PNEs have nothing to do with APs. > > You mentioned previously you had done a simulation on this. > Could you or another > of the Dyhard Dycard Team provide some information about what > the numbers look > like, or a URL to a published paper? [Govind] A paper is under review. I don't think I can make a decision on my own to put it on a webpage. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 13:03:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04300 for ; Fri, 14 Mar 2003 13:03:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EII2O30010; Fri, 14 Mar 2003 13:18:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIHUO29978 for ; Fri, 14 Mar 2003 13:17:30 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04220 for ; Fri, 14 Mar 2003 13:01:58 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EI46802395 for ; Fri, 14 Mar 2003 12:04:07 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 12:04:06 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 12:03:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:03:17 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqTcFEztjs5OWoQdCGEL0w53z+NgAAaeOw To: , , , X-OriginalArrivalTime: 14 Mar 2003 18:03:18.0278 (UTC) FILETIME=[FDE76260:01C2EA53] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EIHUO29979 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, > Govind, > > I'm not convinced Dycard would do any better. [Govind] The discussion in this thread had nothing to do with dycard. It was discussing the cache management scheme you had proposed w.r.t to its applicability as a cache management scheme for the DT draft. I was merely pointing out that it has significant problems when used in conjunction with the DT draft as it is now. > > As the number of malicious MNs increases, the number of PNE > messages will > increase. Thus, the load on the routers increases in any > event. [Govind] I think you should read some of the old threads, where I have pointed out how this can be handled. In short, we restrict entries per MN, identified by its identity. Second, if an MN sends more than one RI message it is clearly malicious and not the case with a MN sending more than one APids as I have pointed out in my example in a previous email. Note, I am not saying that you don't have to handle case of cache contamination in dycard, I am just saying it can be handled differently and even the scheme that you proposed may work better with dycard than with the DT scheme, but I haven't analysed it yet. The simple logic in dycard, using my previous example, is that if you have 10 colluding malicious MNs you would be able to create at max [10* (limit on entries per MN)] in the cache by sending RIs. In our simulations, if you have a large number of MNs (which is there anyways) in the system, limiting to just one entry per MN is quite good. The MNs would have to be able to show that they handed over from non-CARs. This is quite difficult to achieve rather than how you populate caches in the DT scheme, IMO. I think we are going in circles, as this was pointed out previously too. If you read the draft carefully and you don't think this has been explained well then we are willing to address that and make it clearer. If there are > several millions of malicious MNs bombarding the router with > RM messages, the > backhaul will fill with PNE messages as far as I can tell. [Govind] RM messages don't launch PNEs. I > assume Dycard is > using a cache for confirmed APs also, so that no PNE message > would be sent if > the RM resulted in a hit with a known, good GAAP. Or am I > misunderstanding how > Dycard works? [Govind] I think you have a misunderstanding on how dycard works. PNE messages are sent based on new AR reports in RI messages, provided the limit is not reached for the reporting MN. PNEs have nothing to do with APs. > > You mentioned previously you had done a simulation on this. > Could you or another > of the Dyhard Dycard Team provide some information about what > the numbers look > like, or a URL to a published paper? [Govind] A paper is under review. I don't think I can make a decision on my own to put it on a webpage. -Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 13:08:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04431 for ; Fri, 14 Mar 2003 13:08:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EINI230249 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 13:23:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EINIO30246 for ; Fri, 14 Mar 2003 13:23:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04426 for ; Fri, 14 Mar 2003 13:07:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIN2O30227; Fri, 14 Mar 2003 13:23:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIM1O30201 for ; Fri, 14 Mar 2003 13:22:01 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04376 for ; Fri, 14 Mar 2003 13:06:28 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 13:08:38 -0500 Message-ID: <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:09:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 18:08:38.0520 (UTC) FILETIME=[BCC86F80:01C2EA54] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think we should distinguish two things. 1) Whether the proposed mechanism can filter out false information from MN and thus prevent cache contamination. 2) What is the impact of malicious MN's bombarding AR with false information. The first topic is the main thing of this thread. I think the server approach cannot filter out false information or prevent cache contamination. I think Dycard can make cache contamination very difficult. The second topic is more related to DoS attack. We talked about it already. In Dycard, if the AR can know about MN's handoff events, it can limit MN's report as one per handoff. If not, we need rate limiting. In the server approach, we need rate limiting. In the case of the sever approach, if there is a bogus AP (unauthorized AP) transmitting different beacons continuously, MN will lose the chance to report the L2 address of an authorized AP under the rate limiting policy. Anyway I think we should stick to the first topic in this thread and put the second topic in the DoS attack thread. Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; ; Sent: Friday, March 14, 2003 9:16 AM Subject: Re: [SeaMoby] Topic #3: Cache contamination > Govind, > > I'm not convinced Dycard would do any better. > > As the number of malicious MNs increases, the number of PNE messages will > increase. Thus, the load on the routers increases in any event. If there are > several millions of malicious MNs bombarding the router with RM messages, the > backhaul will fill with PNE messages as far as I can tell. I assume Dycard is > using a cache for confirmed APs also, so that no PNE message would be sent if > the RM resulted in a hit with a known, good GAAP. Or am I misunderstanding how > Dycard works? > > You mentioned previously you had done a simulation on this. Could you or another > of the Dyhard Dycard Team provide some information about what the numbers look > like, or a URL to a published paper? > > jak > > ----- Original Message ----- > From: > To: ; ; > ; > Sent: Friday, March 14, 2003 7:19 AM > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > > James, > > > > > > [snip] > > > Why do you say it assumes the server approach? The AAPL could > > > be programmed into > > > the router through a Web page. It doesn't have to come from a > > > server. Something > > > like the AAPL will even be needed in Dycard, else how does a > > > router know that an > > > access point connected to it is authorized? > > > > > [Govind] This is because the cache population schemes are different in the > schemes. Therefore, > > the effectiveness of any cache contamination scheme is different. > > > > [snip] > > > Right, the assumption here is that the probability of an > > > attack decreases > > > according to the number of MNs involved. Remember, for an MN > > > to even get on the > > > link, it must be auth/authz-ed. So, multiple MNs means a > > > bunch of the operator's > > > authorized customers decided to get together and attack. > > > Maybe not such a > > > completely outlandish idea these days, but a much lower > > > probablity event than > > > one lone customer who is having a bad day and decides to > > > cause some mischief. > > > > [Govind] I agree that the probability of more than one malicious user is > lesser than one malicious user. > > However, if this is an inherent deficiency in a scheme that protects the > protocol, > > then I believe in no time will more there be more than one hacker trying to > bring down the system. > > > > > > > > >Also, they might not be removed from the cache. More such > > > entries and more > > > > the unnecessary capability messages. Note, if we are using > > > the server scheme, > > > each MN has > > > > the possibility of reporting a large number of such non-GAAPs. > > > > > > Why do you assume the server scheme? The cache state would > > > need to be timed out > > > for Dycard as well. > > > > > [Govind] Because you have talked about adding cache entries based on APs > > sent in by the MN. > > > > > >Consider this scenario, > > > > 10 malicious MNs each report say 100 genuine non-GAAPs. > > > > > > If I, as an operator, have 10 malicious customers, then I'm > > > pretty bad off. > > > After that attack, they get their service cancelled forthwith. > > [Govind] There is no way you can recognize the fact that they are > > doing something malicious as they are reporting APs that > > are valid and authorized. > > > > > > > > OK, so its a hundred. How big is a cache entry? Let's be > > > conservative and say > > > it's 1K (actually, it's probably a lot smaller). that's still > > > only 100K. Given > > > Moore's law, that costs nothing. > > [Govind] You have no control on what the cache size is yet. This depends on > > what capabilities are transferred, and their respective sizes. But > > cache size is not the attack, increase in inter-AR communication > > and subsequent processing is the problem. > > > > > > > > The point is, it's not a million. The attack becomes less > > > probable and easier to > > > detect the more entries. > > > > > [Govind] My point is even a 100 depending what capabilities are > > is a lot of unnecessary processing. Remember, the ARs are not there just for > CARD > > They are involved in other work too. > > > > > It is all a matter of matching the threat. The highest > > > probability threat, in > > > this case, is a single MN having a bad day and deciding to > > > try some mischief. > > > Now if an average MN reports, say 2 or three APs and suddenly > > > the router starts > > > to get a report of 100, it knows something is amiss. > > [Govind] The number of legal APs (including those from other domains) that a > > MN reports depends on the size of the "cell" as well as the population of APs > of > > other operators. By making > > an unnecessary restriction on the number of APs we are just compromising > > the protocol needlessly. > > > > If 10 > > > MNs each start > > > reporting 100, it's time to call the Department of Homeland > > > Security. :-) > > > > [Govind] Since you can't control the number of legal APs around, any > ratelimiting > > has to be set to a resonably high number (whatever that may be). Otherwise, > > you stand a chance of MNs just reporting APs out of your domain and the > network > > rejecting the its own AP info sent in by the MN. Thats why I said initially > that > > ratelimiting in the server based scheme is more difficult. > > > > [Govind] > > > Sure. There are always false positives. But typically any one > > > GAAP will be seen > > > by more than one MN. And, there are other ways to reduce the > > > probability of > > > flushing good entries, for example, using a weighed moving > > > average of reports. > > [Govind] Clearly this fails as the number of malicious MNs increase. > > > > -Govind > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 13:08:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04445 for ; Fri, 14 Mar 2003 13:08:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIN2O30227; Fri, 14 Mar 2003 13:23:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIM1O30201 for ; Fri, 14 Mar 2003 13:22:01 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04376 for ; Fri, 14 Mar 2003 13:06:28 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 13:08:38 -0500 Message-ID: <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:09:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 18:08:38.0520 (UTC) FILETIME=[BCC86F80:01C2EA54] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think we should distinguish two things. 1) Whether the proposed mechanism can filter out false information from MN and thus prevent cache contamination. 2) What is the impact of malicious MN's bombarding AR with false information. The first topic is the main thing of this thread. I think the server approach cannot filter out false information or prevent cache contamination. I think Dycard can make cache contamination very difficult. The second topic is more related to DoS attack. We talked about it already. In Dycard, if the AR can know about MN's handoff events, it can limit MN's report as one per handoff. If not, we need rate limiting. In the server approach, we need rate limiting. In the case of the sever approach, if there is a bogus AP (unauthorized AP) transmitting different beacons continuously, MN will lose the chance to report the L2 address of an authorized AP under the rate limiting policy. Anyway I think we should stick to the first topic in this thread and put the second topic in the DoS attack thread. Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; ; Sent: Friday, March 14, 2003 9:16 AM Subject: Re: [SeaMoby] Topic #3: Cache contamination > Govind, > > I'm not convinced Dycard would do any better. > > As the number of malicious MNs increases, the number of PNE messages will > increase. Thus, the load on the routers increases in any event. If there are > several millions of malicious MNs bombarding the router with RM messages, the > backhaul will fill with PNE messages as far as I can tell. I assume Dycard is > using a cache for confirmed APs also, so that no PNE message would be sent if > the RM resulted in a hit with a known, good GAAP. Or am I misunderstanding how > Dycard works? > > You mentioned previously you had done a simulation on this. Could you or another > of the Dyhard Dycard Team provide some information about what the numbers look > like, or a URL to a published paper? > > jak > > ----- Original Message ----- > From: > To: ; ; > ; > Sent: Friday, March 14, 2003 7:19 AM > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > > James, > > > > > > [snip] > > > Why do you say it assumes the server approach? The AAPL could > > > be programmed into > > > the router through a Web page. It doesn't have to come from a > > > server. Something > > > like the AAPL will even be needed in Dycard, else how does a > > > router know that an > > > access point connected to it is authorized? > > > > > [Govind] This is because the cache population schemes are different in the > schemes. Therefore, > > the effectiveness of any cache contamination scheme is different. > > > > [snip] > > > Right, the assumption here is that the probability of an > > > attack decreases > > > according to the number of MNs involved. Remember, for an MN > > > to even get on the > > > link, it must be auth/authz-ed. So, multiple MNs means a > > > bunch of the operator's > > > authorized customers decided to get together and attack. > > > Maybe not such a > > > completely outlandish idea these days, but a much lower > > > probablity event than > > > one lone customer who is having a bad day and decides to > > > cause some mischief. > > > > [Govind] I agree that the probability of more than one malicious user is > lesser than one malicious user. > > However, if this is an inherent deficiency in a scheme that protects the > protocol, > > then I believe in no time will more there be more than one hacker trying to > bring down the system. > > > > > > > > >Also, they might not be removed from the cache. More such > > > entries and more > > > > the unnecessary capability messages. Note, if we are using > > > the server scheme, > > > each MN has > > > > the possibility of reporting a large number of such non-GAAPs. > > > > > > Why do you assume the server scheme? The cache state would > > > need to be timed out > > > for Dycard as well. > > > > > [Govind] Because you have talked about adding cache entries based on APs > > sent in by the MN. > > > > > >Consider this scenario, > > > > 10 malicious MNs each report say 100 genuine non-GAAPs. > > > > > > If I, as an operator, have 10 malicious customers, then I'm > > > pretty bad off. > > > After that attack, they get their service cancelled forthwith. > > [Govind] There is no way you can recognize the fact that they are > > doing something malicious as they are reporting APs that > > are valid and authorized. > > > > > > > > OK, so its a hundred. How big is a cache entry? Let's be > > > conservative and say > > > it's 1K (actually, it's probably a lot smaller). that's still > > > only 100K. Given > > > Moore's law, that costs nothing. > > [Govind] You have no control on what the cache size is yet. This depends on > > what capabilities are transferred, and their respective sizes. But > > cache size is not the attack, increase in inter-AR communication > > and subsequent processing is the problem. > > > > > > > > The point is, it's not a million. The attack becomes less > > > probable and easier to > > > detect the more entries. > > > > > [Govind] My point is even a 100 depending what capabilities are > > is a lot of unnecessary processing. Remember, the ARs are not there just for > CARD > > They are involved in other work too. > > > > > It is all a matter of matching the threat. The highest > > > probability threat, in > > > this case, is a single MN having a bad day and deciding to > > > try some mischief. > > > Now if an average MN reports, say 2 or three APs and suddenly > > > the router starts > > > to get a report of 100, it knows something is amiss. > > [Govind] The number of legal APs (including those from other domains) that a > > MN reports depends on the size of the "cell" as well as the population of APs > of > > other operators. By making > > an unnecessary restriction on the number of APs we are just compromising > > the protocol needlessly. > > > > If 10 > > > MNs each start > > > reporting 100, it's time to call the Department of Homeland > > > Security. :-) > > > > [Govind] Since you can't control the number of legal APs around, any > ratelimiting > > has to be set to a resonably high number (whatever that may be). Otherwise, > > you stand a chance of MNs just reporting APs out of your domain and the > network > > rejecting the its own AP info sent in by the MN. Thats why I said initially > that > > ratelimiting in the server based scheme is more difficult. > > > > [Govind] > > > Sure. There are always false positives. But typically any one > > > GAAP will be seen > > > by more than one MN. And, there are other ways to reduce the > > > probability of > > > flushing good entries, for example, using a weighed moving > > > average of reports. > > [Govind] Clearly this fails as the number of malicious MNs increase. > > > > -Govind > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 13:27:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04847 for ; Fri, 14 Mar 2003 13:27:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EIgG731682 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 13:42:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIgGO31679 for ; Fri, 14 Mar 2003 13:42:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04843 for ; Fri, 14 Mar 2003 13:26:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIg5O31669; Fri, 14 Mar 2003 13:42:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIfUO31650 for ; Fri, 14 Mar 2003 13:41:30 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04821 for ; Fri, 14 Mar 2003 13:25:57 -0500 (EST) Message-ID: <00ee01c2ea57$3eb6b1d0$286015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD Issues List Date: Fri, 14 Mar 2003 10:26:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Issue 1: You haven't mentioned the general WG opinion (including people from the DT) > that this issue is out of scope. We may be dealing with non-IP addressable devices here of > different technologies, and as pointed out by a slew of email, > and that there are existing methods to take care of this. > I haven't heard any general WG opinion. I've heard opinions from you and Dirk. Anyone else want to give an opinon? I'd especially like to hear from someone not on the Dyhard Dycard Team or the DT. > So would this be a good statement for an alternative proposal for Issue 1? OK, I will add it. > Proposal 2: Problem is important, but is out-of-scope of CARD. We > can use the following statement in the final spec. The operator/ISP MUST > provide an authorized list of AP beacons that can be attached to each AR. > I'll add that as another proposal. Note: I suspect that whatever opinion the WG has, it will ultimately be the opinion of the Security DAs that will prevail. :-) > Issue 2: > Proposal 2: If you remove the server from the base draft, how is this base draft > going to address the AP-AR mapping. This is not clear to me. > Maybe I'm missing something. > Static configuration, PNE message exchange as in Dycard draft, or a server. Out of scope for the AR to MN protocol. There only needs to be one feasible way, and static configuration will always provide that. > Issue 3: Though I'm not against putting explicit text in, > I don't think explicit text is necessary. If the "cache protection" scheme > is designed well this kind of rate limiting will automatically happen. Rate limiting > may be difficult when used in the DT scheme, as MNs may report APs from other domains. > Govind, IETF protocols typically have this kind of rate limiting text in them. Look at RFC 2461, pg. 47 for example, where rate limiting of RS in IPv6 Neighbor Discovery is discussed. Or RFC 2608, pg. 41 for how SLP rate limits UDP for reliable unicast transport. If we don't put this in, the IESG is going to throw the draft back in our faces. > Issue 4: > Proposal 2: Apart from what is written, this should be added to the > proposal. The scheme also uses a third party verified unique MN id and > tags it with each cache entry. The number of cache entries created > per MN is this limited. > Done. I also added a reference to the Dycard draft and the DT draft for Proposal 1. > Proposal 3: I have illustrated the problems associated with Proposal 3. This is not > very secure against attacks by multiple malicious MNs, particularly when used > in conjunction with the DT approach. I haven't looked at the proposal's efficiency > when used with the cache population scheme described in dycard. I think > Proposal 2 works fine with dycard and we don't need proposal 3. > I've done the same with Dycard. Let's let the WG decide. > > Issue 5: > Again, I think the points raised in the mailing list are missing here. > I think we shouldn't really do what is being proposed here. I think CARD is not > just for FMIPv6. > > That's your opinion. The opinion of the rest of the WG is also of interest, but, ultimately, the ADs will have the final say since they're the managers. > Issues 6 - 9: > These issues may not exist when you have finished tackling prior issues. > > Apart from these issues, here is an issue that was brought up in the mailing list: > > Issue 12: Non-conformance with Requirement that deals with ARs with private > and site-local addresses: > DT draft currently does not address this. > > Proposal: One possible approach is presented in dycard. > Spell it out, please. It is not obvious to me that the DT draft doesn't deal with site-locals, nor that the Dycard draft does. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 13:28:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04888 for ; Fri, 14 Mar 2003 13:28:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIg5O31669; Fri, 14 Mar 2003 13:42:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EIfUO31650 for ; Fri, 14 Mar 2003 13:41:30 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04821 for ; Fri, 14 Mar 2003 13:25:57 -0500 (EST) Message-ID: <00ee01c2ea57$3eb6b1d0$286015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD Issues List Date: Fri, 14 Mar 2003 10:26:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Issue 1: You haven't mentioned the general WG opinion (including people from the DT) > that this issue is out of scope. We may be dealing with non-IP addressable devices here of > different technologies, and as pointed out by a slew of email, > and that there are existing methods to take care of this. > I haven't heard any general WG opinion. I've heard opinions from you and Dirk. Anyone else want to give an opinon? I'd especially like to hear from someone not on the Dyhard Dycard Team or the DT. > So would this be a good statement for an alternative proposal for Issue 1? OK, I will add it. > Proposal 2: Problem is important, but is out-of-scope of CARD. We > can use the following statement in the final spec. The operator/ISP MUST > provide an authorized list of AP beacons that can be attached to each AR. > I'll add that as another proposal. Note: I suspect that whatever opinion the WG has, it will ultimately be the opinion of the Security DAs that will prevail. :-) > Issue 2: > Proposal 2: If you remove the server from the base draft, how is this base draft > going to address the AP-AR mapping. This is not clear to me. > Maybe I'm missing something. > Static configuration, PNE message exchange as in Dycard draft, or a server. Out of scope for the AR to MN protocol. There only needs to be one feasible way, and static configuration will always provide that. > Issue 3: Though I'm not against putting explicit text in, > I don't think explicit text is necessary. If the "cache protection" scheme > is designed well this kind of rate limiting will automatically happen. Rate limiting > may be difficult when used in the DT scheme, as MNs may report APs from other domains. > Govind, IETF protocols typically have this kind of rate limiting text in them. Look at RFC 2461, pg. 47 for example, where rate limiting of RS in IPv6 Neighbor Discovery is discussed. Or RFC 2608, pg. 41 for how SLP rate limits UDP for reliable unicast transport. If we don't put this in, the IESG is going to throw the draft back in our faces. > Issue 4: > Proposal 2: Apart from what is written, this should be added to the > proposal. The scheme also uses a third party verified unique MN id and > tags it with each cache entry. The number of cache entries created > per MN is this limited. > Done. I also added a reference to the Dycard draft and the DT draft for Proposal 1. > Proposal 3: I have illustrated the problems associated with Proposal 3. This is not > very secure against attacks by multiple malicious MNs, particularly when used > in conjunction with the DT approach. I haven't looked at the proposal's efficiency > when used with the cache population scheme described in dycard. I think > Proposal 2 works fine with dycard and we don't need proposal 3. > I've done the same with Dycard. Let's let the WG decide. > > Issue 5: > Again, I think the points raised in the mailing list are missing here. > I think we shouldn't really do what is being proposed here. I think CARD is not > just for FMIPv6. > > That's your opinion. The opinion of the rest of the WG is also of interest, but, ultimately, the ADs will have the final say since they're the managers. > Issues 6 - 9: > These issues may not exist when you have finished tackling prior issues. > > Apart from these issues, here is an issue that was brought up in the mailing list: > > Issue 12: Non-conformance with Requirement that deals with ARs with private > and site-local addresses: > DT draft currently does not address this. > > Proposal: One possible approach is presented in dycard. > Spell it out, please. It is not obvious to me that the DT draft doesn't deal with site-locals, nor that the Dycard draft does. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:12:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09046 for ; Fri, 14 Mar 2003 14:12:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJRix01988 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 14:27:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJRiO01985 for ; Fri, 14 Mar 2003 14:27:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08980 for ; Fri, 14 Mar 2003 14:12:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJRPO01957; Fri, 14 Mar 2003 14:27:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJPtO01873 for ; Fri, 14 Mar 2003 14:25:55 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08876 for ; Fri, 14 Mar 2003 14:10:21 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2EJCL128001; Fri, 14 Mar 2003 11:12:29 -0800 (PST) Message-ID: <3E722934.5060102@cs.ucsb.edu> Date: Fri, 14 Mar 2003 11:10:44 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> In-Reply-To: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, > You mentioned previously you had done a simulation on this. Could you > or another of the Dyhard Dycard Team provide some information about > what the numbers look like, or a URL to a published paper? > The simulations we did weren't concerning the security aspects of the protocol. Rather, we were looking at the advantages of using higher-level info (capabilities) to improve handover performance. We also looked at how well the learning-based scheme performed in relation to the rate of handovers, the probability of errors, etc. At this point I'm not comfortable with releasing the paper publically since we just submitted it to a conference for review. enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:12:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09062 for ; Fri, 14 Mar 2003 14:12:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJRlK02007 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 14:27:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJRlO02004 for ; Fri, 14 Mar 2003 14:27:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08987 for ; Fri, 14 Mar 2003 14:12:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJRKO01937; Fri, 14 Mar 2003 14:27:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJPnO01853 for ; Fri, 14 Mar 2003 14:25:49 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08868 for ; Fri, 14 Mar 2003 14:10:14 -0500 (EST) Message-ID: <014501c2ea5d$6e101100$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 11:10:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Govind, Metacomment: I am trying to understand Dycard, as, I presume, are others in the WG. If you and the rest of your team want it or features of it to be included in the protocol (which is why, I presume, you are arguing so strongly against the DT draft) then you need to help us understand it. It is not helpful or constructive to criticize someone else's work without providing a alternative. From my reading of the Dycard draft, there may be some useful features in it, we need to have the working group understand those. Now, on to specific comments. > [Govind] I think you should read some of the old threads, where I have I did. Like I said yesterday, it was like a rugby match. Not very enlightening. :-) > pointed out how this can be handled. In short, we restrict entries per MN, > identified by its identity. Second, if an MN sends more than one RI message > it is clearly malicious and not the case with a MN sending more than one > APids as I have pointed out in my example in a previous email. Note, > I am not saying that you don't have to handle case of cache contamination > in dycard, I am just saying it can be handled differently and even the scheme > that you proposed may work better with dycard than with the DT scheme, but > I haven't analysed it yet. The simple logic in dycard, using my previous example, > is that if you have 10 colluding > malicious MNs you would be able to create at max [10* (limit on entries per MN)] in the cache by > sending RIs. > In our simulations, if you have a large number of MNs (which is there anyways) in the > system, limiting to just one entry per MN is quite good. > The MNs would have to be able to show that they handed over from non-CARs. > This is quite difficult to achieve rather than how you populate caches in the > DT scheme, IMO. I think we are going in circles, as this was pointed out previously too. If you read > the draft carefully and you don't think this has been explained well then we are willing to > address that and make it clearer. > So why can't the server scheme limit the number of entries per MN? Limiting the number of entries per MN has nothing to do with the back end, where the router finds out what is an authorized GAAP, which is where Dycard and the server scheme differ as I understand it. It has to do with the front end, where the router decides what to do with an incoming message. > If there are > > several millions of malicious MNs bombarding the router with > > RM messages, the > > backhaul will fill with PNE messages as far as I can tell. > > [Govind] RM messages don't launch PNEs. > > I I see from the draft that it is the RI message that launches PNE, my bad. Now, please tell me why an MN can't bombard the router with RI messages? The router can rate limit, as you mention above but, in your comments on the Issues, you said that you didn't think rate limiting was an issue, so...? Is rate limiting important or isn't it? I'm confused. > > assume Dycard is > > using a cache for confirmed APs also, so that no PNE message > > would be sent if > > the RM resulted in a hit with a known, good GAAP. Or am I > > misunderstanding how > > Dycard works? > > [Govind] I think you have a misunderstanding on how dycard works. > PNE messages are sent > based on new AR reports in RI messages, provided the limit is not reached for the > reporting MN. PNEs have nothing to do with APs. > OK. What happens when the limit is reached? Wouldn't a cache (regardless of the timeout policy) be necessary regardless? > > > > You mentioned previously you had done a simulation on this. > > Could you or another > > of the Dyhard Dycard Team provide some information about what > > the numbers look > > like, or a URL to a published paper? > > [Govind] A paper is under review. I don't think I can make a decision on my own to put it on > a webpage. > Fine. Please post a URL when the review is complete, so the WG can have a look. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:13:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09104 for ; Fri, 14 Mar 2003 14:13:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJRPO01957; Fri, 14 Mar 2003 14:27:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJPtO01873 for ; Fri, 14 Mar 2003 14:25:55 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08876 for ; Fri, 14 Mar 2003 14:10:21 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2EJCL128001; Fri, 14 Mar 2003 11:12:29 -0800 (PST) Message-ID: <3E722934.5060102@cs.ucsb.edu> Date: Fri, 14 Mar 2003 11:10:44 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> In-Reply-To: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, > You mentioned previously you had done a simulation on this. Could you > or another of the Dyhard Dycard Team provide some information about > what the numbers look like, or a URL to a published paper? > The simulations we did weren't concerning the security aspects of the protocol. Rather, we were looking at the advantages of using higher-level info (capabilities) to improve handover performance. We also looked at how well the learning-based scheme performed in relation to the rate of handovers, the probability of errors, etc. At this point I'm not comfortable with releasing the paper publically since we just submitted it to a conference for review. enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:13:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09120 for ; Fri, 14 Mar 2003 14:13:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJRKO01937; Fri, 14 Mar 2003 14:27:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJPnO01853 for ; Fri, 14 Mar 2003 14:25:49 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08868 for ; Fri, 14 Mar 2003 14:10:14 -0500 (EST) Message-ID: <014501c2ea5d$6e101100$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 11:10:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Govind, Metacomment: I am trying to understand Dycard, as, I presume, are others in the WG. If you and the rest of your team want it or features of it to be included in the protocol (which is why, I presume, you are arguing so strongly against the DT draft) then you need to help us understand it. It is not helpful or constructive to criticize someone else's work without providing a alternative. From my reading of the Dycard draft, there may be some useful features in it, we need to have the working group understand those. Now, on to specific comments. > [Govind] I think you should read some of the old threads, where I have I did. Like I said yesterday, it was like a rugby match. Not very enlightening. :-) > pointed out how this can be handled. In short, we restrict entries per MN, > identified by its identity. Second, if an MN sends more than one RI message > it is clearly malicious and not the case with a MN sending more than one > APids as I have pointed out in my example in a previous email. Note, > I am not saying that you don't have to handle case of cache contamination > in dycard, I am just saying it can be handled differently and even the scheme > that you proposed may work better with dycard than with the DT scheme, but > I haven't analysed it yet. The simple logic in dycard, using my previous example, > is that if you have 10 colluding > malicious MNs you would be able to create at max [10* (limit on entries per MN)] in the cache by > sending RIs. > In our simulations, if you have a large number of MNs (which is there anyways) in the > system, limiting to just one entry per MN is quite good. > The MNs would have to be able to show that they handed over from non-CARs. > This is quite difficult to achieve rather than how you populate caches in the > DT scheme, IMO. I think we are going in circles, as this was pointed out previously too. If you read > the draft carefully and you don't think this has been explained well then we are willing to > address that and make it clearer. > So why can't the server scheme limit the number of entries per MN? Limiting the number of entries per MN has nothing to do with the back end, where the router finds out what is an authorized GAAP, which is where Dycard and the server scheme differ as I understand it. It has to do with the front end, where the router decides what to do with an incoming message. > If there are > > several millions of malicious MNs bombarding the router with > > RM messages, the > > backhaul will fill with PNE messages as far as I can tell. > > [Govind] RM messages don't launch PNEs. > > I I see from the draft that it is the RI message that launches PNE, my bad. Now, please tell me why an MN can't bombard the router with RI messages? The router can rate limit, as you mention above but, in your comments on the Issues, you said that you didn't think rate limiting was an issue, so...? Is rate limiting important or isn't it? I'm confused. > > assume Dycard is > > using a cache for confirmed APs also, so that no PNE message > > would be sent if > > the RM resulted in a hit with a known, good GAAP. Or am I > > misunderstanding how > > Dycard works? > > [Govind] I think you have a misunderstanding on how dycard works. > PNE messages are sent > based on new AR reports in RI messages, provided the limit is not reached for the > reporting MN. PNEs have nothing to do with APs. > OK. What happens when the limit is reached? Wouldn't a cache (regardless of the timeout policy) be necessary regardless? > > > > You mentioned previously you had done a simulation on this. > > Could you or another > > of the Dyhard Dycard Team provide some information about what > > the numbers look > > like, or a URL to a published paper? > > [Govind] A paper is under review. I don't think I can make a decision on my own to put it on > a webpage. > Fine. Please post a URL when the review is complete, so the WG can have a look. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:16:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09359 for ; Fri, 14 Mar 2003 14:16:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJVK502214 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 14:31:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJVKO02211 for ; Fri, 14 Mar 2003 14:31:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09331 for ; Fri, 14 Mar 2003 14:15:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJV4O02201; Fri, 14 Mar 2003 14:31:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJUmO02169 for ; Fri, 14 Mar 2003 14:30:48 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09296 for ; Fri, 14 Mar 2003 14:15:14 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EJHN819442 for ; Fri, 14 Mar 2003 13:17:23 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 13:17:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 13:17:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD Issues List Date: Fri, 14 Mar 2003 14:17:06 -0500 Message-ID: Thread-Topic: [Seamoby] CARD Issues List Thread-Index: AcLqV3vBTRIe1M/LRmuP0wt9OSVEKQABbiZQ To: , X-OriginalArrivalTime: 14 Mar 2003 19:17:07.0881 (UTC) FILETIME=[4E272990:01C2EA5E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EJUmO02170 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > > So would this be a good statement for an alternative > proposal for Issue 1? > > OK, I will add it. [Govind] Thanks. > > Issue 12: Non-conformance with Requirement that deals with > ARs with private > > and site-local addresses: > > DT draft currently does not address this. > > > > Proposal: One possible approach is presented in dycard. > > > > Spell it out, please. It is not obvious to me that the DT > draft doesn't deal > with site-locals, nor that the Dycard draft does. [Govind] Would it suffice to say that one approach is described in section 4.8.5 of the dycard draft? Or do you want me to go into detail? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:16:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09391 for ; Fri, 14 Mar 2003 14:16:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJV4O02201; Fri, 14 Mar 2003 14:31:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJUmO02169 for ; Fri, 14 Mar 2003 14:30:48 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09296 for ; Fri, 14 Mar 2003 14:15:14 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EJHN819442 for ; Fri, 14 Mar 2003 13:17:23 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 13:17:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 13:17:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD Issues List Date: Fri, 14 Mar 2003 14:17:06 -0500 Message-ID: Thread-Topic: [Seamoby] CARD Issues List Thread-Index: AcLqV3vBTRIe1M/LRmuP0wt9OSVEKQABbiZQ To: , X-OriginalArrivalTime: 14 Mar 2003 19:17:07.0881 (UTC) FILETIME=[4E272990:01C2EA5E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EJUmO02170 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > > So would this be a good statement for an alternative > proposal for Issue 1? > > OK, I will add it. [Govind] Thanks. > > Issue 12: Non-conformance with Requirement that deals with > ARs with private > > and site-local addresses: > > DT draft currently does not address this. > > > > Proposal: One possible approach is presented in dycard. > > > > Spell it out, please. It is not obvious to me that the DT > draft doesn't deal > with site-locals, nor that the Dycard draft does. [Govind] Would it suffice to say that one approach is described in section 4.8.5 of the dycard draft? Or do you want me to go into detail? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:18:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09444 for ; Fri, 14 Mar 2003 14:18:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJXOS02315 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 14:33:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJXOO02312 for ; Fri, 14 Mar 2003 14:33:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09417 for ; Fri, 14 Mar 2003 14:17:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJX7O02291; Fri, 14 Mar 2003 14:33:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJWuO02269 for ; Fri, 14 Mar 2003 14:32:56 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09411 for ; Fri, 14 Mar 2003 14:17:21 -0500 (EST) Message-ID: <014b01c2ea5e$6c5e4ce0$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 11:17:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eunsoo, I agree with this separation. > 1) Whether the proposed mechanism can filter out false information from MN > and thus prevent cache contamination. This is Issue 4. I don't like the term "cache contamination" because it is not possible to actually cause a false GAAP to GAAR resolution. The issue is more one of cache sizing and robustness, not one of a failure of the protocol to properly operate. > 2) What is the impact of malicious MN's bombarding AR with false > information. > This is Issue 3. > The first topic is the main thing of this thread. I think the server > approach cannot filter out false information or prevent cache contamination. > I think Dycard can make cache contamination very difficult. > I'll let the DT members comment on this. > The second topic is more related to DoS attack. We talked about it already. > In Dycard, if the AR can know about MN's handoff events, it can limit MN's > report as one per handoff. The AR might not. It doesn't for 802.11, for example. I've moved rate-limiting to a separate thread. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:18:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09464 for ; Fri, 14 Mar 2003 14:18:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJX7O02291; Fri, 14 Mar 2003 14:33:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJWuO02269 for ; Fri, 14 Mar 2003 14:32:56 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09411 for ; Fri, 14 Mar 2003 14:17:21 -0500 (EST) Message-ID: <014b01c2ea5e$6c5e4ce0$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 11:17:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eunsoo, I agree with this separation. > 1) Whether the proposed mechanism can filter out false information from MN > and thus prevent cache contamination. This is Issue 4. I don't like the term "cache contamination" because it is not possible to actually cause a false GAAP to GAAR resolution. The issue is more one of cache sizing and robustness, not one of a failure of the protocol to properly operate. > 2) What is the impact of malicious MN's bombarding AR with false > information. > This is Issue 3. > The first topic is the main thing of this thread. I think the server > approach cannot filter out false information or prevent cache contamination. > I think Dycard can make cache contamination very difficult. > I'll let the DT members comment on this. > The second topic is more related to DoS attack. We talked about it already. > In Dycard, if the AR can know about MN's handoff events, it can limit MN's > report as one per handoff. The AR might not. It doesn't for 802.11, for example. I've moved rate-limiting to a separate thread. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:20:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09534 for ; Fri, 14 Mar 2003 14:20:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJZHS02449 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 14:35:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJZHO02446 for ; Fri, 14 Mar 2003 14:35:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09517 for ; Fri, 14 Mar 2003 14:19:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJZ2O02436; Fri, 14 Mar 2003 14:35:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJYmO02408 for ; Fri, 14 Mar 2003 14:34:48 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09510 for ; Fri, 14 Mar 2003 14:19:15 -0500 (EST) Message-ID: <015301c2ea5e$b0dcf010$286015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 14 Mar 2003 11:19:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Issue 3: DoS Attack Concensus Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So it sounds from Eunsoo's email this morning that we may have concensus on the need for rate limiting. Anybody want to propose some text? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:20:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09555 for ; Fri, 14 Mar 2003 14:20:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJZ2O02436; Fri, 14 Mar 2003 14:35:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJYmO02408 for ; Fri, 14 Mar 2003 14:34:48 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09510 for ; Fri, 14 Mar 2003 14:19:15 -0500 (EST) Message-ID: <015301c2ea5e$b0dcf010$286015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 14 Mar 2003 11:19:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Issue 3: DoS Attack Concensus Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So it sounds from Eunsoo's email this morning that we may have concensus on the need for rate limiting. Anybody want to propose some text? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:25:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09716 for ; Fri, 14 Mar 2003 14:25:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJeRg03508 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 14:40:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJeRO03505 for ; Fri, 14 Mar 2003 14:40:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09707 for ; Fri, 14 Mar 2003 14:24:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJe8O03483; Fri, 14 Mar 2003 14:40:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJdKO03430 for ; Fri, 14 Mar 2003 14:39:20 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09684 for ; Fri, 14 Mar 2003 14:23:46 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2EJQqNw018324 for ; Fri, 14 Mar 2003 12:26:52 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA26261 for ; Fri, 14 Mar 2003 12:25:56 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 13:25:55 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE65@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'James Kempf'" , Eunsoo Shim , Govind.Krishnamurthi@nokia.com, Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:25:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Eunsoo, > The first topic is the main thing of this thread. I think the server > approach cannot filter out false information or prevent cache contamination. > I think Dycard can make cache contamination very difficult. > AJOY->Why not ? I am confused here. Could you please explain why do you think so? Regards, Ajoy _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:25:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09731 for ; Fri, 14 Mar 2003 14:25:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJe8O03483; Fri, 14 Mar 2003 14:40:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJdKO03430 for ; Fri, 14 Mar 2003 14:39:20 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09684 for ; Fri, 14 Mar 2003 14:23:46 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2EJQqNw018324 for ; Fri, 14 Mar 2003 12:26:52 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA26261 for ; Fri, 14 Mar 2003 12:25:56 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 13:25:55 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE65@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'James Kempf'" , Eunsoo Shim , Govind.Krishnamurthi@nokia.com, Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:25:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Eunsoo, > The first topic is the main thing of this thread. I think the server > approach cannot filter out false information or prevent cache contamination. > I think Dycard can make cache contamination very difficult. > AJOY->Why not ? I am confused here. Could you please explain why do you think so? Regards, Ajoy _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:30:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09887 for ; Fri, 14 Mar 2003 14:30:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJjOG03721 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 14:45:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJjNO03718 for ; Fri, 14 Mar 2003 14:45:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09856 for ; Fri, 14 Mar 2003 14:29:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJj4O03686; Fri, 14 Mar 2003 14:45:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJiRO03631 for ; Fri, 14 Mar 2003 14:44:27 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09812 for ; Fri, 14 Mar 2003 14:28:52 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2EJV2103203 for ; Fri, 14 Mar 2003 11:31:02 -0800 (PST) Message-ID: <3E722D95.1050908@cs.ucsb.edu> Date: Fri, 14 Mar 2003 11:29:25 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] updated dyCARD draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I updated the dyCARD draft with a short section indicating that all messages must be rate limited (Section 7.9). The draft is available at http://www.cs.ucsb.edu/~robertc/drafts/draft-trossen-seamoby-dycard-01.txt enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:30:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09929 for ; Fri, 14 Mar 2003 14:30:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJj5O03702; Fri, 14 Mar 2003 14:45:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJj0O03658 for ; Fri, 14 Mar 2003 14:45:00 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09847 for ; Fri, 14 Mar 2003 14:29:26 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 14:31:35 -0500 Message-ID: <024701c2ea79$a5212370$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "'James Kempf'" , , , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE65@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 14:32:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 19:31:35.0880 (UTC) FILETIME=[53854C80:01C2EA60] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > The first topic is the main thing of this thread. I think the server > > approach cannot filter out false information or prevent cache > contamination. > > I think Dycard can make cache contamination very difficult. > > > > AJOY->Why not ? I am confused here. Could you please explain why do you > think so? > In the server approach, MN sends the L2 address of an AP to the current AR. Then the AR retrieves the L2-L3 mapping entry from the server and puts it in its cache. There is no check whether MN received the beacon of the AP within the coverage area of the current AR. So MN can send L2 address of any AP which is registered in the server and thus the cache of the AR can contain all the L2-L3 mapping entries even though some of them are not of CARs of the current AR. Obviously scope-id is not helpful in verifying the information from MN. Now please can you explain how this can be prevented in the server approach? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:31:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09972 for ; Fri, 14 Mar 2003 14:31:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJj4O03686; Fri, 14 Mar 2003 14:45:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJiRO03631 for ; Fri, 14 Mar 2003 14:44:27 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09812 for ; Fri, 14 Mar 2003 14:28:52 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2EJV2103203 for ; Fri, 14 Mar 2003 11:31:02 -0800 (PST) Message-ID: <3E722D95.1050908@cs.ucsb.edu> Date: Fri, 14 Mar 2003 11:29:25 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] updated dyCARD draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I updated the dyCARD draft with a short section indicating that all messages must be rate limited (Section 7.9). The draft is available at http://www.cs.ucsb.edu/~robertc/drafts/draft-trossen-seamoby-dycard-01.txt enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:33:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10069 for ; Fri, 14 Mar 2003 14:33:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJmER03978 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 14:48:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJmEO03975 for ; Fri, 14 Mar 2003 14:48:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10045 for ; Fri, 14 Mar 2003 14:32:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJm2O03947; Fri, 14 Mar 2003 14:48:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJlQO03882 for ; Fri, 14 Mar 2003 14:47:26 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09994 for ; Fri, 14 Mar 2003 14:31:51 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2EJXx103930; Fri, 14 Mar 2003 11:33:59 -0800 (PST) Message-ID: <3E722E47.80005@cs.ucsb.edu> Date: Fri, 14 Mar 2003 11:32:23 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <3E722934.5060102@cs.ucsb.edu> In-Reply-To: <3E722934.5060102@cs.ucsb.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert Chalmers wrote: > James, > > > >> You mentioned previously you had done a simulation on this. Could >> you or another of the Dyhard Dycard Team provide some information >> about what the numbers look like, or a URL to a published paper? >> > The simulations we did weren't concerning the security aspects of the > protocol. Rather, we were looking at the advantages of using > higher-level info (capabilities) to improve handover performance. We > also looked at how well the learning-based scheme performed in > relation to the rate of handovers, the probability of errors, etc. > > At this point I'm not comfortable with releasing the paper publically > since we just submitted it to a conference for review. > Actually, we did look at one of the security aspects, limiting cache entries per MN. We found that limitiing to 2 entries has almost no effect on the performance of the learning protocol. ttyl, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:33:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10085 for ; Fri, 14 Mar 2003 14:33:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJm2O03947; Fri, 14 Mar 2003 14:48:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJlQO03882 for ; Fri, 14 Mar 2003 14:47:26 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09994 for ; Fri, 14 Mar 2003 14:31:51 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2EJXx103930; Fri, 14 Mar 2003 11:33:59 -0800 (PST) Message-ID: <3E722E47.80005@cs.ucsb.edu> Date: Fri, 14 Mar 2003 11:32:23 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <3E722934.5060102@cs.ucsb.edu> In-Reply-To: <3E722934.5060102@cs.ucsb.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert Chalmers wrote: > James, > > > >> You mentioned previously you had done a simulation on this. Could >> you or another of the Dyhard Dycard Team provide some information >> about what the numbers look like, or a URL to a published paper? >> > The simulations we did weren't concerning the security aspects of the > protocol. Rather, we were looking at the advantages of using > higher-level info (capabilities) to improve handover performance. We > also looked at how well the learning-based scheme performed in > relation to the rate of handovers, the probability of errors, etc. > > At this point I'm not comfortable with releasing the paper publically > since we just submitted it to a conference for review. > Actually, we did look at one of the security aspects, limiting cache entries per MN. We found that limitiing to 2 entries has almost no effect on the performance of the learning protocol. ttyl, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:47:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10546 for ; Fri, 14 Mar 2003 14:47:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EK2fW04651 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 15:02:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK2fO04648 for ; Fri, 14 Mar 2003 15:02:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10507 for ; Fri, 14 Mar 2003 14:47:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK2PO04612; Fri, 14 Mar 2003 15:02:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK12O04565 for ; Fri, 14 Mar 2003 15:01:02 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10472 for ; Fri, 14 Mar 2003 14:45:26 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 14:47:29 -0500 Message-ID: <025201c2ea7b$ddb181b0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> <014b01c2ea5e$6c5e4ce0$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 14:48:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 19:47:29.0830 (UTC) FILETIME=[8C1E8460:01C2EA62] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > 1) Whether the proposed mechanism can filter out false information from MN > > and thus prevent cache contamination. > > This is Issue 4. I don't like the term "cache contamination" because it is not > possible to actually cause a false GAAP to GAAR resolution. The issue is more > one of cache sizing and robustness, not one of a failure of the protocol to > properly operate. > [eunsoo] Well, we have used this term for a while. But now you want to change it. What do you suggest? Anyway, it's a failure of CAR discovery. The first task of the protocol is discovering CARs of a given AR. If the protocol could not provide the list of CARs for the AR, it failed to do its job. I am repeating this. The application of CARD is not just L2->L3 mapping. Let me repeat the example scenario where the false entries are harmful. MNs have two interfaces, let say, GPRS and 802.11b. Since 802.11b interface consumes lots of power even during idle mode, MN wants to keep it down while it is not used. But MN also wants to know whether it should start scanning 802.11 channels for APs. Here CARD becomes useful. The AR in the GPRS network provides list of CARs to the MN. The information tells that there is an AP with 802.11b interface but it is not true. Then MN just turns on its 802.11 interface and consumes its power for nothing. > > 2) What is the impact of malicious MN's bombarding AR with false > > information. > > > > This is Issue 3. > > > The first topic is the main thing of this thread. I think the server > > approach cannot filter out false information or prevent cache contamination. > > I think Dycard can make cache contamination very difficult. > > > > I'll let the DT members comment on this. > > > The second topic is more related to DoS attack. We talked about it already. > > In Dycard, if the AR can know about MN's handoff events, it can limit MN's > > report as one per handoff. > > The AR might not. It doesn't for 802.11, for example. > [eunsoo] 802.11 AP can tell when a MN arrived. Then it can tell its AR about it. Or AR can poll the APs for the events. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:48:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10581 for ; Fri, 14 Mar 2003 14:48:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK2PO04612; Fri, 14 Mar 2003 15:02:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK12O04565 for ; Fri, 14 Mar 2003 15:01:02 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10472 for ; Fri, 14 Mar 2003 14:45:26 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 14:47:29 -0500 Message-ID: <025201c2ea7b$ddb181b0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> <014b01c2ea5e$6c5e4ce0$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 14:48:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 19:47:29.0830 (UTC) FILETIME=[8C1E8460:01C2EA62] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > 1) Whether the proposed mechanism can filter out false information from MN > > and thus prevent cache contamination. > > This is Issue 4. I don't like the term "cache contamination" because it is not > possible to actually cause a false GAAP to GAAR resolution. The issue is more > one of cache sizing and robustness, not one of a failure of the protocol to > properly operate. > [eunsoo] Well, we have used this term for a while. But now you want to change it. What do you suggest? Anyway, it's a failure of CAR discovery. The first task of the protocol is discovering CARs of a given AR. If the protocol could not provide the list of CARs for the AR, it failed to do its job. I am repeating this. The application of CARD is not just L2->L3 mapping. Let me repeat the example scenario where the false entries are harmful. MNs have two interfaces, let say, GPRS and 802.11b. Since 802.11b interface consumes lots of power even during idle mode, MN wants to keep it down while it is not used. But MN also wants to know whether it should start scanning 802.11 channels for APs. Here CARD becomes useful. The AR in the GPRS network provides list of CARs to the MN. The information tells that there is an AP with 802.11b interface but it is not true. Then MN just turns on its 802.11 interface and consumes its power for nothing. > > 2) What is the impact of malicious MN's bombarding AR with false > > information. > > > > This is Issue 3. > > > The first topic is the main thing of this thread. I think the server > > approach cannot filter out false information or prevent cache contamination. > > I think Dycard can make cache contamination very difficult. > > > > I'll let the DT members comment on this. > > > The second topic is more related to DoS attack. We talked about it already. > > In Dycard, if the AR can know about MN's handoff events, it can limit MN's > > report as one per handoff. > > The AR might not. It doesn't for 802.11, for example. > [eunsoo] 802.11 AP can tell when a MN arrived. Then it can tell its AR about it. Or AR can poll the APs for the events. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:53:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10832 for ; Fri, 14 Mar 2003 14:53:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EK8Mf05794 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 15:08:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK8MO05791 for ; Fri, 14 Mar 2003 15:08:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10823 for ; Fri, 14 Mar 2003 14:52:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK83O05777; Fri, 14 Mar 2003 15:08:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK79O05085 for ; Fri, 14 Mar 2003 15:07:09 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10765 for ; Fri, 14 Mar 2003 14:51:33 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2EJrhPO002000 for ; Fri, 14 Mar 2003 12:53:43 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA08576 for ; Fri, 14 Mar 2003 12:53:43 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 13:53:43 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE66@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , "'James Kempf'" , Govind.Krishnamurthi@nokia.com, Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:53:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Friday, March 14, 2003 4:33 PM To: Singh Ajoy-ASINGH1; 'James Kempf'; Govind.Krishnamurthi@nokia.com; Hemant.Chaskar@nokia.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination > > The first topic is the main thing of this thread. I think the server > > approach cannot filter out false information or prevent cache > contamination. > > I think Dycard can make cache contamination very difficult. > > > > AJOY->Why not ? I am confused here. Could you please explain why do you > think so? > In the server approach, MN sends the L2 address of an AP to the current AR. Then the AR retrieves the L2-L3 mapping entry from the server and puts it in its cache. There is no check whether MN received the beacon of the AP within the coverage area of the current AR. So MN can send L2 address of any AP which is registered in the server and thus the cache of the AR can contain all the L2-L3 mapping entries even though some of them are not of CARs of the current AR. AJOY-> What is the probability that a malicious MN will send fake AP id which is also stored in the server ? I am really having hard time imagining any real scenario like this. Obviously scope-id is not helpful in verifying the information from MN. AJOY-> Scope id is used to avoid the cache overflow problem. I do not see how this can cause any cache overflow if the router cache is appropriately sized to store entries for all the routers belonging to the scope. Now please can you explain how this can be prevented in the server approach? AJOY-> BTW, I have a cache contamination question about dycard. Let us assume that a fake MN has some collaboration with fake router which is also connected to the internet and the fake MN sends a message to the current AR indicating that fake router is the valid CAR ? How the dycard assures that it does create an entry in its local cache? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:53:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10850 for ; Fri, 14 Mar 2003 14:53:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK83O05777; Fri, 14 Mar 2003 15:08:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EK79O05085 for ; Fri, 14 Mar 2003 15:07:09 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10765 for ; Fri, 14 Mar 2003 14:51:33 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2EJrhPO002000 for ; Fri, 14 Mar 2003 12:53:43 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA08576 for ; Fri, 14 Mar 2003 12:53:43 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 13:53:43 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE66@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , "'James Kempf'" , Govind.Krishnamurthi@nokia.com, Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:53:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Friday, March 14, 2003 4:33 PM To: Singh Ajoy-ASINGH1; 'James Kempf'; Govind.Krishnamurthi@nokia.com; Hemant.Chaskar@nokia.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination > > The first topic is the main thing of this thread. I think the server > > approach cannot filter out false information or prevent cache > contamination. > > I think Dycard can make cache contamination very difficult. > > > > AJOY->Why not ? I am confused here. Could you please explain why do you > think so? > In the server approach, MN sends the L2 address of an AP to the current AR. Then the AR retrieves the L2-L3 mapping entry from the server and puts it in its cache. There is no check whether MN received the beacon of the AP within the coverage area of the current AR. So MN can send L2 address of any AP which is registered in the server and thus the cache of the AR can contain all the L2-L3 mapping entries even though some of them are not of CARs of the current AR. AJOY-> What is the probability that a malicious MN will send fake AP id which is also stored in the server ? I am really having hard time imagining any real scenario like this. Obviously scope-id is not helpful in verifying the information from MN. AJOY-> Scope id is used to avoid the cache overflow problem. I do not see how this can cause any cache overflow if the router cache is appropriately sized to store entries for all the routers belonging to the scope. Now please can you explain how this can be prevented in the server approach? AJOY-> BTW, I have a cache contamination question about dycard. Let us assume that a fake MN has some collaboration with fake router which is also connected to the internet and the fake MN sends a message to the current AR indicating that fake router is the valid CAR ? How the dycard assures that it does create an entry in its local cache? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 14:56:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10917 for ; Fri, 14 Mar 2003 14:56:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EKBF505901 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 15:11:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKBEO05898 for ; Fri, 14 Mar 2003 15:11:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10912 for ; Fri, 14 Mar 2003 14:55:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKB2O05883; Fri, 14 Mar 2003 15:11:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKApO05865 for ; Fri, 14 Mar 2003 15:10:51 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10892 for ; Fri, 14 Mar 2003 14:55:15 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EK0vF09510 for ; Fri, 14 Mar 2003 22:00:57 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 21:57:24 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 21:57:24 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 13:57:00 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 14:56:59 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqXbOAfBZ86pdgTKKKA1sjmMpm/AAAHD0w To: , , , X-OriginalArrivalTime: 14 Mar 2003 19:57:00.0224 (UTC) FILETIME=[E019BC00:01C2EA63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EKApO05866 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit James, > I am trying to understand Dycard, as, I presume, are others in the > WG. If you and the rest of your team want it or features of it to be included in > the protocol (which is why, I presume, you are arguing so strongly against the > DT draft) then you need to help us understand it. It is not helpful or > constructive to criticize someone else's work without providing a alternative. > From my reading of the Dycard draft, there may be some useful features in it, we > need to have the working group understand those. [Govind] First, its not my team. Second, I am not speaking for others who co-authored dycard. While I agree with you in essense, I think it is unfair to expect us to explain everything when the draft is available for everyone to read. We read the DT draft and raised questions based on our study. If those who are interested, read our draft and asks us questions exactly as how we handle things and ask us to prove the efficiency of our scheme, we will be more than happy to do so as it helps improve our ideas too. If something is not upto standards of the WG we will attempt to rectify those issues. If something is unclear and pointed clarifications are asked from us we can go forward and clarify things. Instead, same questions are being asked again and again, and we seem to go around in circles all the time. I would think similar effort must be made to understand dycard too by people who wish to critique us . > > So why can't the server scheme limit the number of entries > per MN? Limiting the > number of entries per MN has nothing to do with the back end, > where the router > finds out what is an authorized GAAP, which is where Dycard > and the server > scheme differ as I understand it. It has to do with the front > end, where the > router decides what to do with an incoming message. [Govind] Overall I agree. The main point is in the server scheme you are using APids sent by the MNs as the means of populating the cache. Since you can't restrict the number of APids it will hear from outside your domain. You have to consider it while setting the limit in rate limiting. Other than that I believe that tagging the MN with its identity is a nice way to restrict the number of cache entries created by the MN. > I see from the draft that it is the RI message that launches > PNE, my bad. Now, > please tell me why an MN can't bombard the router with RI > messages? The router > can rate limit, as you mention above but, in your comments on > the Issues, you > said that you didn't think rate limiting was an issue, so...? > Is rate limiting > important or isn't it? I'm confused. [Govind] Let me make myself clear yet again. I think it easier to set the "limit" while rate limiting in dycard than in the DT draft. I don't discount the need for rate limiting. > OK. What happens when the limit is reached? Wouldn't a cache > (regardless of the > timeout policy) be necessary regardless? [Govind] I didn't understand your point clearly here. But maybe my previous explanations about understanding the need for rate limiting would suffice for you. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 14:56:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10938 for ; Fri, 14 Mar 2003 14:56:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKB2O05883; Fri, 14 Mar 2003 15:11:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKApO05865 for ; Fri, 14 Mar 2003 15:10:51 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10892 for ; Fri, 14 Mar 2003 14:55:15 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EK0vF09510 for ; Fri, 14 Mar 2003 22:00:57 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 21:57:24 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 21:57:24 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 13:57:00 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 14:56:59 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqXbOAfBZ86pdgTKKKA1sjmMpm/AAAHD0w To: , , , X-OriginalArrivalTime: 14 Mar 2003 19:57:00.0224 (UTC) FILETIME=[E019BC00:01C2EA63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EKApO05866 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, > I am trying to understand Dycard, as, I presume, are others in the > WG. If you and the rest of your team want it or features of it to be included in > the protocol (which is why, I presume, you are arguing so strongly against the > DT draft) then you need to help us understand it. It is not helpful or > constructive to criticize someone else's work without providing a alternative. > From my reading of the Dycard draft, there may be some useful features in it, we > need to have the working group understand those. [Govind] First, its not my team. Second, I am not speaking for others who co-authored dycard. While I agree with you in essense, I think it is unfair to expect us to explain everything when the draft is available for everyone to read. We read the DT draft and raised questions based on our study. If those who are interested, read our draft and asks us questions exactly as how we handle things and ask us to prove the efficiency of our scheme, we will be more than happy to do so as it helps improve our ideas too. If something is not upto standards of the WG we will attempt to rectify those issues. If something is unclear and pointed clarifications are asked from us we can go forward and clarify things. Instead, same questions are being asked again and again, and we seem to go around in circles all the time. I would think similar effort must be made to understand dycard too by people who wish to critique us . > > So why can't the server scheme limit the number of entries > per MN? Limiting the > number of entries per MN has nothing to do with the back end, > where the router > finds out what is an authorized GAAP, which is where Dycard > and the server > scheme differ as I understand it. It has to do with the front > end, where the > router decides what to do with an incoming message. [Govind] Overall I agree. The main point is in the server scheme you are using APids sent by the MNs as the means of populating the cache. Since you can't restrict the number of APids it will hear from outside your domain. You have to consider it while setting the limit in rate limiting. Other than that I believe that tagging the MN with its identity is a nice way to restrict the number of cache entries created by the MN. > I see from the draft that it is the RI message that launches > PNE, my bad. Now, > please tell me why an MN can't bombard the router with RI > messages? The router > can rate limit, as you mention above but, in your comments on > the Issues, you > said that you didn't think rate limiting was an issue, so...? > Is rate limiting > important or isn't it? I'm confused. [Govind] Let me make myself clear yet again. I think it easier to set the "limit" while rate limiting in dycard than in the DT draft. I don't discount the need for rate limiting. > OK. What happens when the limit is reached? Wouldn't a cache > (regardless of the > timeout policy) be necessary regardless? [Govind] I didn't understand your point clearly here. But maybe my previous explanations about understanding the need for rate limiting would suffice for you. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 15:13:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12449 for ; Fri, 14 Mar 2003 15:13:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EKSQ906647 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 15:28:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKSQO06644 for ; Fri, 14 Mar 2003 15:28:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12395 for ; Fri, 14 Mar 2003 15:12:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKSEO06626; Fri, 14 Mar 2003 15:28:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKOeO06506 for ; Fri, 14 Mar 2003 15:24:40 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11847 for ; Fri, 14 Mar 2003 15:09:05 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 15:11:16 -0500 Message-ID: <027d01c2ea7f$2fc067c0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "'James Kempf'" , , , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE66@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 15:12:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 20:11:16.0063 (UTC) FILETIME=[DE3866F0:01C2EA65] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > The first topic is the main thing of this thread. I think the server > > > approach cannot filter out false information or prevent cache > > contamination. > > > I think Dycard can make cache contamination very difficult. > > > > > > > AJOY->Why not ? I am confused here. Could you please explain why do you > > think so? > > > > In the server approach, MN sends the L2 address of an AP to the current AR. > Then the AR retrieves the L2-L3 mapping entry from the server and puts it in > its cache. There is no check whether MN received the beacon of the AP > within the > coverage area of the current AR. So MN can send L2 address of any AP which > is registered in the server and thus the cache of the AR can contain all the > L2-L3 mapping entries even though some of them are not of CARs of the > current AR. > > AJOY-> What is the probability that a malicious MN will send fake AP > id which is also stored in the server ? I am really having hard > time imagining any real scenario like this. > [eunsoo] We are talking about malicious MNs, that is, malicious human beings actually. They can find out AP L2 addresses in the domain by simply walking around. And they can use the information to fill the cache with the L2 addresses. So probabality is not an issue here. > Obviously scope-id is not helpful in verifying the information from MN. > > AJOY-> Scope id is used to avoid the cache overflow problem. I do > not see how this can cause any cache overflow if the router cache is > appropriately sized to store entries for all the routers belonging to the > scope. > [eunsoo]Right. I am pointing it because it was claimed as if scope-id would prevent cache contamination. If nobody claims that scope id prevents cache contamination, then we can skip this. > Now please can you explain how this can be prevented in the server approach? > > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > [eunsoo] To defeat the attack, a simple approach is to accept only authorized ARs as CARs. There are many ways to check authorization of ARs. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 15:13:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12491 for ; Fri, 14 Mar 2003 15:13:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKSEO06626; Fri, 14 Mar 2003 15:28:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKOeO06506 for ; Fri, 14 Mar 2003 15:24:40 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11847 for ; Fri, 14 Mar 2003 15:09:05 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 15:11:16 -0500 Message-ID: <027d01c2ea7f$2fc067c0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "'James Kempf'" , , , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE66@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 15:12:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 20:11:16.0063 (UTC) FILETIME=[DE3866F0:01C2EA65] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > The first topic is the main thing of this thread. I think the server > > > approach cannot filter out false information or prevent cache > > contamination. > > > I think Dycard can make cache contamination very difficult. > > > > > > > AJOY->Why not ? I am confused here. Could you please explain why do you > > think so? > > > > In the server approach, MN sends the L2 address of an AP to the current AR. > Then the AR retrieves the L2-L3 mapping entry from the server and puts it in > its cache. There is no check whether MN received the beacon of the AP > within the > coverage area of the current AR. So MN can send L2 address of any AP which > is registered in the server and thus the cache of the AR can contain all the > L2-L3 mapping entries even though some of them are not of CARs of the > current AR. > > AJOY-> What is the probability that a malicious MN will send fake AP > id which is also stored in the server ? I am really having hard > time imagining any real scenario like this. > [eunsoo] We are talking about malicious MNs, that is, malicious human beings actually. They can find out AP L2 addresses in the domain by simply walking around. And they can use the information to fill the cache with the L2 addresses. So probabality is not an issue here. > Obviously scope-id is not helpful in verifying the information from MN. > > AJOY-> Scope id is used to avoid the cache overflow problem. I do > not see how this can cause any cache overflow if the router cache is > appropriately sized to store entries for all the routers belonging to the > scope. > [eunsoo]Right. I am pointing it because it was claimed as if scope-id would prevent cache contamination. If nobody claims that scope id prevents cache contamination, then we can skip this. > Now please can you explain how this can be prevented in the server approach? > > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > [eunsoo] To defeat the attack, a simple approach is to accept only authorized ARs as CARs. There are many ways to check authorization of ARs. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 15:19:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12933 for ; Fri, 14 Mar 2003 15:19:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EKYc706991 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 15:34:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKYcO06988 for ; Fri, 14 Mar 2003 15:34:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12912 for ; Fri, 14 Mar 2003 15:19:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKYMO06960; Fri, 14 Mar 2003 15:34:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKXHO06836 for ; Fri, 14 Mar 2003 15:33:17 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12857 for ; Fri, 14 Mar 2003 15:17:41 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2EKJk116126; Fri, 14 Mar 2003 12:19:46 -0800 (PST) Message-ID: <3E7238FB.4070607@cs.ucsb.edu> Date: Fri, 14 Mar 2003 12:18:03 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'Eunsoo Shim'" , seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE66@IL27EXM10.cig.mot.com> In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0CD4BE66@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Singh Ajoy-ASINGH1 wrote: > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > It is clearly stated in the draft that the two routers must mutually authenticate one another with the explicit authorization to perform CARD. Are you assuming that this fake AR can in some way authenticate and authorize itself with respect to the attacked AR? If not, the question is moot. If so, then I would question your authentication/authorization scheme. enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 15:19:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12968 for ; Fri, 14 Mar 2003 15:19:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKYMO06960; Fri, 14 Mar 2003 15:34:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKXHO06836 for ; Fri, 14 Mar 2003 15:33:17 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12857 for ; Fri, 14 Mar 2003 15:17:41 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2EKJk116126; Fri, 14 Mar 2003 12:19:46 -0800 (PST) Message-ID: <3E7238FB.4070607@cs.ucsb.edu> Date: Fri, 14 Mar 2003 12:18:03 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'Eunsoo Shim'" , seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE66@IL27EXM10.cig.mot.com> In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0CD4BE66@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Singh Ajoy-ASINGH1 wrote: > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > It is clearly stated in the draft that the two routers must mutually authenticate one another with the explicit authorization to perform CARD. Are you assuming that this fake AR can in some way authenticate and authorize itself with respect to the attacked AR? If not, the question is moot. If so, then I would question your authentication/authorization scheme. enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 15:26:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09888 for ; Fri, 14 Mar 2003 14:30:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJjO303737 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 14:45:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJjOO03732 for ; Fri, 14 Mar 2003 14:45:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09858 for ; Fri, 14 Mar 2003 14:29:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJj5O03702; Fri, 14 Mar 2003 14:45:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJj0O03658 for ; Fri, 14 Mar 2003 14:45:00 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09847 for ; Fri, 14 Mar 2003 14:29:26 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 14:31:35 -0500 Message-ID: <024701c2ea79$a5212370$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "'James Kempf'" , , , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE65@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 14:32:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 19:31:35.0880 (UTC) FILETIME=[53854C80:01C2EA60] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > The first topic is the main thing of this thread. I think the server > > approach cannot filter out false information or prevent cache > contamination. > > I think Dycard can make cache contamination very difficult. > > > > AJOY->Why not ? I am confused here. Could you please explain why do you > think so? > In the server approach, MN sends the L2 address of an AP to the current AR. Then the AR retrieves the L2-L3 mapping entry from the server and puts it in its cache. There is no check whether MN received the beacon of the AP within the coverage area of the current AR. So MN can send L2 address of any AP which is registered in the server and thus the cache of the AR can contain all the L2-L3 mapping entries even though some of them are not of CARs of the current AR. Obviously scope-id is not helpful in verifying the information from MN. Now please can you explain how this can be prevented in the server approach? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 15:41:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13629 for ; Fri, 14 Mar 2003 15:41:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EKugX08784 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 15:56:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKugO08781 for ; Fri, 14 Mar 2003 15:56:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13606 for ; Fri, 14 Mar 2003 15:41:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKuTO08765; Fri, 14 Mar 2003 15:56:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKrRO08671 for ; Fri, 14 Mar 2003 15:53:27 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13543 for ; Fri, 14 Mar 2003 15:37:51 -0500 (EST) Message-ID: <019a01c2ea69$ac2ed050$286015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD Issues List Date: Fri, 14 Mar 2003 12:38:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Spell it out, please. It is not obvious to me that the DT > > draft doesn't deal > > with site-locals, nor that the Dycard draft does. > [Govind] Would it suffice to say that one approach is described in section 4.8.5 of the dycard draft? Or do you want me to go into detail? I will make a short summary from Section 4.8.5 and post. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 15:42:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13699 for ; Fri, 14 Mar 2003 15:42:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKuTO08765; Fri, 14 Mar 2003 15:56:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKrRO08671 for ; Fri, 14 Mar 2003 15:53:27 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13543 for ; Fri, 14 Mar 2003 15:37:51 -0500 (EST) Message-ID: <019a01c2ea69$ac2ed050$286015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD Issues List Date: Fri, 14 Mar 2003 12:38:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Spell it out, please. It is not obvious to me that the DT > > draft doesn't deal > > with site-locals, nor that the Dycard draft does. > [Govind] Would it suffice to say that one approach is described in section 4.8.5 of the dycard draft? Or do you want me to go into detail? I will make a short summary from Section 4.8.5 and post. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 16:02:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14203 for ; Fri, 14 Mar 2003 16:02:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ELHIu10379 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 16:17:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELHIO10376 for ; Fri, 14 Mar 2003 16:17:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14184 for ; Fri, 14 Mar 2003 16:01:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELH6O10358; Fri, 14 Mar 2003 16:17:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELG8O10319 for ; Fri, 14 Mar 2003 16:16:08 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14126 for ; Fri, 14 Mar 2003 16:00:31 -0500 (EST) Message-ID: <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> From: "James Kempf" To: "Robert Chalmers" , References: <3E722D95.1050908@cs.ucsb.edu> Subject: Re: [Seamoby] updated dyCARD draft Date: Fri, 14 Mar 2003 13:01:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert, Do you want to propose this text as the resolution to Issue 3? jak ----- Original Message ----- From: "Robert Chalmers" To: Sent: Friday, March 14, 2003 11:29 AM Subject: [Seamoby] updated dyCARD draft > Folks, > > I updated the dyCARD draft with a short section indicating that all > messages must be rate limited (Section 7.9). The draft is available at > http://www.cs.ucsb.edu/~robertc/drafts/draft-trossen-seamoby-dycard-01.txt > > enjoy, > bob > > -- > /**************************************************************** > > Robert Chalmers > UCSB Computer Science Doctoral Candidate > Network and Multimedia Systems Lab (NMSL) > > "My heart is in the code, but my soul lies in the process" > > | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | > > *****************************************************************/ > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 16:02:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14216 for ; Fri, 14 Mar 2003 16:02:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELH6O10358; Fri, 14 Mar 2003 16:17:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELG8O10319 for ; Fri, 14 Mar 2003 16:16:08 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14126 for ; Fri, 14 Mar 2003 16:00:31 -0500 (EST) Message-ID: <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> From: "James Kempf" To: "Robert Chalmers" , References: <3E722D95.1050908@cs.ucsb.edu> Subject: Re: [Seamoby] updated dyCARD draft Date: Fri, 14 Mar 2003 13:01:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, Do you want to propose this text as the resolution to Issue 3? jak ----- Original Message ----- From: "Robert Chalmers" To: Sent: Friday, March 14, 2003 11:29 AM Subject: [Seamoby] updated dyCARD draft > Folks, > > I updated the dyCARD draft with a short section indicating that all > messages must be rate limited (Section 7.9). The draft is available at > http://www.cs.ucsb.edu/~robertc/drafts/draft-trossen-seamoby-dycard-01.txt > > enjoy, > bob > > -- > /**************************************************************** > > Robert Chalmers > UCSB Computer Science Doctoral Candidate > Network and Multimedia Systems Lab (NMSL) > > "My heart is in the code, but my soul lies in the process" > > | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | > > *****************************************************************/ > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 16:06:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14465 for ; Fri, 14 Mar 2003 16:06:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ELLDF10625 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 16:21:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELLDO10622 for ; Fri, 14 Mar 2003 16:21:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14310 for ; Fri, 14 Mar 2003 16:05:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELL3O10614; Fri, 14 Mar 2003 16:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELKpO10586 for ; Fri, 14 Mar 2003 16:20:51 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14289 for ; Fri, 14 Mar 2003 16:05:14 -0500 (EST) Message-ID: <01dd01c2ea6d$7f8df5e0$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> <014b01c2ea5e$6c5e4ce0$286015ac@T23KEMPF> <025201c2ea7b$ddb181b0$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:05:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [eunsoo] Well, we have used this term for a while. But now you want to > change it. What do you suggest? > Anyway, it's a failure of CAR discovery. The first task of the protocol is > discovering CARs of a given AR. If the protocol could not provide the list > of CARs for the AR, it failed to do its job. > How about "mapping geographical accuracy"? > I am repeating this. The application of CARD is not just L2->L3 mapping. Let > me repeat the example scenario where the false entries are harmful. > MNs have two interfaces, let say, GPRS and 802.11b. Since 802.11b interface > consumes lots of power even during idle mode, MN wants to keep it down while > it is not used. But MN also wants to know whether it should start scanning > 802.11 channels for APs. Here CARD becomes useful. The AR in the GPRS > network provides list of CARs to the MN. The information tells that there is > an AP with 802.11b interface but it is not true. Then MN just turns on its > 802.11 interface and consumes its power for nothing. > Ah, right I had forgotten that issue. Thanx for reminding me. So there are some potential consequences to false information. Though, this particular consequence is not fatal, just inconvenient. That is, the MN won't end up handing over to an AP that is a rogue and getting it's traffic stolen, nor will it get dropped because it handed over to an AP that isn't there, right? Presumably, when it starts the 802.11 handover, it will do the standard L2 scan for APs to determine whether a particular AP is there, then discard any CARD information that is not accurate. Though I have in the past been a proponent for this use of CARD, there are some issues with the granularity of resolution. Suppose my GPRS cell is 10 km in radius and there are 2 disconnected hotspots 100 m in radus. Unless some real geographical information like GPS or triagulation is used (which isn't in any of the proposals), the network can only do an approximate job. So the GPRS router would end up providing the MN with CARD information, even though the 802.11 hotspot might not be available. But I agree it would be convenient if we could find a way to solve this issue. > [eunsoo] 802.11 AP can tell when a MN arrived. Then it can tell its AR about > it. But how? There is no protocol for that (though I personally think there should be). >Or AR can poll the APs for the events. > Polling isn't real time, or, if it is, it would consume router cycles. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 16:06:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14478 for ; Fri, 14 Mar 2003 16:06:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELL3O10614; Fri, 14 Mar 2003 16:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELKpO10586 for ; Fri, 14 Mar 2003 16:20:51 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14289 for ; Fri, 14 Mar 2003 16:05:14 -0500 (EST) Message-ID: <01dd01c2ea6d$7f8df5e0$286015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> <014b01c2ea5e$6c5e4ce0$286015ac@T23KEMPF> <025201c2ea7b$ddb181b0$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:05:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [eunsoo] Well, we have used this term for a while. But now you want to > change it. What do you suggest? > Anyway, it's a failure of CAR discovery. The first task of the protocol is > discovering CARs of a given AR. If the protocol could not provide the list > of CARs for the AR, it failed to do its job. > How about "mapping geographical accuracy"? > I am repeating this. The application of CARD is not just L2->L3 mapping. Let > me repeat the example scenario where the false entries are harmful. > MNs have two interfaces, let say, GPRS and 802.11b. Since 802.11b interface > consumes lots of power even during idle mode, MN wants to keep it down while > it is not used. But MN also wants to know whether it should start scanning > 802.11 channels for APs. Here CARD becomes useful. The AR in the GPRS > network provides list of CARs to the MN. The information tells that there is > an AP with 802.11b interface but it is not true. Then MN just turns on its > 802.11 interface and consumes its power for nothing. > Ah, right I had forgotten that issue. Thanx for reminding me. So there are some potential consequences to false information. Though, this particular consequence is not fatal, just inconvenient. That is, the MN won't end up handing over to an AP that is a rogue and getting it's traffic stolen, nor will it get dropped because it handed over to an AP that isn't there, right? Presumably, when it starts the 802.11 handover, it will do the standard L2 scan for APs to determine whether a particular AP is there, then discard any CARD information that is not accurate. Though I have in the past been a proponent for this use of CARD, there are some issues with the granularity of resolution. Suppose my GPRS cell is 10 km in radius and there are 2 disconnected hotspots 100 m in radus. Unless some real geographical information like GPS or triagulation is used (which isn't in any of the proposals), the network can only do an approximate job. So the GPRS router would end up providing the MN with CARD information, even though the 802.11 hotspot might not be available. But I agree it would be convenient if we could find a way to solve this issue. > [eunsoo] 802.11 AP can tell when a MN arrived. Then it can tell its AR about > it. But how? There is no protocol for that (though I personally think there should be). >Or AR can poll the APs for the events. > Polling isn't real time, or, if it is, it would consume router cycles. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 16:44:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15756 for ; Fri, 14 Mar 2003 16:44:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EM00n13184 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 17:00:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM00O13179 for ; Fri, 14 Mar 2003 17:00:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15606 for ; Fri, 14 Mar 2003 16:44:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELxMO13115; Fri, 14 Mar 2003 16:59:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELwMO13072 for ; Fri, 14 Mar 2003 16:58:22 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15563 for ; Fri, 14 Mar 2003 16:42:44 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ELit825169 for ; Fri, 14 Mar 2003 15:44:55 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 15:44:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 13:44:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 16:44:39 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqTo1QL42r7+OhSL+iP5xAaUpZmgAJDm1g To: , , , X-OriginalArrivalTime: 14 Mar 2003 21:44:40.0044 (UTC) FILETIME=[EA740AC0:01C2EA72] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ELwMO13073 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit OK, you are right if MN has assigned bandwidth slice for which it is paying for. - Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, March 14, 2003 12:23 PM To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Hemant, I don't understand. If an attacking MN reports something that is not a GAAP, then sure, maybe it gets some junk, but so what? If the MN wants to be so antisocial, then it gets to deal with the results. As for wireless bandwidth, I assume the wireless network is enforcing the MN's QoS so it only gets the amount of bandwidth it paid for. As for the router, as mentioned in Issue 3 on the issues Web page, the protocol should include a provision for rate limiting and a provision allowing the router to selectively drop packets in order to deal with a spike in service requests. jak ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 7:36 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Thursday, March 13, 2003 6:44 PM > To: kempf@docomolabs-usa.com; Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > > > > I'm not sure I understand the attack. > > > > If an attacker sends a completely bogus AP, the AR compares > > against the AAPL > > (Authorized AP List) and rejects. > > If an attacker sends an AP that is not bogus but is not a > > GAAP, then it will > > pass the AAPL test but it will remain in the cache for one > > iteration and be > > flushed aftewards. > [Govind] This is assuming a particular cache replacement policy and assumes > the server approach. I think we should first settle whether the server is needed > or not before coming to cache contamination and other cache related issues. > However, if we are not going to do that, then we should propose how any > scheme involving protecting the cache works in either of the proposed solutions. > > > > So, I don't see how interrouter capability and update > > exchange are affected. > [Govind] First thoughts about this cache replacement policy. I will think about this replacement > policy more later.. Its been a long day already, so sorry if I'm wrong :) > > If the number of malicious MNs increase, then wouldn't you have an increase of the number > of entries? Also, they might not be removed from the cache. More such entries and more > the unnecessary capability messages. Note, if we are using the server scheme, each MN has > the possibility of reporting a large number of such non-GAAPs. Consider this scenario, > 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that > each AP is assigned to a different AR. Further assume that > you have a limit of 100 reports per MN. In your scheme, the chance > of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of > non GAARs are in the cache after each flush. So the current AR will communicate > unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities > exchanged you do have an unnecessary burden on the ARs. You will never be able > to detect this and yet keep exchanging messages between non-CARs. > > Another point, by flipping a coin as you suggest > based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability > of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you > keep relying on the server, thus increasing the average response time. > Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes > to remove bad entries may be a better approach. I'm not saying that this is a bad > cache replacement scheme yet but I'll think about this tomorrow. > > > -Govind. > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 16:45:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15778 for ; Fri, 14 Mar 2003 16:45:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELxMO13115; Fri, 14 Mar 2003 16:59:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELwMO13072 for ; Fri, 14 Mar 2003 16:58:22 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15563 for ; Fri, 14 Mar 2003 16:42:44 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2ELit825169 for ; Fri, 14 Mar 2003 15:44:55 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 15:44:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 13:44:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 16:44:39 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqTo1QL42r7+OhSL+iP5xAaUpZmgAJDm1g To: , , , X-OriginalArrivalTime: 14 Mar 2003 21:44:40.0044 (UTC) FILETIME=[EA740AC0:01C2EA72] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ELwMO13073 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit OK, you are right if MN has assigned bandwidth slice for which it is paying for. - Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, March 14, 2003 12:23 PM To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Hemant, I don't understand. If an attacking MN reports something that is not a GAAP, then sure, maybe it gets some junk, but so what? If the MN wants to be so antisocial, then it gets to deal with the results. As for wireless bandwidth, I assume the wireless network is enforcing the MN's QoS so it only gets the amount of bandwidth it paid for. As for the router, as mentioned in Issue 3 on the issues Web page, the protocol should include a provision for rate limiting and a provision allowing the router to selectively drop packets in order to deal with a spike in service requests. jak ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 7:36 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Thursday, March 13, 2003 6:44 PM > To: kempf@docomolabs-usa.com; Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > > > > I'm not sure I understand the attack. > > > > If an attacker sends a completely bogus AP, the AR compares > > against the AAPL > > (Authorized AP List) and rejects. > > If an attacker sends an AP that is not bogus but is not a > > GAAP, then it will > > pass the AAPL test but it will remain in the cache for one > > iteration and be > > flushed aftewards. > [Govind] This is assuming a particular cache replacement policy and assumes > the server approach. I think we should first settle whether the server is needed > or not before coming to cache contamination and other cache related issues. > However, if we are not going to do that, then we should propose how any > scheme involving protecting the cache works in either of the proposed solutions. > > > > So, I don't see how interrouter capability and update > > exchange are affected. > [Govind] First thoughts about this cache replacement policy. I will think about this replacement > policy more later.. Its been a long day already, so sorry if I'm wrong :) > > If the number of malicious MNs increase, then wouldn't you have an increase of the number > of entries? Also, they might not be removed from the cache. More such entries and more > the unnecessary capability messages. Note, if we are using the server scheme, each MN has > the possibility of reporting a large number of such non-GAAPs. Consider this scenario, > 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that > each AP is assigned to a different AR. Further assume that > you have a limit of 100 reports per MN. In your scheme, the chance > of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of > non GAARs are in the cache after each flush. So the current AR will communicate > unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities > exchanged you do have an unnecessary burden on the ARs. You will never be able > to detect this and yet keep exchanging messages between non-CARs. > > Another point, by flipping a coin as you suggest > based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability > of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you > keep relying on the server, thus increasing the average response time. > Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes > to remove bad entries may be a better approach. I'm not saying that this is a bad > cache replacement scheme yet but I'll think about this tomorrow. > > > -Govind. > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 16:47:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15836 for ; Fri, 14 Mar 2003 16:47:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EM2HS13951 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 17:02:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM2HO13948 for ; Fri, 14 Mar 2003 17:02:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15825 for ; Fri, 14 Mar 2003 16:46:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM23O13935; Fri, 14 Mar 2003 17:02:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM16O13866 for ; Fri, 14 Mar 2003 17:01:06 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15807 for ; Fri, 14 Mar 2003 16:45:28 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 16:47:39 -0500 Message-ID: <02db01c2ea8c$a6f74860$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 16:48:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 21:47:39.0763 (UTC) FILETIME=[5592FC30:01C2EA73] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, there are various pricing models. Also we are doing engineering. Being free does not mean we can abuse it. Eunsoo ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 1:44 PM Subject: RE: [SeaMoby] Topic #3: Cache contamination OK, you are right if MN has assigned bandwidth slice for which it is paying for. - Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, March 14, 2003 12:23 PM To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Hemant, I don't understand. If an attacking MN reports something that is not a GAAP, then sure, maybe it gets some junk, but so what? If the MN wants to be so antisocial, then it gets to deal with the results. As for wireless bandwidth, I assume the wireless network is enforcing the MN's QoS so it only gets the amount of bandwidth it paid for. As for the router, as mentioned in Issue 3 on the issues Web page, the protocol should include a provision for rate limiting and a provision allowing the router to selectively drop packets in order to deal with a spike in service requests. jak ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 7:36 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Thursday, March 13, 2003 6:44 PM > To: kempf@docomolabs-usa.com; Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > > > > I'm not sure I understand the attack. > > > > If an attacker sends a completely bogus AP, the AR compares > > against the AAPL > > (Authorized AP List) and rejects. > > If an attacker sends an AP that is not bogus but is not a > > GAAP, then it will > > pass the AAPL test but it will remain in the cache for one > > iteration and be > > flushed aftewards. > [Govind] This is assuming a particular cache replacement policy and assumes > the server approach. I think we should first settle whether the server is needed > or not before coming to cache contamination and other cache related issues. > However, if we are not going to do that, then we should propose how any > scheme involving protecting the cache works in either of the proposed solutions. > > > > So, I don't see how interrouter capability and update > > exchange are affected. > [Govind] First thoughts about this cache replacement policy. I will think about this replacement > policy more later.. Its been a long day already, so sorry if I'm wrong :) > > If the number of malicious MNs increase, then wouldn't you have an increase of the number > of entries? Also, they might not be removed from the cache. More such entries and more > the unnecessary capability messages. Note, if we are using the server scheme, each MN has > the possibility of reporting a large number of such non-GAAPs. Consider this scenario, > 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that > each AP is assigned to a different AR. Further assume that > you have a limit of 100 reports per MN. In your scheme, the chance > of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of > non GAARs are in the cache after each flush. So the current AR will communicate > unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities > exchanged you do have an unnecessary burden on the ARs. You will never be able > to detect this and yet keep exchanging messages between non-CARs. > > Another point, by flipping a coin as you suggest > based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability > of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you > keep relying on the server, thus increasing the average response time. > Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes > to remove bad entries may be a better approach. I'm not saying that this is a bad > cache replacement scheme yet but I'll think about this tomorrow. > > > -Govind. > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 16:47:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15849 for ; Fri, 14 Mar 2003 16:47:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM23O13935; Fri, 14 Mar 2003 17:02:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM16O13866 for ; Fri, 14 Mar 2003 17:01:06 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15807 for ; Fri, 14 Mar 2003 16:45:28 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 16:47:39 -0500 Message-ID: <02db01c2ea8c$a6f74860$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 16:48:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Mar 2003 21:47:39.0763 (UTC) FILETIME=[5592FC30:01C2EA73] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well, there are various pricing models. Also we are doing engineering. Being free does not mean we can abuse it. Eunsoo ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 1:44 PM Subject: RE: [SeaMoby] Topic #3: Cache contamination OK, you are right if MN has assigned bandwidth slice for which it is paying for. - Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, March 14, 2003 12:23 PM To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Hemant, I don't understand. If an attacking MN reports something that is not a GAAP, then sure, maybe it gets some junk, but so what? If the MN wants to be so antisocial, then it gets to deal with the results. As for wireless bandwidth, I assume the wireless network is enforcing the MN's QoS so it only gets the amount of bandwidth it paid for. As for the router, as mentioned in Issue 3 on the issues Web page, the protocol should include a provision for rate limiting and a provision allowing the router to selectively drop packets in order to deal with a spike in service requests. jak ----- Original Message ----- From: To: ; ; ; Sent: Friday, March 14, 2003 7:36 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant > > -----Original Message----- > From: ext Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] > Sent: Thursday, March 13, 2003 6:44 PM > To: kempf@docomolabs-usa.com; Chaskar Hemant (NRC/Boston); eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > > > > I'm not sure I understand the attack. > > > > If an attacker sends a completely bogus AP, the AR compares > > against the AAPL > > (Authorized AP List) and rejects. > > If an attacker sends an AP that is not bogus but is not a > > GAAP, then it will > > pass the AAPL test but it will remain in the cache for one > > iteration and be > > flushed aftewards. > [Govind] This is assuming a particular cache replacement policy and assumes > the server approach. I think we should first settle whether the server is needed > or not before coming to cache contamination and other cache related issues. > However, if we are not going to do that, then we should propose how any > scheme involving protecting the cache works in either of the proposed solutions. > > > > So, I don't see how interrouter capability and update > > exchange are affected. > [Govind] First thoughts about this cache replacement policy. I will think about this replacement > policy more later.. Its been a long day already, so sorry if I'm wrong :) > > If the number of malicious MNs increase, then wouldn't you have an increase of the number > of entries? Also, they might not be removed from the cache. More such entries and more > the unnecessary capability messages. Note, if we are using the server scheme, each MN has > the possibility of reporting a large number of such non-GAAPs. Consider this scenario, > 10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that > each AP is assigned to a different AR. Further assume that > you have a limit of 100 reports per MN. In your scheme, the chance > of it being not removed is (1-1/10) = 0.9. There is a 90% chance that 100 cache entries of > non GAARs are in the cache after each flush. So the current AR will communicate > unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities > exchanged you do have an unnecessary burden on the ARs. You will never be able > to detect this and yet keep exchanging messages between non-CARs. > > Another point, by flipping a coin as you suggest > based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability > of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you > keep relying on the server, thus increasing the average response time. > Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes > to remove bad entries may be a better approach. I'm not saying that this is a bad > cache replacement scheme yet but I'll think about this tomorrow. > > > -Govind. > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 16:52:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15949 for ; Fri, 14 Mar 2003 16:52:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EM7Ew14631 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 17:07:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM7EO14628 for ; Fri, 14 Mar 2003 17:07:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15939 for ; Fri, 14 Mar 2003 16:51:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM72O14232; Fri, 14 Mar 2003 17:07:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM6GO14157 for ; Fri, 14 Mar 2003 17:06:16 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15923 for ; Fri, 14 Mar 2003 16:50:38 -0500 (EST) Message-ID: <020b01c2ea73$d7212f10$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:51:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [Govind] Overall I agree. > The main point is in the server scheme you are using APids > sent by the MNs as the means of populating the cache. So what does Dycard use to populate the cache? The MN is sending AP ids to it via the the RI message (pg. 10) after which the AR uses the PNE message to validate (pg. 5). Seems like the AP ids are the triggering factor for populating the cache. Or am I missing something? >Since you can't restrict > the number of APids it will hear from outside your domain. You have to > consider it while setting the limit in rate limiting. OK. > Other than that I believe that tagging the MN with its identity is a nice way > to restrict the number of cache entries created by the MN. Um, what is the MN's "identity"? It's MIP home address? It's on link care of address? I must have missed this in the draft. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 16:52:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15993 for ; Fri, 14 Mar 2003 16:52:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM72O14232; Fri, 14 Mar 2003 17:07:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM6GO14157 for ; Fri, 14 Mar 2003 17:06:16 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15923 for ; Fri, 14 Mar 2003 16:50:38 -0500 (EST) Message-ID: <020b01c2ea73$d7212f10$286015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 13:51:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [Govind] Overall I agree. > The main point is in the server scheme you are using APids > sent by the MNs as the means of populating the cache. So what does Dycard use to populate the cache? The MN is sending AP ids to it via the the RI message (pg. 10) after which the AR uses the PNE message to validate (pg. 5). Seems like the AP ids are the triggering factor for populating the cache. Or am I missing something? >Since you can't restrict > the number of APids it will hear from outside your domain. You have to > consider it while setting the limit in rate limiting. OK. > Other than that I believe that tagging the MN with its identity is a nice way > to restrict the number of cache entries created by the MN. Um, what is the MN's "identity"? It's MIP home address? It's on link care of address? I must have missed this in the draft. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 18:13:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18843 for ; Fri, 14 Mar 2003 18:13:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ENShZ19264 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 18:28:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ENSgO19261 for ; Fri, 14 Mar 2003 18:28:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18794 for ; Fri, 14 Mar 2003 18:13:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ENSRO19245; Fri, 14 Mar 2003 18:28:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ENR0O19209 for ; Fri, 14 Mar 2003 18:27:00 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18590 for ; Fri, 14 Mar 2003 18:11:20 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2ENDWPO005869 for ; Fri, 14 Mar 2003 16:13:32 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA27134 for ; Fri, 14 Mar 2003 16:13:32 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 17:13:31 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE6B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Robert Chalmers'" , Singh Ajoy-ASINGH1 Cc: "'Eunsoo Shim'" , seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 17:13:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] Sent: Friday, March 14, 2003 2:18 PM To: Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Singh Ajoy-ASINGH1 wrote: > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > It is clearly stated in the draft that the two routers must mutually authenticate one another with the explicit authorization to perform CARD. Are you assuming that this fake AR can in some way authenticate and authorize itself with respect to the attacked AR? If not, the question is moot. If so, then I would question your authentication/authorization scheme. AJOY-> You have rightly pointed out that security of dycard scheme would depend upon how routers authorize and authenticate each other. BTW, what is the proposed scheme for mutual authentication and authorization? Do you believe manual configuration of SA is enough? -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 18:13:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18900 for ; Fri, 14 Mar 2003 18:13:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ENSRO19245; Fri, 14 Mar 2003 18:28:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ENR0O19209 for ; Fri, 14 Mar 2003 18:27:00 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18590 for ; Fri, 14 Mar 2003 18:11:20 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2ENDWPO005869 for ; Fri, 14 Mar 2003 16:13:32 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA27134 for ; Fri, 14 Mar 2003 16:13:32 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 17:13:31 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE6B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Robert Chalmers'" , Singh Ajoy-ASINGH1 Cc: "'Eunsoo Shim'" , seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 17:13:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] Sent: Friday, March 14, 2003 2:18 PM To: Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Singh Ajoy-ASINGH1 wrote: > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > It is clearly stated in the draft that the two routers must mutually authenticate one another with the explicit authorization to perform CARD. Are you assuming that this fake AR can in some way authenticate and authorize itself with respect to the attacked AR? If not, the question is moot. If so, then I would question your authentication/authorization scheme. AJOY-> You have rightly pointed out that security of dycard scheme would depend upon how routers authorize and authenticate each other. BTW, what is the proposed scheme for mutual authentication and authorization? Do you believe manual configuration of SA is enough? -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 18:56:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20017 for ; Fri, 14 Mar 2003 18:56:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F0BIO22156 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 19:11:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0BIO22153 for ; Fri, 14 Mar 2003 19:11:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19983 for ; Fri, 14 Mar 2003 18:55:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0B6O22144; Fri, 14 Mar 2003 19:11:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F09SO22085 for ; Fri, 14 Mar 2003 19:09:28 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19975 for ; Fri, 14 Mar 2003 18:53:47 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2ENtrZj003985 for ; Fri, 14 Mar 2003 16:55:53 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA19121 for ; Fri, 14 Mar 2003 16:55:58 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 17:55:58 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE6D@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , "'James Kempf'" , Govind.Krishnamurthi@nokia.com, Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 17:55:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Friday, March 14, 2003 5:12 PM To: Singh Ajoy-ASINGH1; 'James Kempf'; Govind.Krishnamurthi@nokia.com; Hemant.Chaskar@nokia.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > The first topic is the main thing of this thread. I think the server > > > approach cannot filter out false information or prevent cache > > contamination. > > > I think Dycard can make cache contamination very difficult. > > > > > > > AJOY->Why not ? I am confused here. Could you please explain why do you > > think so? > > > > In the server approach, MN sends the L2 address of an AP to the current AR. > Then the AR retrieves the L2-L3 mapping entry from the server and puts it in > its cache. There is no check whether MN received the beacon of the AP > within the > coverage area of the current AR. So MN can send L2 address of any AP which > is registered in the server and thus the cache of the AR can contain all the > L2-L3 mapping entries even though some of them are not of CARs of the > current AR. > > AJOY-> What is the probability that a malicious MN will send fake AP > id which is also stored in the server ? I am really having hard > time imagining any real scenario like this. > [eunsoo] We are talking about malicious MNs, that is, malicious human beings actually. They can find out AP L2 addresses in the domain by simply walking around. And they can use the information to fill the cache with the L2 addresses. So probabality is not an issue here. > Obviously scope-id is not helpful in verifying the information from MN. > > AJOY-> Scope id is used to avoid the cache overflow problem. I do > not see how this can cause any cache overflow if the router cache is > appropriately sized to store entries for all the routers belonging to the > scope. > [eunsoo]Right. I am pointing it because it was claimed as if scope-id would prevent cache contamination. If nobody claims that scope id prevents cache contamination, then we can skip this. AJOY->The scope-id can be used to limit the cache contamination within the given scope. If you configure the AR cache size appropriately to allow the caching of the maximum number of CAR entries supported in the given domain, then there is no harmful affect of the cache contamination. Also, it should be possible to eliminate the contamination completely if the server maintains a lists of APs and its neighbors and use this information to reject the request when the CARD Req options is being reported from a mobile node attached to a an AP and the AP is not the neighbor of the AP whose AP id is being provided by the mobile node. But I do not see and need for doing this because this will require additional configuration information without any significant advantage. > Now please can you explain how this can be prevented in the server approach? > > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > [eunsoo] To defeat the attack, a simple approach is to accept only authorized ARs as CARs. There are many ways to check authorization of ARs. AJOY-> Ok. Could you please name a few possible approaches of the mutual authentication and authorization of ARs that you have in mind? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 18:56:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20040 for ; Fri, 14 Mar 2003 18:56:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0B6O22144; Fri, 14 Mar 2003 19:11:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F09SO22085 for ; Fri, 14 Mar 2003 19:09:28 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19975 for ; Fri, 14 Mar 2003 18:53:47 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2ENtrZj003985 for ; Fri, 14 Mar 2003 16:55:53 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA19121 for ; Fri, 14 Mar 2003 16:55:58 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 17:55:58 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE6D@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , "'James Kempf'" , Govind.Krishnamurthi@nokia.com, Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 17:55:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Friday, March 14, 2003 5:12 PM To: Singh Ajoy-ASINGH1; 'James Kempf'; Govind.Krishnamurthi@nokia.com; Hemant.Chaskar@nokia.com; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > The first topic is the main thing of this thread. I think the server > > > approach cannot filter out false information or prevent cache > > contamination. > > > I think Dycard can make cache contamination very difficult. > > > > > > > AJOY->Why not ? I am confused here. Could you please explain why do you > > think so? > > > > In the server approach, MN sends the L2 address of an AP to the current AR. > Then the AR retrieves the L2-L3 mapping entry from the server and puts it in > its cache. There is no check whether MN received the beacon of the AP > within the > coverage area of the current AR. So MN can send L2 address of any AP which > is registered in the server and thus the cache of the AR can contain all the > L2-L3 mapping entries even though some of them are not of CARs of the > current AR. > > AJOY-> What is the probability that a malicious MN will send fake AP > id which is also stored in the server ? I am really having hard > time imagining any real scenario like this. > [eunsoo] We are talking about malicious MNs, that is, malicious human beings actually. They can find out AP L2 addresses in the domain by simply walking around. And they can use the information to fill the cache with the L2 addresses. So probabality is not an issue here. > Obviously scope-id is not helpful in verifying the information from MN. > > AJOY-> Scope id is used to avoid the cache overflow problem. I do > not see how this can cause any cache overflow if the router cache is > appropriately sized to store entries for all the routers belonging to the > scope. > [eunsoo]Right. I am pointing it because it was claimed as if scope-id would prevent cache contamination. If nobody claims that scope id prevents cache contamination, then we can skip this. AJOY->The scope-id can be used to limit the cache contamination within the given scope. If you configure the AR cache size appropriately to allow the caching of the maximum number of CAR entries supported in the given domain, then there is no harmful affect of the cache contamination. Also, it should be possible to eliminate the contamination completely if the server maintains a lists of APs and its neighbors and use this information to reject the request when the CARD Req options is being reported from a mobile node attached to a an AP and the AP is not the neighbor of the AP whose AP id is being provided by the mobile node. But I do not see and need for doing this because this will require additional configuration information without any significant advantage. > Now please can you explain how this can be prevented in the server approach? > > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > [eunsoo] To defeat the attack, a simple approach is to accept only authorized ARs as CARs. There are many ways to check authorization of ARs. AJOY-> Ok. Could you please name a few possible approaches of the mutual authentication and authorization of ARs that you have in mind? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 19:20:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20597 for ; Fri, 14 Mar 2003 19:20:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F0ZRI23169 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 19:35:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0ZRO23166 for ; Fri, 14 Mar 2003 19:35:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20582 for ; Fri, 14 Mar 2003 19:19:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0ZDO23158; Fri, 14 Mar 2003 19:35:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0YMO23117 for ; Fri, 14 Mar 2003 19:34:22 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20565 for ; Fri, 14 Mar 2003 19:18:42 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2F0Kq825683 for ; Fri, 14 Mar 2003 18:20:52 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 18:20:52 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 16:20:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 19:20:44 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqf5YR4co2PEK4RT6WtWQh0qrhsgACOpvw To: , Cc: , X-OriginalArrivalTime: 15 Mar 2003 00:20:45.0104 (UTC) FILETIME=[B876CB00:01C2EA88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2F0YNO23118 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Security of all handoff schemes depends upon existence of inter-AR SA. BCPs should be used for this - take cues from routing, policy framework, FMIP and CT. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Friday, March 14, 2003 6:13 PM To: 'Robert Chalmers'; Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination -----Original Message----- From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] Sent: Friday, March 14, 2003 2:18 PM To: Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Singh Ajoy-ASINGH1 wrote: > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > It is clearly stated in the draft that the two routers must mutually authenticate one another with the explicit authorization to perform CARD. Are you assuming that this fake AR can in some way authenticate and authorize itself with respect to the attacked AR? If not, the question is moot. If so, then I would question your authentication/authorization scheme. AJOY-> You have rightly pointed out that security of dycard scheme would depend upon how routers authorize and authenticate each other. BTW, what is the proposed scheme for mutual authentication and authorization? Do you believe manual configuration of SA is enough? -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 19:20:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20610 for ; Fri, 14 Mar 2003 19:20:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0ZDO23158; Fri, 14 Mar 2003 19:35:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0YMO23117 for ; Fri, 14 Mar 2003 19:34:22 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20565 for ; Fri, 14 Mar 2003 19:18:42 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2F0Kq825683 for ; Fri, 14 Mar 2003 18:20:52 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Mar 2003 18:20:52 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 16:20:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 19:20:44 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqf5YR4co2PEK4RT6WtWQh0qrhsgACOpvw To: , Cc: , X-OriginalArrivalTime: 15 Mar 2003 00:20:45.0104 (UTC) FILETIME=[B876CB00:01C2EA88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2F0YNO23118 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Security of all handoff schemes depends upon existence of inter-AR SA. BCPs should be used for this - take cues from routing, policy framework, FMIP and CT. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Friday, March 14, 2003 6:13 PM To: 'Robert Chalmers'; Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination -----Original Message----- From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] Sent: Friday, March 14, 2003 2:18 PM To: Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Singh Ajoy-ASINGH1 wrote: > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > It is clearly stated in the draft that the two routers must mutually authenticate one another with the explicit authorization to perform CARD. Are you assuming that this fake AR can in some way authenticate and authorize itself with respect to the attacked AR? If not, the question is moot. If so, then I would question your authentication/authorization scheme. AJOY-> You have rightly pointed out that security of dycard scheme would depend upon how routers authorize and authenticate each other. BTW, what is the proposed scheme for mutual authentication and authorization? Do you believe manual configuration of SA is enough? -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 20:29:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22145 for ; Fri, 14 Mar 2003 20:29:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F1iTn27823 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 20:44:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1iTO27820 for ; Fri, 14 Mar 2003 20:44:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22138 for ; Fri, 14 Mar 2003 20:28:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1iGO27810; Fri, 14 Mar 2003 20:44:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1hdO27783 for ; Fri, 14 Mar 2003 20:43:39 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22134 for ; Fri, 14 Mar 2003 20:27:57 -0500 (EST) Message-ID: <000501c2ea92$32218ea0$286015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 14 Mar 2003 17:28:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Rev. 2 of Issues List Now Available Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The Issues list has been updated with Govind's comments. It is available at: http://www.geocities.com/kempf42/CARD_Issues_List.htm. Please keep the technical discussion going as time and travel allows. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 20:29:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22158 for ; Fri, 14 Mar 2003 20:29:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1iGO27810; Fri, 14 Mar 2003 20:44:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1hdO27783 for ; Fri, 14 Mar 2003 20:43:39 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22134 for ; Fri, 14 Mar 2003 20:27:57 -0500 (EST) Message-ID: <000501c2ea92$32218ea0$286015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 14 Mar 2003 17:28:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Rev. 2 of Issues List Now Available Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The Issues list has been updated with Govind's comments. It is available at: http://www.geocities.com/kempf42/CARD_Issues_List.htm. Please keep the technical discussion going as time and travel allows. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 20:45:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22468 for ; Fri, 14 Mar 2003 20:45:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F20Pq28290 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 21:00:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F20PO28287 for ; Fri, 14 Mar 2003 21:00:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22462 for ; Fri, 14 Mar 2003 20:44:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F206O28278; Fri, 14 Mar 2003 21:00:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1xxO28232 for ; Fri, 14 Mar 2003 20:59:59 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22457 for ; Fri, 14 Mar 2003 20:44:17 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2F1kP110116; Fri, 14 Mar 2003 17:46:25 -0800 (PST) Message-ID: <3E72858F.5050503@cs.ucsb.edu> Date: Fri, 14 Mar 2003 17:44:47 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] updated dyCARD draft References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> In-Reply-To: <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, > Do you want to propose this text as the resolution to Issue 3? > I think the text is probably a bit rough and too specific to dyCARD, but the idea is about right. I actually sent that e-mail before I read your mail concerning text to resolve the issue. I just wanted to make sure that something was in the draft to address rate limiting (meant to put it in earlier). For some reason, the DT draft stands with gaping holes, but dyCARD has to be explicit in every respect before it's "understandable". In short, we need to be sure that the router can rate limit the messages it receives from MNs, as well as any messages it sends to other participants (neighboring ARs or backend server). On a side note, I agree with you that we should pobably separate the AR-MN signalling from the AR-AR or AR-server signalling. Whether or not the WG wants to standardize mutiple back-end schemes (static, server-based, learning-based), I don't know. Finally, I definitely agree with you that we need some input from people who don't have invested interest in either approach. Please don't take this the wrong way, but are you invested in either approach? It seems that some of the dyHardness might stem from the perception that you might or the DT in general might be invested. Moreover, while the DT was hashing out which direction they would take, we (the dyCARD team) received a lot of questions concerning how to secure the protocol. It was my impression that the the DT eventually went towards the server-based solution because we couldn't guarantee absolutely that the caches could not be contaminated with non-GAAR entries (this is not the same as bad AR-AP mapping - that we can guarantee). With the recent discussion, though, these problems seem to have taken a back seat. Now, it seems that malicious MNs aren't that big of a deal, cache contamination is not a big issue. Maybe, the next step is to start talking about what properties would make for the best protocol, not what's wrong with one approach or the other. my 2 cents, bob >>Folks, >> >>I updated the dyCARD draft with a short section indicating that all >>messages must be rate limited (Section 7.9). The draft is available at >>http://www.cs.ucsb.edu/~robertc/drafts/draft-trossen-seamoby-dycard-01.txt >> >>enjoy, >>bob >> >>-- >>/**************************************************************** >> >> Robert Chalmers >> UCSB Computer Science Doctoral Candidate >> Network and Multimedia Systems Lab (NMSL) >> >> "My heart is in the code, but my soul lies in the process" >> >> | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | >> >>*****************************************************************/ >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby >> > > -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 20:45:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22483 for ; Fri, 14 Mar 2003 20:45:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F206O28278; Fri, 14 Mar 2003 21:00:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1xxO28232 for ; Fri, 14 Mar 2003 20:59:59 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22457 for ; Fri, 14 Mar 2003 20:44:17 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2F1kP110116; Fri, 14 Mar 2003 17:46:25 -0800 (PST) Message-ID: <3E72858F.5050503@cs.ucsb.edu> Date: Fri, 14 Mar 2003 17:44:47 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] updated dyCARD draft References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> In-Reply-To: <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, > Do you want to propose this text as the resolution to Issue 3? > I think the text is probably a bit rough and too specific to dyCARD, but the idea is about right. I actually sent that e-mail before I read your mail concerning text to resolve the issue. I just wanted to make sure that something was in the draft to address rate limiting (meant to put it in earlier). For some reason, the DT draft stands with gaping holes, but dyCARD has to be explicit in every respect before it's "understandable". In short, we need to be sure that the router can rate limit the messages it receives from MNs, as well as any messages it sends to other participants (neighboring ARs or backend server). On a side note, I agree with you that we should pobably separate the AR-MN signalling from the AR-AR or AR-server signalling. Whether or not the WG wants to standardize mutiple back-end schemes (static, server-based, learning-based), I don't know. Finally, I definitely agree with you that we need some input from people who don't have invested interest in either approach. Please don't take this the wrong way, but are you invested in either approach? It seems that some of the dyHardness might stem from the perception that you might or the DT in general might be invested. Moreover, while the DT was hashing out which direction they would take, we (the dyCARD team) received a lot of questions concerning how to secure the protocol. It was my impression that the the DT eventually went towards the server-based solution because we couldn't guarantee absolutely that the caches could not be contaminated with non-GAAR entries (this is not the same as bad AR-AP mapping - that we can guarantee). With the recent discussion, though, these problems seem to have taken a back seat. Now, it seems that malicious MNs aren't that big of a deal, cache contamination is not a big issue. Maybe, the next step is to start talking about what properties would make for the best protocol, not what's wrong with one approach or the other. my 2 cents, bob >>Folks, >> >>I updated the dyCARD draft with a short section indicating that all >>messages must be rate limited (Section 7.9). The draft is available at >>http://www.cs.ucsb.edu/~robertc/drafts/draft-trossen-seamoby-dycard-01.txt >> >>enjoy, >>bob >> >>-- >>/**************************************************************** >> >> Robert Chalmers >> UCSB Computer Science Doctoral Candidate >> Network and Multimedia Systems Lab (NMSL) >> >> "My heart is in the code, but my soul lies in the process" >> >> | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | >> >>*****************************************************************/ >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby >> > > -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 14 20:56:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22694 for ; Fri, 14 Mar 2003 20:56:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F2BKD29394 for seamoby-archive@odin.ietf.org; Fri, 14 Mar 2003 21:11:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F2BJO29391 for ; Fri, 14 Mar 2003 21:11:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22689 for ; Fri, 14 Mar 2003 20:55:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F2B9O29378; Fri, 14 Mar 2003 21:11:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F2AiO29344 for ; Fri, 14 Mar 2003 21:10:44 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22665 for ; Fri, 14 Mar 2003 20:55:01 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2F1tl128490 for ; Sat, 15 Mar 2003 03:55:47 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 15 Mar 2003 03:57:10 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 15 Mar 2003 03:57:10 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 17:55:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 20:55:36 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqhYqWkdh21l4URcyq4yo9zgojDwADxlOA To: , , , , , X-OriginalArrivalTime: 15 Mar 2003 01:55:36.0861 (UTC) FILETIME=[F903FCD0:01C2EA95] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2F2AiO29345 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, >[eunsoo]Right. I am pointing it because it was claimed as if >scope-id would >prevent cache contamination. If nobody claims that scope id >prevents cache >contamination, then we can skip this. > >AJOY->The scope-id can be used to limit the cache >contamination within the >given scope. If you configure the AR cache size appropriately >to allow the >caching of >the maximum number of CAR entries supported in the given >domain, then there >is >no harmful affect of the cache contamination. Also, it should be >possible to eliminate the contamination completely if the server >maintains a lists of APs and its neighbors and >use this information to reject the request when the CARD >Req options is being reported from a mobile node attached >to a an AP and the AP is not the neighbor of the AP whose >AP id is being provided by the mobile node. But I do not >see and need >for doing >this because this will require additional configuration >information without >any significant advantage. Do you actually realize that we have this kind of argument all over again? However, there are still no design guidelines how this "should be possible" and "could be used" might look like. I saw nobody else who tried so desparately to uphold something that is so clearly underdefined in its meaning, and I cannot see anything in the direction of a consensus that this "scope-id" would make any use and would get an entry into a final solution. Maybe we should put a hold on the discussion of this scope-id and its whatever use and try to make progress with other issues. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 14 20:56:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22708 for ; Fri, 14 Mar 2003 20:56:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F2B9O29378; Fri, 14 Mar 2003 21:11:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F2AiO29344 for ; Fri, 14 Mar 2003 21:10:44 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22665 for ; Fri, 14 Mar 2003 20:55:01 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2F1tl128490 for ; Sat, 15 Mar 2003 03:55:47 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 15 Mar 2003 03:57:10 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 15 Mar 2003 03:57:10 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 17:55:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Fri, 14 Mar 2003 20:55:36 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLqhYqWkdh21l4URcyq4yo9zgojDwADxlOA To: , , , , , X-OriginalArrivalTime: 15 Mar 2003 01:55:36.0861 (UTC) FILETIME=[F903FCD0:01C2EA95] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2F2AiO29345 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, >[eunsoo]Right. I am pointing it because it was claimed as if >scope-id would >prevent cache contamination. If nobody claims that scope id >prevents cache >contamination, then we can skip this. > >AJOY->The scope-id can be used to limit the cache >contamination within the >given scope. If you configure the AR cache size appropriately >to allow the >caching of >the maximum number of CAR entries supported in the given >domain, then there >is >no harmful affect of the cache contamination. Also, it should be >possible to eliminate the contamination completely if the server >maintains a lists of APs and its neighbors and >use this information to reject the request when the CARD >Req options is being reported from a mobile node attached >to a an AP and the AP is not the neighbor of the AP whose >AP id is being provided by the mobile node. But I do not >see and need >for doing >this because this will require additional configuration >information without >any significant advantage. Do you actually realize that we have this kind of argument all over again? However, there are still no design guidelines how this "should be possible" and "could be used" might look like. I saw nobody else who tried so desparately to uphold something that is so clearly underdefined in its meaning, and I cannot see anything in the direction of a consensus that this "scope-id" would make any use and would get an entry into a final solution. Maybe we should put a hold on the discussion of this scope-id and its whatever use and try to make progress with other issues. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 15 08:51:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16100 for ; Sat, 15 Mar 2003 08:51:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FE6PU09065 for seamoby-archive@odin.ietf.org; Sat, 15 Mar 2003 09:06:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FE6PO09062 for ; Sat, 15 Mar 2003 09:06:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16091 for ; Sat, 15 Mar 2003 08:50:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FE5hO09042; Sat, 15 Mar 2003 09:05:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FE4JO09012 for ; Sat, 15 Mar 2003 09:04:19 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16065 for ; Sat, 15 Mar 2003 08:48:22 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 08:50:33 -0500 Message-ID: <033801c2eb13$28c8a7e0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> <014b01c2ea5e$6c5e4ce0$286015ac@T23KEMPF> <025201c2ea7b$ddb181b0$e26b0f8a@eunsoo> <01dd01c2ea6d$7f8df5e0$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sat, 15 Mar 2003 08:51:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Mar 2003 13:50:33.0636 (UTC) FILETIME=[D97C6640:01C2EAF9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > [eunsoo] Well, we have used this term for a while. But now you want to > > change it. What do you suggest? > > Anyway, it's a failure of CAR discovery. The first task of the protocol is > > discovering CARs of a given AR. If the protocol could not provide the list > > of CARs for the AR, it failed to do its job. > > > > How about "mapping geographical accuracy"? [eunsoo] Well, it is quite confusing and vague. If a new name is necessary, I'd say "CAR table corruption or contamination". Cache is a term too specific to the server approach. > > > I am repeating this. The application of CARD is not just L2->L3 mapping. Let > > me repeat the example scenario where the false entries are harmful. > > MNs have two interfaces, let say, GPRS and 802.11b. Since 802.11b interface > > consumes lots of power even during idle mode, MN wants to keep it down while > > it is not used. But MN also wants to know whether it should start scanning > > 802.11 channels for APs. Here CARD becomes useful. The AR in the GPRS > > network provides list of CARs to the MN. The information tells that there is > > an AP with 802.11b interface but it is not true. Then MN just turns on its > > 802.11 interface and consumes its power for nothing. > > > > Ah, right I had forgotten that issue. Thanx for reminding me. > > So there are some potential consequences to false information. Though, this > particular consequence is not fatal, just inconvenient. That is, the MN won't > end up handing over to an AP that is a rogue and getting it's traffic stolen, > nor will it get dropped because it handed over to an AP that isn't there, right? > Presumably, when it starts the 802.11 handover, it will do the standard L2 scan > for APs to determine whether a particular AP is there, then discard any CARD > information that is not accurate. > > Though I have in the past been a proponent for this use of CARD, there are some > issues with the granularity of resolution. Suppose my GPRS cell is 10 km in > radius and there are 2 disconnected hotspots 100 m in radus. Unless some real > geographical information like GPS or triagulation is used (which isn't in any of > the proposals), the network can only do an approximate job. So the GPRS router > would end up providing the MN with CARD information, even though the 802.11 > hotspot might not be available. > > But I agree it would be convenient if we could find a way to solve this issue. > [eunsoo] What is a matter of convenience and what else is a matter of vitality? Maybe battery lifetime is a matter of convenience for some people but more than that for other people. I understand it is one of the most significant issues in wireless communications. > > > [eunsoo] 802.11 AP can tell when a MN arrived. Then it can tell its AR about > > it. > > But how? There is no protocol for that (though I personally think there should > be). > > >Or AR can poll the APs for the events. > > > > Polling isn't real time, or, if it is, it would consume router cycles. > [eunsoo]Information about handoff events is all about L2 triggers. You advocated for L2 triggers for fast handoff, didn't you? If they are feasible, certainly we can take advantage of them. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 15 08:51:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16116 for ; Sat, 15 Mar 2003 08:51:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FE5hO09042; Sat, 15 Mar 2003 09:05:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FE4JO09012 for ; Sat, 15 Mar 2003 09:04:19 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16065 for ; Sat, 15 Mar 2003 08:48:22 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 08:50:33 -0500 Message-ID: <033801c2eb13$28c8a7e0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , , References: <008e01c2ea4d$7f096a20$286015ac@T23KEMPF> <01ce01c2ea6e$0e92a970$e26b0f8a@eunsoo> <014b01c2ea5e$6c5e4ce0$286015ac@T23KEMPF> <025201c2ea7b$ddb181b0$e26b0f8a@eunsoo> <01dd01c2ea6d$7f8df5e0$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sat, 15 Mar 2003 08:51:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Mar 2003 13:50:33.0636 (UTC) FILETIME=[D97C6640:01C2EAF9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > [eunsoo] Well, we have used this term for a while. But now you want to > > change it. What do you suggest? > > Anyway, it's a failure of CAR discovery. The first task of the protocol is > > discovering CARs of a given AR. If the protocol could not provide the list > > of CARs for the AR, it failed to do its job. > > > > How about "mapping geographical accuracy"? [eunsoo] Well, it is quite confusing and vague. If a new name is necessary, I'd say "CAR table corruption or contamination". Cache is a term too specific to the server approach. > > > I am repeating this. The application of CARD is not just L2->L3 mapping. Let > > me repeat the example scenario where the false entries are harmful. > > MNs have two interfaces, let say, GPRS and 802.11b. Since 802.11b interface > > consumes lots of power even during idle mode, MN wants to keep it down while > > it is not used. But MN also wants to know whether it should start scanning > > 802.11 channels for APs. Here CARD becomes useful. The AR in the GPRS > > network provides list of CARs to the MN. The information tells that there is > > an AP with 802.11b interface but it is not true. Then MN just turns on its > > 802.11 interface and consumes its power for nothing. > > > > Ah, right I had forgotten that issue. Thanx for reminding me. > > So there are some potential consequences to false information. Though, this > particular consequence is not fatal, just inconvenient. That is, the MN won't > end up handing over to an AP that is a rogue and getting it's traffic stolen, > nor will it get dropped because it handed over to an AP that isn't there, right? > Presumably, when it starts the 802.11 handover, it will do the standard L2 scan > for APs to determine whether a particular AP is there, then discard any CARD > information that is not accurate. > > Though I have in the past been a proponent for this use of CARD, there are some > issues with the granularity of resolution. Suppose my GPRS cell is 10 km in > radius and there are 2 disconnected hotspots 100 m in radus. Unless some real > geographical information like GPS or triagulation is used (which isn't in any of > the proposals), the network can only do an approximate job. So the GPRS router > would end up providing the MN with CARD information, even though the 802.11 > hotspot might not be available. > > But I agree it would be convenient if we could find a way to solve this issue. > [eunsoo] What is a matter of convenience and what else is a matter of vitality? Maybe battery lifetime is a matter of convenience for some people but more than that for other people. I understand it is one of the most significant issues in wireless communications. > > > [eunsoo] 802.11 AP can tell when a MN arrived. Then it can tell its AR about > > it. > > But how? There is no protocol for that (though I personally think there should > be). > > >Or AR can poll the APs for the events. > > > > Polling isn't real time, or, if it is, it would consume router cycles. > [eunsoo]Information about handoff events is all about L2 triggers. You advocated for L2 triggers for fast handoff, didn't you? If they are feasible, certainly we can take advantage of them. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 15 09:05:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16279 for ; Sat, 15 Mar 2003 09:05:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FEKdn10150 for seamoby-archive@odin.ietf.org; Sat, 15 Mar 2003 09:20:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEKcO10147 for ; Sat, 15 Mar 2003 09:20:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16265 for ; Sat, 15 Mar 2003 09:04:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEK7O10133; Sat, 15 Mar 2003 09:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEJiO10085 for ; Sat, 15 Mar 2003 09:19:44 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16260 for ; Sat, 15 Mar 2003 09:03:47 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 09:05:57 -0500 Message-ID: <036801c2eb15$4faddc70$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sat, 15 Mar 2003 09:07:07 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Mar 2003 14:05:57.0929 (UTC) FILETIME=[00685190:01C2EAFC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, I think you are distinguishing two things clearly: discovering GAAP/GAAR and checking authorization of AP/AR. Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is not identified in advance. It is what the protocol should discover. So we can only say an AP/AR is authorized to participate in the CARD protocol or the discovery process. One of the main functionalities of the CARD protocol is to discover GAAP/GAAR and that is what we have to focus on at this moment. How to check an AP/AR is authorized to participate in the CARD protocol can be separated from CARD since it is a kind of general authorization problem. It is almost the same problem with what is in the IP routing protocol. So we can take a look at existing solutions and can take one. Please notice that node<->router protocol has two aspects: discovery process and information distribution process. For the discovery process, we are seeing that we need interaction between router and MN and between router and router in Dycard. Also the server approach requires interaction between router and MN and between router and the server. So simply separating communication between router and MN and between router and router is not appropriate. Anyway, it seems you agree that we don't need the server for CARD. Am I right? Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; "Xiaoming Wang" ; "Daichi Funato" ; Sent: Friday, March 14, 2003 10:00 AM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > Eunsoo, > > So as I understand your argument: > > 1) How the cache gets filled is irrelevent to the router to node CARD, > 2) How the router authorizes what is an authorized GAAP or not is irrelevent to > the router to node CARD. > > Is that right? If so, I accept your argument. > > Furthermore, I would add: > > 3) How a router determines what is and is not an *authorized* GAAP is intimately > intertwined with what is or is not a GAAP, since a GAAP that is not on the AAPL > MUST not be used by the router. This will differ depending on the deployment > situation. For example, in my home network, I want to be able to use a Web page > to configure the routers with a list of authorized GAAPs, and not have to use a > server *or* not have to deal with PNE messages flying around my network. On the > other hand, operators like Docomo want to have easy centralized managment of > many APs and ARs, so a server. Enterprise networks might want to have easy self > configuration, so Dycard's PNE messages. Like Xiaoming said, the configuration > information can come from anywhere. > > This suggests splitting the protocol into to separate parts: > > 1) A router to node protocol that provides an MN with CARD information and > allows the MN to report potential GAAPs, > 2) Configuration and validation of authorized GAAPs. > > How 2) is done can be the subject of a separate specification. This is the point > of Issue 2, Proposal 2, but perhaps we should separate this out into a different > issue. > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "Xiaoming Wang" ; "James Kempf" > ; "Daichi Funato" ; > > Sent: Friday, March 14, 2003 11:40 AM > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > So far, what I heard about the necessity of the server for CARD were two > > things: > > 1) Initial population of the cache > > 2) AP authorization > > > > 1) Initial population of the cache > > There are lots of arguments about whether we really need such initial > > population of the cache. Personally I doubt the need. > > Anyway, as Xiaoming and other folks already pointed out, if it is really > > necessary, such initial population can be done using any existing management > > tool. We don't need to reinvent the wheel for initial router configuration. > > That is, we don't need to introduce any server or protocol for that. > > > > 2) AP authorization > > AP authorization is a very general problem. I think this should be handled > > separately from CARD. How AP should be authorized is a L2 issue and thus is > > not even in the scope of the IETF. We cannot devise a general protocol based > > on IP for AP-AR since such communication depends on the L2 technology and we > > cannot assume IP between AP and AR. What we can do is we assume each AR > > knows the list of APs associated with it. Such information can be configured > > at each AR also using any existing management tool. Thus again, I don't > > think we need to introduce the server of the DT draft for this purpose > > either. > > > > Was there any other item as the necessity of the server for CARD? > > Or does anyone want to propose anything else? > > > > Eunsoo > > > > ----- Original Message ----- > > From: "Xiaoming Wang" > > To: "James Kempf" ; "Daichi Funato" > > ; > > Sent: Thursday, March 13, 2003 8:49 PM > > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > James, > > > > > > > > [xiaoming] I think this can be improved by static configuration at the > > > > > initial stage. Initial data can be computed with the geographical and > > > > > topological information of access network, which is used during > > > > the network > > > > > planning and construction stage. Based on it, learning-based > > > > approach will > > > > > not experience failure at the initial stage and will learn by itself > > > > > dynamically when there is a change of the topology of the > > > > access network, > > > > > and thus performs well at any time. > > > > > > > > > > > > > Where does the router get the static information from? > > > > > > > > > > These static information can be defined as profile for configuation, which > > > can be maitained by management entity. It is as natural as initial > > > configuration of routing table from some predefined information. > > > > > > xiaoming > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 15 09:05:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16304 for ; Sat, 15 Mar 2003 09:05:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEK7O10133; Sat, 15 Mar 2003 09:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEJiO10085 for ; Sat, 15 Mar 2003 09:19:44 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16260 for ; Sat, 15 Mar 2003 09:03:47 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 09:05:57 -0500 Message-ID: <036801c2eb15$4faddc70$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sat, 15 Mar 2003 09:07:07 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Mar 2003 14:05:57.0929 (UTC) FILETIME=[00685190:01C2EAFC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, I think you are distinguishing two things clearly: discovering GAAP/GAAR and checking authorization of AP/AR. Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is not identified in advance. It is what the protocol should discover. So we can only say an AP/AR is authorized to participate in the CARD protocol or the discovery process. One of the main functionalities of the CARD protocol is to discover GAAP/GAAR and that is what we have to focus on at this moment. How to check an AP/AR is authorized to participate in the CARD protocol can be separated from CARD since it is a kind of general authorization problem. It is almost the same problem with what is in the IP routing protocol. So we can take a look at existing solutions and can take one. Please notice that node<->router protocol has two aspects: discovery process and information distribution process. For the discovery process, we are seeing that we need interaction between router and MN and between router and router in Dycard. Also the server approach requires interaction between router and MN and between router and the server. So simply separating communication between router and MN and between router and router is not appropriate. Anyway, it seems you agree that we don't need the server for CARD. Am I right? Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; "Xiaoming Wang" ; "Daichi Funato" ; Sent: Friday, March 14, 2003 10:00 AM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > Eunsoo, > > So as I understand your argument: > > 1) How the cache gets filled is irrelevent to the router to node CARD, > 2) How the router authorizes what is an authorized GAAP or not is irrelevent to > the router to node CARD. > > Is that right? If so, I accept your argument. > > Furthermore, I would add: > > 3) How a router determines what is and is not an *authorized* GAAP is intimately > intertwined with what is or is not a GAAP, since a GAAP that is not on the AAPL > MUST not be used by the router. This will differ depending on the deployment > situation. For example, in my home network, I want to be able to use a Web page > to configure the routers with a list of authorized GAAPs, and not have to use a > server *or* not have to deal with PNE messages flying around my network. On the > other hand, operators like Docomo want to have easy centralized managment of > many APs and ARs, so a server. Enterprise networks might want to have easy self > configuration, so Dycard's PNE messages. Like Xiaoming said, the configuration > information can come from anywhere. > > This suggests splitting the protocol into to separate parts: > > 1) A router to node protocol that provides an MN with CARD information and > allows the MN to report potential GAAPs, > 2) Configuration and validation of authorized GAAPs. > > How 2) is done can be the subject of a separate specification. This is the point > of Issue 2, Proposal 2, but perhaps we should separate this out into a different > issue. > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "Xiaoming Wang" ; "James Kempf" > ; "Daichi Funato" ; > > Sent: Friday, March 14, 2003 11:40 AM > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > So far, what I heard about the necessity of the server for CARD were two > > things: > > 1) Initial population of the cache > > 2) AP authorization > > > > 1) Initial population of the cache > > There are lots of arguments about whether we really need such initial > > population of the cache. Personally I doubt the need. > > Anyway, as Xiaoming and other folks already pointed out, if it is really > > necessary, such initial population can be done using any existing management > > tool. We don't need to reinvent the wheel for initial router configuration. > > That is, we don't need to introduce any server or protocol for that. > > > > 2) AP authorization > > AP authorization is a very general problem. I think this should be handled > > separately from CARD. How AP should be authorized is a L2 issue and thus is > > not even in the scope of the IETF. We cannot devise a general protocol based > > on IP for AP-AR since such communication depends on the L2 technology and we > > cannot assume IP between AP and AR. What we can do is we assume each AR > > knows the list of APs associated with it. Such information can be configured > > at each AR also using any existing management tool. Thus again, I don't > > think we need to introduce the server of the DT draft for this purpose > > either. > > > > Was there any other item as the necessity of the server for CARD? > > Or does anyone want to propose anything else? > > > > Eunsoo > > > > ----- Original Message ----- > > From: "Xiaoming Wang" > > To: "James Kempf" ; "Daichi Funato" > > ; > > Sent: Thursday, March 13, 2003 8:49 PM > > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > James, > > > > > > > > [xiaoming] I think this can be improved by static configuration at the > > > > > initial stage. Initial data can be computed with the geographical and > > > > > topological information of access network, which is used during > > > > the network > > > > > planning and construction stage. Based on it, learning-based > > > > approach will > > > > > not experience failure at the initial stage and will learn by itself > > > > > dynamically when there is a change of the topology of the > > > > access network, > > > > > and thus performs well at any time. > > > > > > > > > > > > > Where does the router get the static information from? > > > > > > > > > > These static information can be defined as profile for configuation, which > > > can be maitained by management entity. It is as natural as initial > > > configuration of routing table from some predefined information. > > > > > > xiaoming > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 15 09:28:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16557 for ; Sat, 15 Mar 2003 09:28:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FEhxU11447 for seamoby-archive@odin.ietf.org; Sat, 15 Mar 2003 09:43:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEhxO11444 for ; Sat, 15 Mar 2003 09:43:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16549 for ; Sat, 15 Mar 2003 09:28:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEh8O11424; Sat, 15 Mar 2003 09:43:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEgYO11402 for ; Sat, 15 Mar 2003 09:42:34 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16536 for ; Sat, 15 Mar 2003 09:26:36 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2FESlIG028426 for ; Sat, 15 Mar 2003 07:28:47 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id HAA06863 for ; Sat, 15 Mar 2003 07:28:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sat, 15 Mar 2003 08:28:02 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE70@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , Singh Ajoy-ASINGH1 , eunsoo@nec-labs.com, kempf@docomolabs-usa.com, Govind.Krishnamurthi@nokia.com, Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sat, 15 Mar 2003 08:26:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Friday, March 14, 2003 7:56 PM To: Ajoy Singh; eunsoo@nec-labs.com; kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; Hemant.Chaskar@nokia.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Hi, >[eunsoo]Right. I am pointing it because it was claimed as if >scope-id would >prevent cache contamination. If nobody claims that scope id >prevents cache >contamination, then we can skip this. > >AJOY->The scope-id can be used to limit the cache >contamination within the >given scope. If you configure the AR cache size appropriately >to allow the >caching of >the maximum number of CAR entries supported in the given >domain, then there >is >no harmful affect of the cache contamination. Also, it should be >possible to eliminate the contamination completely if the server >maintains a lists of APs and its neighbors and >use this information to reject the request when the CARD >Req options is being reported from a mobile node attached >to a an AP and the AP is not the neighbor of the AP whose >AP id is being provided by the mobile node. But I do not >see and need >for doing >this because this will require additional configuration >information without >any significant advantage. Do you actually realize that we have this kind of argument all over again? However, there are still no design guidelines how this "should be possible" and "could be used" might look like. I saw nobody else who tried so desparately to uphold something that is so clearly underdefined in its meaning, and I cannot see anything in the direction of a consensus that this "scope-id" would make any use and would get an entry into a final solution. Maybe we should put a hold on the discussion of this scope-id and its whatever use and try to make progress with other issues. AJOY-> I am not sure what is your confusion though. Let us meet offline in IETF and discuss the issue of scope id. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 15 09:28:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16570 for ; Sat, 15 Mar 2003 09:28:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEh8O11424; Sat, 15 Mar 2003 09:43:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEgYO11402 for ; Sat, 15 Mar 2003 09:42:34 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16536 for ; Sat, 15 Mar 2003 09:26:36 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2FESlIG028426 for ; Sat, 15 Mar 2003 07:28:47 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id HAA06863 for ; Sat, 15 Mar 2003 07:28:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sat, 15 Mar 2003 08:28:02 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE70@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Dirk.Trossen@nokia.com'" , Singh Ajoy-ASINGH1 , eunsoo@nec-labs.com, kempf@docomolabs-usa.com, Govind.Krishnamurthi@nokia.com, Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sat, 15 Mar 2003 08:26:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Friday, March 14, 2003 7:56 PM To: Ajoy Singh; eunsoo@nec-labs.com; kempf@docomolabs-usa.com; Govind.Krishnamurthi@nokia.com; Hemant.Chaskar@nokia.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Hi, >[eunsoo]Right. I am pointing it because it was claimed as if >scope-id would >prevent cache contamination. If nobody claims that scope id >prevents cache >contamination, then we can skip this. > >AJOY->The scope-id can be used to limit the cache >contamination within the >given scope. If you configure the AR cache size appropriately >to allow the >caching of >the maximum number of CAR entries supported in the given >domain, then there >is >no harmful affect of the cache contamination. Also, it should be >possible to eliminate the contamination completely if the server >maintains a lists of APs and its neighbors and >use this information to reject the request when the CARD >Req options is being reported from a mobile node attached >to a an AP and the AP is not the neighbor of the AP whose >AP id is being provided by the mobile node. But I do not >see and need >for doing >this because this will require additional configuration >information without >any significant advantage. Do you actually realize that we have this kind of argument all over again? However, there are still no design guidelines how this "should be possible" and "could be used" might look like. I saw nobody else who tried so desparately to uphold something that is so clearly underdefined in its meaning, and I cannot see anything in the direction of a consensus that this "scope-id" would make any use and would get an entry into a final solution. Maybe we should put a hold on the discussion of this scope-id and its whatever use and try to make progress with other issues. AJOY-> I am not sure what is your confusion though. Let us meet offline in IETF and discuss the issue of scope id. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 15 09:38:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16859 for ; Sat, 15 Mar 2003 09:38:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FErXi11754 for seamoby-archive@odin.ietf.org; Sat, 15 Mar 2003 09:53:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FErWO11751 for ; Sat, 15 Mar 2003 09:53:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16852 for ; Sat, 15 Mar 2003 09:37:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEr3O11728; Sat, 15 Mar 2003 09:53:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEqmO11694 for ; Sat, 15 Mar 2003 09:52:48 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16823 for ; Sat, 15 Mar 2003 09:36:50 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 09:39:01 -0500 Message-ID: <037c01c2eb19$edae7b60$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> <036801c2eb15$4faddc70$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sat, 15 Mar 2003 09:40:10 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Mar 2003 14:39:01.0134 (UTC) FILETIME=[9E7D62E0:01C2EB00] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Below I missed one word "NOT". To clarify the meaning, please let me copy the text with "NOT". > James, > > I think you are NOT distinguishing two things clearly: discovering GAAP/GAAR and > checking authorization of AP/AR. > Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is > not identified in advance. It is what the protocol should discover. So we > can only say an AP/AR is authorized to participate in the CARD protocol or > the discovery process. > One of the main functionalities of the CARD protocol is to discover > GAAP/GAAR and that is what we have to focus on at this moment. > > How to check an AP/AR is authorized to participate in the CARD protocol can > be separated from CARD since it is a kind of general authorization problem. > It is almost the same problem with what is in the IP routing protocol. So we > can take a look at existing solutions and can take one. > > Please notice that node<->router protocol has two aspects: discovery process > and information distribution process. > For the discovery process, we are seeing that we need interaction between > router and MN and between router and router in Dycard. Also the server > approach requires interaction between router and MN and between router and > the server. So simply separating communication between router and MN and > between router and router is not appropriate. > > Anyway, it seems you agree that we don't need the server for CARD. Am I > right? > > Eunsoo > ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Xiaoming Wang" ; "Daichi Funato" ; Sent: Saturday, March 15, 2003 9:07 AM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > James, > > I think you are distinguishing two things clearly: discovering GAAP/GAAR and > checking authorization of AP/AR. > Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is > not identified in advance. It is what the protocol should discover. So we > can only say an AP/AR is authorized to participate in the CARD protocol or > the discovery process. > One of the main functionalities of the CARD protocol is to discover > GAAP/GAAR and that is what we have to focus on at this moment. > > How to check an AP/AR is authorized to participate in the CARD protocol can > be separated from CARD since it is a kind of general authorization problem. > It is almost the same problem with what is in the IP routing protocol. So we > can take a look at existing solutions and can take one. > > Please notice that node<->router protocol has two aspects: discovery process > and information distribution process. > For the discovery process, we are seeing that we need interaction between > router and MN and between router and router in Dycard. Also the server > approach requires interaction between router and MN and between router and > the server. So simply separating communication between router and MN and > between router and router is not appropriate. > > Anyway, it seems you agree that we don't need the server for CARD. Am I > right? > > Eunsoo > > > ----- Original Message ----- > From: "James Kempf" > To: "Eunsoo Shim" ; "Xiaoming Wang" > ; "Daichi Funato" ; > > Sent: Friday, March 14, 2003 10:00 AM > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > Eunsoo, > > > > So as I understand your argument: > > > > 1) How the cache gets filled is irrelevent to the router to node CARD, > > 2) How the router authorizes what is an authorized GAAP or not is > irrelevent to > > the router to node CARD. > > > > Is that right? If so, I accept your argument. > > > > Furthermore, I would add: > > > > 3) How a router determines what is and is not an *authorized* GAAP is > intimately > > intertwined with what is or is not a GAAP, since a GAAP that is not on the > AAPL > > MUST not be used by the router. This will differ depending on the > deployment > > situation. For example, in my home network, I want to be able to use a Web > page > > to configure the routers with a list of authorized GAAPs, and not have to > use a > > server *or* not have to deal with PNE messages flying around my network. > On the > > other hand, operators like Docomo want to have easy centralized managment > of > > many APs and ARs, so a server. Enterprise networks might want to have easy > self > > configuration, so Dycard's PNE messages. Like Xiaoming said, the > configuration > > information can come from anywhere. > > > > This suggests splitting the protocol into to separate parts: > > > > 1) A router to node protocol that provides an MN with CARD information and > > allows the MN to report potential GAAPs, > > 2) Configuration and validation of authorized GAAPs. > > > > How 2) is done can be the subject of a separate specification. This is the > point > > of Issue 2, Proposal 2, but perhaps we should separate this out into a > different > > issue. > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "Xiaoming Wang" ; "James Kempf" > > ; "Daichi Funato" ; > > > > Sent: Friday, March 14, 2003 11:40 AM > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > So far, what I heard about the necessity of the server for CARD were two > > > things: > > > 1) Initial population of the cache > > > 2) AP authorization > > > > > > 1) Initial population of the cache > > > There are lots of arguments about whether we really need such initial > > > population of the cache. Personally I doubt the need. > > > Anyway, as Xiaoming and other folks already pointed out, if it is really > > > necessary, such initial population can be done using any existing > management > > > tool. We don't need to reinvent the wheel for initial router > configuration. > > > That is, we don't need to introduce any server or protocol for that. > > > > > > 2) AP authorization > > > AP authorization is a very general problem. I think this should be > handled > > > separately from CARD. How AP should be authorized is a L2 issue and thus > is > > > not even in the scope of the IETF. We cannot devise a general protocol > based > > > on IP for AP-AR since such communication depends on the L2 technology > and we > > > cannot assume IP between AP and AR. What we can do is we assume each AR > > > knows the list of APs associated with it. Such information can be > configured > > > at each AR also using any existing management tool. Thus again, I don't > > > think we need to introduce the server of the DT draft for this purpose > > > either. > > > > > > Was there any other item as the necessity of the server for CARD? > > > Or does anyone want to propose anything else? > > > > > > Eunsoo > > > > > > ----- Original Message ----- > > > From: "Xiaoming Wang" > > > To: "James Kempf" ; "Daichi Funato" > > > ; > > > Sent: Thursday, March 13, 2003 8:49 PM > > > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > > James, > > > > > > > > > > [xiaoming] I think this can be improved by static configuration at > the > > > > > > initial stage. Initial data can be computed with the geographical > and > > > > > > topological information of access network, which is used during > > > > > the network > > > > > > planning and construction stage. Based on it, learning-based > > > > > approach will > > > > > > not experience failure at the initial stage and will learn by > itself > > > > > > dynamically when there is a change of the topology of the > > > > > access network, > > > > > > and thus performs well at any time. > > > > > > > > > > > > > > > > Where does the router get the static information from? > > > > > > > > > > > > > These static information can be defined as profile for configuation, > which > > > > can be maitained by management entity. It is as natural as initial > > > > configuration of routing table from some predefined information. > > > > > > > > xiaoming > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 15 09:39:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16884 for ; Sat, 15 Mar 2003 09:39:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEr3O11728; Sat, 15 Mar 2003 09:53:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEqmO11694 for ; Sat, 15 Mar 2003 09:52:48 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16823 for ; Sat, 15 Mar 2003 09:36:50 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 09:39:01 -0500 Message-ID: <037c01c2eb19$edae7b60$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> <036801c2eb15$4faddc70$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sat, 15 Mar 2003 09:40:10 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Mar 2003 14:39:01.0134 (UTC) FILETIME=[9E7D62E0:01C2EB00] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Below I missed one word "NOT". To clarify the meaning, please let me copy the text with "NOT". > James, > > I think you are NOT distinguishing two things clearly: discovering GAAP/GAAR and > checking authorization of AP/AR. > Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is > not identified in advance. It is what the protocol should discover. So we > can only say an AP/AR is authorized to participate in the CARD protocol or > the discovery process. > One of the main functionalities of the CARD protocol is to discover > GAAP/GAAR and that is what we have to focus on at this moment. > > How to check an AP/AR is authorized to participate in the CARD protocol can > be separated from CARD since it is a kind of general authorization problem. > It is almost the same problem with what is in the IP routing protocol. So we > can take a look at existing solutions and can take one. > > Please notice that node<->router protocol has two aspects: discovery process > and information distribution process. > For the discovery process, we are seeing that we need interaction between > router and MN and between router and router in Dycard. Also the server > approach requires interaction between router and MN and between router and > the server. So simply separating communication between router and MN and > between router and router is not appropriate. > > Anyway, it seems you agree that we don't need the server for CARD. Am I > right? > > Eunsoo > ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; "Xiaoming Wang" ; "Daichi Funato" ; Sent: Saturday, March 15, 2003 9:07 AM Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > James, > > I think you are distinguishing two things clearly: discovering GAAP/GAAR and > checking authorization of AP/AR. > Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is > not identified in advance. It is what the protocol should discover. So we > can only say an AP/AR is authorized to participate in the CARD protocol or > the discovery process. > One of the main functionalities of the CARD protocol is to discover > GAAP/GAAR and that is what we have to focus on at this moment. > > How to check an AP/AR is authorized to participate in the CARD protocol can > be separated from CARD since it is a kind of general authorization problem. > It is almost the same problem with what is in the IP routing protocol. So we > can take a look at existing solutions and can take one. > > Please notice that node<->router protocol has two aspects: discovery process > and information distribution process. > For the discovery process, we are seeing that we need interaction between > router and MN and between router and router in Dycard. Also the server > approach requires interaction between router and MN and between router and > the server. So simply separating communication between router and MN and > between router and router is not appropriate. > > Anyway, it seems you agree that we don't need the server for CARD. Am I > right? > > Eunsoo > > > ----- Original Message ----- > From: "James Kempf" > To: "Eunsoo Shim" ; "Xiaoming Wang" > ; "Daichi Funato" ; > > Sent: Friday, March 14, 2003 10:00 AM > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > Eunsoo, > > > > So as I understand your argument: > > > > 1) How the cache gets filled is irrelevent to the router to node CARD, > > 2) How the router authorizes what is an authorized GAAP or not is > irrelevent to > > the router to node CARD. > > > > Is that right? If so, I accept your argument. > > > > Furthermore, I would add: > > > > 3) How a router determines what is and is not an *authorized* GAAP is > intimately > > intertwined with what is or is not a GAAP, since a GAAP that is not on the > AAPL > > MUST not be used by the router. This will differ depending on the > deployment > > situation. For example, in my home network, I want to be able to use a Web > page > > to configure the routers with a list of authorized GAAPs, and not have to > use a > > server *or* not have to deal with PNE messages flying around my network. > On the > > other hand, operators like Docomo want to have easy centralized managment > of > > many APs and ARs, so a server. Enterprise networks might want to have easy > self > > configuration, so Dycard's PNE messages. Like Xiaoming said, the > configuration > > information can come from anywhere. > > > > This suggests splitting the protocol into to separate parts: > > > > 1) A router to node protocol that provides an MN with CARD information and > > allows the MN to report potential GAAPs, > > 2) Configuration and validation of authorized GAAPs. > > > > How 2) is done can be the subject of a separate specification. This is the > point > > of Issue 2, Proposal 2, but perhaps we should separate this out into a > different > > issue. > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "Xiaoming Wang" ; "James Kempf" > > ; "Daichi Funato" ; > > > > Sent: Friday, March 14, 2003 11:40 AM > > Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > So far, what I heard about the necessity of the server for CARD were two > > > things: > > > 1) Initial population of the cache > > > 2) AP authorization > > > > > > 1) Initial population of the cache > > > There are lots of arguments about whether we really need such initial > > > population of the cache. Personally I doubt the need. > > > Anyway, as Xiaoming and other folks already pointed out, if it is really > > > necessary, such initial population can be done using any existing > management > > > tool. We don't need to reinvent the wheel for initial router > configuration. > > > That is, we don't need to introduce any server or protocol for that. > > > > > > 2) AP authorization > > > AP authorization is a very general problem. I think this should be > handled > > > separately from CARD. How AP should be authorized is a L2 issue and thus > is > > > not even in the scope of the IETF. We cannot devise a general protocol > based > > > on IP for AP-AR since such communication depends on the L2 technology > and we > > > cannot assume IP between AP and AR. What we can do is we assume each AR > > > knows the list of APs associated with it. Such information can be > configured > > > at each AR also using any existing management tool. Thus again, I don't > > > think we need to introduce the server of the DT draft for this purpose > > > either. > > > > > > Was there any other item as the necessity of the server for CARD? > > > Or does anyone want to propose anything else? > > > > > > Eunsoo > > > > > > ----- Original Message ----- > > > From: "Xiaoming Wang" > > > To: "James Kempf" ; "Daichi Funato" > > > ; > > > Sent: Thursday, March 13, 2003 8:49 PM > > > Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD > > > > > > > > > > James, > > > > > > > > > > [xiaoming] I think this can be improved by static configuration at > the > > > > > > initial stage. Initial data can be computed with the geographical > and > > > > > > topological information of access network, which is used during > > > > > the network > > > > > > planning and construction stage. Based on it, learning-based > > > > > approach will > > > > > > not experience failure at the initial stage and will learn by > itself > > > > > > dynamically when there is a change of the topology of the > > > > > access network, > > > > > > and thus performs well at any time. > > > > > > > > > > > > > > > > Where does the router get the static information from? > > > > > > > > > > > > > These static information can be defined as profile for configuation, > which > > > > can be maitained by management entity. It is as natural as initial > > > > configuration of routing table from some predefined information. > > > > > > > > xiaoming > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 15 10:10:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18077 for ; Sat, 15 Mar 2003 10:10:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FFQ2F13440 for seamoby-archive@odin.ietf.org; Sat, 15 Mar 2003 10:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFQ2O13437 for ; Sat, 15 Mar 2003 10:26:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17889 for ; Sat, 15 Mar 2003 10:10:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFPTO13403; Sat, 15 Mar 2003 10:25:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFOaO13367 for ; Sat, 15 Mar 2003 10:24:36 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17736 for ; Sat, 15 Mar 2003 10:08:37 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2FFABu5025845 for ; Sat, 15 Mar 2003 08:10:11 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id IAA11283 for ; Sat, 15 Mar 2003 08:10:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sat, 15 Mar 2003 09:10:47 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE71@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Singh Ajoy-ASINGH1 , robertc@cs.ucsb.edu Cc: eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sat, 15 Mar 2003 09:08:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , I think the security requirement of CARD is not same as that of FMIP. In CARD, the routers have to mutually authorize each other for validating and updating the L3->L3 mapping and capabilities based upon indication from a random MN which will eventually impact the other mobile nodes in the long run. Whereas in the fast handoff, this only impacts the mobile node in handoff. So, we need to better understand how such authorization will work in context of CARD especially dyCard. What are the possible tools available for enabling such inter-AR authorization of dyCard ARs? In server based approach I do see server (e.g.,AAA) playing such a role. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Friday, March 14, 2003 6:21 PM To: Ajoy Singh; robertc@cs.ucsb.edu Cc: eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Security of all handoff schemes depends upon existence of inter-AR SA. BCPs should be used for this - take cues from routing, policy framework, FMIP and CT. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Friday, March 14, 2003 6:13 PM To: 'Robert Chalmers'; Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination -----Original Message----- From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] Sent: Friday, March 14, 2003 2:18 PM To: Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Singh Ajoy-ASINGH1 wrote: > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > It is clearly stated in the draft that the two routers must mutually authenticate one another with the explicit authorization to perform CARD. Are you assuming that this fake AR can in some way authenticate and authorize itself with respect to the attacked AR? If not, the question is moot. If so, then I would question your authentication/authorization scheme. AJOY-> You have rightly pointed out that security of dycard scheme would depend upon how routers authorize and authenticate each other. BTW, what is the proposed scheme for mutual authentication and authorization? Do you believe manual configuration of SA is enough? -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 15 10:10:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18106 for ; Sat, 15 Mar 2003 10:10:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFPTO13403; Sat, 15 Mar 2003 10:25:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFOaO13367 for ; Sat, 15 Mar 2003 10:24:36 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17736 for ; Sat, 15 Mar 2003 10:08:37 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2FFABu5025845 for ; Sat, 15 Mar 2003 08:10:11 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id IAA11283 for ; Sat, 15 Mar 2003 08:10:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sat, 15 Mar 2003 09:10:47 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE71@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Hemant.Chaskar@nokia.com'" , Singh Ajoy-ASINGH1 , robertc@cs.ucsb.edu Cc: eunsoo@nec-labs.com, seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sat, 15 Mar 2003 09:08:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , I think the security requirement of CARD is not same as that of FMIP. In CARD, the routers have to mutually authorize each other for validating and updating the L3->L3 mapping and capabilities based upon indication from a random MN which will eventually impact the other mobile nodes in the long run. Whereas in the fast handoff, this only impacts the mobile node in handoff. So, we need to better understand how such authorization will work in context of CARD especially dyCard. What are the possible tools available for enabling such inter-AR authorization of dyCard ARs? In server based approach I do see server (e.g.,AAA) playing such a role. Regards, Ajoy -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Friday, March 14, 2003 6:21 PM To: Ajoy Singh; robertc@cs.ucsb.edu Cc: eunsoo@nec-labs.com; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Security of all handoff schemes depends upon existence of inter-AR SA. BCPs should be used for this - take cues from routing, policy framework, FMIP and CT. - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Friday, March 14, 2003 6:13 PM To: 'Robert Chalmers'; Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination -----Original Message----- From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] Sent: Friday, March 14, 2003 2:18 PM To: Singh Ajoy-ASINGH1 Cc: 'Eunsoo Shim'; seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Singh Ajoy-ASINGH1 wrote: > AJOY-> BTW, I have a cache contamination question about dycard. Let us > assume that > a fake MN has some collaboration with fake router which is > also connected to the internet and the fake MN sends > a message to the current AR indicating that fake router > is the valid CAR ? How the dycard assures that it > does create an entry in its local cache? > It is clearly stated in the draft that the two routers must mutually authenticate one another with the explicit authorization to perform CARD. Are you assuming that this fake AR can in some way authenticate and authorize itself with respect to the attacked AR? If not, the question is moot. If so, then I would question your authentication/authorization scheme. AJOY-> You have rightly pointed out that security of dycard scheme would depend upon how routers authorize and authenticate each other. BTW, what is the proposed scheme for mutual authentication and authorization? Do you believe manual configuration of SA is enough? -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 15 10:48:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19544 for ; Sat, 15 Mar 2003 10:48:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FG3rF15327 for seamoby-archive@odin.ietf.org; Sat, 15 Mar 2003 11:03:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FG3rO15324 for ; Sat, 15 Mar 2003 11:03:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19512 for ; Sat, 15 Mar 2003 10:47:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FG39O15283; Sat, 15 Mar 2003 11:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FG2KO15252 for ; Sat, 15 Mar 2003 11:02:20 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19482 for ; Sat, 15 Mar 2003 10:46:21 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 10:48:33 -0500 Message-ID: <038e01c2eb23$a430a7b0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE71@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sat, 15 Mar 2003 10:49:42 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Mar 2003 15:48:33.0060 (UTC) FILETIME=[5526C640:01C2EB0A] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ajoy, The role of the server in the server approach is currently storing all L2-L3 mapping entries and providing them at the request by ARs. You may say the program of the CARD server can be also running in the AAA server but two servers are very different in terms of functionality and involved protocols. Dycard does not exclude existence of an AAA server at all. I think the security requirements for CARD regarding AR authorization is quite similar to that of IP routing protocols. There are already proposed/implemented solutions for IP routing protocol security. We had a separate thread for the need of the server for CARD. It was being summarized and so far there was no compelling reason to have a server for CARD. If you want to propose the server as the AAA server, please can you do it in that thread? Eunsoo ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: ; "Singh Ajoy-ASINGH1" ; Cc: ; Sent: Saturday, March 15, 2003 7:08 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I think the security requirement of CARD is not same > as that of FMIP. In CARD, the routers have to mutually > authorize each other for validating and updating > the L3->L3 mapping and capabilities based upon indication > from a random MN which will eventually impact the other mobile > nodes in the long run. Whereas in the fast handoff, > this only impacts the mobile node in handoff. So, we need to > better understand how such authorization will work in context of > CARD especially dyCard. What are the possible tools available > for enabling such inter-AR authorization of dyCard ARs? In server based > approach I do see server (e.g.,AAA) playing such a role. > > Regards, > Ajoy > > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: Friday, March 14, 2003 6:21 PM > To: Ajoy Singh; robertc@cs.ucsb.edu > Cc: eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > Security of all handoff schemes depends upon existence of inter-AR SA. BCPs > should be used for this - take cues from routing, policy framework, FMIP and > CT. - Hemant > > -----Original Message----- > From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Friday, March 14, 2003 6:13 PM > To: 'Robert Chalmers'; Singh Ajoy-ASINGH1 > Cc: 'Eunsoo Shim'; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > -----Original Message----- > From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] > Sent: Friday, March 14, 2003 2:18 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Eunsoo Shim'; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > Singh Ajoy-ASINGH1 wrote: > > > > AJOY-> BTW, I have a cache contamination question about dycard. Let us > > assume that > > a fake MN has some collaboration with fake router which is > > also connected to the internet and the fake MN sends > > a message to the current AR indicating that fake router > > is the valid CAR ? How the dycard assures that it > > does create an entry in its local cache? > > > It is clearly stated in the draft that the two routers must mutually > authenticate one another with the explicit authorization to perform > CARD. Are you assuming that this fake AR can in some way authenticate > and authorize itself with respect to the attacked AR? If not, the > question is moot. If so, then I would question your > authentication/authorization scheme. > > AJOY-> You have rightly pointed out that security of > dycard scheme would depend upon how routers authorize and > authenticate each other. BTW, what is the proposed > scheme for mutual authentication and authorization? > Do you believe manual configuration of SA is enough? > > > > > -- > /**************************************************************** > > Robert Chalmers > UCSB Computer Science Doctoral Candidate > Network and Multimedia Systems Lab (NMSL) > > "My heart is in the code, but my soul lies in the process" > > | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | > > *****************************************************************/ > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 15 10:48:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19562 for ; Sat, 15 Mar 2003 10:48:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FG39O15283; Sat, 15 Mar 2003 11:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FG2KO15252 for ; Sat, 15 Mar 2003 11:02:20 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19482 for ; Sat, 15 Mar 2003 10:46:21 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 10:48:33 -0500 Message-ID: <038e01c2eb23$a430a7b0$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE71@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sat, 15 Mar 2003 10:49:42 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Mar 2003 15:48:33.0060 (UTC) FILETIME=[5526C640:01C2EB0A] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ajoy, The role of the server in the server approach is currently storing all L2-L3 mapping entries and providing them at the request by ARs. You may say the program of the CARD server can be also running in the AAA server but two servers are very different in terms of functionality and involved protocols. Dycard does not exclude existence of an AAA server at all. I think the security requirements for CARD regarding AR authorization is quite similar to that of IP routing protocols. There are already proposed/implemented solutions for IP routing protocol security. We had a separate thread for the need of the server for CARD. It was being summarized and so far there was no compelling reason to have a server for CARD. If you want to propose the server as the AAA server, please can you do it in that thread? Eunsoo ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: ; "Singh Ajoy-ASINGH1" ; Cc: ; Sent: Saturday, March 15, 2003 7:08 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I think the security requirement of CARD is not same > as that of FMIP. In CARD, the routers have to mutually > authorize each other for validating and updating > the L3->L3 mapping and capabilities based upon indication > from a random MN which will eventually impact the other mobile > nodes in the long run. Whereas in the fast handoff, > this only impacts the mobile node in handoff. So, we need to > better understand how such authorization will work in context of > CARD especially dyCard. What are the possible tools available > for enabling such inter-AR authorization of dyCard ARs? In server based > approach I do see server (e.g.,AAA) playing such a role. > > Regards, > Ajoy > > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: Friday, March 14, 2003 6:21 PM > To: Ajoy Singh; robertc@cs.ucsb.edu > Cc: eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > Security of all handoff schemes depends upon existence of inter-AR SA. BCPs > should be used for this - take cues from routing, policy framework, FMIP and > CT. - Hemant > > -----Original Message----- > From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Friday, March 14, 2003 6:13 PM > To: 'Robert Chalmers'; Singh Ajoy-ASINGH1 > Cc: 'Eunsoo Shim'; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > -----Original Message----- > From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] > Sent: Friday, March 14, 2003 2:18 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Eunsoo Shim'; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > Singh Ajoy-ASINGH1 wrote: > > > > AJOY-> BTW, I have a cache contamination question about dycard. Let us > > assume that > > a fake MN has some collaboration with fake router which is > > also connected to the internet and the fake MN sends > > a message to the current AR indicating that fake router > > is the valid CAR ? How the dycard assures that it > > does create an entry in its local cache? > > > It is clearly stated in the draft that the two routers must mutually > authenticate one another with the explicit authorization to perform > CARD. Are you assuming that this fake AR can in some way authenticate > and authorize itself with respect to the attacked AR? If not, the > question is moot. If so, then I would question your > authentication/authorization scheme. > > AJOY-> You have rightly pointed out that security of > dycard scheme would depend upon how routers authorize and > authenticate each other. BTW, what is the proposed > scheme for mutual authentication and authorization? > Do you believe manual configuration of SA is enough? > > > > > -- > /**************************************************************** > > Robert Chalmers > UCSB Computer Science Doctoral Candidate > Network and Multimedia Systems Lab (NMSL) > > "My heart is in the code, but my soul lies in the process" > > | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | > > *****************************************************************/ > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 15 15:11:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24785 for ; Sat, 15 Mar 2003 15:11:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FKR9830575 for seamoby-archive@odin.ietf.org; Sat, 15 Mar 2003 15:27:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKR9O30572 for ; Sat, 15 Mar 2003 15:27:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24741 for ; Sat, 15 Mar 2003 15:11:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKQVO30552; Sat, 15 Mar 2003 15:26:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKPjO30528 for ; Sat, 15 Mar 2003 15:25:45 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24448 for ; Sat, 15 Mar 2003 15:09:41 -0500 (EST) Message-ID: <005f01c2eb2e$e6d050b0$456015ac@T23KEMPF> From: "James Kempf" To: "Robert Chalmers" Cc: References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> <3E72858F.5050503@cs.ucsb.edu> Subject: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) Date: Sat, 15 Mar 2003 12:10:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert, > I think the text is probably a bit rough and too specific to dyCARD, but > the idea is about right. I actually sent that e-mail before I read your > mail concerning text to resolve the issue. I just wanted to make sure > that something was in the draft to address rate limiting (meant to put > it in earlier). For some reason, the DT draft stands with gaping holes, > but dyCARD has to be explicit in every respect before it's "understandable". > I think you and perhaps others in the WG may have some misunderstands about the nature of IETF Design Teams. The product of the Design Team is only a suggestion and it can be amended by the Working Group. Thus, if it turns out that the DT draft has "gaping holes" (and I would be the last one to suggest that it is a finished product), they must be filled. If it turns out that Dycard has some good ideas to fill them, and the WG agrees, then those ideas will be used. I believe the discussion in the last couple weeks has identified a couple holes in the DT draft, and I believe there have been some reasonable suggestions from the Dycard team to fill them. We need to consider them. Of course, if the intent of the Dycard team in posting the draft was that the Dycard design was a "take it or leave it" proposition, then I'm afraid that is not how IETF WGs function. Even if the original base WG draft is an individual contribution, it is often amended and ultimately may look nothing like the original design (in fact, the original designers may get sick of working on it and leave the working group after a couple years). jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 15 15:11:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24813 for ; Sat, 15 Mar 2003 15:11:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKQVO30552; Sat, 15 Mar 2003 15:26:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKPjO30528 for ; Sat, 15 Mar 2003 15:25:45 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24448 for ; Sat, 15 Mar 2003 15:09:41 -0500 (EST) Message-ID: <005f01c2eb2e$e6d050b0$456015ac@T23KEMPF> From: "James Kempf" To: "Robert Chalmers" Cc: References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> <3E72858F.5050503@cs.ucsb.edu> Subject: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) Date: Sat, 15 Mar 2003 12:10:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, > I think the text is probably a bit rough and too specific to dyCARD, but > the idea is about right. I actually sent that e-mail before I read your > mail concerning text to resolve the issue. I just wanted to make sure > that something was in the draft to address rate limiting (meant to put > it in earlier). For some reason, the DT draft stands with gaping holes, > but dyCARD has to be explicit in every respect before it's "understandable". > I think you and perhaps others in the WG may have some misunderstands about the nature of IETF Design Teams. The product of the Design Team is only a suggestion and it can be amended by the Working Group. Thus, if it turns out that the DT draft has "gaping holes" (and I would be the last one to suggest that it is a finished product), they must be filled. If it turns out that Dycard has some good ideas to fill them, and the WG agrees, then those ideas will be used. I believe the discussion in the last couple weeks has identified a couple holes in the DT draft, and I believe there have been some reasonable suggestions from the Dycard team to fill them. We need to consider them. Of course, if the intent of the Dycard team in posting the draft was that the Dycard design was a "take it or leave it" proposition, then I'm afraid that is not how IETF WGs function. Even if the original base WG draft is an individual contribution, it is often amended and ultimately may look nothing like the original design (in fact, the original designers may get sick of working on it and leave the working group after a couple years). jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 15 15:22:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25688 for ; Sat, 15 Mar 2003 15:22:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FKbme31734 for seamoby-archive@odin.ietf.org; Sat, 15 Mar 2003 15:37:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKbmO31731 for ; Sat, 15 Mar 2003 15:37:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25641 for ; Sat, 15 Mar 2003 15:21:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKb6O31077; Sat, 15 Mar 2003 15:37:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKa8O30893 for ; Sat, 15 Mar 2003 15:36:08 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25574 for ; Sat, 15 Mar 2003 15:20:03 -0500 (EST) Message-ID: <006001c2eb30$59cd4ea0$456015ac@T23KEMPF> From: "James Kempf" To: "Robert Chalmers" Cc: References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> <3E72858F.5050503@cs.ucsb.edu> Subject: Re: [Seamoby] updated dyCARD draft Date: Sat, 15 Mar 2003 12:20:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On a side note, I agree with you that we should pobably separate the > AR-MN signalling from the AR-AR or AR-server signalling. Whether or not > the WG wants to standardize mutiple back-end schemes (static, > server-based, learning-based), I don't know. > I think concentrating on the back-end is probably better. The front end has lots of overlap with FMIP. The DT draft has basically two front end protocols, one with and one without FMIP. I think we need only one. Of course, we must be sure that the front end provides what the back end needs. That's my opinion. > Finally, I definitely agree with you that we need some input from people > who don't have invested interest in either approach. Please don't take > this the wrong way, but are you invested in either approach? It seems No. Regardless of who has IPR on what. But I am invested in getting a well-integrated realtime handover protocol suite. As WG chair (and, further, IAB member), I need to make sure the design changes we are making in local link protocols and router protocols integrate well with the existing Internet, and provide the functionality required. And I need to advise the IESG about how I think we can best get there. Like I said in another posting, the DT draft is just a suggestion. The WG has ultimate responsiblity for the result. > that some of the dyHardness might stem from the perception that you > might or the DT in general might be invested. Moreover, while the DT was > hashing out which direction they would take, we (the dyCARD team) > received a lot of questions concerning how to secure the protocol. It > was my impression that the the DT eventually went towards the > server-based solution because we couldn't guarantee absolutely that the > caches could not be contaminated with non-GAAR entries (this is not the > same as bad AR-AP mapping - that we can guarantee). With the recent > discussion, though, these problems seem to have taken a back seat. Now, > it seems that malicious MNs aren't that big of a deal, cache > contamination is not a big issue. > My view is that preventing false information from getting to the MN is the absolute baseline. Any protocol that doesn't supply this is broken. Further than that, we need to discuss how accurate the wireless connectivity information should be in the absence of full geographical information, and weigh that against the cost in terms of infrastructure and inter-router signaling. Pat and I have asked Eunsoo to discuss this topic and problems with the server approach at the meeting. Ajoy and Marco's talk will discuss how the scope-id and server approach work. > Maybe, the next step is to start talking about what properties would > make for the best protocol, not what's wrong with one approach or the other. > Yes,exactly. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 15 15:22:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25712 for ; Sat, 15 Mar 2003 15:22:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKb6O31077; Sat, 15 Mar 2003 15:37:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FKa8O30893 for ; Sat, 15 Mar 2003 15:36:08 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25574 for ; Sat, 15 Mar 2003 15:20:03 -0500 (EST) Message-ID: <006001c2eb30$59cd4ea0$456015ac@T23KEMPF> From: "James Kempf" To: "Robert Chalmers" Cc: References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> <3E72858F.5050503@cs.ucsb.edu> Subject: Re: [Seamoby] updated dyCARD draft Date: Sat, 15 Mar 2003 12:20:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On a side note, I agree with you that we should pobably separate the > AR-MN signalling from the AR-AR or AR-server signalling. Whether or not > the WG wants to standardize mutiple back-end schemes (static, > server-based, learning-based), I don't know. > I think concentrating on the back-end is probably better. The front end has lots of overlap with FMIP. The DT draft has basically two front end protocols, one with and one without FMIP. I think we need only one. Of course, we must be sure that the front end provides what the back end needs. That's my opinion. > Finally, I definitely agree with you that we need some input from people > who don't have invested interest in either approach. Please don't take > this the wrong way, but are you invested in either approach? It seems No. Regardless of who has IPR on what. But I am invested in getting a well-integrated realtime handover protocol suite. As WG chair (and, further, IAB member), I need to make sure the design changes we are making in local link protocols and router protocols integrate well with the existing Internet, and provide the functionality required. And I need to advise the IESG about how I think we can best get there. Like I said in another posting, the DT draft is just a suggestion. The WG has ultimate responsiblity for the result. > that some of the dyHardness might stem from the perception that you > might or the DT in general might be invested. Moreover, while the DT was > hashing out which direction they would take, we (the dyCARD team) > received a lot of questions concerning how to secure the protocol. It > was my impression that the the DT eventually went towards the > server-based solution because we couldn't guarantee absolutely that the > caches could not be contaminated with non-GAAR entries (this is not the > same as bad AR-AP mapping - that we can guarantee). With the recent > discussion, though, these problems seem to have taken a back seat. Now, > it seems that malicious MNs aren't that big of a deal, cache > contamination is not a big issue. > My view is that preventing false information from getting to the MN is the absolute baseline. Any protocol that doesn't supply this is broken. Further than that, we need to discuss how accurate the wireless connectivity information should be in the absence of full geographical information, and weigh that against the cost in terms of infrastructure and inter-router signaling. Pat and I have asked Eunsoo to discuss this topic and problems with the server approach at the meeting. Ajoy and Marco's talk will discuss how the scope-id and server approach work. > Maybe, the next step is to start talking about what properties would > make for the best protocol, not what's wrong with one approach or the other. > Yes,exactly. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 15 16:05:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26337 for ; Sat, 15 Mar 2003 16:05:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FLKZ401170 for seamoby-archive@odin.ietf.org; Sat, 15 Mar 2003 16:20:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FLKZO01167 for ; Sat, 15 Mar 2003 16:20:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26331 for ; Sat, 15 Mar 2003 16:04:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FLJ9O01098; Sat, 15 Mar 2003 16:19:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FLIMO01066 for ; Sat, 15 Mar 2003 16:18:22 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26304 for ; Sat, 15 Mar 2003 16:02:16 -0500 (EST) Message-ID: <010801c2eb36$3f1e0ad0$456015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> <036801c2eb15$4faddc70$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sat, 15 Mar 2003 13:02:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I think you are distinguishing two things clearly: discovering GAAP/GAAR and > checking authorization of AP/AR. > Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is > not identified in advance. It is what the protocol should discover. So we > can only say an AP/AR is authorized to participate in the CARD protocol or > the discovery process. The two are distinct, but they are not disconnected. That is, before an AP can even be considered as a GAAP, it must be authorized. Thus, checking whether an AP is authorized is a prerequesite for determining if it is a GAAP. > One of the main functionalities of the CARD protocol is to discover > GAAP/GAAR and that is what we have to focus on at this moment. > > How to check an AP/AR is authorized to participate in the CARD protocol can > be separated from CARD since it is a kind of general authorization problem. > It is almost the same problem with what is in the IP routing protocol. So we > can take a look at existing solutions and can take one. > The problem is that there are currently *no* existing solutions to dynamically determining whether an AP is authorized. Since our goal is to enable autoconfiguration, there's a problem. CARD is dependent on something that doesn't exist. Static configuration of the AAPL is always possible, of course. But, at that point, one must ask why not also statically configure the information on geographical adjacency? If a new AP is added, the authorization list must be changed anyway, so the geographical adjacency information could be added too. So a fully statically configured back end is one possibility. At the next level, one could just statically configure the authorization list, and have the geographical check be dynamic, presumably because the geographical information was harder to configure. But I am somewhat skeptical of this. The next level is fully dynamic autoconfiguration for both authorization and geographical check. This is, of course, the ideal. > Please notice that node<->router protocol has two aspects: discovery process > and information distribution process. > For the discovery process, we are seeing that we need interaction between > router and MN and between router and router in Dycard. Also the server > approach requires interaction between router and MN and between router and > the server. So simply separating communication between router and MN and > between router and router is not appropriate. > I think separating it might make it easier to fit CARD onto the existing handover protocol work, which is my primary concern. There is too much duplication currently in both drafts of protocol that FMIP and ND provide. > Anyway, it seems you agree that we don't need the server for CARD. Am I > right? > I hope at the working group meeting we can get some agreement about problems of the server approach, how much geographical accuracy is enough, and whether we should use a server or a router to router approach. In either case, I think an authorization technique other than static configuration is necessary, else why bother with autoconfiguration in the first place? I'm sure the security ADs will insist on an authorization technique being available. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 15 16:05:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26350 for ; Sat, 15 Mar 2003 16:05:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FLJ9O01098; Sat, 15 Mar 2003 16:19:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FLIMO01066 for ; Sat, 15 Mar 2003 16:18:22 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26304 for ; Sat, 15 Mar 2003 16:02:16 -0500 (EST) Message-ID: <010801c2eb36$3f1e0ad0$456015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> <036801c2eb15$4faddc70$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sat, 15 Mar 2003 13:02:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I think you are distinguishing two things clearly: discovering GAAP/GAAR and > checking authorization of AP/AR. > Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is > not identified in advance. It is what the protocol should discover. So we > can only say an AP/AR is authorized to participate in the CARD protocol or > the discovery process. The two are distinct, but they are not disconnected. That is, before an AP can even be considered as a GAAP, it must be authorized. Thus, checking whether an AP is authorized is a prerequesite for determining if it is a GAAP. > One of the main functionalities of the CARD protocol is to discover > GAAP/GAAR and that is what we have to focus on at this moment. > > How to check an AP/AR is authorized to participate in the CARD protocol can > be separated from CARD since it is a kind of general authorization problem. > It is almost the same problem with what is in the IP routing protocol. So we > can take a look at existing solutions and can take one. > The problem is that there are currently *no* existing solutions to dynamically determining whether an AP is authorized. Since our goal is to enable autoconfiguration, there's a problem. CARD is dependent on something that doesn't exist. Static configuration of the AAPL is always possible, of course. But, at that point, one must ask why not also statically configure the information on geographical adjacency? If a new AP is added, the authorization list must be changed anyway, so the geographical adjacency information could be added too. So a fully statically configured back end is one possibility. At the next level, one could just statically configure the authorization list, and have the geographical check be dynamic, presumably because the geographical information was harder to configure. But I am somewhat skeptical of this. The next level is fully dynamic autoconfiguration for both authorization and geographical check. This is, of course, the ideal. > Please notice that node<->router protocol has two aspects: discovery process > and information distribution process. > For the discovery process, we are seeing that we need interaction between > router and MN and between router and router in Dycard. Also the server > approach requires interaction between router and MN and between router and > the server. So simply separating communication between router and MN and > between router and router is not appropriate. > I think separating it might make it easier to fit CARD onto the existing handover protocol work, which is my primary concern. There is too much duplication currently in both drafts of protocol that FMIP and ND provide. > Anyway, it seems you agree that we don't need the server for CARD. Am I > right? > I hope at the working group meeting we can get some agreement about problems of the server approach, how much geographical accuracy is enough, and whether we should use a server or a router to router approach. In either case, I think an authorization technique other than static configuration is necessary, else why bother with autoconfiguration in the first place? I'm sure the security ADs will insist on an authorization technique being available. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 03:19:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20179 for ; Sun, 16 Mar 2003 03:19:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2G8Zku13758 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 03:35:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G8ZkO13755 for ; Sun, 16 Mar 2003 03:35:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20176 for ; Sun, 16 Mar 2003 03:19:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G8ZEO13739; Sun, 16 Mar 2003 03:35:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G8X4O13669 for ; Sun, 16 Mar 2003 03:33:04 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20127 for ; Sun, 16 Mar 2003 03:16:44 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2G8Io106466; Sun, 16 Mar 2003 00:18:50 -0800 (PST) Message-ID: <3E743304.2050705@cs.ucsb.edu> Date: Sun, 16 Mar 2003 00:17:08 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> <3E72858F.5050503@cs.ucsb.edu> <005f01c2eb2e$e6d050b0$456015ac@T23KEMPF> In-Reply-To: <005f01c2eb2e$e6d050b0$456015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, > I think you and perhaps others in the WG may have some misunderstands > about the nature of IETF Design Teams. > I don't think so. I do feel, however, that in reality design teams end up wielding more power than is intended. It seems like this basic argument should have taken place before the design team was ever formed. > The product of the Design Team is only a suggestion and it can be > amended by the Working Group. Thus, if it turns out that the DT draft > has "gaping holes" (and I would be the last one to suggest that it > is a finished product), they must be filled. If it turns out that > Dycard has some good ideas to fill them, and the WG agrees, then > those ideas will be used. I believe the discussion in the last couple > weeks has identified a couple holes in the DT draft, and I believe > there have been some reasonable suggestions from the Dycard team to > fill them. We need to consider them. > The point I was trying to make had more to do with your recent comments concerning the fact that dyCARD needs to be explained to the WG. Is the DT draft somehow crystal clear? The dyCARD draft is pretty explicit, but there are bound to be omissions and/or implicit assumptions that are not explained well enough (e.g., rate limiting). I just want to make sure that everything is spelled out so that its "understandable" to the WG, so that the concepts aren't disregarded simply because a detail has not been fully addressed in writing. > Of course, if the intent of the Dycard team in posting the draft was > that the Dycard design was a "take it or leave it" proposition, then > I'm afraid that is not how IETF WGs function. Even if the original > base WG draft is an individual contribution, it is often amended and > ultimately may look nothing like the original design (in fact, the > original designers may get sick of working on it and leave the > working group after a couple years). > Absolutely not. But it does seem that every detail of dyCARD has to be addressed before the general concept is given due consideration by the design team. And I really don't feel that the server-based approach has been faced with the same restrictions. That's just my impression of the way the argument has progressed over the last week or so. Please don't take this as some outraged rant. It's just a little annoyed rant :0) Your comment just struck me as odd, not to mention the dyHard references. I'm just looking for a fair consideration of both general techniques. enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 03:20:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20210 for ; Sun, 16 Mar 2003 03:20:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G8ZEO13739; Sun, 16 Mar 2003 03:35:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G8X4O13669 for ; Sun, 16 Mar 2003 03:33:04 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20127 for ; Sun, 16 Mar 2003 03:16:44 -0500 (EST) Received: from cs.ucsb.edu (heavenly [128.111.52.25]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2G8Io106466; Sun, 16 Mar 2003 00:18:50 -0800 (PST) Message-ID: <3E743304.2050705@cs.ucsb.edu> Date: Sun, 16 Mar 2003 00:17:08 -0800 From: Robert Chalmers Organization: UCSB Computer Science User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030311 Debian/1.2.1-10 MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> <3E72858F.5050503@cs.ucsb.edu> <005f01c2eb2e$e6d050b0$456015ac@T23KEMPF> In-Reply-To: <005f01c2eb2e$e6d050b0$456015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, > I think you and perhaps others in the WG may have some misunderstands > about the nature of IETF Design Teams. > I don't think so. I do feel, however, that in reality design teams end up wielding more power than is intended. It seems like this basic argument should have taken place before the design team was ever formed. > The product of the Design Team is only a suggestion and it can be > amended by the Working Group. Thus, if it turns out that the DT draft > has "gaping holes" (and I would be the last one to suggest that it > is a finished product), they must be filled. If it turns out that > Dycard has some good ideas to fill them, and the WG agrees, then > those ideas will be used. I believe the discussion in the last couple > weeks has identified a couple holes in the DT draft, and I believe > there have been some reasonable suggestions from the Dycard team to > fill them. We need to consider them. > The point I was trying to make had more to do with your recent comments concerning the fact that dyCARD needs to be explained to the WG. Is the DT draft somehow crystal clear? The dyCARD draft is pretty explicit, but there are bound to be omissions and/or implicit assumptions that are not explained well enough (e.g., rate limiting). I just want to make sure that everything is spelled out so that its "understandable" to the WG, so that the concepts aren't disregarded simply because a detail has not been fully addressed in writing. > Of course, if the intent of the Dycard team in posting the draft was > that the Dycard design was a "take it or leave it" proposition, then > I'm afraid that is not how IETF WGs function. Even if the original > base WG draft is an individual contribution, it is often amended and > ultimately may look nothing like the original design (in fact, the > original designers may get sick of working on it and leave the > working group after a couple years). > Absolutely not. But it does seem that every detail of dyCARD has to be addressed before the general concept is given due consideration by the design team. And I really don't feel that the server-based approach has been faced with the same restrictions. That's just my impression of the way the argument has progressed over the last week or so. Please don't take this as some outraged rant. It's just a little annoyed rant :0) Your comment just struck me as odd, not to mention the dyHard references. I'm just looking for a fair consideration of both general techniques. enjoy, bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 09:55:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25724 for ; Sun, 16 Mar 2003 09:55:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GFB0704012 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 10:11:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GFB0O04009 for ; Sun, 16 Mar 2003 10:11:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25692 for ; Sun, 16 Mar 2003 09:54:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GFAgO03993; Sun, 16 Mar 2003 10:10:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GF9ZO03960 for ; Sun, 16 Mar 2003 10:09:35 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25671 for ; Sun, 16 Mar 2003 09:53:08 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2GEtJ809576 for ; Sun, 16 Mar 2003 08:55:19 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 16 Mar 2003 08:55:19 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 16 Mar 2003 08:55:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) Date: Sun, 16 Mar 2003 09:55:17 -0500 Message-ID: Thread-Topic: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) Thread-Index: AcLrlRj1TOOY6PZHTCCuPdPl+eTY5QANc+zg To: , Cc: X-OriginalArrivalTime: 16 Mar 2003 14:55:18.0708 (UTC) FILETIME=[0F951740:01C2EBCC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2GF9aO03961 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Bob, thanks for the clear message. As one of the dyHard team members (I too believe that this reference was totally out of place for a WG chair as a reference to a valid proposal solving an existing SEAMOBY problem), I see the very same problems when it comes to the willingness of understanding dyCard. While we keep turning around a scope-id design that is based on "properly configured"-like arguments (and I don't see an objection of the WG chair on this), we have to even point to sections of the dyCard draft simply because the draft has not been read well, e.g., the site-local handling of dyCard. This just makes the normal process so difficult. However, I do appreciate your clarification that the DT draft is supposed to be a suggestion only and that we should start discussing how to get the best out of both approaches into a WG document. Even though I cannot talk for every dyCard team member, I do believe that this is definitely our intention. Thanks, Dirk >-----Original Message----- >From: ext Robert Chalmers [mailto:robertc@cs.ucsb.edu] >Sent: Sunday, March 16, 2003 3:17 AM >To: James Kempf >Cc: seamoby@ietf.org >Subject: Re: How Design Teams Work(was: Re: [Seamoby] updated dyCARD >draft) > > >James, > >> I think you and perhaps others in the WG may have some misunderstands >> about the nature of IETF Design Teams. >> >I don't think so. I do feel, however, that in reality design teams end >up wielding more power than is intended. It seems like this basic >argument should have taken place before the design team was >ever formed. > >> The product of the Design Team is only a suggestion and it can be >> amended by the Working Group. Thus, if it turns out that the DT draft >> has "gaping holes" (and I would be the last one to suggest that it >> is a finished product), they must be filled. If it turns out that >> Dycard has some good ideas to fill them, and the WG agrees, then >> those ideas will be used. I believe the discussion in the last couple >> weeks has identified a couple holes in the DT draft, and I believe >> there have been some reasonable suggestions from the Dycard team to >> fill them. We need to consider them. >> >The point I was trying to make had more to do with your recent comments >concerning the fact that dyCARD needs to be explained to the WG. Is the >DT draft somehow crystal clear? The dyCARD draft is pretty >explicit, but >there are bound to be omissions and/or implicit >assumptions that are not explained well enough (e.g., rate limiting). I >just want to make sure that everything is spelled out so that its >"understandable" to the WG, so that the concepts aren't disregarded >simply because a detail has not been fully addressed in writing. > >> Of course, if the intent of the Dycard team in posting the draft was >> that the Dycard design was a "take it or leave it" proposition, then >> I'm afraid that is not how IETF WGs function. Even if the original >> base WG draft is an individual contribution, it is often amended and >> ultimately may look nothing like the original design (in fact, the >> original designers may get sick of working on it and leave the >> working group after a couple years). >> >Absolutely not. But it does seem that every detail of dyCARD has to be >addressed before the general concept is given due consideration by the >design team. And I really don't feel that the server-based approach has >been faced with the same restrictions. That's just my impression of the >way the argument has progressed over the last week or so. > >Please don't take this as some outraged rant. It's just a >little annoyed >rant :0) Your comment just struck me as odd, not to mention the dyHard >references. I'm just looking for a fair consideration of both general >techniques. > >enjoy, >bob > >-- >/**************************************************************** > > Robert Chalmers > UCSB Computer Science Doctoral Candidate > Network and Multimedia Systems Lab (NMSL) > > "My heart is in the code, but my soul lies in the process" > > | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | > >*****************************************************************/ > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 09:55:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25788 for ; Sun, 16 Mar 2003 09:55:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GFAgO03993; Sun, 16 Mar 2003 10:10:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GF9ZO03960 for ; Sun, 16 Mar 2003 10:09:35 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25671 for ; Sun, 16 Mar 2003 09:53:08 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2GEtJ809576 for ; Sun, 16 Mar 2003 08:55:19 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 16 Mar 2003 08:55:19 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 16 Mar 2003 08:55:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) Date: Sun, 16 Mar 2003 09:55:17 -0500 Message-ID: Thread-Topic: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) Thread-Index: AcLrlRj1TOOY6PZHTCCuPdPl+eTY5QANc+zg To: , Cc: X-OriginalArrivalTime: 16 Mar 2003 14:55:18.0708 (UTC) FILETIME=[0F951740:01C2EBCC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2GF9aO03961 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, thanks for the clear message. As one of the dyHard team members (I too believe that this reference was totally out of place for a WG chair as a reference to a valid proposal solving an existing SEAMOBY problem), I see the very same problems when it comes to the willingness of understanding dyCard. While we keep turning around a scope-id design that is based on "properly configured"-like arguments (and I don't see an objection of the WG chair on this), we have to even point to sections of the dyCard draft simply because the draft has not been read well, e.g., the site-local handling of dyCard. This just makes the normal process so difficult. However, I do appreciate your clarification that the DT draft is supposed to be a suggestion only and that we should start discussing how to get the best out of both approaches into a WG document. Even though I cannot talk for every dyCard team member, I do believe that this is definitely our intention. Thanks, Dirk >-----Original Message----- >From: ext Robert Chalmers [mailto:robertc@cs.ucsb.edu] >Sent: Sunday, March 16, 2003 3:17 AM >To: James Kempf >Cc: seamoby@ietf.org >Subject: Re: How Design Teams Work(was: Re: [Seamoby] updated dyCARD >draft) > > >James, > >> I think you and perhaps others in the WG may have some misunderstands >> about the nature of IETF Design Teams. >> >I don't think so. I do feel, however, that in reality design teams end >up wielding more power than is intended. It seems like this basic >argument should have taken place before the design team was >ever formed. > >> The product of the Design Team is only a suggestion and it can be >> amended by the Working Group. Thus, if it turns out that the DT draft >> has "gaping holes" (and I would be the last one to suggest that it >> is a finished product), they must be filled. If it turns out that >> Dycard has some good ideas to fill them, and the WG agrees, then >> those ideas will be used. I believe the discussion in the last couple >> weeks has identified a couple holes in the DT draft, and I believe >> there have been some reasonable suggestions from the Dycard team to >> fill them. We need to consider them. >> >The point I was trying to make had more to do with your recent comments >concerning the fact that dyCARD needs to be explained to the WG. Is the >DT draft somehow crystal clear? The dyCARD draft is pretty >explicit, but >there are bound to be omissions and/or implicit >assumptions that are not explained well enough (e.g., rate limiting). I >just want to make sure that everything is spelled out so that its >"understandable" to the WG, so that the concepts aren't disregarded >simply because a detail has not been fully addressed in writing. > >> Of course, if the intent of the Dycard team in posting the draft was >> that the Dycard design was a "take it or leave it" proposition, then >> I'm afraid that is not how IETF WGs function. Even if the original >> base WG draft is an individual contribution, it is often amended and >> ultimately may look nothing like the original design (in fact, the >> original designers may get sick of working on it and leave the >> working group after a couple years). >> >Absolutely not. But it does seem that every detail of dyCARD has to be >addressed before the general concept is given due consideration by the >design team. And I really don't feel that the server-based approach has >been faced with the same restrictions. That's just my impression of the >way the argument has progressed over the last week or so. > >Please don't take this as some outraged rant. It's just a >little annoyed >rant :0) Your comment just struck me as odd, not to mention the dyHard >references. I'm just looking for a fair consideration of both general >techniques. > >enjoy, >bob > >-- >/**************************************************************** > > Robert Chalmers > UCSB Computer Science Doctoral Candidate > Network and Multimedia Systems Lab (NMSL) > > "My heart is in the code, but my soul lies in the process" > > | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | > >*****************************************************************/ > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 12:44:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00504 for ; Sun, 16 Mar 2003 12:44:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GI0qL12754 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 13:00:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GI0qO12751 for ; Sun, 16 Mar 2003 13:00:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00499 for ; Sun, 16 Mar 2003 12:44:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GI0PO12735; Sun, 16 Mar 2003 13:00:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHvFO12584 for ; Sun, 16 Mar 2003 12:57:15 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00326 for ; Sun, 16 Mar 2003 12:40:43 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2GHgsIG005817 for ; Sun, 16 Mar 2003 10:42:54 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA26293 for ; Sun, 16 Mar 2003 10:42:54 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 11:42:08 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE74@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , Hemant.Chaskar@nokia.com, robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 11:40:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Eunsoo, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Saturday, March 15, 2003 12:50 PM To: Singh Ajoy-ASINGH1; Hemant.Chaskar@nokia.com; robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Ajoy, The role of the server in the server approach is currently storing all L2-L3 mapping entries and providing them at the request by ARs. AJOY-> This is the subset of CARD function. You may say the program of the CARD server can be also running in the AAA server but two servers are very different in terms of functionality and involved protocols. AJOY-> This is not what I meant. I meant that CARD functionality can integrated with AAA server. Given that inter-AR authorization is key requirement of CARD, this may be good point to discuss. Dycard does not exclude existence of an AAA server at all. AJOY-> Are you saying that dycard will use AAA server for providing inter-AR authorization? If yes, could you please explain us how this will be done. I think the security requirements for CARD regarding AR authorization is quite similar to that of IP routing protocols. There are already proposed/implemented solutions for IP routing protocol security. AJOY-> Not really. The security requirements of CARD should be more stringent than inter-domain or intra-domain routing protocol. In CARD, any random MN is able to initiate the process of L2->L3 mapping as well as capability discovery. In dycard the mobile node provides the IP address of the AR with which the current AR is required to communicate to obtain the L2->L3 mapping as well as capabilities. The dycard MN can provide an IP address of a malicious CAR which may be any node on the Internet. If somehow the security of AR-CAR is compromised, this will cause the current AR to have bogus L2->L3 mapping as well invalid capabilities. This will have serious impact on the handoff performance of subsequent mobile nodes. The routing protocol does not initiate routing table update based upon trigger from a random mobile node and am not sure how the security requirement of routing protocol is comparable with CARD. We had a separate thread for the need of the server for CARD. It was being summarized and so far there was no compelling reason to have a server for CARD. If you want to propose the server as the AAA server, please can you do it in that thread? AJOY-> I have already stated this in my earlier email. The DT draft also mentions about this. I guess we can discuss this during Seamoby presentation. Also, I am very interested to hear from other members of WG who are not co-authors of dycard. Eunsoo ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: ; "Singh Ajoy-ASINGH1" ; Cc: ; Sent: Saturday, March 15, 2003 7:08 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I think the security requirement of CARD is not same > as that of FMIP. In CARD, the routers have to mutually > authorize each other for validating and updating > the L3->L3 mapping and capabilities based upon indication > from a random MN which will eventually impact the other mobile > nodes in the long run. Whereas in the fast handoff, > this only impacts the mobile node in handoff. So, we need to > better understand how such authorization will work in context of > CARD especially dyCard. What are the possible tools available > for enabling such inter-AR authorization of dyCard ARs? In server based > approach I do see server (e.g.,AAA) playing such a role. > > Regards, > Ajoy > > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: Friday, March 14, 2003 6:21 PM > To: Ajoy Singh; robertc@cs.ucsb.edu > Cc: eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > Security of all handoff schemes depends upon existence of inter-AR SA. BCPs > should be used for this - take cues from routing, policy framework, FMIP and > CT. - Hemant > > -----Original Message----- > From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Friday, March 14, 2003 6:13 PM > To: 'Robert Chalmers'; Singh Ajoy-ASINGH1 > Cc: 'Eunsoo Shim'; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > -----Original Message----- > From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] > Sent: Friday, March 14, 2003 2:18 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Eunsoo Shim'; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > Singh Ajoy-ASINGH1 wrote: > > > > AJOY-> BTW, I have a cache contamination question about dycard. Let us > > assume that > > a fake MN has some collaboration with fake router which is > > also connected to the internet and the fake MN sends > > a message to the current AR indicating that fake router > > is the valid CAR ? How the dycard assures that it > > does create an entry in its local cache? > > > It is clearly stated in the draft that the two routers must mutually > authenticate one another with the explicit authorization to perform > CARD. Are you assuming that this fake AR can in some way authenticate > and authorize itself with respect to the attacked AR? If not, the > question is moot. If so, then I would question your > authentication/authorization scheme. > > AJOY-> You have rightly pointed out that security of > dycard scheme would depend upon how routers authorize and > authenticate each other. BTW, what is the proposed > scheme for mutual authentication and authorization? > Do you believe manual configuration of SA is enough? > > > > > -- > /**************************************************************** > > Robert Chalmers > UCSB Computer Science Doctoral Candidate > Network and Multimedia Systems Lab (NMSL) > > "My heart is in the code, but my soul lies in the process" > > | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | > > *****************************************************************/ > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 12:45:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00517 for ; Sun, 16 Mar 2003 12:45:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GI0PO12735; Sun, 16 Mar 2003 13:00:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHvFO12584 for ; Sun, 16 Mar 2003 12:57:15 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00326 for ; Sun, 16 Mar 2003 12:40:43 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2GHgsIG005817 for ; Sun, 16 Mar 2003 10:42:54 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA26293 for ; Sun, 16 Mar 2003 10:42:54 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 11:42:08 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE74@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , Hemant.Chaskar@nokia.com, robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 11:40:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Eunsoo, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Saturday, March 15, 2003 12:50 PM To: Singh Ajoy-ASINGH1; Hemant.Chaskar@nokia.com; robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Ajoy, The role of the server in the server approach is currently storing all L2-L3 mapping entries and providing them at the request by ARs. AJOY-> This is the subset of CARD function. You may say the program of the CARD server can be also running in the AAA server but two servers are very different in terms of functionality and involved protocols. AJOY-> This is not what I meant. I meant that CARD functionality can integrated with AAA server. Given that inter-AR authorization is key requirement of CARD, this may be good point to discuss. Dycard does not exclude existence of an AAA server at all. AJOY-> Are you saying that dycard will use AAA server for providing inter-AR authorization? If yes, could you please explain us how this will be done. I think the security requirements for CARD regarding AR authorization is quite similar to that of IP routing protocols. There are already proposed/implemented solutions for IP routing protocol security. AJOY-> Not really. The security requirements of CARD should be more stringent than inter-domain or intra-domain routing protocol. In CARD, any random MN is able to initiate the process of L2->L3 mapping as well as capability discovery. In dycard the mobile node provides the IP address of the AR with which the current AR is required to communicate to obtain the L2->L3 mapping as well as capabilities. The dycard MN can provide an IP address of a malicious CAR which may be any node on the Internet. If somehow the security of AR-CAR is compromised, this will cause the current AR to have bogus L2->L3 mapping as well invalid capabilities. This will have serious impact on the handoff performance of subsequent mobile nodes. The routing protocol does not initiate routing table update based upon trigger from a random mobile node and am not sure how the security requirement of routing protocol is comparable with CARD. We had a separate thread for the need of the server for CARD. It was being summarized and so far there was no compelling reason to have a server for CARD. If you want to propose the server as the AAA server, please can you do it in that thread? AJOY-> I have already stated this in my earlier email. The DT draft also mentions about this. I guess we can discuss this during Seamoby presentation. Also, I am very interested to hear from other members of WG who are not co-authors of dycard. Eunsoo ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: ; "Singh Ajoy-ASINGH1" ; Cc: ; Sent: Saturday, March 15, 2003 7:08 AM Subject: RE: [SeaMoby] Topic #3: Cache contamination > I think the security requirement of CARD is not same > as that of FMIP. In CARD, the routers have to mutually > authorize each other for validating and updating > the L3->L3 mapping and capabilities based upon indication > from a random MN which will eventually impact the other mobile > nodes in the long run. Whereas in the fast handoff, > this only impacts the mobile node in handoff. So, we need to > better understand how such authorization will work in context of > CARD especially dyCard. What are the possible tools available > for enabling such inter-AR authorization of dyCard ARs? In server based > approach I do see server (e.g.,AAA) playing such a role. > > Regards, > Ajoy > > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: Friday, March 14, 2003 6:21 PM > To: Ajoy Singh; robertc@cs.ucsb.edu > Cc: eunsoo@nec-labs.com; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > Security of all handoff schemes depends upon existence of inter-AR SA. BCPs > should be used for this - take cues from routing, policy framework, FMIP and > CT. - Hemant > > -----Original Message----- > From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Friday, March 14, 2003 6:13 PM > To: 'Robert Chalmers'; Singh Ajoy-ASINGH1 > Cc: 'Eunsoo Shim'; seamoby@ietf.org > Subject: RE: [SeaMoby] Topic #3: Cache contamination > > > -----Original Message----- > From: Robert Chalmers [mailto:robertc@cs.ucsb.edu] > Sent: Friday, March 14, 2003 2:18 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Eunsoo Shim'; seamoby@ietf.org > Subject: Re: [SeaMoby] Topic #3: Cache contamination > > > Singh Ajoy-ASINGH1 wrote: > > > > AJOY-> BTW, I have a cache contamination question about dycard. Let us > > assume that > > a fake MN has some collaboration with fake router which is > > also connected to the internet and the fake MN sends > > a message to the current AR indicating that fake router > > is the valid CAR ? How the dycard assures that it > > does create an entry in its local cache? > > > It is clearly stated in the draft that the two routers must mutually > authenticate one another with the explicit authorization to perform > CARD. Are you assuming that this fake AR can in some way authenticate > and authorize itself with respect to the attacked AR? If not, the > question is moot. If so, then I would question your > authentication/authorization scheme. > > AJOY-> You have rightly pointed out that security of > dycard scheme would depend upon how routers authorize and > authenticate each other. BTW, what is the proposed > scheme for mutual authentication and authorization? > Do you believe manual configuration of SA is enough? > > > > > -- > /**************************************************************** > > Robert Chalmers > UCSB Computer Science Doctoral Candidate > Network and Multimedia Systems Lab (NMSL) > > "My heart is in the code, but my soul lies in the process" > > | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | > > *****************************************************************/ > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 14:31:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03911 for ; Sun, 16 Mar 2003 14:31:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GJlZr18848 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 14:47:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJlZO18845 for ; Sun, 16 Mar 2003 14:47:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03887 for ; Sun, 16 Mar 2003 14:31:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJlJO18836; Sun, 16 Mar 2003 14:47:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJkJO18748 for ; Sun, 16 Mar 2003 14:46:19 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03826 for ; Sun, 16 Mar 2003 14:29:45 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 14:31:59 -0500 Message-ID: <022201c2ec0c$01cbc790$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE74@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 14:33:03 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 19:31:59.0230 (UTC) FILETIME=[B643B9E0:01C2EBF2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ajoy, My comments are inline. > > The role of the server in the server approach is currently storing all L2-L3 > mapping entries and providing them at the request by ARs. > > AJOY-> This is the subset of CARD function. > [eunsoo] CARD does not require all L2-L3 mapping entries in a central server. Such a central server is what DT proposed and we had discussion about why we need a server for CARD. There was no compelling reason yet. > You may say the program of the CARD server can be also running in the AAA > server but two servers are very different in terms of functionality and > involved protocols. > > AJOY-> This is not what I meant. I meant that CARD functionality > can integrated with AAA server. Given that inter-AR authorization > is key requirement of CARD, this may be good point to discuss. > [eunsoo] Unless there is a compelling reason to have a central server for CARD, it does not matter where we can put the server. > Dycard does not exclude existence of an AAA server at > all. > > AJOY-> Are you saying that dycard will use AAA server > for providing inter-AR authorization? If yes, could > you please explain us how this will be done. > [eunsoo] I think Dycard can be integrated with many ways of inter-AR authorization. The current Dycard draft does not propose any specific method yet. > I think the security requirements for CARD regarding AR authorization is > quite similar to that of IP routing protocols. There are already > proposed/implemented solutions for IP routing protocol security. > > AJOY-> Not really. The security requirements of CARD should > be more stringent than inter-domain or intra-domain routing > protocol. In CARD, any random MN is able to initiate the > process of L2->L3 mapping as well as capability discovery. > In dycard the mobile node provides the IP address of the AR > with which the current AR is required to communicate to obtain > the L2->L3 mapping as well as capabilities. The dycard MN can > provide an IP address of a malicious CAR which may be any node > on the Internet. If somehow the security of AR-CAR is compromised, > this will cause the current AR to have bogus L2->L3 mapping as > well invalid capabilities. This will have serious impact on > the handoff performance of subsequent mobile nodes. The > routing protocol does not initiate routing table update > based upon trigger from a random mobile node and am > not sure how the security requirement of routing > protocol is comparable with CARD. > [eunsoo] No matter what triggers the inter-AR authorization process, still it is two ARs who are involved and responsible for checking authorization of each other. MN cannot have influence on it. So it is not correct to say CARD has more strict security requirements regarding inter-AR authorization because MN provides the trigger. You cannot say corruption of the IP routing tables in the routers are less serious than the curruption of the cache (CAR table) of the edge ARs. Also now you are say bogus L2-L3 mapping entries can cause serious consequences. I pointed out repeatedly that the server approach cannot prevent MN from providing a L2 address of an AP which is a GAAP and thus the cache (the CAR table at the AR) will be contaminated. What do you think of the seriousness of this problem? > We had a separate thread for the need of the server for CARD. It was being > summarized and so far there was no compelling reason to have a server for > CARD. If you want to propose the server as the AAA server, please can you do > it in that thread? > > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we need is a AAA server but not a server that stores all the L2-L3 mapping entries statically and provide them at the request of the ARs. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 14:31:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03924 for ; Sun, 16 Mar 2003 14:31:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJlJO18836; Sun, 16 Mar 2003 14:47:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJkJO18748 for ; Sun, 16 Mar 2003 14:46:19 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03826 for ; Sun, 16 Mar 2003 14:29:45 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 14:31:59 -0500 Message-ID: <022201c2ec0c$01cbc790$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE74@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 14:33:03 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 19:31:59.0230 (UTC) FILETIME=[B643B9E0:01C2EBF2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ajoy, My comments are inline. > > The role of the server in the server approach is currently storing all L2-L3 > mapping entries and providing them at the request by ARs. > > AJOY-> This is the subset of CARD function. > [eunsoo] CARD does not require all L2-L3 mapping entries in a central server. Such a central server is what DT proposed and we had discussion about why we need a server for CARD. There was no compelling reason yet. > You may say the program of the CARD server can be also running in the AAA > server but two servers are very different in terms of functionality and > involved protocols. > > AJOY-> This is not what I meant. I meant that CARD functionality > can integrated with AAA server. Given that inter-AR authorization > is key requirement of CARD, this may be good point to discuss. > [eunsoo] Unless there is a compelling reason to have a central server for CARD, it does not matter where we can put the server. > Dycard does not exclude existence of an AAA server at > all. > > AJOY-> Are you saying that dycard will use AAA server > for providing inter-AR authorization? If yes, could > you please explain us how this will be done. > [eunsoo] I think Dycard can be integrated with many ways of inter-AR authorization. The current Dycard draft does not propose any specific method yet. > I think the security requirements for CARD regarding AR authorization is > quite similar to that of IP routing protocols. There are already > proposed/implemented solutions for IP routing protocol security. > > AJOY-> Not really. The security requirements of CARD should > be more stringent than inter-domain or intra-domain routing > protocol. In CARD, any random MN is able to initiate the > process of L2->L3 mapping as well as capability discovery. > In dycard the mobile node provides the IP address of the AR > with which the current AR is required to communicate to obtain > the L2->L3 mapping as well as capabilities. The dycard MN can > provide an IP address of a malicious CAR which may be any node > on the Internet. If somehow the security of AR-CAR is compromised, > this will cause the current AR to have bogus L2->L3 mapping as > well invalid capabilities. This will have serious impact on > the handoff performance of subsequent mobile nodes. The > routing protocol does not initiate routing table update > based upon trigger from a random mobile node and am > not sure how the security requirement of routing > protocol is comparable with CARD. > [eunsoo] No matter what triggers the inter-AR authorization process, still it is two ARs who are involved and responsible for checking authorization of each other. MN cannot have influence on it. So it is not correct to say CARD has more strict security requirements regarding inter-AR authorization because MN provides the trigger. You cannot say corruption of the IP routing tables in the routers are less serious than the curruption of the cache (CAR table) of the edge ARs. Also now you are say bogus L2-L3 mapping entries can cause serious consequences. I pointed out repeatedly that the server approach cannot prevent MN from providing a L2 address of an AP which is a GAAP and thus the cache (the CAR table at the AR) will be contaminated. What do you think of the seriousness of this problem? > We had a separate thread for the need of the server for CARD. It was being > summarized and so far there was no compelling reason to have a server for > CARD. If you want to propose the server as the AAA server, please can you do > it in that thread? > > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we need is a AAA server but not a server that stores all the L2-L3 mapping entries statically and provide them at the request of the ARs. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 14:37:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04157 for ; Sun, 16 Mar 2003 14:37:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GJrFl18958 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 14:53:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJrEO18955 for ; Sun, 16 Mar 2003 14:53:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04134 for ; Sun, 16 Mar 2003 14:36:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJr2O18942; Sun, 16 Mar 2003 14:53:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJqSO18927 for ; Sun, 16 Mar 2003 14:52:28 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04125 for ; Sun, 16 Mar 2003 14:35:55 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 14:38:08 -0500 Message-ID: <022f01c2ec0c$ddd82d50$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE74@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 14:39:12 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 19:38:08.0427 (UTC) FILETIME=[9252B7B0:01C2EBF3] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > I am also very interested to hear from other members of WG about the DT proposal who are not members of the DT and are not affiliated to them. There were many issues raised about the DT proposal such as cache contamination and even the fundamental need of the central server. I have not heard convincing explanations from the DT members as well as any supporting opinion from non-DT members yet. I'd appreciate if anyone provides one. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 14:37:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04170 for ; Sun, 16 Mar 2003 14:37:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJr2O18942; Sun, 16 Mar 2003 14:53:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJqSO18927 for ; Sun, 16 Mar 2003 14:52:28 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04125 for ; Sun, 16 Mar 2003 14:35:55 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 14:38:08 -0500 Message-ID: <022f01c2ec0c$ddd82d50$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE74@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 14:39:12 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 19:38:08.0427 (UTC) FILETIME=[9252B7B0:01C2EBF3] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > I am also very interested to hear from other members of WG about the DT proposal who are not members of the DT and are not affiliated to them. There were many issues raised about the DT proposal such as cache contamination and even the fundamental need of the central server. I have not heard convincing explanations from the DT members as well as any supporting opinion from non-DT members yet. I'd appreciate if anyone provides one. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 14:52:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04313 for ; Sun, 16 Mar 2003 14:52:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GK8KQ19981 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:08:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GK8KO19978 for ; Sun, 16 Mar 2003 15:08:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04303 for ; Sun, 16 Mar 2003 14:51:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GK86O19970; Sun, 16 Mar 2003 15:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GK7YO19951 for ; Sun, 16 Mar 2003 15:07:34 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04268 for ; Sun, 16 Mar 2003 14:50:59 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2GJqjPO022413 for ; Sun, 16 Mar 2003 12:52:45 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA09442 for ; Sun, 16 Mar 2003 12:52:45 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 13:52:45 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE76@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , Hemant.Chaskar@nokia.com, robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 13:52:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Eunsoo, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 4:33 PM To: Singh Ajoy-ASINGH1; Hemant.Chaskar@nokia.com; robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Ajoy, My comments are inline. > > The role of the server in the server approach is currently storing all L2-L3 > mapping entries and providing them at the request by ARs. > > AJOY-> This is the subset of CARD function. > [eunsoo] CARD does not require all L2-L3 mapping entries in a central server. Such a central server is what DT proposed and we had discussion about why we need a server for CARD. There was no compelling reason yet. > You may say the program of the CARD server can be also running in the AAA > server but two servers are very different in terms of functionality and > involved protocols. > > AJOY-> This is not what I meant. I meant that CARD functionality > can integrated with AAA server. Given that inter-AR authorization > is key requirement of CARD, this may be good point to discuss. > [eunsoo] Unless there is a compelling reason to have a central server for CARD, it does not matter where we can put the server. AJOY-> I am not talking about introducing any additional server though. I am just talking about re-using the existing server functionality in an access network. > Dycard does not exclude existence of an AAA server at > all. > > AJOY-> Are you saying that dycard will use AAA server > for providing inter-AR authorization? If yes, could > you please explain us how this will be done. > [eunsoo] I think Dycard can be integrated with many ways of inter-AR authorization. The current Dycard draft does not propose any specific method yet. AJOY-> List few inter-AR authorization protocols that can be used. You have not answered my question yet. > I think the security requirements for CARD regarding AR authorization is > quite similar to that of IP routing protocols. There are already > proposed/implemented solutions for IP routing protocol security. > > AJOY-> Not really. The security requirements of CARD should > be more stringent than inter-domain or intra-domain routing > protocol. In CARD, any random MN is able to initiate the > process of L2->L3 mapping as well as capability discovery. > In dycard the mobile node provides the IP address of the AR > with which the current AR is required to communicate to obtain > the L2->L3 mapping as well as capabilities. The dycard MN can > provide an IP address of a malicious CAR which may be any node > on the Internet. If somehow the security of AR-CAR is compromised, > this will cause the current AR to have bogus L2->L3 mapping as > well invalid capabilities. This will have serious impact on > the handoff performance of subsequent mobile nodes. The > routing protocol does not initiate routing table update > based upon trigger from a random mobile node and am > not sure how the security requirement of routing > protocol is comparable with CARD. > [eunsoo] No matter what triggers the inter-AR authorization process, still it is two ARs who are involved and responsible for checking authorization of each other. MN cannot have influence on it. AJOY-> The current AR believes the information provided by MN and acts upon that. So, I am not sure why you say that MN does not have any influence over it. So it is not correct to say CARD has more strict security requirements regarding inter-AR authorization because MN provides the trigger. AJOY-> Why not? You cannot say corruption of the IP routing tables in the routers are less serious than the curruption of the cache (CAR table) of the edge ARs. Also now you are say bogus L2-L3 mapping entries can cause serious consequences. I pointed out repeatedly that the server approach cannot prevent MN from providing a L2 address of an AP which is a GAAP and thus the cache (the CAR table at the AR) will be contaminated. What do you think of the seriousness of this problem? AJOY-> I do not agree with this statement. Let us discuss scope-id approach offline or doing IETF presentation. I have already indicated this in my earlier email to Dirk. > We had a separate thread for the need of the server for CARD. It was being > summarized and so far there was no compelling reason to have a server for > CARD. If you want to propose the server as the AAA server, please can you do > it in that thread? > > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we need is a AAA server but not a server that stores all the L2-L3 mapping entries statically and provide them at the request of the ARs. AJOY-> If we need AAA sever then why not discuss about piggybacking some additional function required by the CARD over it. I do not see any reason to make CARD complicated protocol as being proposed in dycard. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 14:52:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04340 for ; Sun, 16 Mar 2003 14:52:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GK86O19970; Sun, 16 Mar 2003 15:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GK7YO19951 for ; Sun, 16 Mar 2003 15:07:34 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04268 for ; Sun, 16 Mar 2003 14:50:59 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2GJqjPO022413 for ; Sun, 16 Mar 2003 12:52:45 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA09442 for ; Sun, 16 Mar 2003 12:52:45 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 13:52:45 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE76@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , Hemant.Chaskar@nokia.com, robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 13:52:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Eunsoo, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 4:33 PM To: Singh Ajoy-ASINGH1; Hemant.Chaskar@nokia.com; robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Ajoy, My comments are inline. > > The role of the server in the server approach is currently storing all L2-L3 > mapping entries and providing them at the request by ARs. > > AJOY-> This is the subset of CARD function. > [eunsoo] CARD does not require all L2-L3 mapping entries in a central server. Such a central server is what DT proposed and we had discussion about why we need a server for CARD. There was no compelling reason yet. > You may say the program of the CARD server can be also running in the AAA > server but two servers are very different in terms of functionality and > involved protocols. > > AJOY-> This is not what I meant. I meant that CARD functionality > can integrated with AAA server. Given that inter-AR authorization > is key requirement of CARD, this may be good point to discuss. > [eunsoo] Unless there is a compelling reason to have a central server for CARD, it does not matter where we can put the server. AJOY-> I am not talking about introducing any additional server though. I am just talking about re-using the existing server functionality in an access network. > Dycard does not exclude existence of an AAA server at > all. > > AJOY-> Are you saying that dycard will use AAA server > for providing inter-AR authorization? If yes, could > you please explain us how this will be done. > [eunsoo] I think Dycard can be integrated with many ways of inter-AR authorization. The current Dycard draft does not propose any specific method yet. AJOY-> List few inter-AR authorization protocols that can be used. You have not answered my question yet. > I think the security requirements for CARD regarding AR authorization is > quite similar to that of IP routing protocols. There are already > proposed/implemented solutions for IP routing protocol security. > > AJOY-> Not really. The security requirements of CARD should > be more stringent than inter-domain or intra-domain routing > protocol. In CARD, any random MN is able to initiate the > process of L2->L3 mapping as well as capability discovery. > In dycard the mobile node provides the IP address of the AR > with which the current AR is required to communicate to obtain > the L2->L3 mapping as well as capabilities. The dycard MN can > provide an IP address of a malicious CAR which may be any node > on the Internet. If somehow the security of AR-CAR is compromised, > this will cause the current AR to have bogus L2->L3 mapping as > well invalid capabilities. This will have serious impact on > the handoff performance of subsequent mobile nodes. The > routing protocol does not initiate routing table update > based upon trigger from a random mobile node and am > not sure how the security requirement of routing > protocol is comparable with CARD. > [eunsoo] No matter what triggers the inter-AR authorization process, still it is two ARs who are involved and responsible for checking authorization of each other. MN cannot have influence on it. AJOY-> The current AR believes the information provided by MN and acts upon that. So, I am not sure why you say that MN does not have any influence over it. So it is not correct to say CARD has more strict security requirements regarding inter-AR authorization because MN provides the trigger. AJOY-> Why not? You cannot say corruption of the IP routing tables in the routers are less serious than the curruption of the cache (CAR table) of the edge ARs. Also now you are say bogus L2-L3 mapping entries can cause serious consequences. I pointed out repeatedly that the server approach cannot prevent MN from providing a L2 address of an AP which is a GAAP and thus the cache (the CAR table at the AR) will be contaminated. What do you think of the seriousness of this problem? AJOY-> I do not agree with this statement. Let us discuss scope-id approach offline or doing IETF presentation. I have already indicated this in my earlier email to Dirk. > We had a separate thread for the need of the server for CARD. It was being > summarized and so far there was no compelling reason to have a server for > CARD. If you want to propose the server as the AAA server, please can you do > it in that thread? > > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we need is a AAA server but not a server that stores all the L2-L3 mapping entries statically and provide them at the request of the ARs. AJOY-> If we need AAA sever then why not discuss about piggybacking some additional function required by the CARD over it. I do not see any reason to make CARD complicated protocol as being proposed in dycard. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 14:57:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04462 for ; Sun, 16 Mar 2003 14:57:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKDEx20197 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:13:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKDEO20194 for ; Sun, 16 Mar 2003 15:13:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04443 for ; Sun, 16 Mar 2003 14:56:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKD2O20180; Sun, 16 Mar 2003 15:13:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKC5O20149 for ; Sun, 16 Mar 2003 15:12:05 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04429 for ; Sun, 16 Mar 2003 14:55:30 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 14:57:43 -0500 Message-ID: <023901c2ec0f$9a6b8f00$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> <036801c2eb15$4faddc70$e26b0f8a@eunsoo> <010801c2eb36$3f1e0ad0$456015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sun, 16 Mar 2003 14:58:47 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 19:57:43.0872 (UTC) FILETIME=[4EF16400:01C2EBF6] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, My comments are inline. > > I think you are distinguishing two things clearly: discovering GAAP/GAAR and > > checking authorization of AP/AR. > > Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is > > not identified in advance. It is what the protocol should discover. So we > > can only say an AP/AR is authorized to participate in the CARD protocol or > > the discovery process. > > > The two are distinct, but they are not disconnected. That is, before an AP can > even be considered as a GAAP, it must be authorized. Thus, checking whether an > AP is authorized is a prerequesite for determining if it is a GAAP. > > > One of the main functionalities of the CARD protocol is to discover > > GAAP/GAAR and that is what we have to focus on at this moment. > > > > How to check an AP/AR is authorized to participate in the CARD protocol can > > be separated from CARD since it is a kind of general authorization problem. > > It is almost the same problem with what is in the IP routing protocol. So we > > can take a look at existing solutions and can take one. > > > > The problem is that there are currently *no* existing solutions to dynamically > determining whether an AP is authorized. Since our goal is to enable > autoconfiguration, there's a problem. CARD is dependent on something that > doesn't exist. > As you said below, we can proceed assuming static configuration for this. The fast handoff proposal of the MobileIP WG also proceeded without a solution for dynamic L2-L3 mapping. As we wee, that problem can be solved independently of the rest of the fast handoff proposal. > Static configuration of the AAPL is always possible, of course. But, at that > point, one must ask why not also statically configure the information on > geographical adjacency? If a new AP is added, the authorization list must be > changed anyway, so the geographical adjacency information could be added too. So > a fully statically configured back end is one possibility. > [eunsoo] As I said below, it is rarely practical to use geographical information in general situations. Do you know exact coverage of an 802.11 AP in your officie building? Also it is affected by the environment which may change without your notice. > At the next level, one could just statically configure the authorization list, > and have the geographical check be dynamic, presumably because the geographical > information was harder to configure. But I am somewhat skeptical of this. > [eunsoo] I remember that you said using geographical information for CARD was not practical. Now you say differently. I think your previous opinion is correct. It is not practical in many situations. Just configuring whether an AP connected to an AR is authorized is not such a difficult job at all. It is clear to the admin from the beginning when he connected the AP to the AR. > The next level is fully dynamic autoconfiguration for both authorization and > geographical check. This is, of course, the ideal. > > > Please notice that node<->router protocol has two aspects: discovery process > > and information distribution process. > > For the discovery process, we are seeing that we need interaction between > > router and MN and between router and router in Dycard. Also the server > > approach requires interaction between router and MN and between router and > > the server. So simply separating communication between router and MN and > > between router and router is not appropriate. > > > > I think separating it might make it easier to fit CARD onto the existing > handover protocol work, which is my primary concern. There is too much > duplication currently in both drafts of protocol that FMIP and ND provide. > [eunsoo] You cannot rely on something that is not fixed yet. Mixing two things while both are under change will make any decision very difficult. Once two things are fixed, then we can think about possible merge scenario or adjustment. It is not an ideal situation but it is what we have today. > > Anyway, it seems you agree that we don't need the server for CARD. Am I > > right? > > > > I hope at the working group meeting we can get some agreement about problems of > the server approach, how much geographical accuracy is enough, and whether we > should use a server or a router to router approach. > [eunsoo] Can you please confirm my understanding or answer my question in the above? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 14:57:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04477 for ; Sun, 16 Mar 2003 14:57:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKD2O20180; Sun, 16 Mar 2003 15:13:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKC5O20149 for ; Sun, 16 Mar 2003 15:12:05 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04429 for ; Sun, 16 Mar 2003 14:55:30 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 14:57:43 -0500 Message-ID: <023901c2ec0f$9a6b8f00$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> <036801c2eb15$4faddc70$e26b0f8a@eunsoo> <010801c2eb36$3f1e0ad0$456015ac@T23KEMPF> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sun, 16 Mar 2003 14:58:47 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 19:57:43.0872 (UTC) FILETIME=[4EF16400:01C2EBF6] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, My comments are inline. > > I think you are distinguishing two things clearly: discovering GAAP/GAAR and > > checking authorization of AP/AR. > > Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is > > not identified in advance. It is what the protocol should discover. So we > > can only say an AP/AR is authorized to participate in the CARD protocol or > > the discovery process. > > > The two are distinct, but they are not disconnected. That is, before an AP can > even be considered as a GAAP, it must be authorized. Thus, checking whether an > AP is authorized is a prerequesite for determining if it is a GAAP. > > > One of the main functionalities of the CARD protocol is to discover > > GAAP/GAAR and that is what we have to focus on at this moment. > > > > How to check an AP/AR is authorized to participate in the CARD protocol can > > be separated from CARD since it is a kind of general authorization problem. > > It is almost the same problem with what is in the IP routing protocol. So we > > can take a look at existing solutions and can take one. > > > > The problem is that there are currently *no* existing solutions to dynamically > determining whether an AP is authorized. Since our goal is to enable > autoconfiguration, there's a problem. CARD is dependent on something that > doesn't exist. > As you said below, we can proceed assuming static configuration for this. The fast handoff proposal of the MobileIP WG also proceeded without a solution for dynamic L2-L3 mapping. As we wee, that problem can be solved independently of the rest of the fast handoff proposal. > Static configuration of the AAPL is always possible, of course. But, at that > point, one must ask why not also statically configure the information on > geographical adjacency? If a new AP is added, the authorization list must be > changed anyway, so the geographical adjacency information could be added too. So > a fully statically configured back end is one possibility. > [eunsoo] As I said below, it is rarely practical to use geographical information in general situations. Do you know exact coverage of an 802.11 AP in your officie building? Also it is affected by the environment which may change without your notice. > At the next level, one could just statically configure the authorization list, > and have the geographical check be dynamic, presumably because the geographical > information was harder to configure. But I am somewhat skeptical of this. > [eunsoo] I remember that you said using geographical information for CARD was not practical. Now you say differently. I think your previous opinion is correct. It is not practical in many situations. Just configuring whether an AP connected to an AR is authorized is not such a difficult job at all. It is clear to the admin from the beginning when he connected the AP to the AR. > The next level is fully dynamic autoconfiguration for both authorization and > geographical check. This is, of course, the ideal. > > > Please notice that node<->router protocol has two aspects: discovery process > > and information distribution process. > > For the discovery process, we are seeing that we need interaction between > > router and MN and between router and router in Dycard. Also the server > > approach requires interaction between router and MN and between router and > > the server. So simply separating communication between router and MN and > > between router and router is not appropriate. > > > > I think separating it might make it easier to fit CARD onto the existing > handover protocol work, which is my primary concern. There is too much > duplication currently in both drafts of protocol that FMIP and ND provide. > [eunsoo] You cannot rely on something that is not fixed yet. Mixing two things while both are under change will make any decision very difficult. Once two things are fixed, then we can think about possible merge scenario or adjustment. It is not an ideal situation but it is what we have today. > > Anyway, it seems you agree that we don't need the server for CARD. Am I > > right? > > > > I hope at the working group meeting we can get some agreement about problems of > the server approach, how much geographical accuracy is enough, and whether we > should use a server or a router to router approach. > [eunsoo] Can you please confirm my understanding or answer my question in the above? Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 15:03:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04611 for ; Sun, 16 Mar 2003 15:03:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKJJG20388 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:19:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKJJO20385 for ; Sun, 16 Mar 2003 15:19:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04595 for ; Sun, 16 Mar 2003 15:02:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKJ8O20368; Sun, 16 Mar 2003 15:19:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKI3O20326 for ; Sun, 16 Mar 2003 15:18:03 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04575 for ; Sun, 16 Mar 2003 15:01:28 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2GK32u5003256 for ; Sun, 16 Mar 2003 13:03:02 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA20514 for ; Sun, 16 Mar 2003 13:01:34 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 14:03:40 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE77@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , Hemant.Chaskar@nokia.com, robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 14:03:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , I am also very interested to hear from other members of WG about the DT proposal who are not members of the DT and are not affiliated to them. There were many issues raised about the DT proposal such as cache contamination and even the fundamental need of the central server. I have not heard convincing explanations from the DT members as well as any supporting opinion from non-DT members yet. I'd appreciate if anyone provides one. AJOY-> I have indicated in my earlier email that we need discuss your so called cache contamination comments either offline to during IETF presentation. BTW, here a few reasons for having server (e.g., AAA) based CARD functions: 1. Server based approach is able to provide seamless handoff even if the CAR information is not available in the current AR cache. This has been made clear in previous discussion. 2. The servers are easier to configure and manage. 3. Server can be used for inter-AR authorization. -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 4:39 PM To: Singh Ajoy-ASINGH1; Hemant.Chaskar@nokia.com; robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > I am also very interested to hear from other members of WG about the DT proposal who are not members of the DT and are not affiliated to them. There were many issues raised about the DT proposal such as cache contamination and even the fundamental need of the central server. I have not heard convincing explanations from the DT members as well as any supporting opinion from non-DT members yet. I'd appreciate if anyone provides one. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 15:03:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04638 for ; Sun, 16 Mar 2003 15:03:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKJ8O20368; Sun, 16 Mar 2003 15:19:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKI3O20326 for ; Sun, 16 Mar 2003 15:18:03 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04575 for ; Sun, 16 Mar 2003 15:01:28 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2GK32u5003256 for ; Sun, 16 Mar 2003 13:03:02 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA20514 for ; Sun, 16 Mar 2003 13:01:34 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 14:03:40 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE77@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 , Hemant.Chaskar@nokia.com, robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 14:03:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , I am also very interested to hear from other members of WG about the DT proposal who are not members of the DT and are not affiliated to them. There were many issues raised about the DT proposal such as cache contamination and even the fundamental need of the central server. I have not heard convincing explanations from the DT members as well as any supporting opinion from non-DT members yet. I'd appreciate if anyone provides one. AJOY-> I have indicated in my earlier email that we need discuss your so called cache contamination comments either offline to during IETF presentation. BTW, here a few reasons for having server (e.g., AAA) based CARD functions: 1. Server based approach is able to provide seamless handoff even if the CAR information is not available in the current AR cache. This has been made clear in previous discussion. 2. The servers are easier to configure and manage. 3. Server can be used for inter-AR authorization. -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 4:39 PM To: Singh Ajoy-ASINGH1; Hemant.Chaskar@nokia.com; robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > I am also very interested to hear from other members of WG about the DT proposal who are not members of the DT and are not affiliated to them. There were many issues raised about the DT proposal such as cache contamination and even the fundamental need of the central server. I have not heard convincing explanations from the DT members as well as any supporting opinion from non-DT members yet. I'd appreciate if anyone provides one. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 15:09:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05254 for ; Sun, 16 Mar 2003 15:09:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKPEE20578 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:25:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKPEO20575 for ; Sun, 16 Mar 2003 15:25:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05201 for ; Sun, 16 Mar 2003 15:08:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKP2O20565; Sun, 16 Mar 2003 15:25:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKO2O20518 for ; Sun, 16 Mar 2003 15:24:02 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05077 for ; Sun, 16 Mar 2003 15:07:27 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 15:09:40 -0500 Message-ID: <024001c2ec11$45752720$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE76@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 15:10:44 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 20:09:40.0372 (UTC) FILETIME=[FA029D40:01C2EBF7] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ajoy, My comments are inline. > > Dycard does not exclude existence of an AAA server at > > all. > > > > AJOY-> Are you saying that dycard will use AAA server > > for providing inter-AR authorization? If yes, could > > you please explain us how this will be done. > > > [eunsoo] I think Dycard can be integrated with many ways of inter-AR > authorization. The current Dycard draft does not propose any specific method > yet. > > AJOY-> List few inter-AR authorization protocols that can be used. > You have not answered my question yet. > [eunsoo] A very simple solution is using shared secret key for intra-domain authorization check. This is just one example. > > I think the security requirements for CARD regarding AR authorization is > > quite similar to that of IP routing protocols. There are already > > proposed/implemented solutions for IP routing protocol security. > > > > AJOY-> Not really. The security requirements of CARD should > > be more stringent than inter-domain or intra-domain routing > > protocol. In CARD, any random MN is able to initiate the > > process of L2->L3 mapping as well as capability discovery. > > In dycard the mobile node provides the IP address of the AR > > with which the current AR is required to communicate to obtain > > the L2->L3 mapping as well as capabilities. The dycard MN can > > provide an IP address of a malicious CAR which may be any node > > on the Internet. If somehow the security of AR-CAR is compromised, > > this will cause the current AR to have bogus L2->L3 mapping as > > well invalid capabilities. This will have serious impact on > > the handoff performance of subsequent mobile nodes. The > > routing protocol does not initiate routing table update > > based upon trigger from a random mobile node and am > > not sure how the security requirement of routing > > protocol is comparable with CARD. > > > [eunsoo] > No matter what triggers the inter-AR authorization process, still it is two > ARs who are involved and responsible for checking authorization of each > other. MN cannot have influence on it. > > AJOY-> The current AR believes the information provided by MN > and acts upon that. So, I am not sure why you say that MN > does not have any influence over it. > [eunsoo] The current AR does not believe the information provided by MN as it is. It takes the information as an input and verifies it. It is the difference between the server approach and Dycard. The server approach does not verify it. It really believes it. But in Dycard, the previous AR and the current AR cooperate to verify the information. Once the information is given to the MN, MN is not involved in the verification process at all. Of course, MN is not involed in the inter-AR authorization process at all either. > So it is not correct to say CARD has > more strict security requirements regarding inter-AR authorization because > MN provides the trigger. > > AJOY-> Why not? > [eunsoo] My comment in the above explains this. > You cannot say corruption of the IP routing tables in the routers are less > serious than the curruption of the cache (CAR table) of the edge ARs. > > Also now you are say bogus L2-L3 mapping entries can cause serious > consequences. I pointed out repeatedly that the server approach cannot > prevent MN from providing a L2 address of an AP which is a GAAP and thus the > cache (the CAR table at the AR) will be contaminated. > What do you think of the seriousness of this problem? > > AJOY-> I do not agree with this statement. Let us discuss scope-id > approach offline or doing IETF presentation. I have already indicated > this in my earlier email to Dirk. > [eunsoo] Not everyone can attend the meeting. As far as I understand, the mailing list is the primary tool of discussion for the IETF. So I expect online discussion is not stopped. Also I repeatedly asked how the server approach can prevent cache contamination. No one answered it yet. If you are planning to answer it in the IETF meeting, I'd appreciate your answering it also in the mailing list. > > We had a separate thread for the need of the server for CARD. It was being > > summarized and so far there was no compelling reason to have a server for > > CARD. If you want to propose the server as the AAA server, please can you > do > > it in that thread? > > > > AJOY-> I have already stated this in my earlier email. The DT > > draft also mentions about this. I guess we can discuss this during > > Seamoby presentation. Also, I am very interested to hear from > > other members of WG who are not co-authors of dycard. > > > > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we > need is a AAA server but not a server that stores all the L2-L3 mapping > entries statically and provide them at the request of the ARs. > > AJOY-> If we need AAA sever then why not discuss about piggybacking > some additional function required by the CARD over it. I do not > see any reason to make CARD complicated protocol as being proposed > in dycard. > [eunsoo] Again, it should be presented first why we need a server for CARD. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 15:09:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05286 for ; Sun, 16 Mar 2003 15:09:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKP2O20565; Sun, 16 Mar 2003 15:25:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKO2O20518 for ; Sun, 16 Mar 2003 15:24:02 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05077 for ; Sun, 16 Mar 2003 15:07:27 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 15:09:40 -0500 Message-ID: <024001c2ec11$45752720$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE76@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 15:10:44 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 20:09:40.0372 (UTC) FILETIME=[FA029D40:01C2EBF7] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ajoy, My comments are inline. > > Dycard does not exclude existence of an AAA server at > > all. > > > > AJOY-> Are you saying that dycard will use AAA server > > for providing inter-AR authorization? If yes, could > > you please explain us how this will be done. > > > [eunsoo] I think Dycard can be integrated with many ways of inter-AR > authorization. The current Dycard draft does not propose any specific method > yet. > > AJOY-> List few inter-AR authorization protocols that can be used. > You have not answered my question yet. > [eunsoo] A very simple solution is using shared secret key for intra-domain authorization check. This is just one example. > > I think the security requirements for CARD regarding AR authorization is > > quite similar to that of IP routing protocols. There are already > > proposed/implemented solutions for IP routing protocol security. > > > > AJOY-> Not really. The security requirements of CARD should > > be more stringent than inter-domain or intra-domain routing > > protocol. In CARD, any random MN is able to initiate the > > process of L2->L3 mapping as well as capability discovery. > > In dycard the mobile node provides the IP address of the AR > > with which the current AR is required to communicate to obtain > > the L2->L3 mapping as well as capabilities. The dycard MN can > > provide an IP address of a malicious CAR which may be any node > > on the Internet. If somehow the security of AR-CAR is compromised, > > this will cause the current AR to have bogus L2->L3 mapping as > > well invalid capabilities. This will have serious impact on > > the handoff performance of subsequent mobile nodes. The > > routing protocol does not initiate routing table update > > based upon trigger from a random mobile node and am > > not sure how the security requirement of routing > > protocol is comparable with CARD. > > > [eunsoo] > No matter what triggers the inter-AR authorization process, still it is two > ARs who are involved and responsible for checking authorization of each > other. MN cannot have influence on it. > > AJOY-> The current AR believes the information provided by MN > and acts upon that. So, I am not sure why you say that MN > does not have any influence over it. > [eunsoo] The current AR does not believe the information provided by MN as it is. It takes the information as an input and verifies it. It is the difference between the server approach and Dycard. The server approach does not verify it. It really believes it. But in Dycard, the previous AR and the current AR cooperate to verify the information. Once the information is given to the MN, MN is not involved in the verification process at all. Of course, MN is not involed in the inter-AR authorization process at all either. > So it is not correct to say CARD has > more strict security requirements regarding inter-AR authorization because > MN provides the trigger. > > AJOY-> Why not? > [eunsoo] My comment in the above explains this. > You cannot say corruption of the IP routing tables in the routers are less > serious than the curruption of the cache (CAR table) of the edge ARs. > > Also now you are say bogus L2-L3 mapping entries can cause serious > consequences. I pointed out repeatedly that the server approach cannot > prevent MN from providing a L2 address of an AP which is a GAAP and thus the > cache (the CAR table at the AR) will be contaminated. > What do you think of the seriousness of this problem? > > AJOY-> I do not agree with this statement. Let us discuss scope-id > approach offline or doing IETF presentation. I have already indicated > this in my earlier email to Dirk. > [eunsoo] Not everyone can attend the meeting. As far as I understand, the mailing list is the primary tool of discussion for the IETF. So I expect online discussion is not stopped. Also I repeatedly asked how the server approach can prevent cache contamination. No one answered it yet. If you are planning to answer it in the IETF meeting, I'd appreciate your answering it also in the mailing list. > > We had a separate thread for the need of the server for CARD. It was being > > summarized and so far there was no compelling reason to have a server for > > CARD. If you want to propose the server as the AAA server, please can you > do > > it in that thread? > > > > AJOY-> I have already stated this in my earlier email. The DT > > draft also mentions about this. I guess we can discuss this during > > Seamoby presentation. Also, I am very interested to hear from > > other members of WG who are not co-authors of dycard. > > > > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we > need is a AAA server but not a server that stores all the L2-L3 mapping > entries statically and provide them at the request of the ARs. > > AJOY-> If we need AAA sever then why not discuss about piggybacking > some additional function required by the CARD over it. I do not > see any reason to make CARD complicated protocol as being proposed > in dycard. > [eunsoo] Again, it should be presented first why we need a server for CARD. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 15:24:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06417 for ; Sun, 16 Mar 2003 15:24:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKeNs21864 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:40:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeMO21861 for ; Sun, 16 Mar 2003 15:40:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06388 for ; Sun, 16 Mar 2003 15:23:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeBO21780; Sun, 16 Mar 2003 15:40:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKdgO21713 for ; Sun, 16 Mar 2003 15:39:42 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06357 for ; Sun, 16 Mar 2003 15:23:09 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 15:25:20 -0500 Message-ID: <025001c2ec13$759de110$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE77@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 15:26:23 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 20:25:20.0213 (UTC) FILETIME=[2A32F850:01C2EBFA] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I am also very interested to hear from other members of WG about the DT > proposal who are not members of the DT and are not affiliated to them. > There were many issues raised about the DT proposal such as cache > contamination and even the fundamental need of the central server. > I have not heard convincing explanations from the DT members as well as any > supporting opinion from non-DT members yet. > I'd appreciate if anyone provides one. > > AJOY-> I have indicated in my earlier email that we need > discuss your so called cache contamination comments > either offline to during IETF presentation. BTW, > here a few reasons for having server (e.g., AAA) > based CARD functions: > > 1. Server based approach is able to provide seamless > handoff even if the CAR information is not available in > the current AR cache. This has been made clear > in previous discussion. > [eunsoo] This is about initial population of the cache. We had lots of discussion about this. There were arguements about whether we need initial population of the cache. However it was clear that any existing management tool can be used for the initial population from the discussion. It tells us that we don't need to invenet the wheel for initial router configuration. > 2. The servers are easier to configure and manage. > [eunsoo] It is arguable. If you have to figure out proper scope-ids for every AR whenever there is a change in the network, it is not a really dummy job. Also we have to pay attention to the price of having a central server. In general it is easier to manage one entity than many entities but you have to pay the price of reliability (single point of failure) and scalability. I don't think the price is smaller than the benefit of easiness. > 3. Server can be used for inter-AR authorization. > > [eunsoo] Again, if we need a AAA server, we use it. We don't have to introduce a new type of server functionality. An important point is that there is alternative requiring no central server. Why should we bother ourselves with the server? We need compelling reasons such as something that should/can be provided only by the central server and that is not feasible in a solution without the server. Certainly it should not be the case where there is already the wheel or the price is much larger than the benefit. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 15:24:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06427 for ; Sun, 16 Mar 2003 15:24:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKeOa21880 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:40:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeOO21877 for ; Sun, 16 Mar 2003 15:40:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06393 for ; Sun, 16 Mar 2003 15:23:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeDO21801; Sun, 16 Mar 2003 15:40:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKdtO21721 for ; Sun, 16 Mar 2003 15:39:55 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06364 for ; Sun, 16 Mar 2003 15:23:21 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:25:32 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047772844.1135.51.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:23:57 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:25:32.0252 (UTC) FILETIME=[315FF9C0:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My thoughts on Server approaches Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. The last one is rumblings about inter-domain. This subject has come up before, and at that time the result was that it was out of scope (and it still is). Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 15:24:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06444 for ; Sun, 16 Mar 2003 15:24:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKeRb21902 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:40:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeRO21895 for ; Sun, 16 Mar 2003 15:40:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06402 for ; Sun, 16 Mar 2003 15:23:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeGO21837; Sun, 16 Mar 2003 15:40:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKdvO21729 for ; Sun, 16 Mar 2003 15:39:57 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06368 for ; Sun, 16 Mar 2003 15:23:24 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:25:33 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047773069.3344.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:24:01 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:25:33.0455 (UTC) FILETIME=[321789F0:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My thoughts on server approaches Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. The last one is rumblings about inter-domain. This subject has come up before, and at that time the result was that it was out of scope (and it still is). Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 15:24:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06466 for ; Sun, 16 Mar 2003 15:24:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKeUV21936 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:40:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeUO21933 for ; Sun, 16 Mar 2003 15:40:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06408 for ; Sun, 16 Mar 2003 15:23:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeIO21853; Sun, 16 Mar 2003 15:40:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKdwO21733 for ; Sun, 16 Mar 2003 15:39:58 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06370 for ; Sun, 16 Mar 2003 15:23:25 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:25:33 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047841967.3344.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:24:02 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:25:33.0908 (UTC) FILETIME=[325CA940:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My thoughts on server approaches (and other fun stuff) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. The last one is rumblings about inter-domain. This subject has come up before, and at that time the result was that it was out of scope (and it still is). Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 15:24:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06479 for ; Sun, 16 Mar 2003 15:24:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeDO21801; Sun, 16 Mar 2003 15:40:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKdtO21721 for ; Sun, 16 Mar 2003 15:39:55 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06364 for ; Sun, 16 Mar 2003 15:23:21 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:25:32 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047772844.1135.51.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:23:57 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:25:32.0252 (UTC) FILETIME=[315FF9C0:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My thoughts on Server approaches Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. The last one is rumblings about inter-domain. This subject has come up before, and at that time the result was that it was out of scope (and it still is). Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 15:24:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06492 for ; Sun, 16 Mar 2003 15:24:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeBO21780; Sun, 16 Mar 2003 15:40:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKdgO21713 for ; Sun, 16 Mar 2003 15:39:42 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06357 for ; Sun, 16 Mar 2003 15:23:09 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 15:25:20 -0500 Message-ID: <025001c2ec13$759de110$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE77@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 15:26:23 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 20:25:20.0213 (UTC) FILETIME=[2A32F850:01C2EBFA] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I am also very interested to hear from other members of WG about the DT > proposal who are not members of the DT and are not affiliated to them. > There were many issues raised about the DT proposal such as cache > contamination and even the fundamental need of the central server. > I have not heard convincing explanations from the DT members as well as any > supporting opinion from non-DT members yet. > I'd appreciate if anyone provides one. > > AJOY-> I have indicated in my earlier email that we need > discuss your so called cache contamination comments > either offline to during IETF presentation. BTW, > here a few reasons for having server (e.g., AAA) > based CARD functions: > > 1. Server based approach is able to provide seamless > handoff even if the CAR information is not available in > the current AR cache. This has been made clear > in previous discussion. > [eunsoo] This is about initial population of the cache. We had lots of discussion about this. There were arguements about whether we need initial population of the cache. However it was clear that any existing management tool can be used for the initial population from the discussion. It tells us that we don't need to invenet the wheel for initial router configuration. > 2. The servers are easier to configure and manage. > [eunsoo] It is arguable. If you have to figure out proper scope-ids for every AR whenever there is a change in the network, it is not a really dummy job. Also we have to pay attention to the price of having a central server. In general it is easier to manage one entity than many entities but you have to pay the price of reliability (single point of failure) and scalability. I don't think the price is smaller than the benefit of easiness. > 3. Server can be used for inter-AR authorization. > > [eunsoo] Again, if we need a AAA server, we use it. We don't have to introduce a new type of server functionality. An important point is that there is alternative requiring no central server. Why should we bother ourselves with the server? We need compelling reasons such as something that should/can be provided only by the central server and that is not feasible in a solution without the server. Certainly it should not be the case where there is already the wheel or the price is much larger than the benefit. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 15:24:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06505 for ; Sun, 16 Mar 2003 15:24:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeFO21818; Sun, 16 Mar 2003 15:40:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKduO21725 for ; Sun, 16 Mar 2003 15:39:56 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06366 for ; Sun, 16 Mar 2003 15:23:23 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:25:33 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047772956.3250.53.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:24:01 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:25:33.0095 (UTC) FILETIME=[31E09B70:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My thoughts on server approaches (and other fun stuff) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. The last one is rumblings about inter-domain. This subject has come up before, and at that time the result was that it was out of scope (and it still is). Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 15:24:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06518 for ; Sun, 16 Mar 2003 15:24:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeGO21837; Sun, 16 Mar 2003 15:40:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKdvO21729 for ; Sun, 16 Mar 2003 15:39:57 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06368 for ; Sun, 16 Mar 2003 15:23:24 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:25:33 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047773069.3344.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:24:01 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:25:33.0455 (UTC) FILETIME=[321789F0:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My thoughts on server approaches Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. The last one is rumblings about inter-domain. This subject has come up before, and at that time the result was that it was out of scope (and it still is). Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 15:24:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06531 for ; Sun, 16 Mar 2003 15:24:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeIO21853; Sun, 16 Mar 2003 15:40:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKdwO21733 for ; Sun, 16 Mar 2003 15:39:58 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06370 for ; Sun, 16 Mar 2003 15:23:25 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:25:33 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047841967.3344.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:24:02 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:25:33.0908 (UTC) FILETIME=[325CA940:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My thoughts on server approaches (and other fun stuff) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. The last one is rumblings about inter-domain. This subject has come up before, and at that time the result was that it was out of scope (and it still is). Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 15:26:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06590 for ; Sun, 16 Mar 2003 15:26:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKgDP21996 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:42:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKgDO21993 for ; Sun, 16 Mar 2003 15:42:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06585 for ; Sun, 16 Mar 2003 15:25:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKg2O21983; Sun, 16 Mar 2003 15:42:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKfqO21969 for ; Sun, 16 Mar 2003 15:41:52 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06558 for ; Sun, 16 Mar 2003 15:25:19 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:27:30 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047846358.12529.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:25:58 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:27:30.0537 (UTC) FILETIME=[77E0D590:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My apologies Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For the flood of e-mails... mailer fun :( PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 15:26:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06603 for ; Sun, 16 Mar 2003 15:26:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKg2O21983; Sun, 16 Mar 2003 15:42:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKfqO21969 for ; Sun, 16 Mar 2003 15:41:52 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06558 for ; Sun, 16 Mar 2003 15:25:19 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:27:30 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047846358.12529.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:25:58 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:27:30.0537 (UTC) FILETIME=[77E0D590:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My apologies Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit For the flood of e-mails... mailer fun :( PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 16:06:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07627 for ; Sun, 16 Mar 2003 16:06:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GLMWe24742 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 16:22:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLMWO24739 for ; Sun, 16 Mar 2003 16:22:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07580 for ; Sun, 16 Mar 2003 16:05:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLMHO24629; Sun, 16 Mar 2003 16:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLEKO23857 for ; Sun, 16 Mar 2003 16:14:20 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07297 for ; Sun, 16 Mar 2003 15:57:46 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2GKxpZj012073 for ; Sun, 16 Mar 2003 13:59:51 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA18795 for ; Sun, 16 Mar 2003 13:59:57 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 14:59:11 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE78@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 14:58:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 5:26 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination > I am also very interested to hear from other members of WG about the DT > proposal who are not members of the DT and are not affiliated to them. > There were many issues raised about the DT proposal such as cache > contamination and even the fundamental need of the central server. > I have not heard convincing explanations from the DT members as well as any > supporting opinion from non-DT members yet. > I'd appreciate if anyone provides one. > > AJOY-> I have indicated in my earlier email that we need > discuss your so called cache contamination comments > either offline to during IETF presentation. BTW, > here a few reasons for having server (e.g., AAA) > based CARD functions: > > 1. Server based approach is able to provide seamless > handoff even if the CAR information is not available in > the current AR cache. This has been made clear > in previous discussion. > [eunsoo] This is about initial population of the cache. We had lots of discussion about this. There were arguements about whether we need initial population of the cache. However it was clear that any existing management tool can be used for the initial population from the discussion. It tells us that we don't need to invenet the wheel for initial router configuration. AJOY-> Initial population of cache does not address the problems due to cache timeout as well as cases when a new AP is added or removed from the coverage area of an AR. Also, server less approach of initial cache population is very difficult and challenging task for the service providers. That is why we are defining CARD protocol in first place. If service provider would like to manually configure L2->L3 mapping at each and every ARs then there is no good reason for the existence of the CARD protocol. > 2. The servers are easier to configure and manage. > [eunsoo] It is arguable. If you have to figure out proper scope-ids for every AR whenever there is a change in the network, it is not a really dummy job. Also we have to pay attention to the price of having a central server. In general it is easier to manage one entity than many entities but you have to pay the price of reliability (single point of failure) and scalability. I don't think the price is smaller than the benefit of easiness. AJOY-> BTW, there is no additional price if the CARD is integrated with AAA function. On the contrary, I think probably managing 1000s of AR would be more expensive and error prone than managing a few servers. > 3. Server can be used for inter-AR authorization. > > [eunsoo] Again, if we need a AAA server, we use it. We don't have to introduce a new type of server functionality. AJOY-> If we need to use AAA server then why not enhance that to support CARD functionality as well. I do see any justification for deploying a complicated protocol such as dycard when we can achieve the same function my making some enhancements to AAA function. An important point is that there is alternative requiring no central server. Why should we bother ourselves with the server? AJOY-> This is because AAA servers are anyway required in an access network and can also be useful tool for providing inter-AR authorization. So, I do not see any convincing reason for deploying a complicated protocol like dycard. We need compelling reasons such as something that should/can be provided only by the central server and that is not feasible in a solution without the server. Certainly it should not be the case where there is already the wheel or the price is much larger than the benefit. AJOY-> I guess my previous reply would have answered your question. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 16:06:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07654 for ; Sun, 16 Mar 2003 16:06:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLMHO24629; Sun, 16 Mar 2003 16:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLEKO23857 for ; Sun, 16 Mar 2003 16:14:20 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07297 for ; Sun, 16 Mar 2003 15:57:46 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2GKxpZj012073 for ; Sun, 16 Mar 2003 13:59:51 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA18795 for ; Sun, 16 Mar 2003 13:59:57 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 14:59:11 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE78@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 14:58:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 5:26 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination > I am also very interested to hear from other members of WG about the DT > proposal who are not members of the DT and are not affiliated to them. > There were many issues raised about the DT proposal such as cache > contamination and even the fundamental need of the central server. > I have not heard convincing explanations from the DT members as well as any > supporting opinion from non-DT members yet. > I'd appreciate if anyone provides one. > > AJOY-> I have indicated in my earlier email that we need > discuss your so called cache contamination comments > either offline to during IETF presentation. BTW, > here a few reasons for having server (e.g., AAA) > based CARD functions: > > 1. Server based approach is able to provide seamless > handoff even if the CAR information is not available in > the current AR cache. This has been made clear > in previous discussion. > [eunsoo] This is about initial population of the cache. We had lots of discussion about this. There were arguements about whether we need initial population of the cache. However it was clear that any existing management tool can be used for the initial population from the discussion. It tells us that we don't need to invenet the wheel for initial router configuration. AJOY-> Initial population of cache does not address the problems due to cache timeout as well as cases when a new AP is added or removed from the coverage area of an AR. Also, server less approach of initial cache population is very difficult and challenging task for the service providers. That is why we are defining CARD protocol in first place. If service provider would like to manually configure L2->L3 mapping at each and every ARs then there is no good reason for the existence of the CARD protocol. > 2. The servers are easier to configure and manage. > [eunsoo] It is arguable. If you have to figure out proper scope-ids for every AR whenever there is a change in the network, it is not a really dummy job. Also we have to pay attention to the price of having a central server. In general it is easier to manage one entity than many entities but you have to pay the price of reliability (single point of failure) and scalability. I don't think the price is smaller than the benefit of easiness. AJOY-> BTW, there is no additional price if the CARD is integrated with AAA function. On the contrary, I think probably managing 1000s of AR would be more expensive and error prone than managing a few servers. > 3. Server can be used for inter-AR authorization. > > [eunsoo] Again, if we need a AAA server, we use it. We don't have to introduce a new type of server functionality. AJOY-> If we need to use AAA server then why not enhance that to support CARD functionality as well. I do see any justification for deploying a complicated protocol such as dycard when we can achieve the same function my making some enhancements to AAA function. An important point is that there is alternative requiring no central server. Why should we bother ourselves with the server? AJOY-> This is because AAA servers are anyway required in an access network and can also be useful tool for providing inter-AR authorization. So, I do not see any convincing reason for deploying a complicated protocol like dycard. We need compelling reasons such as something that should/can be provided only by the central server and that is not feasible in a solution without the server. Certainly it should not be the case where there is already the wheel or the price is much larger than the benefit. AJOY-> I guess my previous reply would have answered your question. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 16:11:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06443 for ; Sun, 16 Mar 2003 15:24:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKeRE21899 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 15:40:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeRO21893 for ; Sun, 16 Mar 2003 15:40:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06400 for ; Sun, 16 Mar 2003 15:23:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKeFO21818; Sun, 16 Mar 2003 15:40:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKduO21725 for ; Sun, 16 Mar 2003 15:39:56 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06366 for ; Sun, 16 Mar 2003 15:23:23 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:25:33 -0800 From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Message-Id: <1047772956.3250.53.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 12:24:01 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 20:25:33.0095 (UTC) FILETIME=[31E09B70:01C2EBFA] Content-Transfer-Encoding: 7bit Subject: [Seamoby] My thoughts on server approaches (and other fun stuff) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. The last one is rumblings about inter-domain. This subject has come up before, and at that time the result was that it was out of scope (and it still is). Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 16:15:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07909 for ; Sun, 16 Mar 2003 16:15:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GLW1M25513 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 16:32:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLW0O25510 for ; Sun, 16 Mar 2003 16:32:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07903 for ; Sun, 16 Mar 2003 16:15:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLVSO25494; Sun, 16 Mar 2003 16:31:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLS0O25269 for ; Sun, 16 Mar 2003 16:28:00 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07802 for ; Sun, 16 Mar 2003 16:11:26 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 13:13:37 -0800 Subject: Re: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) From: Pat Calhoun To: Robert Chalmers Cc: James Kempf , seamoby@ietf.org In-Reply-To: <3E743304.2050705@cs.ucsb.edu> References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> <3E72858F.5050503@cs.ucsb.edu> <005f01c2eb2e$e6d050b0$456015ac@T23KEMPF> <3E743304.2050705@cs.ucsb.edu> Content-Type: text/plain Message-Id: <1047849125.12531.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 13:12:05 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 21:13:37.0516 (UTC) FILETIME=[E92052C0:01C2EC00] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert, First off, the DT does not (or should not) have more power than anyone else in the WG. They were merely selected to help work on a document, but the ultimate decision comes from the WG, not the DT. If the DT comes out with a document, and the general consensus is that the work is not worth the disk space it takes up, then we trash it. I appreciate the fact that some folks have come up with an alternative proposal. This provides the WG with some alternatives on how to solve a problem, which the DT may not have thought of. Ultimately, it's up to the WG. If the consensus is that the DT was wrong, and that dycard should be used as a starting point, then that's the decision we'll make... However, I haven't heard that... yet. Keep up the great discussions. I understand there's alot of controversy here, but I have to agree that I do see some benefits to some of the dycard proposal PatC On Sun, 2003-03-16 at 00:17, Robert Chalmers wrote: > James, > > > I think you and perhaps others in the WG may have some misunderstands > > about the nature of IETF Design Teams. > > > I don't think so. I do feel, however, that in reality design teams end > up wielding more power than is intended. It seems like this basic > argument should have taken place before the design team was ever formed. > > > The product of the Design Team is only a suggestion and it can be > > amended by the Working Group. Thus, if it turns out that the DT draft > > has "gaping holes" (and I would be the last one to suggest that it > > is a finished product), they must be filled. If it turns out that > > Dycard has some good ideas to fill them, and the WG agrees, then > > those ideas will be used. I believe the discussion in the last couple > > weeks has identified a couple holes in the DT draft, and I believe > > there have been some reasonable suggestions from the Dycard team to > > fill them. We need to consider them. > > > The point I was trying to make had more to do with your recent comments > concerning the fact that dyCARD needs to be explained to the WG. Is the > DT draft somehow crystal clear? The dyCARD draft is pretty explicit, but > there are bound to be omissions and/or implicit > assumptions that are not explained well enough (e.g., rate limiting). I > just want to make sure that everything is spelled out so that its > "understandable" to the WG, so that the concepts aren't disregarded > simply because a detail has not been fully addressed in writing. > > > Of course, if the intent of the Dycard team in posting the draft was > > that the Dycard design was a "take it or leave it" proposition, then > > I'm afraid that is not how IETF WGs function. Even if the original > > base WG draft is an individual contribution, it is often amended and > > ultimately may look nothing like the original design (in fact, the > > original designers may get sick of working on it and leave the > > working group after a couple years). > > > Absolutely not. But it does seem that every detail of dyCARD has to be > addressed before the general concept is given due consideration by the > design team. And I really don't feel that the server-based approach has > been faced with the same restrictions. That's just my impression of the > way the argument has progressed over the last week or so. > > Please don't take this as some outraged rant. It's just a little annoyed > rant :0) Your comment just struck me as odd, not to mention the dyHard > references. I'm just looking for a fair consideration of both general > techniques. > > enjoy, > bob _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 16:16:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07930 for ; Sun, 16 Mar 2003 16:16:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLVSO25494; Sun, 16 Mar 2003 16:31:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLS0O25269 for ; Sun, 16 Mar 2003 16:28:00 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07802 for ; Sun, 16 Mar 2003 16:11:26 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 13:13:37 -0800 Subject: Re: How Design Teams Work(was: Re: [Seamoby] updated dyCARD draft) From: Pat Calhoun To: Robert Chalmers Cc: James Kempf , seamoby@ietf.org In-Reply-To: <3E743304.2050705@cs.ucsb.edu> References: <3E722D95.1050908@cs.ucsb.edu> <01da01c2ea6c$d4f579a0$286015ac@T23KEMPF> <3E72858F.5050503@cs.ucsb.edu> <005f01c2eb2e$e6d050b0$456015ac@T23KEMPF> <3E743304.2050705@cs.ucsb.edu> Content-Type: text/plain Message-Id: <1047849125.12531.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 13:12:05 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 21:13:37.0516 (UTC) FILETIME=[E92052C0:01C2EC00] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, First off, the DT does not (or should not) have more power than anyone else in the WG. They were merely selected to help work on a document, but the ultimate decision comes from the WG, not the DT. If the DT comes out with a document, and the general consensus is that the work is not worth the disk space it takes up, then we trash it. I appreciate the fact that some folks have come up with an alternative proposal. This provides the WG with some alternatives on how to solve a problem, which the DT may not have thought of. Ultimately, it's up to the WG. If the consensus is that the DT was wrong, and that dycard should be used as a starting point, then that's the decision we'll make... However, I haven't heard that... yet. Keep up the great discussions. I understand there's alot of controversy here, but I have to agree that I do see some benefits to some of the dycard proposal PatC On Sun, 2003-03-16 at 00:17, Robert Chalmers wrote: > James, > > > I think you and perhaps others in the WG may have some misunderstands > > about the nature of IETF Design Teams. > > > I don't think so. I do feel, however, that in reality design teams end > up wielding more power than is intended. It seems like this basic > argument should have taken place before the design team was ever formed. > > > The product of the Design Team is only a suggestion and it can be > > amended by the Working Group. Thus, if it turns out that the DT draft > > has "gaping holes" (and I would be the last one to suggest that it > > is a finished product), they must be filled. If it turns out that > > Dycard has some good ideas to fill them, and the WG agrees, then > > those ideas will be used. I believe the discussion in the last couple > > weeks has identified a couple holes in the DT draft, and I believe > > there have been some reasonable suggestions from the Dycard team to > > fill them. We need to consider them. > > > The point I was trying to make had more to do with your recent comments > concerning the fact that dyCARD needs to be explained to the WG. Is the > DT draft somehow crystal clear? The dyCARD draft is pretty explicit, but > there are bound to be omissions and/or implicit > assumptions that are not explained well enough (e.g., rate limiting). I > just want to make sure that everything is spelled out so that its > "understandable" to the WG, so that the concepts aren't disregarded > simply because a detail has not been fully addressed in writing. > > > Of course, if the intent of the Dycard team in posting the draft was > > that the Dycard design was a "take it or leave it" proposition, then > > I'm afraid that is not how IETF WGs function. Even if the original > > base WG draft is an individual contribution, it is often amended and > > ultimately may look nothing like the original design (in fact, the > > original designers may get sick of working on it and leave the > > working group after a couple years). > > > Absolutely not. But it does seem that every detail of dyCARD has to be > addressed before the general concept is given due consideration by the > design team. And I really don't feel that the server-based approach has > been faced with the same restrictions. That's just my impression of the > way the argument has progressed over the last week or so. > > Please don't take this as some outraged rant. It's just a little annoyed > rant :0) Your comment just struck me as odd, not to mention the dyHard > references. I'm just looking for a fair consideration of both general > techniques. > > enjoy, > bob _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 16:19:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08007 for ; Sun, 16 Mar 2003 16:19:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GLZMT25700 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 16:35:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLZMO25697 for ; Sun, 16 Mar 2003 16:35:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07994 for ; Sun, 16 Mar 2003 16:18:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLZ8O25683; Sun, 16 Mar 2003 16:35:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLTAO25395 for ; Sun, 16 Mar 2003 16:29:10 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07861 for ; Sun, 16 Mar 2003 16:12:35 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2GLE8u5011294 for ; Sun, 16 Mar 2003 14:14:08 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA14449 for ; Sun, 16 Mar 2003 14:12:39 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 15:14:46 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE79@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 15:14:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 5:11 PM To: Singh Ajoy-ASINGH1; Hemant.Chaskar@nokia.com; robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Ajoy, My comments are inline. > > Dycard does not exclude existence of an AAA server at > > all. > > > > AJOY-> Are you saying that dycard will use AAA server > > for providing inter-AR authorization? If yes, could > > you please explain us how this will be done. > > > [eunsoo] I think Dycard can be integrated with many ways of inter-AR > authorization. The current Dycard draft does not propose any specific method > yet. > > AJOY-> List few inter-AR authorization protocols that can be used. > You have not answered my question yet. > [eunsoo] A very simple solution is using shared secret key for intra-domain authorization check. This is just one example. AJOY-> There are two problems here: 1. Authentication 2. Authorization If AR can authenticate each, this does not mean they can authorize each for CARD discovery. I am not sure manual configuration of SA for authenticating as well as authorizing AR for CAR discovery will scale in big access network. > > I think the security requirements for CARD regarding AR authorization is > > quite similar to that of IP routing protocols. There are already > > proposed/implemented solutions for IP routing protocol security. > > > > AJOY-> Not really. The security requirements of CARD should > > be more stringent than inter-domain or intra-domain routing > > protocol. In CARD, any random MN is able to initiate the > > process of L2->L3 mapping as well as capability discovery. > > In dycard the mobile node provides the IP address of the AR > > with which the current AR is required to communicate to obtain > > the L2->L3 mapping as well as capabilities. The dycard MN can > > provide an IP address of a malicious CAR which may be any node > > on the Internet. If somehow the security of AR-CAR is compromised, > > this will cause the current AR to have bogus L2->L3 mapping as > > well invalid capabilities. This will have serious impact on > > the handoff performance of subsequent mobile nodes. The > > routing protocol does not initiate routing table update > > based upon trigger from a random mobile node and am > > not sure how the security requirement of routing > > protocol is comparable with CARD. > > > [eunsoo] > No matter what triggers the inter-AR authorization process, still it is two > ARs who are involved and responsible for checking authorization of each > other. MN cannot have influence on it. > > AJOY-> The current AR believes the information provided by MN > and acts upon that. So, I am not sure why you say that MN > does not have any influence over it. > [eunsoo] The current AR does not believe the information provided by MN as it is. It takes the information as an input and verifies it. It is the difference between the server approach and Dycard. The server approach does not verify it. It really believes it. But in Dycard, the previous AR and the current AR cooperate to verify the information. Once the information is given to the MN, MN is not involved in the verification process at all. Of course, MN is not involed in the inter-AR authorization process at all either. AJOY-> In server based approach, AR gets correct information from the server so AR is not required to validate this. > So it is not correct to say CARD has > more strict security requirements regarding inter-AR authorization because > MN provides the trigger. > > AJOY-> Why not? > [eunsoo] My comment in the above explains this. AJOY-> I am not sure it does. Please see my earlier reply. > You cannot say corruption of the IP routing tables in the routers are less > serious than the curruption of the cache (CAR table) of the edge ARs. > > Also now you are say bogus L2-L3 mapping entries can cause serious > consequences. I pointed out repeatedly that the server approach cannot > prevent MN from providing a L2 address of an AP which is a GAAP and thus the > cache (the CAR table at the AR) will be contaminated. > What do you think of the seriousness of this problem? > > AJOY-> I do not agree with this statement. Let us discuss scope-id > approach offline or doing IETF presentation. I have already indicated > this in my earlier email to Dirk. > [eunsoo] Not everyone can attend the meeting. As far as I understand, the mailing list is the primary tool of discussion for the IETF. So I expect online discussion is not stopped. AJOY-> Sure. Also I repeatedly asked how the server approach can prevent cache contamination. No one answered it yet. If you are planning to answer it in the IETF meeting, I'd appreciate your answering it also in the mailing list. AJOY-> So far we had lots of discussion about the cache contamination and have not been able to resolve the issue over email discussion. Hopefully, face to face discussion would help us to resolve this issue. This way we may be able to engage some security experts who may attend WG meeting but may not be participating in the email discussion. > > We had a separate thread for the need of the server for CARD. It was being > > summarized and so far there was no compelling reason to have a server for > > CARD. If you want to propose the server as the AAA server, please can you > do > > it in that thread? > > > > AJOY-> I have already stated this in my earlier email. The DT > > draft also mentions about this. I guess we can discuss this during > > Seamoby presentation. Also, I am very interested to hear from > > other members of WG who are not co-authors of dycard. > > > > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we > need is a AAA server but not a server that stores all the L2-L3 mapping > entries statically and provide them at the request of the ARs. > > AJOY-> If we need AAA sever then why not discuss about piggybacking > some additional function required by the CARD over it. I do not > see any reason to make CARD complicated protocol as being proposed > in dycard. > [eunsoo] Again, it should be presented first why we need a server for CARD. AJOY-> I have explained this so many times. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 16:19:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08022 for ; Sun, 16 Mar 2003 16:19:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLZ8O25683; Sun, 16 Mar 2003 16:35:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLTAO25395 for ; Sun, 16 Mar 2003 16:29:10 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07861 for ; Sun, 16 Mar 2003 16:12:35 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2GLE8u5011294 for ; Sun, 16 Mar 2003 14:14:08 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA14449 for ; Sun, 16 Mar 2003 14:12:39 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 15:14:46 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE79@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" Cc: seamoby@ietf.org Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 15:14:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 5:11 PM To: Singh Ajoy-ASINGH1; Hemant.Chaskar@nokia.com; robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Ajoy, My comments are inline. > > Dycard does not exclude existence of an AAA server at > > all. > > > > AJOY-> Are you saying that dycard will use AAA server > > for providing inter-AR authorization? If yes, could > > you please explain us how this will be done. > > > [eunsoo] I think Dycard can be integrated with many ways of inter-AR > authorization. The current Dycard draft does not propose any specific method > yet. > > AJOY-> List few inter-AR authorization protocols that can be used. > You have not answered my question yet. > [eunsoo] A very simple solution is using shared secret key for intra-domain authorization check. This is just one example. AJOY-> There are two problems here: 1. Authentication 2. Authorization If AR can authenticate each, this does not mean they can authorize each for CARD discovery. I am not sure manual configuration of SA for authenticating as well as authorizing AR for CAR discovery will scale in big access network. > > I think the security requirements for CARD regarding AR authorization is > > quite similar to that of IP routing protocols. There are already > > proposed/implemented solutions for IP routing protocol security. > > > > AJOY-> Not really. The security requirements of CARD should > > be more stringent than inter-domain or intra-domain routing > > protocol. In CARD, any random MN is able to initiate the > > process of L2->L3 mapping as well as capability discovery. > > In dycard the mobile node provides the IP address of the AR > > with which the current AR is required to communicate to obtain > > the L2->L3 mapping as well as capabilities. The dycard MN can > > provide an IP address of a malicious CAR which may be any node > > on the Internet. If somehow the security of AR-CAR is compromised, > > this will cause the current AR to have bogus L2->L3 mapping as > > well invalid capabilities. This will have serious impact on > > the handoff performance of subsequent mobile nodes. The > > routing protocol does not initiate routing table update > > based upon trigger from a random mobile node and am > > not sure how the security requirement of routing > > protocol is comparable with CARD. > > > [eunsoo] > No matter what triggers the inter-AR authorization process, still it is two > ARs who are involved and responsible for checking authorization of each > other. MN cannot have influence on it. > > AJOY-> The current AR believes the information provided by MN > and acts upon that. So, I am not sure why you say that MN > does not have any influence over it. > [eunsoo] The current AR does not believe the information provided by MN as it is. It takes the information as an input and verifies it. It is the difference between the server approach and Dycard. The server approach does not verify it. It really believes it. But in Dycard, the previous AR and the current AR cooperate to verify the information. Once the information is given to the MN, MN is not involved in the verification process at all. Of course, MN is not involed in the inter-AR authorization process at all either. AJOY-> In server based approach, AR gets correct information from the server so AR is not required to validate this. > So it is not correct to say CARD has > more strict security requirements regarding inter-AR authorization because > MN provides the trigger. > > AJOY-> Why not? > [eunsoo] My comment in the above explains this. AJOY-> I am not sure it does. Please see my earlier reply. > You cannot say corruption of the IP routing tables in the routers are less > serious than the curruption of the cache (CAR table) of the edge ARs. > > Also now you are say bogus L2-L3 mapping entries can cause serious > consequences. I pointed out repeatedly that the server approach cannot > prevent MN from providing a L2 address of an AP which is a GAAP and thus the > cache (the CAR table at the AR) will be contaminated. > What do you think of the seriousness of this problem? > > AJOY-> I do not agree with this statement. Let us discuss scope-id > approach offline or doing IETF presentation. I have already indicated > this in my earlier email to Dirk. > [eunsoo] Not everyone can attend the meeting. As far as I understand, the mailing list is the primary tool of discussion for the IETF. So I expect online discussion is not stopped. AJOY-> Sure. Also I repeatedly asked how the server approach can prevent cache contamination. No one answered it yet. If you are planning to answer it in the IETF meeting, I'd appreciate your answering it also in the mailing list. AJOY-> So far we had lots of discussion about the cache contamination and have not been able to resolve the issue over email discussion. Hopefully, face to face discussion would help us to resolve this issue. This way we may be able to engage some security experts who may attend WG meeting but may not be participating in the email discussion. > > We had a separate thread for the need of the server for CARD. It was being > > summarized and so far there was no compelling reason to have a server for > > CARD. If you want to propose the server as the AAA server, please can you > do > > it in that thread? > > > > AJOY-> I have already stated this in my earlier email. The DT > > draft also mentions about this. I guess we can discuss this during > > Seamoby presentation. Also, I am very interested to hear from > > other members of WG who are not co-authors of dycard. > > > > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we > need is a AAA server but not a server that stores all the L2-L3 mapping > entries statically and provide them at the request of the ARs. > > AJOY-> If we need AAA sever then why not discuss about piggybacking > some additional function required by the CARD over it. I do not > see any reason to make CARD complicated protocol as being proposed > in dycard. > [eunsoo] Again, it should be presented first why we need a server for CARD. AJOY-> I have explained this so many times. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 16:39:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08954 for ; Sun, 16 Mar 2003 16:39:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GLtJt27246 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 16:55:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLtJO27242 for ; Sun, 16 Mar 2003 16:55:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08931 for ; Sun, 16 Mar 2003 16:38:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLt6O27227; Sun, 16 Mar 2003 16:55:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLsXO27198 for ; Sun, 16 Mar 2003 16:54:33 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08907 for ; Sun, 16 Mar 2003 16:37:57 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 16:40:09 -0500 Message-ID: <029e01c2ec1d$e985ec30$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE78@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 16:41:13 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 21:40:09.0929 (UTC) FILETIME=[9E474390:01C2EC04] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > > > 1. Server based approach is able to provide seamless > > handoff even if the CAR information is not available in > > the current AR cache. This has been made clear > > in previous discussion. > > > [eunsoo] This is about initial population of the cache. We had lots of > discussion about this. There were arguements about whether we need initial > population of the cache. However it was clear that any existing management > tool can be used for the initial population from the discussion. It tells us > that we don't need to invenet the wheel for initial router configuration. > > AJOY-> Initial population of cache does not address the problems due to > cache timeout as well as cases when a new AP is added or removed from > the coverage area of an AR. Also, server less approach of initial cache > population is very difficult and challenging task for the service providers. > [eunsoo] Initial population in Dycard is just done by one handoff between each pair of CARs. What is so difficult and challenging? Can you please explain your claims? It was pointed out that the cache (CAR table) would be refreshed by repeated handoffs and thus we would see rarely timeout of the cache entries unless there was no handoff between two CARs for a long time. Of couse, when a new AP/AR is added, we need a learning period in Dycard like the dynamic IP routing protocol. Because of tradeoffs between static and central system and dynamic and distributed system, people have adopted dynamic and distributed IP routing protocols in most cases. Also please notice that you need to reconfigure the server whenever there is a change in AP/AR, like even simple IP address change. I don't think the learning period justifies any static and central system. > That is why we are defining CARD protocol in first place. If service > provider would like to manually configure L2->L3 mapping at each and > every ARs then there is no good reason for the existence of the CARD > protocol. > [eunsoo] You are confused. In Dycard, the admin does NOT have to configure L2-L3 mapping entries at each AR. It is discovered dynamically. Actually the server approach require that it is manually entered in the server. > > 2. The servers are easier to configure and manage. > > > [eunsoo] It is arguable. If you have to figure out proper scope-ids for > every AR whenever there is a change in the network, it is not a really dummy > job. > Also we have to pay attention to the price of having a central server. In > general it is easier to manage one entity than many entities but you have to > pay the price of reliability (single point of failure) and scalability. > > I don't think the price is smaller than the benefit of easiness. > > AJOY-> BTW, there is no additional price if the CARD is integrated > with AAA function. On the contrary, I think probably managing 1000s of > AR would be more expensive and error prone than managing a few > servers. > [eunsoo] The fact there is an AAA server does not mean we should use it. Or it does not mean we have to share (actually double) the price of reliability and scalability with the AAA server. Now the discussion is getting into somewhat philosophical stage: Dynamic and distributed system versus static and central system.... Also it sounds to me like this. We have a printer server. So let's build a central file system. Also let's build a central routing system. All the reliability and scalability cost was already paid by the printer server... This is not a right approach. The central AAA server does not mean we can make CARD also kind of a central system without any additional price. Now you are putting the reliability and scalability cost on the CARD protocol as well as the AAA protocol. > > 3. Server can be used for inter-AR authorization. > > > > > [eunsoo] Again, if we need a AAA server, we use it. We don't have to > introduce a new type of server functionality. > > AJOY-> If we need to use AAA server then > why not enhance that to support CARD functionality as well. I do > see any justification for deploying a complicated protocol such > as dycard when we can achieve the same function my making some > enhancements to AAA function. > [eunsoo] Please see my above comments. > An important point is that there is alternative requiring no central server. > Why should we bother ourselves with the server? > > AJOY-> This is because AAA servers are anyway required in an access > network and can also be useful tool for providing inter-AR > authorization. So, I do not see any convincing reason for deploying a > complicated protocol like dycard. > [eunsoo] Can you please substantiate your claim that Dycard is a complicated protocol? > We need compelling reasons > such as something that should/can be provided only by the central server and > that is not feasible in a solution without the server. > Certainly it should > not be the case where there is already the wheel or the price is much larger > than the benefit. > > AJOY-> I guess my previous reply would have answered your question. > [eunsoo] Not really. The main argument was that there was a AAA server and thus let's use it as the central CARD server. You did not say what could be done by having the server which was not possible without the server. Regarding the initial cache population, it was also mentioned many times that we could use any existing management tool if we need it. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 16:39:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08968 for ; Sun, 16 Mar 2003 16:39:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLt6O27227; Sun, 16 Mar 2003 16:55:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLsXO27198 for ; Sun, 16 Mar 2003 16:54:33 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08907 for ; Sun, 16 Mar 2003 16:37:57 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 16:40:09 -0500 Message-ID: <029e01c2ec1d$e985ec30$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE78@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 16:41:13 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Mar 2003 21:40:09.0929 (UTC) FILETIME=[9E474390:01C2EC04] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > > > 1. Server based approach is able to provide seamless > > handoff even if the CAR information is not available in > > the current AR cache. This has been made clear > > in previous discussion. > > > [eunsoo] This is about initial population of the cache. We had lots of > discussion about this. There were arguements about whether we need initial > population of the cache. However it was clear that any existing management > tool can be used for the initial population from the discussion. It tells us > that we don't need to invenet the wheel for initial router configuration. > > AJOY-> Initial population of cache does not address the problems due to > cache timeout as well as cases when a new AP is added or removed from > the coverage area of an AR. Also, server less approach of initial cache > population is very difficult and challenging task for the service providers. > [eunsoo] Initial population in Dycard is just done by one handoff between each pair of CARs. What is so difficult and challenging? Can you please explain your claims? It was pointed out that the cache (CAR table) would be refreshed by repeated handoffs and thus we would see rarely timeout of the cache entries unless there was no handoff between two CARs for a long time. Of couse, when a new AP/AR is added, we need a learning period in Dycard like the dynamic IP routing protocol. Because of tradeoffs between static and central system and dynamic and distributed system, people have adopted dynamic and distributed IP routing protocols in most cases. Also please notice that you need to reconfigure the server whenever there is a change in AP/AR, like even simple IP address change. I don't think the learning period justifies any static and central system. > That is why we are defining CARD protocol in first place. If service > provider would like to manually configure L2->L3 mapping at each and > every ARs then there is no good reason for the existence of the CARD > protocol. > [eunsoo] You are confused. In Dycard, the admin does NOT have to configure L2-L3 mapping entries at each AR. It is discovered dynamically. Actually the server approach require that it is manually entered in the server. > > 2. The servers are easier to configure and manage. > > > [eunsoo] It is arguable. If you have to figure out proper scope-ids for > every AR whenever there is a change in the network, it is not a really dummy > job. > Also we have to pay attention to the price of having a central server. In > general it is easier to manage one entity than many entities but you have to > pay the price of reliability (single point of failure) and scalability. > > I don't think the price is smaller than the benefit of easiness. > > AJOY-> BTW, there is no additional price if the CARD is integrated > with AAA function. On the contrary, I think probably managing 1000s of > AR would be more expensive and error prone than managing a few > servers. > [eunsoo] The fact there is an AAA server does not mean we should use it. Or it does not mean we have to share (actually double) the price of reliability and scalability with the AAA server. Now the discussion is getting into somewhat philosophical stage: Dynamic and distributed system versus static and central system.... Also it sounds to me like this. We have a printer server. So let's build a central file system. Also let's build a central routing system. All the reliability and scalability cost was already paid by the printer server... This is not a right approach. The central AAA server does not mean we can make CARD also kind of a central system without any additional price. Now you are putting the reliability and scalability cost on the CARD protocol as well as the AAA protocol. > > 3. Server can be used for inter-AR authorization. > > > > > [eunsoo] Again, if we need a AAA server, we use it. We don't have to > introduce a new type of server functionality. > > AJOY-> If we need to use AAA server then > why not enhance that to support CARD functionality as well. I do > see any justification for deploying a complicated protocol such > as dycard when we can achieve the same function my making some > enhancements to AAA function. > [eunsoo] Please see my above comments. > An important point is that there is alternative requiring no central server. > Why should we bother ourselves with the server? > > AJOY-> This is because AAA servers are anyway required in an access > network and can also be useful tool for providing inter-AR > authorization. So, I do not see any convincing reason for deploying a > complicated protocol like dycard. > [eunsoo] Can you please substantiate your claim that Dycard is a complicated protocol? > We need compelling reasons > such as something that should/can be provided only by the central server and > that is not feasible in a solution without the server. > Certainly it should > not be the case where there is already the wheel or the price is much larger > than the benefit. > > AJOY-> I guess my previous reply would have answered your question. > [eunsoo] Not really. The main argument was that there was a AAA server and thus let's use it as the central CARD server. You did not say what could be done by having the server which was not possible without the server. Regarding the initial cache population, it was also mentioned many times that we could use any existing management tool if we need it. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 16:58:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09554 for ; Sun, 16 Mar 2003 16:58:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GMEIf29327 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 17:14:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMEIO29324 for ; Sun, 16 Mar 2003 17:14:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09502 for ; Sun, 16 Mar 2003 16:57:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GME5O29317; Sun, 16 Mar 2003 17:14:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMDhO29293 for ; Sun, 16 Mar 2003 17:13:43 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09493 for ; Sun, 16 Mar 2003 16:57:07 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2GLxJIG019061 for ; Sun, 16 Mar 2003 14:59:19 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA29996 for ; Sun, 16 Mar 2003 14:57:11 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 15:59:18 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7A@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Pat Calhoun'" , seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Sun, 16 Mar 2003 15:59:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Pat, Thanks for expressing your thoughts. Please find my few inline comments. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 2:24 PM To: seamoby@ietf.org Subject: [Seamoby] My thoughts on server approaches (and other fun stuff) Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. AJOY-> I agree that requiring a new server introduces a single point of failure. But if we piggyback CARD function over the existing server such as AAA, it will not have this problem though. BTW, if WG decides not to that then I am fine with that too. But so far I have only heard from dycard co-authors. BTW, the DT proposed server based approach to get the feedback from WG. The DT will be happy change the approach if WG decides that. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. AJOY-> Servers are easier to manage. BTW, if the CARD function can be integrated with existing server function e.g., AAA, then I do not see why enterprise will need to manage extra infrastructure. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? AJOY-> I am not sure if comparing security requirements of intra-domain routing protocol with that of CARD is fair. I will definitely like to hear from the security experts because I do not consider myself as a security expert. The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). AJOY-> I think here simplicity is the key. If we can get simpler protocol that can guarantee less or zero call drop, then what is wrong in using that. I would request you to read dycard as well as DT draft to conclude which is more complicated protocol. Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. AJOY-> I agree that cell phone can drop the call due to poor radio conditions. The radio conditions change due to many factors which we cannot control sometime. But, cellular networks are not designed to drop the call though. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. AJOY-> I will be happy with such protocol if the protocol in questions is a simple protocol and provides significant benefit over other protocol in consideration. The last one is rumblings about inter-domain. This subject has come u before, and at that time the result was that it was out of scope (and it still is). AJOY-> Ok, but I suppose we are not discussing the inter-domain issues. Even in big access network, the security associations are not manually configured though. Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 16:58:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09585 for ; Sun, 16 Mar 2003 16:58:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GME5O29317; Sun, 16 Mar 2003 17:14:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMDhO29293 for ; Sun, 16 Mar 2003 17:13:43 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09493 for ; Sun, 16 Mar 2003 16:57:07 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2GLxJIG019061 for ; Sun, 16 Mar 2003 14:59:19 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA29996 for ; Sun, 16 Mar 2003 14:57:11 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 15:59:18 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7A@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Pat Calhoun'" , seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Sun, 16 Mar 2003 15:59:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Pat, Thanks for expressing your thoughts. Please find my few inline comments. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 2:24 PM To: seamoby@ietf.org Subject: [Seamoby] My thoughts on server approaches (and other fun stuff) Just caught up on the rather long e-mail thread, and wanted to communicate my feelings about the discussions going on. My initial reaction is that mandating a server is the wrong approach. I am not claiming that discovery over the air, or some other approach, is better, but *requiring* a server is problematic. AJOY-> I agree that requiring a new server introduces a single point of failure. But if we piggyback CARD function over the existing server such as AAA, it will not have this problem though. BTW, if WG decides not to that then I am fine with that too. But so far I have only heard from dycard co-authors. BTW, the DT proposed server based approach to get the feedback from WG. The DT will be happy change the approach if WG decides that. I agree that service providers will most likely not have much of an issue with requiring a server for their network, but I doubt that enterprises that require mobility, really want more infrastructure to manage. AJOY-> Servers are easier to manage. BTW, if the CARD function can be integrated with existing server function e.g., AAA, then I do not see why enterprise will need to manage extra infrastructure. One issue that I've heard in favor of a server approach is security. I'll admit that I don't understand all of the issues, but there are plenty of proof points where security can be provided without a backend server. Whether it be peer-2-peer authentication via shared secrets, certs, or what-have-you. In fact, maybe we should look at how OSPF domains are created, and how routers communicate in a secure fashion? I understand there are significant differences, but is there anything we can learn from? AJOY-> I am not sure if comparing security requirements of intra-domain routing protocol with that of CARD is fair. I will definitely like to hear from the security experts because I do not consider myself as a security expert. The next issue I have is what appears to be a requirement to build an iron-clad protocol. I get very nervous when I hear that folks want to create a protocol that cannot drop a single call (or packet!). AJOY-> I think here simplicity is the key. If we can get simpler protocol that can guarantee less or zero call drop, then what is wrong in using that. I would request you to read dycard as well as DT draft to conclude which is more complicated protocol. Let's be fair here folks, my cell phone drops calls all the time, regardless of whether I'm doing a 911 call or not. That's just the nature of 1) really complex systems, 2) unreliable code and 3) wireless is simply NOT reliable. So in my opinion, we need to design a protocol that works well, and can tolerate failures and recover from any problems. AJOY-> I agree that cell phone can drop the call due to poor radio conditions. The radio conditions change due to many factors which we cannot control sometime. But, cellular networks are not designed to drop the call though. I'm perfectly happy with a protocol that learns about it's neighbors. It's all about trade-offs. Ethernet also has a cache, and has designed a mechanism to re-validate the cache before it expires. Again, another area that we should look into, and determine whether it can be applied to this particular scenario. AJOY-> I will be happy with such protocol if the protocol in questions is a simple protocol and provides significant benefit over other protocol in consideration. The last one is rumblings about inter-domain. This subject has come u before, and at that time the result was that it was out of scope (and it still is). AJOY-> Ok, but I suppose we are not discussing the inter-domain issues. Even in big access network, the security associations are not manually configured though. Next is just a nit. When I hear "DT hat off", it provides the appearance that DT members have more power than the rest of the WG, and I just wanted to lay that one to rest... a DT serves the WG and does not have more power (or say). We are all individual contributors working towards a common goal. Hope this help, PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 17:20:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10276 for ; Sun, 16 Mar 2003 17:20:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GMaJe30103 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 17:36:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMaJO30100 for ; Sun, 16 Mar 2003 17:36:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10221 for ; Sun, 16 Mar 2003 17:19:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMa5O30094; Sun, 16 Mar 2003 17:36:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMY2O30009 for ; Sun, 16 Mar 2003 17:34:02 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10119 for ; Sun, 16 Mar 2003 17:17:25 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 14:19:37 -0800 Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) From: Pat Calhoun To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7A@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7A@IL27EXM10.cig.mot.com> Content-Type: text/plain Message-Id: <1047853085.12499.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 14:18:05 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 22:19:37.0596 (UTC) FILETIME=[218493C0:01C2EC0A] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > My initial reaction is that mandating a server is the wrong approach. I > am not claiming that discovery over the air, or some other approach, is > better, but *requiring* a server is problematic. > > AJOY-> I agree that requiring a new server introduces a single point > of failure. But if we piggyback CARD function over the existing > server such as AAA, it will not have this problem though. BTW, > if WG decides not to that then I am fine with that too. But so > far I have only heard from dycard co-authors. BTW, the DT > proposed server based approach to get the feedback from WG. > The DT will be happy change the approach if WG decides that. Right, and I'm providing my feedback... but I'm just one of many. > > I agree that service > providers will most likely not have much of an issue with requiring a > server for their network, but I doubt that enterprises that require > mobility, really want more infrastructure to manage. > > AJOY-> Servers are easier to manage. BTW, if the CARD function > can be integrated with existing server function e.g., AAA, then I do > not see why enterprise will need to manage extra infrastructure. embedded devices need to be configured, regardless of whether a server is present or not. At a minimum, you'll want to create some form of security relationship between the embedded device and the server... so there's no way around it :( > > One issue that I've heard in favor of a server approach is security. > I'll admit that I don't understand all of the issues, but there are > plenty of proof points where security can be provided without a backend > server. Whether it be peer-2-peer authentication via shared secrets, > certs, or what-have-you. In fact, maybe we should look at how OSPF > domains are created, and how routers communicate in a secure fashion? I > understand there are significant differences, but is there anything we > can learn from? > > AJOY-> I am not sure if comparing security requirements of intra-domain > routing protocol with that of CARD is fair. I will definitely like to > hear from the security experts because I do not consider myself > as a security expert. Well, maybe it's not a fair comparison, but I'd like to know why. If we are focused on intra-domain, then I see no difference. > > The next issue I have is what appears to be a requirement to build an > iron-clad protocol. I get very nervous when I hear that folks want to > create a protocol that cannot drop a single call (or packet!). > > AJOY-> I think here simplicity is the key. If we can get simpler > protocol that can guarantee less or zero call drop, then what is > wrong in using that. I would request you to read dycard as > well as DT draft to conclude which is more complicated protocol. There's nothing wrong with high availability, but there's a price to pay for that. If you're telling me that it's free... then I get really confused and am willing to be convinced :) > > Let's be > fair here folks, my cell phone drops calls all the time, regardless of > whether I'm doing a 911 call or not. That's just the nature of 1) really > complex systems, 2) unreliable code and 3) wireless is simply NOT > reliable. So in my opinion, we need to design a protocol that works > well, and can tolerate failures and recover from any problems. > > AJOY-> I agree that cell phone can drop the call due to poor > radio conditions. The radio conditions change due to many > factors which we cannot control sometime. But, cellular networks are > not designed to drop the call though. Ah, but that's my point exactly. They are designed to NOT drop calls, but they do. There's physics involved here, and there's nothing in the IETF we can do about it. So let's just keep that in mind while we decide how complex this needs to be. > > I'm perfectly happy with a protocol that learns about it's neighbors. > It's all about trade-offs. Ethernet also has a cache, and has designed a > mechanism to re-validate the cache before it expires. Again, another > area that we should look into, and determine whether it can be applied > to this particular scenario. > > AJOY-> I will be happy with such protocol if the protocol in questions > is a simple protocol and provides significant benefit over > other protocol in consideration. Simplicity, in itself, is a significant benefit. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 17:20:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10290 for ; Sun, 16 Mar 2003 17:20:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMa5O30094; Sun, 16 Mar 2003 17:36:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMY2O30009 for ; Sun, 16 Mar 2003 17:34:02 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10119 for ; Sun, 16 Mar 2003 17:17:25 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 14:19:37 -0800 Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) From: Pat Calhoun To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7A@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7A@IL27EXM10.cig.mot.com> Content-Type: text/plain Message-Id: <1047853085.12499.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 14:18:05 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2003 22:19:37.0596 (UTC) FILETIME=[218493C0:01C2EC0A] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > My initial reaction is that mandating a server is the wrong approach. I > am not claiming that discovery over the air, or some other approach, is > better, but *requiring* a server is problematic. > > AJOY-> I agree that requiring a new server introduces a single point > of failure. But if we piggyback CARD function over the existing > server such as AAA, it will not have this problem though. BTW, > if WG decides not to that then I am fine with that too. But so > far I have only heard from dycard co-authors. BTW, the DT > proposed server based approach to get the feedback from WG. > The DT will be happy change the approach if WG decides that. Right, and I'm providing my feedback... but I'm just one of many. > > I agree that service > providers will most likely not have much of an issue with requiring a > server for their network, but I doubt that enterprises that require > mobility, really want more infrastructure to manage. > > AJOY-> Servers are easier to manage. BTW, if the CARD function > can be integrated with existing server function e.g., AAA, then I do > not see why enterprise will need to manage extra infrastructure. embedded devices need to be configured, regardless of whether a server is present or not. At a minimum, you'll want to create some form of security relationship between the embedded device and the server... so there's no way around it :( > > One issue that I've heard in favor of a server approach is security. > I'll admit that I don't understand all of the issues, but there are > plenty of proof points where security can be provided without a backend > server. Whether it be peer-2-peer authentication via shared secrets, > certs, or what-have-you. In fact, maybe we should look at how OSPF > domains are created, and how routers communicate in a secure fashion? I > understand there are significant differences, but is there anything we > can learn from? > > AJOY-> I am not sure if comparing security requirements of intra-domain > routing protocol with that of CARD is fair. I will definitely like to > hear from the security experts because I do not consider myself > as a security expert. Well, maybe it's not a fair comparison, but I'd like to know why. If we are focused on intra-domain, then I see no difference. > > The next issue I have is what appears to be a requirement to build an > iron-clad protocol. I get very nervous when I hear that folks want to > create a protocol that cannot drop a single call (or packet!). > > AJOY-> I think here simplicity is the key. If we can get simpler > protocol that can guarantee less or zero call drop, then what is > wrong in using that. I would request you to read dycard as > well as DT draft to conclude which is more complicated protocol. There's nothing wrong with high availability, but there's a price to pay for that. If you're telling me that it's free... then I get really confused and am willing to be convinced :) > > Let's be > fair here folks, my cell phone drops calls all the time, regardless of > whether I'm doing a 911 call or not. That's just the nature of 1) really > complex systems, 2) unreliable code and 3) wireless is simply NOT > reliable. So in my opinion, we need to design a protocol that works > well, and can tolerate failures and recover from any problems. > > AJOY-> I agree that cell phone can drop the call due to poor > radio conditions. The radio conditions change due to many > factors which we cannot control sometime. But, cellular networks are > not designed to drop the call though. Ah, but that's my point exactly. They are designed to NOT drop calls, but they do. There's physics involved here, and there's nothing in the IETF we can do about it. So let's just keep that in mind while we decide how complex this needs to be. > > I'm perfectly happy with a protocol that learns about it's neighbors. > It's all about trade-offs. Ethernet also has a cache, and has designed a > mechanism to re-validate the cache before it expires. Again, another > area that we should look into, and determine whether it can be applied > to this particular scenario. > > AJOY-> I will be happy with such protocol if the protocol in questions > is a simple protocol and provides significant benefit over > other protocol in consideration. Simplicity, in itself, is a significant benefit. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 18:33:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13040 for ; Sun, 16 Mar 2003 18:33:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GNnGI02030 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 18:49:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNnGO02027 for ; Sun, 16 Mar 2003 18:49:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13023 for ; Sun, 16 Mar 2003 18:32:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNmoO02014; Sun, 16 Mar 2003 18:48:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNkAO01947 for ; Sun, 16 Mar 2003 18:46:10 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12987 for ; Sun, 16 Mar 2003 18:29:31 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2GNVbZj009700 for ; Sun, 16 Mar 2003 16:31:37 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA02198 for ; Sun, 16 Mar 2003 16:31:43 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 17:31:43 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Pat Calhoun'" , Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Sun, 16 Mar 2003 17:31:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Pat, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 4:18 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) > My initial reaction is that mandating a server is the wrong approach. I > am not claiming that discovery over the air, or some other approach, is > better, but *requiring* a server is problematic. > > AJOY-> I agree that requiring a new server introduces a single point > of failure. But if we piggyback CARD function over the existing > server such as AAA, it will not have this problem though. BTW, > if WG decides not to that then I am fine with that too. But so > far I have only heard from dycard co-authors. BTW, the DT > proposed server based approach to get the feedback from WG. > The DT will be happy change the approach if WG decides that. Right, and I'm providing my feedback... but I'm just one of many. > > I agree that service > providers will most likely not have much of an issue with requiring a > server for their network, but I doubt that enterprises that require > mobility, really want more infrastructure to manage. > > AJOY-> Servers are easier to manage. BTW, if the CARD function > can be integrated with existing server function e.g., AAA, then I do > not see why enterprise will need to manage extra infrastructure. embedded devices need to be configured, regardless of whether a server is present or not. AJOY-> Yup. How much cost it will add over the configuration of base AAA server? At a minimum, you'll want to create some form of security relationship between the embedded device and the server... so there's no way around it :( AJOY-> I did not follow this. If CARD function is extension of AAA function then why we need SA between embedded device and AAA server. > > One issue that I've heard in favor of a server approach is security. > I'll admit that I don't understand all of the issues, but there are > plenty of proof points where security can be provided without a backend > server. Whether it be peer-2-peer authentication via shared secrets, > certs, or what-have-you. In fact, maybe we should look at how OSPF > domains are created, and how routers communicate in a secure fashion? I > understand there are significant differences, but is there anything we > can learn from? > > AJOY-> I am not sure if comparing security requirements of intra-domain > routing protocol with that of CARD is fair. I will definitely like to > hear from the security experts because I do not consider myself > as a security expert. Well, maybe it's not a fair comparison, but I'd like to know why. If we are focused on intra-domain, then I see no difference. AJOY-> The dycard in initiated based upon trigger from a mobile node. The infrastructure does not have any control over what is provided by mobile node. What happens when a mobile node provides IP address of malicious node as CAR and the somehow security of AR is compromised? In this case, current AR will have to believe what is provided by the malicious CAR as valid information. This type of scenario may not be possible in intra-domain routing. But as I said before if security experts believe that this is not an issue and we can design a protocol assuming that security of AR will never be comprised, then I do have any problem. > > The next issue I have is what appears to be a requirement to build an > iron-clad protocol. I get very nervous when I hear that folks want to > create a protocol that cannot drop a single call (or packet!). > > AJOY-> I think here simplicity is the key. If we can get simpler > protocol that can guarantee less or zero call drop, then what is > wrong in using that. I would request you to read dycard as > well as DT draft to conclude which is more complicated protocol. There's nothing wrong with high availability, but there's a price to pay for that. If you're telling me that it's free... then I get really confused and am willing to be convinced :) AJOY-> You did not answer my question about the simplicity of protocol. The DT proposal of CARD is lot simpler than what is being proposed in dycard. BTW, I am not sure how much extra cost we will incur if just enhance the AAA server to provide CARD function. It does not look very expensive to me. I will be more concerned about the cost of high availability when the server is involved in routing such as HA. > > Let's be > fair here folks, my cell phone drops calls all the time, regardless of > whether I'm doing a 911 call or not. That's just the nature of 1) really > complex systems, 2) unreliable code and 3) wireless is simply NOT > reliable. So in my opinion, we need to design a protocol that works > well, and can tolerate failures and recover from any problems. > > AJOY-> I agree that cell phone can drop the call due to poor > radio conditions. The radio conditions change due to many > factors which we cannot control sometime. But, cellular networks are > not designed to drop the call though. Ah, but that's my point exactly. They are designed to NOT drop calls, but they do. There's physics involved here, and there's nothing in the IETF we can do about it. So let's just keep that in mind while we decide how complex this needs to be. AJOY-> But we do have alternative which will reduce the chances of poor handoff. In dycard we know that some percentage of calls will be be affected due to lack of cache. This is in additional to the calls that are being dropped due to poor radio conditions. I know we can't control the radio conditions, but at least we should try to eliminate the poor performance that is being caused due to something that can be fixed. > > I'm perfectly happy with a protocol that learns about it's neighbors. > It's all about trade-offs. Ethernet also has a cache, and has designed a > mechanism to re-validate the cache before it expires. Again, another > area that we should look into, and determine whether it can be applied > to this particular scenario. > > AJOY-> I will be happy with such protocol if the protocol in questions > is a simple protocol and provides significant benefit over > other protocol in consideration. Simplicity, in itself, is a significant benefit. AJOY-> That is what I am questioning about the dycard. Do we really need a complicated protocol to solve an easy problem? Please read the dycard draft and let me know if you still think dycard approach is simpler. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 18:33:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13053 for ; Sun, 16 Mar 2003 18:33:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNmoO02014; Sun, 16 Mar 2003 18:48:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNkAO01947 for ; Sun, 16 Mar 2003 18:46:10 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12987 for ; Sun, 16 Mar 2003 18:29:31 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2GNVbZj009700 for ; Sun, 16 Mar 2003 16:31:37 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA02198 for ; Sun, 16 Mar 2003 16:31:43 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 17:31:43 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Pat Calhoun'" , Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Sun, 16 Mar 2003 17:31:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Pat, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 4:18 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) > My initial reaction is that mandating a server is the wrong approach. I > am not claiming that discovery over the air, or some other approach, is > better, but *requiring* a server is problematic. > > AJOY-> I agree that requiring a new server introduces a single point > of failure. But if we piggyback CARD function over the existing > server such as AAA, it will not have this problem though. BTW, > if WG decides not to that then I am fine with that too. But so > far I have only heard from dycard co-authors. BTW, the DT > proposed server based approach to get the feedback from WG. > The DT will be happy change the approach if WG decides that. Right, and I'm providing my feedback... but I'm just one of many. > > I agree that service > providers will most likely not have much of an issue with requiring a > server for their network, but I doubt that enterprises that require > mobility, really want more infrastructure to manage. > > AJOY-> Servers are easier to manage. BTW, if the CARD function > can be integrated with existing server function e.g., AAA, then I do > not see why enterprise will need to manage extra infrastructure. embedded devices need to be configured, regardless of whether a server is present or not. AJOY-> Yup. How much cost it will add over the configuration of base AAA server? At a minimum, you'll want to create some form of security relationship between the embedded device and the server... so there's no way around it :( AJOY-> I did not follow this. If CARD function is extension of AAA function then why we need SA between embedded device and AAA server. > > One issue that I've heard in favor of a server approach is security. > I'll admit that I don't understand all of the issues, but there are > plenty of proof points where security can be provided without a backend > server. Whether it be peer-2-peer authentication via shared secrets, > certs, or what-have-you. In fact, maybe we should look at how OSPF > domains are created, and how routers communicate in a secure fashion? I > understand there are significant differences, but is there anything we > can learn from? > > AJOY-> I am not sure if comparing security requirements of intra-domain > routing protocol with that of CARD is fair. I will definitely like to > hear from the security experts because I do not consider myself > as a security expert. Well, maybe it's not a fair comparison, but I'd like to know why. If we are focused on intra-domain, then I see no difference. AJOY-> The dycard in initiated based upon trigger from a mobile node. The infrastructure does not have any control over what is provided by mobile node. What happens when a mobile node provides IP address of malicious node as CAR and the somehow security of AR is compromised? In this case, current AR will have to believe what is provided by the malicious CAR as valid information. This type of scenario may not be possible in intra-domain routing. But as I said before if security experts believe that this is not an issue and we can design a protocol assuming that security of AR will never be comprised, then I do have any problem. > > The next issue I have is what appears to be a requirement to build an > iron-clad protocol. I get very nervous when I hear that folks want to > create a protocol that cannot drop a single call (or packet!). > > AJOY-> I think here simplicity is the key. If we can get simpler > protocol that can guarantee less or zero call drop, then what is > wrong in using that. I would request you to read dycard as > well as DT draft to conclude which is more complicated protocol. There's nothing wrong with high availability, but there's a price to pay for that. If you're telling me that it's free... then I get really confused and am willing to be convinced :) AJOY-> You did not answer my question about the simplicity of protocol. The DT proposal of CARD is lot simpler than what is being proposed in dycard. BTW, I am not sure how much extra cost we will incur if just enhance the AAA server to provide CARD function. It does not look very expensive to me. I will be more concerned about the cost of high availability when the server is involved in routing such as HA. > > Let's be > fair here folks, my cell phone drops calls all the time, regardless of > whether I'm doing a 911 call or not. That's just the nature of 1) really > complex systems, 2) unreliable code and 3) wireless is simply NOT > reliable. So in my opinion, we need to design a protocol that works > well, and can tolerate failures and recover from any problems. > > AJOY-> I agree that cell phone can drop the call due to poor > radio conditions. The radio conditions change due to many > factors which we cannot control sometime. But, cellular networks are > not designed to drop the call though. Ah, but that's my point exactly. They are designed to NOT drop calls, but they do. There's physics involved here, and there's nothing in the IETF we can do about it. So let's just keep that in mind while we decide how complex this needs to be. AJOY-> But we do have alternative which will reduce the chances of poor handoff. In dycard we know that some percentage of calls will be be affected due to lack of cache. This is in additional to the calls that are being dropped due to poor radio conditions. I know we can't control the radio conditions, but at least we should try to eliminate the poor performance that is being caused due to something that can be fixed. > > I'm perfectly happy with a protocol that learns about it's neighbors. > It's all about trade-offs. Ethernet also has a cache, and has designed a > mechanism to re-validate the cache before it expires. Again, another > area that we should look into, and determine whether it can be applied > to this particular scenario. > > AJOY-> I will be happy with such protocol if the protocol in questions > is a simple protocol and provides significant benefit over > other protocol in consideration. Simplicity, in itself, is a significant benefit. AJOY-> That is what I am questioning about the dycard. Do we really need a complicated protocol to solve an easy problem? Please read the dycard draft and let me know if you still think dycard approach is simpler. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 18:38:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13229 for ; Sun, 16 Mar 2003 18:38:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GNsK902236 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 18:54:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNsKO02233 for ; Sun, 16 Mar 2003 18:54:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13212 for ; Sun, 16 Mar 2003 18:37:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNs2O02227; Sun, 16 Mar 2003 18:54:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNrsO02211 for ; Sun, 16 Mar 2003 18:53:54 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13202 for ; Sun, 16 Mar 2003 18:37:15 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2GNdSIG008537 for ; Sun, 16 Mar 2003 16:39:28 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA08036 for ; Sun, 16 Mar 2003 16:39:28 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 17:39:28 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7C@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: Singh Ajoy-ASINGH1 , "'Pat Calhoun'" Cc: "'seamoby@ietf.org'" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Sun, 16 Mar 2003 17:38:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , I missed a NOT in my previous email so resending this with the correction. Regards, Ajoy -----Original Message----- From: Singh Ajoy-ASINGH1 Sent: Sunday, March 16, 2003 5:31 PM To: 'Pat Calhoun'; Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Hello Pat, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 4:18 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) > My initial reaction is that mandating a server is the wrong approach. I > am not claiming that discovery over the air, or some other approach, is > better, but *requiring* a server is problematic. > > AJOY-> I agree that requiring a new server introduces a single point > of failure. But if we piggyback CARD function over the existing > server such as AAA, it will not have this problem though. BTW, > if WG decides not to that then I am fine with that too. But so > far I have only heard from dycard co-authors. BTW, the DT > proposed server based approach to get the feedback from WG. > The DT will be happy change the approach if WG decides that. Right, and I'm providing my feedback... but I'm just one of many. > > I agree that service > providers will most likely not have much of an issue with requiring a > server for their network, but I doubt that enterprises that require > mobility, really want more infrastructure to manage. > > AJOY-> Servers are easier to manage. BTW, if the CARD function > can be integrated with existing server function e.g., AAA, then I do > not see why enterprise will need to manage extra infrastructure. embedded devices need to be configured, regardless of whether a server is present or not. AJOY-> Yup. How much cost it will add over the configuration of base AAA server? At a minimum, you'll want to create some form of security relationship between the embedded device and the server... so there's no way around it :( AJOY-> I did not follow this. If CARD function is extension of AAA function then why we need SA between embedded device and AAA server. > > One issue that I've heard in favor of a server approach is security. > I'll admit that I don't understand all of the issues, but there are > plenty of proof points where security can be provided without a backend > server. Whether it be peer-2-peer authentication via shared secrets, > certs, or what-have-you. In fact, maybe we should look at how OSPF > domains are created, and how routers communicate in a secure fashion? I > understand there are significant differences, but is there anything we > can learn from? > > AJOY-> I am not sure if comparing security requirements of intra-domain > routing protocol with that of CARD is fair. I will definitely like to > hear from the security experts because I do not consider myself > as a security expert. Well, maybe it's not a fair comparison, but I'd like to know why. If we are focused on intra-domain, then I see no difference. AJOY-> The dycard in initiated based upon trigger from a mobile node. The infrastructure does not have any control over what is provided by mobile node. What happens when a mobile node provides IP address of malicious node as CAR and the somehow security of AR is compromised? In this case, current AR will have to believe what is provided by the malicious CAR as valid information. This type of scenario may not be possible in intra-domain routing. But as I said before if security experts believe that this is not an issue and we can design a protocol assuming that security of AR will never be comprised, then I do NOT have any problem. > > The next issue I have is what appears to be a requirement to build an > iron-clad protocol. I get very nervous when I hear that folks want to > create a protocol that cannot drop a single call (or packet!). > > AJOY-> I think here simplicity is the key. If we can get simpler > protocol that can guarantee less or zero call drop, then what is > wrong in using that. I would request you to read dycard as > well as DT draft to conclude which is more complicated protocol. There's nothing wrong with high availability, but there's a price to pay for that. If you're telling me that it's free... then I get really confused and am willing to be convinced :) AJOY-> You did not answer my question about the simplicity of protocol. The DT proposal of CARD is lot simpler than what is being proposed in dycard. BTW, I am not sure how much extra cost we will incur if just enhance the AAA server to provide CARD function. It does not look very expensive to me. I will be more concerned about the cost of high availability when the server is involved in routing such as HA. > > Let's be > fair here folks, my cell phone drops calls all the time, regardless of > whether I'm doing a 911 call or not. That's just the nature of 1) really > complex systems, 2) unreliable code and 3) wireless is simply NOT > reliable. So in my opinion, we need to design a protocol that works > well, and can tolerate failures and recover from any problems. > > AJOY-> I agree that cell phone can drop the call due to poor > radio conditions. The radio conditions change due to many > factors which we cannot control sometime. But, cellular networks are > not designed to drop the call though. Ah, but that's my point exactly. They are designed to NOT drop calls, but they do. There's physics involved here, and there's nothing in the IETF we can do about it. So let's just keep that in mind while we decide how complex this needs to be. AJOY-> But we do have alternative which will reduce the chances of poor handoff. In dycard we know that some percentage of calls will be be affected due to lack of cache. This is in additional to the calls that are being dropped due to poor radio conditions. I know we can't control the radio conditions, but at least we should try to eliminate the poor performance that is being caused due to something that can be fixed. > > I'm perfectly happy with a protocol that learns about it's neighbors. > It's all about trade-offs. Ethernet also has a cache, and has designed a > mechanism to re-validate the cache before it expires. Again, another > area that we should look into, and determine whether it can be applied > to this particular scenario. > > AJOY-> I will be happy with such protocol if the protocol in questions > is a simple protocol and provides significant benefit over > other protocol in consideration. Simplicity, in itself, is a significant benefit. AJOY-> That is what I am questioning about the dycard. Do we really need a complicated protocol to solve an easy problem? Please read the dycard draft and let me know if you still think dycard approach is simpler. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 18:38:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13247 for ; Sun, 16 Mar 2003 18:38:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNs2O02227; Sun, 16 Mar 2003 18:54:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNrsO02211 for ; Sun, 16 Mar 2003 18:53:54 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13202 for ; Sun, 16 Mar 2003 18:37:15 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2GNdSIG008537 for ; Sun, 16 Mar 2003 16:39:28 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA08036 for ; Sun, 16 Mar 2003 16:39:28 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Sun, 16 Mar 2003 17:39:28 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7C@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: Singh Ajoy-ASINGH1 , "'Pat Calhoun'" Cc: "'seamoby@ietf.org'" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Sun, 16 Mar 2003 17:38:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , I missed a NOT in my previous email so resending this with the correction. Regards, Ajoy -----Original Message----- From: Singh Ajoy-ASINGH1 Sent: Sunday, March 16, 2003 5:31 PM To: 'Pat Calhoun'; Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Hello Pat, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 4:18 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) > My initial reaction is that mandating a server is the wrong approach. I > am not claiming that discovery over the air, or some other approach, is > better, but *requiring* a server is problematic. > > AJOY-> I agree that requiring a new server introduces a single point > of failure. But if we piggyback CARD function over the existing > server such as AAA, it will not have this problem though. BTW, > if WG decides not to that then I am fine with that too. But so > far I have only heard from dycard co-authors. BTW, the DT > proposed server based approach to get the feedback from WG. > The DT will be happy change the approach if WG decides that. Right, and I'm providing my feedback... but I'm just one of many. > > I agree that service > providers will most likely not have much of an issue with requiring a > server for their network, but I doubt that enterprises that require > mobility, really want more infrastructure to manage. > > AJOY-> Servers are easier to manage. BTW, if the CARD function > can be integrated with existing server function e.g., AAA, then I do > not see why enterprise will need to manage extra infrastructure. embedded devices need to be configured, regardless of whether a server is present or not. AJOY-> Yup. How much cost it will add over the configuration of base AAA server? At a minimum, you'll want to create some form of security relationship between the embedded device and the server... so there's no way around it :( AJOY-> I did not follow this. If CARD function is extension of AAA function then why we need SA between embedded device and AAA server. > > One issue that I've heard in favor of a server approach is security. > I'll admit that I don't understand all of the issues, but there are > plenty of proof points where security can be provided without a backend > server. Whether it be peer-2-peer authentication via shared secrets, > certs, or what-have-you. In fact, maybe we should look at how OSPF > domains are created, and how routers communicate in a secure fashion? I > understand there are significant differences, but is there anything we > can learn from? > > AJOY-> I am not sure if comparing security requirements of intra-domain > routing protocol with that of CARD is fair. I will definitely like to > hear from the security experts because I do not consider myself > as a security expert. Well, maybe it's not a fair comparison, but I'd like to know why. If we are focused on intra-domain, then I see no difference. AJOY-> The dycard in initiated based upon trigger from a mobile node. The infrastructure does not have any control over what is provided by mobile node. What happens when a mobile node provides IP address of malicious node as CAR and the somehow security of AR is compromised? In this case, current AR will have to believe what is provided by the malicious CAR as valid information. This type of scenario may not be possible in intra-domain routing. But as I said before if security experts believe that this is not an issue and we can design a protocol assuming that security of AR will never be comprised, then I do NOT have any problem. > > The next issue I have is what appears to be a requirement to build an > iron-clad protocol. I get very nervous when I hear that folks want to > create a protocol that cannot drop a single call (or packet!). > > AJOY-> I think here simplicity is the key. If we can get simpler > protocol that can guarantee less or zero call drop, then what is > wrong in using that. I would request you to read dycard as > well as DT draft to conclude which is more complicated protocol. There's nothing wrong with high availability, but there's a price to pay for that. If you're telling me that it's free... then I get really confused and am willing to be convinced :) AJOY-> You did not answer my question about the simplicity of protocol. The DT proposal of CARD is lot simpler than what is being proposed in dycard. BTW, I am not sure how much extra cost we will incur if just enhance the AAA server to provide CARD function. It does not look very expensive to me. I will be more concerned about the cost of high availability when the server is involved in routing such as HA. > > Let's be > fair here folks, my cell phone drops calls all the time, regardless of > whether I'm doing a 911 call or not. That's just the nature of 1) really > complex systems, 2) unreliable code and 3) wireless is simply NOT > reliable. So in my opinion, we need to design a protocol that works > well, and can tolerate failures and recover from any problems. > > AJOY-> I agree that cell phone can drop the call due to poor > radio conditions. The radio conditions change due to many > factors which we cannot control sometime. But, cellular networks are > not designed to drop the call though. Ah, but that's my point exactly. They are designed to NOT drop calls, but they do. There's physics involved here, and there's nothing in the IETF we can do about it. So let's just keep that in mind while we decide how complex this needs to be. AJOY-> But we do have alternative which will reduce the chances of poor handoff. In dycard we know that some percentage of calls will be be affected due to lack of cache. This is in additional to the calls that are being dropped due to poor radio conditions. I know we can't control the radio conditions, but at least we should try to eliminate the poor performance that is being caused due to something that can be fixed. > > I'm perfectly happy with a protocol that learns about it's neighbors. > It's all about trade-offs. Ethernet also has a cache, and has designed a > mechanism to re-validate the cache before it expires. Again, another > area that we should look into, and determine whether it can be applied > to this particular scenario. > > AJOY-> I will be happy with such protocol if the protocol in questions > is a simple protocol and provides significant benefit over > other protocol in consideration. Simplicity, in itself, is a significant benefit. AJOY-> That is what I am questioning about the dycard. Do we really need a complicated protocol to solve an easy problem? Please read the dycard draft and let me know if you still think dycard approach is simpler. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 19:00:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13528 for ; Sun, 16 Mar 2003 19:00:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H0GJV03589 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 19:16:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0GJO03586 for ; Sun, 16 Mar 2003 19:16:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13509 for ; Sun, 16 Mar 2003 18:59:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0G6O03579; Sun, 16 Mar 2003 19:16:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0FSO03550 for ; Sun, 16 Mar 2003 19:15:28 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13502 for ; Sun, 16 Mar 2003 18:58:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 16 Mar 2003 16:01:01 -0800 X-Originating-IP: [138.15.107.226] From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "'Pat Calhoun'" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7C@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Sun, 16 Mar 2003 19:02:02 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 17 Mar 2003 00:01:01.0238 (UTC) FILETIME=[4BA6AD60:01C2EC18] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ajoy, Pease see my inline comments. > > > My initial reaction is that mandating a server is the wrong approach. I > > am not claiming that discovery over the air, or some other approach, is > > better, but *requiring* a server is problematic. > > > > AJOY-> I agree that requiring a new server introduces a single point > > of failure. But if we piggyback CARD function over the existing > > server such as AAA, it will not have this problem though. BTW, > > if WG decides not to that then I am fine with that too. But so > > far I have only heard from dycard co-authors. BTW, the DT > > proposed server based approach to get the feedback from WG. > > The DT will be happy change the approach if WG decides that. > Right, and I'm providing my feedback... but I'm just one of many. > > > > > I agree that service > > providers will most likely not have much of an issue with requiring a > > server for their network, but I doubt that enterprises that require > > mobility, really want more infrastructure to manage. > > > > AJOY-> Servers are easier to manage. BTW, if the CARD function > > can be integrated with existing server function e.g., AAA, then I do > > not see why enterprise will need to manage extra infrastructure. > embedded devices need to be configured, regardless of whether a server > is present or not. > > AJOY-> Yup. How much cost it will add over the configuration of > base AAA server? > [eunsoo] The cost is not just the configuration effort of the server. The cost of the central server is reliability, scalability, cache contamination, inflexibility due to static configuration in addition to changing the AAA server in my current view. Also my understanding of Pat's comment in the above is that the presence of the server does not remove the need to configure ARs and APs. > At a minimum, you'll want to create some form of > security relationship between the embedded device and the server... so > there's no way around it :( > > AJOY-> I did not follow this. If CARD function is extension of > AAA function then why we need SA between embedded device and > AAA server. > > > > > One issue that I've heard in favor of a server approach is security. > > I'll admit that I don't understand all of the issues, but there are > > plenty of proof points where security can be provided without a backend > > server. Whether it be peer-2-peer authentication via shared secrets, > > certs, or what-have-you. In fact, maybe we should look at how OSPF > > domains are created, and how routers communicate in a secure fashion? I > > understand there are significant differences, but is there anything we > > can learn from? > > > > AJOY-> I am not sure if comparing security requirements of intra-domain > > routing protocol with that of CARD is fair. I will definitely like to > > hear from the security experts because I do not consider myself > > as a security expert. > > Well, maybe it's not a fair comparison, but I'd like to know why. If we > are focused on intra-domain, then I see no difference. > > AJOY-> The dycard in initiated based upon trigger from a mobile node. > The infrastructure does not have any control over what is provided by mobile > node. > What happens when a mobile node provides IP address of malicious node as > CAR and the somehow security of AR is compromised? In this case, current AR > will have to > believe what is provided by the malicious CAR as valid > information. This type of scenario may not be possible in > intra-domain routing. But as I said before if security experts > believe that this is not an issue and we can design a protocol > assuming that security of AR will never be comprised, then I do > NOT have any problem. > [eunsoo] Are you saying that the server approach will work fine even when the security of AR is broken? If you assume the security of AR is broken, what is safe among whatever the AR is seriously involved in? How is the intra-domain routing system safe when the security of the AR is broken? BTW I am not sure whether this kind of extreme scenario should be considered. > > > > The next issue I have is what appears to be a requirement to build an > > iron-clad protocol. I get very nervous when I hear that folks want to > > create a protocol that cannot drop a single call (or packet!). > > > > AJOY-> I think here simplicity is the key. If we can get simpler > > protocol that can guarantee less or zero call drop, then what is > > wrong in using that. I would request you to read dycard as > > well as DT draft to conclude which is more complicated protocol. > > There's nothing wrong with high availability, but there's a price to pay > for that. If you're telling me that it's free... then I get really > confused and am willing to be convinced :) > > AJOY-> You did not answer my question about the simplicity of protocol. > The DT proposal of CARD is lot simpler than what is > being proposed in dycard. BTW, I am not sure how much extra > cost we will incur if just enhance the AAA server to provide > CARD function. It does not look very expensive to me. I > will be more concerned about the cost of high availability > when the server is involved in routing such as HA. > [eunsoo] Again, please substantiate your claim that the DT proposal is a lot simpler than Dycard. How come you ignore the cost of reliability, scalability, cache contamination and inflexibility on the CARD protocol caused by the server? > > > > Let's be > > fair here folks, my cell phone drops calls all the time, regardless of > > whether I'm doing a 911 call or not. That's just the nature of 1) really > > complex systems, 2) unreliable code and 3) wireless is simply NOT > > reliable. So in my opinion, we need to design a protocol that works > > well, and can tolerate failures and recover from any problems. > > > > AJOY-> I agree that cell phone can drop the call due to poor > > radio conditions. The radio conditions change due to many > > factors which we cannot control sometime. But, cellular networks are > > not designed to drop the call though. > > Ah, but that's my point exactly. They are designed to NOT drop calls, > but they do. There's physics involved here, and there's nothing in the > IETF we can do about it. So let's just keep that in mind while we decide > how complex this needs to be. > > AJOY-> But we do have alternative which will reduce the chances > of poor handoff. In dycard we know that some percentage of calls > will be be affected due to lack of cache. This is in additional to the > calls that are being dropped due to poor radio conditions. I know we can't > control the radio conditions, but at least we should try to > eliminate the poor performance that is being caused > due to something that can be fixed. > [eunsoo] What percentage of calls will be affected in Dycard? Can you substantiate your claims? > > > > I'm perfectly happy with a protocol that learns about it's neighbors. > > It's all about trade-offs. Ethernet also has a cache, and has designed a > > mechanism to re-validate the cache before it expires. Again, another > > area that we should look into, and determine whether it can be applied > > to this particular scenario. > > > > AJOY-> I will be happy with such protocol if the protocol in questions > > is a simple protocol and provides significant benefit over > > other protocol in consideration. > Simplicity, in itself, is a significant benefit. > > AJOY-> That is what I am questioning about the dycard. Do we really > need a complicated protocol to solve an easy problem? Please read > the dycard draft and let me know if you still think dycard approach > is simpler. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 19:00:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13541 for ; Sun, 16 Mar 2003 19:00:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0G6O03579; Sun, 16 Mar 2003 19:16:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0FSO03550 for ; Sun, 16 Mar 2003 19:15:28 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13502 for ; Sun, 16 Mar 2003 18:58:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 16 Mar 2003 16:01:01 -0800 X-Originating-IP: [138.15.107.226] From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "'Pat Calhoun'" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7C@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Sun, 16 Mar 2003 19:02:02 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 17 Mar 2003 00:01:01.0238 (UTC) FILETIME=[4BA6AD60:01C2EC18] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ajoy, Pease see my inline comments. > > > My initial reaction is that mandating a server is the wrong approach. I > > am not claiming that discovery over the air, or some other approach, is > > better, but *requiring* a server is problematic. > > > > AJOY-> I agree that requiring a new server introduces a single point > > of failure. But if we piggyback CARD function over the existing > > server such as AAA, it will not have this problem though. BTW, > > if WG decides not to that then I am fine with that too. But so > > far I have only heard from dycard co-authors. BTW, the DT > > proposed server based approach to get the feedback from WG. > > The DT will be happy change the approach if WG decides that. > Right, and I'm providing my feedback... but I'm just one of many. > > > > > I agree that service > > providers will most likely not have much of an issue with requiring a > > server for their network, but I doubt that enterprises that require > > mobility, really want more infrastructure to manage. > > > > AJOY-> Servers are easier to manage. BTW, if the CARD function > > can be integrated with existing server function e.g., AAA, then I do > > not see why enterprise will need to manage extra infrastructure. > embedded devices need to be configured, regardless of whether a server > is present or not. > > AJOY-> Yup. How much cost it will add over the configuration of > base AAA server? > [eunsoo] The cost is not just the configuration effort of the server. The cost of the central server is reliability, scalability, cache contamination, inflexibility due to static configuration in addition to changing the AAA server in my current view. Also my understanding of Pat's comment in the above is that the presence of the server does not remove the need to configure ARs and APs. > At a minimum, you'll want to create some form of > security relationship between the embedded device and the server... so > there's no way around it :( > > AJOY-> I did not follow this. If CARD function is extension of > AAA function then why we need SA between embedded device and > AAA server. > > > > > One issue that I've heard in favor of a server approach is security. > > I'll admit that I don't understand all of the issues, but there are > > plenty of proof points where security can be provided without a backend > > server. Whether it be peer-2-peer authentication via shared secrets, > > certs, or what-have-you. In fact, maybe we should look at how OSPF > > domains are created, and how routers communicate in a secure fashion? I > > understand there are significant differences, but is there anything we > > can learn from? > > > > AJOY-> I am not sure if comparing security requirements of intra-domain > > routing protocol with that of CARD is fair. I will definitely like to > > hear from the security experts because I do not consider myself > > as a security expert. > > Well, maybe it's not a fair comparison, but I'd like to know why. If we > are focused on intra-domain, then I see no difference. > > AJOY-> The dycard in initiated based upon trigger from a mobile node. > The infrastructure does not have any control over what is provided by mobile > node. > What happens when a mobile node provides IP address of malicious node as > CAR and the somehow security of AR is compromised? In this case, current AR > will have to > believe what is provided by the malicious CAR as valid > information. This type of scenario may not be possible in > intra-domain routing. But as I said before if security experts > believe that this is not an issue and we can design a protocol > assuming that security of AR will never be comprised, then I do > NOT have any problem. > [eunsoo] Are you saying that the server approach will work fine even when the security of AR is broken? If you assume the security of AR is broken, what is safe among whatever the AR is seriously involved in? How is the intra-domain routing system safe when the security of the AR is broken? BTW I am not sure whether this kind of extreme scenario should be considered. > > > > The next issue I have is what appears to be a requirement to build an > > iron-clad protocol. I get very nervous when I hear that folks want to > > create a protocol that cannot drop a single call (or packet!). > > > > AJOY-> I think here simplicity is the key. If we can get simpler > > protocol that can guarantee less or zero call drop, then what is > > wrong in using that. I would request you to read dycard as > > well as DT draft to conclude which is more complicated protocol. > > There's nothing wrong with high availability, but there's a price to pay > for that. If you're telling me that it's free... then I get really > confused and am willing to be convinced :) > > AJOY-> You did not answer my question about the simplicity of protocol. > The DT proposal of CARD is lot simpler than what is > being proposed in dycard. BTW, I am not sure how much extra > cost we will incur if just enhance the AAA server to provide > CARD function. It does not look very expensive to me. I > will be more concerned about the cost of high availability > when the server is involved in routing such as HA. > [eunsoo] Again, please substantiate your claim that the DT proposal is a lot simpler than Dycard. How come you ignore the cost of reliability, scalability, cache contamination and inflexibility on the CARD protocol caused by the server? > > > > Let's be > > fair here folks, my cell phone drops calls all the time, regardless of > > whether I'm doing a 911 call or not. That's just the nature of 1) really > > complex systems, 2) unreliable code and 3) wireless is simply NOT > > reliable. So in my opinion, we need to design a protocol that works > > well, and can tolerate failures and recover from any problems. > > > > AJOY-> I agree that cell phone can drop the call due to poor > > radio conditions. The radio conditions change due to many > > factors which we cannot control sometime. But, cellular networks are > > not designed to drop the call though. > > Ah, but that's my point exactly. They are designed to NOT drop calls, > but they do. There's physics involved here, and there's nothing in the > IETF we can do about it. So let's just keep that in mind while we decide > how complex this needs to be. > > AJOY-> But we do have alternative which will reduce the chances > of poor handoff. In dycard we know that some percentage of calls > will be be affected due to lack of cache. This is in additional to the > calls that are being dropped due to poor radio conditions. I know we can't > control the radio conditions, but at least we should try to > eliminate the poor performance that is being caused > due to something that can be fixed. > [eunsoo] What percentage of calls will be affected in Dycard? Can you substantiate your claims? > > > > I'm perfectly happy with a protocol that learns about it's neighbors. > > It's all about trade-offs. Ethernet also has a cache, and has designed a > > mechanism to re-validate the cache before it expires. Again, another > > area that we should look into, and determine whether it can be applied > > to this particular scenario. > > > > AJOY-> I will be happy with such protocol if the protocol in questions > > is a simple protocol and provides significant benefit over > > other protocol in consideration. > Simplicity, in itself, is a significant benefit. > > AJOY-> That is what I am questioning about the dycard. Do we really > need a complicated protocol to solve an easy problem? Please read > the dycard draft and let me know if you still think dycard approach > is simpler. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 19:24:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13867 for ; Sun, 16 Mar 2003 19:24:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H0eJE05032 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 19:40:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0eJO05029 for ; Sun, 16 Mar 2003 19:40:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13863 for ; Sun, 16 Mar 2003 19:23:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0e6O05020; Sun, 16 Mar 2003 19:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0djO04966 for ; Sun, 16 Mar 2003 19:39:45 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13857 for ; Sun, 16 Mar 2003 19:23:06 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 16:25:18 -0800 Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) From: Pat Calhoun To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7B@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7B@IL27EXM10.cig.mot.com> Content-Type: text/plain Message-Id: <1047860625.12529.145.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 16:23:46 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2003 00:25:18.0775 (UTC) FILETIME=[B0692C70:01C2EC1B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ajoy, Instead of answer my fairly point blank questions, you appear to be defending CARD against Dycar. Let's put aside dycar for a moment as my point is not to start a comparison war. Instead I want to look at the current CARD proposal and see if it can be simplified. I don't have the answers, all I have are questions. Regarding the one question I can answer: AJOY-> I did not follow this. If CARD function is extension of > AAA function then why we need SA between embedded device and > AAA server. exactly, if it's an extension to an AAA protocol, every AAA protocol that I know requires some form of security relationship in order to communicate in a secure fashion, either via shared secrets, or certs. So there's security configuration required regardless of the approach. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 19:24:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13880 for ; Sun, 16 Mar 2003 19:24:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0e6O05020; Sun, 16 Mar 2003 19:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0djO04966 for ; Sun, 16 Mar 2003 19:39:45 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13857 for ; Sun, 16 Mar 2003 19:23:06 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 16:25:18 -0800 Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) From: Pat Calhoun To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7B@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7B@IL27EXM10.cig.mot.com> Content-Type: text/plain Message-Id: <1047860625.12529.145.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 16 Mar 2003 16:23:46 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2003 00:25:18.0775 (UTC) FILETIME=[B0692C70:01C2EC1B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ajoy, Instead of answer my fairly point blank questions, you appear to be defending CARD against Dycar. Let's put aside dycar for a moment as my point is not to start a comparison war. Instead I want to look at the current CARD proposal and see if it can be simplified. I don't have the answers, all I have are questions. Regarding the one question I can answer: AJOY-> I did not follow this. If CARD function is extension of > AAA function then why we need SA between embedded device and > AAA server. exactly, if it's an extension to an AAA protocol, every AAA protocol that I know requires some form of security relationship in order to communicate in a secure fashion, either via shared secrets, or certs. So there's security configuration required regardless of the approach. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 23:02:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18298 for ; Sun, 16 Mar 2003 23:02:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H4IV717843 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 23:18:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4IVO17840 for ; Sun, 16 Mar 2003 23:18:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18268 for ; Sun, 16 Mar 2003 23:01:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4IHO17832; Sun, 16 Mar 2003 23:18:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4HrO17815 for ; Sun, 16 Mar 2003 23:17:53 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18256 for ; Sun, 16 Mar 2003 23:01:10 -0500 (EST) Message-ID: <001401c2ec39$f072c6a0$476015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> <036801c2eb15$4faddc70$e26b0f8a@eunsoo> <010801c2eb36$3f1e0ad0$456015ac@T23KEMPF> <023901c2ec0f$9a6b8f00$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sun, 16 Mar 2003 20:01:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [eunsoo] I remember that you said using geographical information for CARD > was not practical. Now you say differently. > I think your previous opinion is correct. It is not practical in many > situations. > Just configuring whether an AP connected to an AR is authorized is not such > a difficult job at all. It is clear to the admin from the beginning when he > connected the AP to the AR. > Sorry, I meant the IP address to AP L2 id mapping for neighboring subnets. I was not talking about GPS co-ordinates, or something like that. Suppose I have a small office with two or three subnets, with maybe 6 AP per subnet. Seems like it would be simple enough to log into each router and configure. But scaling this up to an enterprise level or ISP is where the problems occur. > > [eunsoo] You cannot rely on something that is not fixed yet. Mixing two > things while both are under change will make any decision very difficult. > Once two things are fixed, then we can think about possible merge scenario > or adjustment. It is not an ideal situation but it is what we have today. > But we want to end up with one thing on the front end, not two. So the issue is how to make that work. With PrxyRtAdv/PrxyRtAdvSol moved away from handover in FMIP, it now serves essentially the same function as CARD's front end, except that it doesn't provide all the functionality. I think it might make sense to define the necessary functionality for CARD in that context, to avoid having duplication. > > > Anyway, it seems you agree that we don't need the server for CARD. Am I > > > right? > > > > > > > I hope at the working group meeting we can get some agreement about > problems of > > the server approach, how much geographical accuracy is enough, and whether > we > > should use a server or a router to router approach. > > > > [eunsoo] Can you please confirm my understanding or answer my question in > the above? > The working group has the final decision. I want to have the advantages and disadvantages of both on the table, in a clear and objective way, so that people who are not invested in either approach can express an opinion. At that point, Pat and I will judge concensus. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 23:02:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18312 for ; Sun, 16 Mar 2003 23:02:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4IHO17832; Sun, 16 Mar 2003 23:18:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4HrO17815 for ; Sun, 16 Mar 2003 23:17:53 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18256 for ; Sun, 16 Mar 2003 23:01:10 -0500 (EST) Message-ID: <001401c2ec39$f072c6a0$476015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Xiaoming Wang" , "Daichi Funato" , References: <00ed01c2ea61$8348f880$e26b0f8a@eunsoo> <00e401c2ea53$95a1f6c0$286015ac@T23KEMPF> <036801c2eb15$4faddc70$e26b0f8a@eunsoo> <010801c2eb36$3f1e0ad0$456015ac@T23KEMPF> <023901c2ec0f$9a6b8f00$e26b0f8a@eunsoo> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD Date: Sun, 16 Mar 2003 20:01:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [eunsoo] I remember that you said using geographical information for CARD > was not practical. Now you say differently. > I think your previous opinion is correct. It is not practical in many > situations. > Just configuring whether an AP connected to an AR is authorized is not such > a difficult job at all. It is clear to the admin from the beginning when he > connected the AP to the AR. > Sorry, I meant the IP address to AP L2 id mapping for neighboring subnets. I was not talking about GPS co-ordinates, or something like that. Suppose I have a small office with two or three subnets, with maybe 6 AP per subnet. Seems like it would be simple enough to log into each router and configure. But scaling this up to an enterprise level or ISP is where the problems occur. > > [eunsoo] You cannot rely on something that is not fixed yet. Mixing two > things while both are under change will make any decision very difficult. > Once two things are fixed, then we can think about possible merge scenario > or adjustment. It is not an ideal situation but it is what we have today. > But we want to end up with one thing on the front end, not two. So the issue is how to make that work. With PrxyRtAdv/PrxyRtAdvSol moved away from handover in FMIP, it now serves essentially the same function as CARD's front end, except that it doesn't provide all the functionality. I think it might make sense to define the necessary functionality for CARD in that context, to avoid having duplication. > > > Anyway, it seems you agree that we don't need the server for CARD. Am I > > > right? > > > > > > > I hope at the working group meeting we can get some agreement about > problems of > > the server approach, how much geographical accuracy is enough, and whether > we > > should use a server or a router to router approach. > > > > [eunsoo] Can you please confirm my understanding or answer my question in > the above? > The working group has the final decision. I want to have the advantages and disadvantages of both on the table, in a clear and objective way, so that people who are not invested in either approach can express an opinion. At that point, Pat and I will judge concensus. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 16 23:05:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18388 for ; Sun, 16 Mar 2003 23:05:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H4LE118048 for seamoby-archive@odin.ietf.org; Sun, 16 Mar 2003 23:21:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4LEO18045 for ; Sun, 16 Mar 2003 23:21:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18383 for ; Sun, 16 Mar 2003 23:04:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4L3O18020; Sun, 16 Mar 2003 23:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4KXO17994 for ; Sun, 16 Mar 2003 23:20:33 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18370 for ; Sun, 16 Mar 2003 23:03:50 -0500 (EST) Message-ID: <001c01c2ec3a$4ef7dbc0$476015ac@T23KEMPF> From: "James Kempf" To: "Singh Ajoy-ASINGH1" , "'Eunsoo Shim'" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE76@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 20:04:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ajoy, > AJOY-> List few inter-AR authorization protocols that can be used. > You have not answered my question yet. > This could be IPsec AH with ISAKMP/IKE to set up the key distribution. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 16 23:05:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18402 for ; Sun, 16 Mar 2003 23:05:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4L3O18020; Sun, 16 Mar 2003 23:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4KXO17994 for ; Sun, 16 Mar 2003 23:20:33 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18370 for ; Sun, 16 Mar 2003 23:03:50 -0500 (EST) Message-ID: <001c01c2ec3a$4ef7dbc0$476015ac@T23KEMPF> From: "James Kempf" To: "Singh Ajoy-ASINGH1" , "'Eunsoo Shim'" , , Cc: References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE76@IL27EXM10.cig.mot.com> Subject: Re: [SeaMoby] Topic #3: Cache contamination Date: Sun, 16 Mar 2003 20:04:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ajoy, > AJOY-> List few inter-AR authorization protocols that can be used. > You have not answered my question yet. > This could be IPsec AH with ISAKMP/IKE to set up the key distribution. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 17 09:12:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13784 for ; Mon, 17 Mar 2003 09:12:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HESnA03361 for seamoby-archive@odin.ietf.org; Mon, 17 Mar 2003 09:28:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HESnO03358 for ; Mon, 17 Mar 2003 09:28:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13774 for ; Mon, 17 Mar 2003 09:11:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HESZO03347; Mon, 17 Mar 2003 09:28:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HEP6O03237 for ; Mon, 17 Mar 2003 09:25:06 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13694 for ; Mon, 17 Mar 2003 09:08:10 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HEAN824658 for ; Mon, 17 Mar 2003 08:10:23 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 08:10:23 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 08:10:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Mon, 17 Mar 2003 09:10:08 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLr91ZgdcsGJYFMRpuoLvtkdIUp4AAluMsA To: , , , Cc: X-OriginalArrivalTime: 17 Mar 2003 14:10:09.0096 (UTC) FILETIME=[EAF0DC80:01C2EC8E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HEP7O03238 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Ajoy, >AJOY-> I have indicated in my earlier email that we need >discuss your so called cache contamination comments >either offline to during IETF presentation. BTW, >here a few reasons for having server (e.g., AAA) >based CARD functions: > >1. Server based approach is able to provide seamless >handoff even if the CAR information is not available in >the current AR cache. This has been made clear >in previous discussion. It was also made clear that this seamless first handoff only happens with a probability that is smaller than 1, and that there might be situations in which might not even happen. > >2. The servers are easier to configure and manage. A server that does not exists is even easier to manage, namely not at all. Your statement is really kind of funny. Instead of answering the fundamental question why we need the server, you come over and over again with the argument that servers are easy to manage. This is fundamentally wrong if we don't need the server. Hence, the concerns are not about manageability, there are about necessity. As long as we haven't clarified the latter, the former doesn't matter. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 17 09:12:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13799 for ; Mon, 17 Mar 2003 09:12:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HESZO03347; Mon, 17 Mar 2003 09:28:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HEP6O03237 for ; Mon, 17 Mar 2003 09:25:06 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13694 for ; Mon, 17 Mar 2003 09:08:10 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HEAN824658 for ; Mon, 17 Mar 2003 08:10:23 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 08:10:23 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 08:10:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Mon, 17 Mar 2003 09:10:08 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLr91ZgdcsGJYFMRpuoLvtkdIUp4AAluMsA To: , , , Cc: X-OriginalArrivalTime: 17 Mar 2003 14:10:09.0096 (UTC) FILETIME=[EAF0DC80:01C2EC8E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HEP7O03238 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ajoy, >AJOY-> I have indicated in my earlier email that we need >discuss your so called cache contamination comments >either offline to during IETF presentation. BTW, >here a few reasons for having server (e.g., AAA) >based CARD functions: > >1. Server based approach is able to provide seamless >handoff even if the CAR information is not available in >the current AR cache. This has been made clear >in previous discussion. It was also made clear that this seamless first handoff only happens with a probability that is smaller than 1, and that there might be situations in which might not even happen. > >2. The servers are easier to configure and manage. A server that does not exists is even easier to manage, namely not at all. Your statement is really kind of funny. Instead of answering the fundamental question why we need the server, you come over and over again with the argument that servers are easy to manage. This is fundamentally wrong if we don't need the server. Hence, the concerns are not about manageability, there are about necessity. As long as we haven't clarified the latter, the former doesn't matter. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 17 09:27:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14069 for ; Mon, 17 Mar 2003 09:27:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HEiI904747 for seamoby-archive@odin.ietf.org; Mon, 17 Mar 2003 09:44:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HEiIO04744 for ; Mon, 17 Mar 2003 09:44:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14064 for ; Mon, 17 Mar 2003 09:27:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HEi7O04713; Mon, 17 Mar 2003 09:44:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HEeeO04583 for ; Mon, 17 Mar 2003 09:40:40 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13955 for ; Mon, 17 Mar 2003 09:23:43 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HEPu827565 for ; Mon, 17 Mar 2003 08:25:57 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 08:25:44 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 06:25:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Mon, 17 Mar 2003 09:25:29 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stu ff) Thread-Index: AcLsGG2uJW8n/XzgRlC0Y8rrG+GI+gAd5B+w To: , , Cc: X-OriginalArrivalTime: 17 Mar 2003 14:25:30.0573 (UTC) FILETIME=[102F17D0:01C2EC91] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HEeeO04584 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit >> AJOY-> You did not answer my question about the simplicity >of protocol. >> The DT proposal of CARD is lot simpler than what is >> being proposed in dycard. Do you have anything of substance here to say? Why on earth is a server-based approach simpler than an approach that does not require said server? Statements don't get right just because you post them. And rejecting our questions regarding the grounds for what you claim with "I would like to hear opinions of others" doesn't make it better. You post statements on the list with claims, and everybody, the silent WG members and the dycard authors, have a right to hear the grounds for your argument. Otherwise, it is nothing more than a simple, unproven claim which can easily be rejected. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 17 09:28:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14087 for ; Mon, 17 Mar 2003 09:28:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HEi7O04713; Mon, 17 Mar 2003 09:44:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HEeeO04583 for ; Mon, 17 Mar 2003 09:40:40 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13955 for ; Mon, 17 Mar 2003 09:23:43 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HEPu827565 for ; Mon, 17 Mar 2003 08:25:57 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 08:25:44 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 06:25:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Mon, 17 Mar 2003 09:25:29 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stu ff) Thread-Index: AcLsGG2uJW8n/XzgRlC0Y8rrG+GI+gAd5B+w To: , , Cc: X-OriginalArrivalTime: 17 Mar 2003 14:25:30.0573 (UTC) FILETIME=[102F17D0:01C2EC91] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HEeeO04584 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit >> AJOY-> You did not answer my question about the simplicity >of protocol. >> The DT proposal of CARD is lot simpler than what is >> being proposed in dycard. Do you have anything of substance here to say? Why on earth is a server-based approach simpler than an approach that does not require said server? Statements don't get right just because you post them. And rejecting our questions regarding the grounds for what you claim with "I would like to hear opinions of others" doesn't make it better. You post statements on the list with claims, and everybody, the silent WG members and the dycard authors, have a right to hear the grounds for your argument. Otherwise, it is nothing more than a simple, unproven claim which can easily be rejected. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 17 12:43:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22117 for ; Mon, 17 Mar 2003 12:43:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HI0Kh19527 for seamoby-archive@odin.ietf.org; Mon, 17 Mar 2003 13:00:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HI0KO19524 for ; Mon, 17 Mar 2003 13:00:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22105 for ; Mon, 17 Mar 2003 12:43:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HI02O19509; Mon, 17 Mar 2003 13:00:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHwjO19441 for ; Mon, 17 Mar 2003 12:58:45 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22077 for ; Mon, 17 Mar 2003 12:41:45 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HHhu819945 for ; Mon, 17 Mar 2003 11:43:57 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 11:43:56 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 11:43:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Mon, 17 Mar 2003 12:43:55 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLr8rziQ7GjhUqdQjCtV+V9hHvfGQAucQ7w To: , , Cc: X-OriginalArrivalTime: 17 Mar 2003 17:43:56.0415 (UTC) FILETIME=[C89E68F0:01C2ECAC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HHwjO19442 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Inter-AR authorization is not a key point of CARD, IMHO. It is a requirement for many protocols - routing, FMIP, CT etc. Then there are CBPs and other efforts underway to solve this problem so that a family of protocols can use them. Key points of CARD are - rev. addr. translation and capability discovery, and that is exactly what is stated in issues draft. - Hemant -----Original Message----- From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 5:33 PM To: Singh Ajoy-ASINGH1; Chaskar Hemant (NRC/Boston); robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Ajoy, My comments are inline. > > The role of the server in the server approach is currently storing all L2-L3 > mapping entries and providing them at the request by ARs. > > AJOY-> This is the subset of CARD function. > [eunsoo] CARD does not require all L2-L3 mapping entries in a central server. Such a central server is what DT proposed and we had discussion about why we need a server for CARD. There was no compelling reason yet. > You may say the program of the CARD server can be also running in the AAA > server but two servers are very different in terms of functionality and > involved protocols. > > AJOY-> This is not what I meant. I meant that CARD functionality > can integrated with AAA server. Given that inter-AR authorization > is key requirement of CARD, this may be good point to discuss. > [eunsoo] Unless there is a compelling reason to have a central server for CARD, it does not matter where we can put the server. > Dycard does not exclude existence of an AAA server at > all. > > AJOY-> Are you saying that dycard will use AAA server > for providing inter-AR authorization? If yes, could > you please explain us how this will be done. > [eunsoo] I think Dycard can be integrated with many ways of inter-AR authorization. The current Dycard draft does not propose any specific method yet. > I think the security requirements for CARD regarding AR authorization is > quite similar to that of IP routing protocols. There are already > proposed/implemented solutions for IP routing protocol security. > > AJOY-> Not really. The security requirements of CARD should > be more stringent than inter-domain or intra-domain routing > protocol. In CARD, any random MN is able to initiate the > process of L2->L3 mapping as well as capability discovery. > In dycard the mobile node provides the IP address of the AR > with which the current AR is required to communicate to obtain > the L2->L3 mapping as well as capabilities. The dycard MN can > provide an IP address of a malicious CAR which may be any node > on the Internet. If somehow the security of AR-CAR is compromised, > this will cause the current AR to have bogus L2->L3 mapping as > well invalid capabilities. This will have serious impact on > the handoff performance of subsequent mobile nodes. The > routing protocol does not initiate routing table update > based upon trigger from a random mobile node and am > not sure how the security requirement of routing > protocol is comparable with CARD. > [eunsoo] No matter what triggers the inter-AR authorization process, still it is two ARs who are involved and responsible for checking authorization of each other. MN cannot have influence on it. So it is not correct to say CARD has more strict security requirements regarding inter-AR authorization because MN provides the trigger. You cannot say corruption of the IP routing tables in the routers are less serious than the curruption of the cache (CAR table) of the edge ARs. Also now you are say bogus L2-L3 mapping entries can cause serious consequences. I pointed out repeatedly that the server approach cannot prevent MN from providing a L2 address of an AP which is a GAAP and thus the cache (the CAR table at the AR) will be contaminated. What do you think of the seriousness of this problem? > We had a separate thread for the need of the server for CARD. It was being > summarized and so far there was no compelling reason to have a server for > CARD. If you want to propose the server as the AAA server, please can you do > it in that thread? > > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we need is a AAA server but not a server that stores all the L2-L3 mapping entries statically and provide them at the request of the ARs. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 17 12:44:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22131 for ; Mon, 17 Mar 2003 12:44:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HI02O19509; Mon, 17 Mar 2003 13:00:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHwjO19441 for ; Mon, 17 Mar 2003 12:58:45 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22077 for ; Mon, 17 Mar 2003 12:41:45 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HHhu819945 for ; Mon, 17 Mar 2003 11:43:57 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 11:43:56 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 11:43:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Mon, 17 Mar 2003 12:43:55 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLr8rziQ7GjhUqdQjCtV+V9hHvfGQAucQ7w To: , , Cc: X-OriginalArrivalTime: 17 Mar 2003 17:43:56.0415 (UTC) FILETIME=[C89E68F0:01C2ECAC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HHwjO19442 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Inter-AR authorization is not a key point of CARD, IMHO. It is a requirement for many protocols - routing, FMIP, CT etc. Then there are CBPs and other efforts underway to solve this problem so that a family of protocols can use them. Key points of CARD are - rev. addr. translation and capability discovery, and that is exactly what is stated in issues draft. - Hemant -----Original Message----- From: ext Eunsoo Shim [mailto:eunsoo@nec-labs.com] Sent: Sunday, March 16, 2003 5:33 PM To: Singh Ajoy-ASINGH1; Chaskar Hemant (NRC/Boston); robertc@cs.ucsb.edu Cc: seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination Ajoy, My comments are inline. > > The role of the server in the server approach is currently storing all L2-L3 > mapping entries and providing them at the request by ARs. > > AJOY-> This is the subset of CARD function. > [eunsoo] CARD does not require all L2-L3 mapping entries in a central server. Such a central server is what DT proposed and we had discussion about why we need a server for CARD. There was no compelling reason yet. > You may say the program of the CARD server can be also running in the AAA > server but two servers are very different in terms of functionality and > involved protocols. > > AJOY-> This is not what I meant. I meant that CARD functionality > can integrated with AAA server. Given that inter-AR authorization > is key requirement of CARD, this may be good point to discuss. > [eunsoo] Unless there is a compelling reason to have a central server for CARD, it does not matter where we can put the server. > Dycard does not exclude existence of an AAA server at > all. > > AJOY-> Are you saying that dycard will use AAA server > for providing inter-AR authorization? If yes, could > you please explain us how this will be done. > [eunsoo] I think Dycard can be integrated with many ways of inter-AR authorization. The current Dycard draft does not propose any specific method yet. > I think the security requirements for CARD regarding AR authorization is > quite similar to that of IP routing protocols. There are already > proposed/implemented solutions for IP routing protocol security. > > AJOY-> Not really. The security requirements of CARD should > be more stringent than inter-domain or intra-domain routing > protocol. In CARD, any random MN is able to initiate the > process of L2->L3 mapping as well as capability discovery. > In dycard the mobile node provides the IP address of the AR > with which the current AR is required to communicate to obtain > the L2->L3 mapping as well as capabilities. The dycard MN can > provide an IP address of a malicious CAR which may be any node > on the Internet. If somehow the security of AR-CAR is compromised, > this will cause the current AR to have bogus L2->L3 mapping as > well invalid capabilities. This will have serious impact on > the handoff performance of subsequent mobile nodes. The > routing protocol does not initiate routing table update > based upon trigger from a random mobile node and am > not sure how the security requirement of routing > protocol is comparable with CARD. > [eunsoo] No matter what triggers the inter-AR authorization process, still it is two ARs who are involved and responsible for checking authorization of each other. MN cannot have influence on it. So it is not correct to say CARD has more strict security requirements regarding inter-AR authorization because MN provides the trigger. You cannot say corruption of the IP routing tables in the routers are less serious than the curruption of the cache (CAR table) of the edge ARs. Also now you are say bogus L2-L3 mapping entries can cause serious consequences. I pointed out repeatedly that the server approach cannot prevent MN from providing a L2 address of an AP which is a GAAP and thus the cache (the CAR table at the AR) will be contaminated. What do you think of the seriousness of this problem? > We had a separate thread for the need of the server for CARD. It was being > summarized and so far there was no compelling reason to have a server for > CARD. If you want to propose the server as the AAA server, please can you do > it in that thread? > > AJOY-> I have already stated this in my earlier email. The DT > draft also mentions about this. I guess we can discuss this during > Seamoby presentation. Also, I am very interested to hear from > other members of WG who are not co-authors of dycard. > [eunsoo] If we want to use an AAA server for inter-AR authorization, what we need is a AAA server but not a server that stores all the L2-L3 mapping entries statically and provide them at the request of the ARs. Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 17 12:54:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22630 for ; Mon, 17 Mar 2003 12:54:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HIBLx20862 for seamoby-archive@odin.ietf.org; Mon, 17 Mar 2003 13:11:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIBLO20859 for ; Mon, 17 Mar 2003 13:11:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22586 for ; Mon, 17 Mar 2003 12:54:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIB6O20833; Mon, 17 Mar 2003 13:11:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HI8CO20712 for ; Mon, 17 Mar 2003 13:08:12 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22364 for ; Mon, 17 Mar 2003 12:51:12 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HHrN822144 for ; Mon, 17 Mar 2003 11:53:23 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 11:53:21 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 09:52:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] updated dyCARD draft Date: Mon, 17 Mar 2003 12:52:24 -0500 Message-ID: Thread-Topic: [Seamoby] updated dyCARD draft Thread-Index: AcLrMMeG4U22zJCjSlWcsKb5iAVZjgBfLgSg To: , Cc: X-OriginalArrivalTime: 17 Mar 2003 17:52:24.0965 (UTC) FILETIME=[F7BCFB50:01C2ECAD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HI8CO20713 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: See comments below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Saturday, March 15, 2003 3:21 PM To: Robert Chalmers Cc: seamoby@ietf.org Subject: Re: [Seamoby] updated dyCARD draft > On a side note, I agree with you that we should pobably separate the > AR-MN signalling from the AR-AR or AR-server signalling. Whether or not > the WG wants to standardize mutiple back-end schemes (static, > server-based, learning-based), I don't know. > I think concentrating on the back-end is probably better. The front end has lots of overlap with FMIP. The DT draft has basically two front end protocols, one with and one without FMIP. I think we need only one. Of course, we must be sure that the front end provides what the back end needs. That's my opinion. Hemant -> We had run this issue by Eric and the current design has been approved by him. The current design works with FMIP as well as without. Shall we close this issue now, or you think this is still open. > Finally, I definitely agree with you that we need some input from people > who don't have invested interest in either approach. Please don't take > this the wrong way, but are you invested in either approach? It seems No. Regardless of who has IPR on what. But I am invested in getting a well-integrated realtime handover protocol suite. As WG chair (and, further, IAB member), I need to make sure the design changes we are making in local link protocols and router protocols integrate well with the existing Internet, and provide the functionality required. And I need to advise the IESG about how I think we can best get there. Like I said in another posting, the DT draft is just a suggestion. The WG has ultimate responsiblity for the result. > that some of the dyHardness might stem from the perception that you > might or the DT in general might be invested. Moreover, while the DT was > hashing out which direction they would take, we (the dyCARD team) > received a lot of questions concerning how to secure the protocol. It > was my impression that the the DT eventually went towards the > server-based solution because we couldn't guarantee absolutely that the > caches could not be contaminated with non-GAAR entries (this is not the > same as bad AR-AP mapping - that we can guarantee). With the recent > discussion, though, these problems seem to have taken a back seat. Now, > it seems that malicious MNs aren't that big of a deal, cache > contamination is not a big issue. > My view is that preventing false information from getting to the MN is the absolute baseline. Any protocol that doesn't supply this is broken. Further than that, we need to discuss how accurate the wireless connectivity information should be in the absence of full geographical information, and weigh that against the cost in terms of infrastructure and inter-router signaling. Pat and I have asked Eunsoo to discuss this topic and problems with the server approach at the meeting. Ajoy and Marco's talk will discuss how the scope-id and server approach work. > Maybe, the next step is to start talking about what properties would > make for the best protocol, not what's wrong with one approach or the other. > Yes,exactly. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 17 12:55:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22660 for ; Mon, 17 Mar 2003 12:55:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIB6O20833; Mon, 17 Mar 2003 13:11:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HI8CO20712 for ; Mon, 17 Mar 2003 13:08:12 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22364 for ; Mon, 17 Mar 2003 12:51:12 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HHrN822144 for ; Mon, 17 Mar 2003 11:53:23 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 11:53:21 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 09:52:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] updated dyCARD draft Date: Mon, 17 Mar 2003 12:52:24 -0500 Message-ID: Thread-Topic: [Seamoby] updated dyCARD draft Thread-Index: AcLrMMeG4U22zJCjSlWcsKb5iAVZjgBfLgSg To: , Cc: X-OriginalArrivalTime: 17 Mar 2003 17:52:24.0965 (UTC) FILETIME=[F7BCFB50:01C2ECAD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HI8CO20713 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: See comments below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Saturday, March 15, 2003 3:21 PM To: Robert Chalmers Cc: seamoby@ietf.org Subject: Re: [Seamoby] updated dyCARD draft > On a side note, I agree with you that we should pobably separate the > AR-MN signalling from the AR-AR or AR-server signalling. Whether or not > the WG wants to standardize mutiple back-end schemes (static, > server-based, learning-based), I don't know. > I think concentrating on the back-end is probably better. The front end has lots of overlap with FMIP. The DT draft has basically two front end protocols, one with and one without FMIP. I think we need only one. Of course, we must be sure that the front end provides what the back end needs. That's my opinion. Hemant -> We had run this issue by Eric and the current design has been approved by him. The current design works with FMIP as well as without. Shall we close this issue now, or you think this is still open. > Finally, I definitely agree with you that we need some input from people > who don't have invested interest in either approach. Please don't take > this the wrong way, but are you invested in either approach? It seems No. Regardless of who has IPR on what. But I am invested in getting a well-integrated realtime handover protocol suite. As WG chair (and, further, IAB member), I need to make sure the design changes we are making in local link protocols and router protocols integrate well with the existing Internet, and provide the functionality required. And I need to advise the IESG about how I think we can best get there. Like I said in another posting, the DT draft is just a suggestion. The WG has ultimate responsiblity for the result. > that some of the dyHardness might stem from the perception that you > might or the DT in general might be invested. Moreover, while the DT was > hashing out which direction they would take, we (the dyCARD team) > received a lot of questions concerning how to secure the protocol. It > was my impression that the the DT eventually went towards the > server-based solution because we couldn't guarantee absolutely that the > caches could not be contaminated with non-GAAR entries (this is not the > same as bad AR-AP mapping - that we can guarantee). With the recent > discussion, though, these problems seem to have taken a back seat. Now, > it seems that malicious MNs aren't that big of a deal, cache > contamination is not a big issue. > My view is that preventing false information from getting to the MN is the absolute baseline. Any protocol that doesn't supply this is broken. Further than that, we need to discuss how accurate the wireless connectivity information should be in the absence of full geographical information, and weigh that against the cost in terms of infrastructure and inter-router signaling. Pat and I have asked Eunsoo to discuss this topic and problems with the server approach at the meeting. Ajoy and Marco's talk will discuss how the scope-id and server approach work. > Maybe, the next step is to start talking about what properties would > make for the best protocol, not what's wrong with one approach or the other. > Yes,exactly. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 17 13:17:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23373 for ; Mon, 17 Mar 2003 13:17:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HIYR422154 for seamoby-archive@odin.ietf.org; Mon, 17 Mar 2003 13:34:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIYRO22151 for ; Mon, 17 Mar 2003 13:34:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23356 for ; Mon, 17 Mar 2003 13:17:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIYBO22121; Mon, 17 Mar 2003 13:34:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIXoO22081 for ; Mon, 17 Mar 2003 13:33:50 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23324 for ; Mon, 17 Mar 2003 13:16:48 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HIJ5a28472 for ; Mon, 17 Mar 2003 12:19:05 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 12:18:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 10:17:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Mon, 17 Mar 2003 13:17:16 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stu ff) Thread-Index: AcLsFVsEoz+TKw3XT8eyp3H/WMCtjgAm0ESA To: , Cc: X-OriginalArrivalTime: 17 Mar 2003 18:17:16.0880 (UTC) FILETIME=[70FD2500:01C2ECB1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HIXoO22082 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit My 2 cents at the end - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Sunday, March 16, 2003 6:38 PM To: Singh Ajoy-ASINGH1; 'Pat Calhoun' Cc: 'seamoby@ietf.org' Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) I missed a NOT in my previous email so resending this with the correction. Regards, Ajoy -----Original Message----- From: Singh Ajoy-ASINGH1 Sent: Sunday, March 16, 2003 5:31 PM To: 'Pat Calhoun'; Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Hello Pat, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 4:18 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) > My initial reaction is that mandating a server is the wrong approach. I > am not claiming that discovery over the air, or some other approach, is > better, but *requiring* a server is problematic. > > AJOY-> I agree that requiring a new server introduces a single point > of failure. But if we piggyback CARD function over the existing > server such as AAA, it will not have this problem though. BTW, > if WG decides not to that then I am fine with that too. But so > far I have only heard from dycard co-authors. BTW, the DT > proposed server based approach to get the feedback from WG. > The DT will be happy change the approach if WG decides that. Right, and I'm providing my feedback... but I'm just one of many. > > I agree that service > providers will most likely not have much of an issue with requiring a > server for their network, but I doubt that enterprises that require > mobility, really want more infrastructure to manage. > > AJOY-> Servers are easier to manage. BTW, if the CARD function > can be integrated with existing server function e.g., AAA, then I do > not see why enterprise will need to manage extra infrastructure. embedded devices need to be configured, regardless of whether a server is present or not. AJOY-> Yup. How much cost it will add over the configuration of base AAA server? At a minimum, you'll want to create some form of security relationship between the embedded device and the server... so there's no way around it :( AJOY-> I did not follow this. If CARD function is extension of AAA function then why we need SA between embedded device and AAA server. > > One issue that I've heard in favor of a server approach is security. > I'll admit that I don't understand all of the issues, but there are > plenty of proof points where security can be provided without a backend > server. Whether it be peer-2-peer authentication via shared secrets, > certs, or what-have-you. In fact, maybe we should look at how OSPF > domains are created, and how routers communicate in a secure fashion? I > understand there are significant differences, but is there anything we > can learn from? > > AJOY-> I am not sure if comparing security requirements of intra-domain > routing protocol with that of CARD is fair. I will definitely like to > hear from the security experts because I do not consider myself > as a security expert. Well, maybe it's not a fair comparison, but I'd like to know why. If we are focused on intra-domain, then I see no difference. AJOY-> The dycard in initiated based upon trigger from a mobile node. The infrastructure does not have any control over what is provided by mobile node. What happens when a mobile node provides IP address of malicious node as CAR and the somehow security of AR is compromised? In this case, current AR will have to believe what is provided by the malicious CAR as valid information. This type of scenario may not be possible in intra-domain routing. But as I said before if security experts believe that this is not an issue and we can design a protocol assuming that security of AR will never be comprised, then I do NOT have any problem. > > The next issue I have is what appears to be a requirement to build an > iron-clad protocol. I get very nervous when I hear that folks want to > create a protocol that cannot drop a single call (or packet!). > > AJOY-> I think here simplicity is the key. If we can get simpler > protocol that can guarantee less or zero call drop, then what is > wrong in using that. I would request you to read dycard as > well as DT draft to conclude which is more complicated protocol. There's nothing wrong with high availability, but there's a price to pay for that. If you're telling me that it's free... then I get really confused and am willing to be convinced :) AJOY-> You did not answer my question about the simplicity of protocol. The DT proposal of CARD is lot simpler than what is being proposed in dycard. BTW, I am not sure how much extra cost we will incur if just enhance the AAA server to provide CARD function. It does not look very expensive to me. I will be more concerned about the cost of high availability when the server is involved in routing such as HA. > > Let's be > fair here folks, my cell phone drops calls all the time, regardless of > whether I'm doing a 911 call or not. That's just the nature of 1) really > complex systems, 2) unreliable code and 3) wireless is simply NOT > reliable. So in my opinion, we need to design a protocol that works > well, and can tolerate failures and recover from any problems. > > AJOY-> I agree that cell phone can drop the call due to poor > radio conditions. The radio conditions change due to many > factors which we cannot control sometime. But, cellular networks are > not designed to drop the call though. Ah, but that's my point exactly. They are designed to NOT drop calls, but they do. There's physics involved here, and there's nothing in the IETF we can do about it. So let's just keep that in mind while we decide how complex this needs to be. AJOY-> But we do have alternative which will reduce the chances of poor handoff. In dycard we know that some percentage of calls will be be affected due to lack of cache. This is in additional to the calls that are being dropped due to poor radio conditions. Hemant --> PSTNs were designed for 2% call blocking probability as a rule of thumb (recall Erlang blocking models). Then, another point about theory of statistics - addition of two very low probabilities does not degrade system performance. In other words addition of failure event of prob 10^(-6) to an event of prob 10^(-6) does not in practice (or even in theory) make any difference to overall system performance. I am not saying that we apply this straight to IP, but just because we were talking about probabilities ;-). I know we can't control the radio conditions, but at least we should try to eliminate the poor performance that is being caused due to something that can be fixed. > > I'm perfectly happy with a protocol that learns about it's neighbors. > It's all about trade-offs. Ethernet also has a cache, and has designed a > mechanism to re-validate the cache before it expires. Again, another > area that we should look into, and determine whether it can be applied > to this particular scenario. > > AJOY-> I will be happy with such protocol if the protocol in questions > is a simple protocol and provides significant benefit over > other protocol in consideration. Simplicity, in itself, is a significant benefit. AJOY-> That is what I am questioning about the dycard. Do we really need a complicated protocol to solve an easy problem? Please read the dycard draft and let me know if you still think dycard approach is simpler. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 17 13:18:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23388 for ; Mon, 17 Mar 2003 13:18:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIYBO22121; Mon, 17 Mar 2003 13:34:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIXoO22081 for ; Mon, 17 Mar 2003 13:33:50 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23324 for ; Mon, 17 Mar 2003 13:16:48 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2HIJ5a28472 for ; Mon, 17 Mar 2003 12:19:05 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Mar 2003 12:18:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 17 Mar 2003 10:17:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Mon, 17 Mar 2003 13:17:16 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stu ff) Thread-Index: AcLsFVsEoz+TKw3XT8eyp3H/WMCtjgAm0ESA To: , Cc: X-OriginalArrivalTime: 17 Mar 2003 18:17:16.0880 (UTC) FILETIME=[70FD2500:01C2ECB1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2HIXoO22082 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit My 2 cents at the end - Hemant -----Original Message----- From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Sunday, March 16, 2003 6:38 PM To: Singh Ajoy-ASINGH1; 'Pat Calhoun' Cc: 'seamoby@ietf.org' Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) I missed a NOT in my previous email so resending this with the correction. Regards, Ajoy -----Original Message----- From: Singh Ajoy-ASINGH1 Sent: Sunday, March 16, 2003 5:31 PM To: 'Pat Calhoun'; Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Hello Pat, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 4:18 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) > My initial reaction is that mandating a server is the wrong approach. I > am not claiming that discovery over the air, or some other approach, is > better, but *requiring* a server is problematic. > > AJOY-> I agree that requiring a new server introduces a single point > of failure. But if we piggyback CARD function over the existing > server such as AAA, it will not have this problem though. BTW, > if WG decides not to that then I am fine with that too. But so > far I have only heard from dycard co-authors. BTW, the DT > proposed server based approach to get the feedback from WG. > The DT will be happy change the approach if WG decides that. Right, and I'm providing my feedback... but I'm just one of many. > > I agree that service > providers will most likely not have much of an issue with requiring a > server for their network, but I doubt that enterprises that require > mobility, really want more infrastructure to manage. > > AJOY-> Servers are easier to manage. BTW, if the CARD function > can be integrated with existing server function e.g., AAA, then I do > not see why enterprise will need to manage extra infrastructure. embedded devices need to be configured, regardless of whether a server is present or not. AJOY-> Yup. How much cost it will add over the configuration of base AAA server? At a minimum, you'll want to create some form of security relationship between the embedded device and the server... so there's no way around it :( AJOY-> I did not follow this. If CARD function is extension of AAA function then why we need SA between embedded device and AAA server. > > One issue that I've heard in favor of a server approach is security. > I'll admit that I don't understand all of the issues, but there are > plenty of proof points where security can be provided without a backend > server. Whether it be peer-2-peer authentication via shared secrets, > certs, or what-have-you. In fact, maybe we should look at how OSPF > domains are created, and how routers communicate in a secure fashion? I > understand there are significant differences, but is there anything we > can learn from? > > AJOY-> I am not sure if comparing security requirements of intra-domain > routing protocol with that of CARD is fair. I will definitely like to > hear from the security experts because I do not consider myself > as a security expert. Well, maybe it's not a fair comparison, but I'd like to know why. If we are focused on intra-domain, then I see no difference. AJOY-> The dycard in initiated based upon trigger from a mobile node. The infrastructure does not have any control over what is provided by mobile node. What happens when a mobile node provides IP address of malicious node as CAR and the somehow security of AR is compromised? In this case, current AR will have to believe what is provided by the malicious CAR as valid information. This type of scenario may not be possible in intra-domain routing. But as I said before if security experts believe that this is not an issue and we can design a protocol assuming that security of AR will never be comprised, then I do NOT have any problem. > > The next issue I have is what appears to be a requirement to build an > iron-clad protocol. I get very nervous when I hear that folks want to > create a protocol that cannot drop a single call (or packet!). > > AJOY-> I think here simplicity is the key. If we can get simpler > protocol that can guarantee less or zero call drop, then what is > wrong in using that. I would request you to read dycard as > well as DT draft to conclude which is more complicated protocol. There's nothing wrong with high availability, but there's a price to pay for that. If you're telling me that it's free... then I get really confused and am willing to be convinced :) AJOY-> You did not answer my question about the simplicity of protocol. The DT proposal of CARD is lot simpler than what is being proposed in dycard. BTW, I am not sure how much extra cost we will incur if just enhance the AAA server to provide CARD function. It does not look very expensive to me. I will be more concerned about the cost of high availability when the server is involved in routing such as HA. > > Let's be > fair here folks, my cell phone drops calls all the time, regardless of > whether I'm doing a 911 call or not. That's just the nature of 1) really > complex systems, 2) unreliable code and 3) wireless is simply NOT > reliable. So in my opinion, we need to design a protocol that works > well, and can tolerate failures and recover from any problems. > > AJOY-> I agree that cell phone can drop the call due to poor > radio conditions. The radio conditions change due to many > factors which we cannot control sometime. But, cellular networks are > not designed to drop the call though. Ah, but that's my point exactly. They are designed to NOT drop calls, but they do. There's physics involved here, and there's nothing in the IETF we can do about it. So let's just keep that in mind while we decide how complex this needs to be. AJOY-> But we do have alternative which will reduce the chances of poor handoff. In dycard we know that some percentage of calls will be be affected due to lack of cache. This is in additional to the calls that are being dropped due to poor radio conditions. Hemant --> PSTNs were designed for 2% call blocking probability as a rule of thumb (recall Erlang blocking models). Then, another point about theory of statistics - addition of two very low probabilities does not degrade system performance. In other words addition of failure event of prob 10^(-6) to an event of prob 10^(-6) does not in practice (or even in theory) make any difference to overall system performance. I am not saying that we apply this straight to IP, but just because we were talking about probabilities ;-). I know we can't control the radio conditions, but at least we should try to eliminate the poor performance that is being caused due to something that can be fixed. > > I'm perfectly happy with a protocol that learns about it's neighbors. > It's all about trade-offs. Ethernet also has a cache, and has designed a > mechanism to re-validate the cache before it expires. Again, another > area that we should look into, and determine whether it can be applied > to this particular scenario. > > AJOY-> I will be happy with such protocol if the protocol in questions > is a simple protocol and provides significant benefit over > other protocol in consideration. Simplicity, in itself, is a significant benefit. AJOY-> That is what I am questioning about the dycard. Do we really need a complicated protocol to solve an easy problem? Please read the dycard draft and let me know if you still think dycard approach is simpler. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 17 13:23:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23546 for ; Mon, 17 Mar 2003 13:23:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HIeL023228 for seamoby-archive@odin.ietf.org; Mon, 17 Mar 2003 13:40:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIeLO23225 for ; Mon, 17 Mar 2003 13:40:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23522 for ; Mon, 17 Mar 2003 13:23:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIe4O23205; Mon, 17 Mar 2003 13:40:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIdoO23155 for ; Mon, 17 Mar 2003 13:39:50 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23508 for ; Mon, 17 Mar 2003 13:22:49 -0500 (EST) Message-ID: <014601c2ecb2$4f0a3cc0$246015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: Subject: Re: [Seamoby] updated dyCARD draft Date: Mon, 17 Mar 2003 10:20:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Hemant -> We had run this issue by Eric and the current design has been approved by him. The current design works with FMIP as well as without. Shall we close this issue now, or you think this is still open. > I think it is still open re. NSIIM. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 17 13:24:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23570 for ; Mon, 17 Mar 2003 13:24:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIe4O23205; Mon, 17 Mar 2003 13:40:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIdoO23155 for ; Mon, 17 Mar 2003 13:39:50 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23508 for ; Mon, 17 Mar 2003 13:22:49 -0500 (EST) Message-ID: <014601c2ecb2$4f0a3cc0$246015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: Subject: Re: [Seamoby] updated dyCARD draft Date: Mon, 17 Mar 2003 10:20:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Hemant -> We had run this issue by Eric and the current design has been approved by him. The current design works with FMIP as well as without. Shall we close this issue now, or you think this is still open. > I think it is still open re. NSIIM. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 12:58:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20792 for ; Tue, 18 Mar 2003 12:58:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IIFiW03060 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 13:15:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIFiO03057 for ; Tue, 18 Mar 2003 13:15:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20744 for ; Tue, 18 Mar 2003 12:58:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIFOO03032; Tue, 18 Mar 2003 13:15:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IICuO02868 for ; Tue, 18 Mar 2003 13:12:56 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20625 for ; Tue, 18 Mar 2003 12:55:26 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IHvbCx092870; Tue, 18 Mar 2003 18:57:37 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IHxE4J077404; Tue, 18 Mar 2003 17:59:15 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E776BB9.F616C3EA@ccrle.nec.de> Date: Tue, 18 Mar 2003 19:55:53 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stuff) References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7B@IL27EXM10.cig.mot.com> <1047860625.12529.145.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat, since DT proposed the server function for reverse address translation and optionally for static caps distribution, intention of DT was to discuss with the WG whether or not it's beneficial to put this function to a node that is integrated with an infrastructure already. Now, requirement of established SAs between protocol peers is not only for AAA protocols, as you referred to. But (and that's actually the reson why DT addressed this issue) we could integrate the CARD server function with an entity that has an established SA with ARs already. This avoids additional establishemnt of SAs. We took this proposal over as 'to be discussed' Alternatively, if the server function is somewhere else, we took also this into consideration and propose to have administratively configured keys/ passwords on ARs for initial weak authentication. After AR's activation, strong authentication is to be established dynamically (IKE, or alternatives). Means to establishthese SAs is not a CARD specific issue, I think, since it addresses all other areas as well (FastMIP, CT, ...) so, there should be a common mechanism to establish SAs between protocol peers. marco Pat Calhoun wrote: > Ajoy, > > Instead of answer my fairly point blank questions, you appear to be > defending CARD against Dycar. Let's put aside dycar for a moment as my > point is not to start a comparison war. Instead I want to look at the > current CARD proposal and see if it can be simplified. I don't have the > answers, all I have are questions. > > Regarding the one question I can answer: > AJOY-> I did not follow this. If CARD function is extension of > > AAA function then why we need SA between embedded device and > > AAA server. > > exactly, if it's an extension to an AAA protocol, every AAA protocol that I > know requires some form of security relationship in order to communicate in > a secure fashion, either via shared secrets, or certs. So there's security > configuration required regardless of the approach. > > PatC > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 12:59:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20811 for ; Tue, 18 Mar 2003 12:59:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIFOO03032; Tue, 18 Mar 2003 13:15:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IICuO02868 for ; Tue, 18 Mar 2003 13:12:56 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20625 for ; Tue, 18 Mar 2003 12:55:26 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IHvbCx092870; Tue, 18 Mar 2003 18:57:37 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IHxE4J077404; Tue, 18 Mar 2003 17:59:15 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E776BB9.F616C3EA@ccrle.nec.de> Date: Tue, 18 Mar 2003 19:55:53 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stuff) References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7B@IL27EXM10.cig.mot.com> <1047860625.12529.145.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pat, since DT proposed the server function for reverse address translation and optionally for static caps distribution, intention of DT was to discuss with the WG whether or not it's beneficial to put this function to a node that is integrated with an infrastructure already. Now, requirement of established SAs between protocol peers is not only for AAA protocols, as you referred to. But (and that's actually the reson why DT addressed this issue) we could integrate the CARD server function with an entity that has an established SA with ARs already. This avoids additional establishemnt of SAs. We took this proposal over as 'to be discussed' Alternatively, if the server function is somewhere else, we took also this into consideration and propose to have administratively configured keys/ passwords on ARs for initial weak authentication. After AR's activation, strong authentication is to be established dynamically (IKE, or alternatives). Means to establishthese SAs is not a CARD specific issue, I think, since it addresses all other areas as well (FastMIP, CT, ...) so, there should be a common mechanism to establish SAs between protocol peers. marco Pat Calhoun wrote: > Ajoy, > > Instead of answer my fairly point blank questions, you appear to be > defending CARD against Dycar. Let's put aside dycar for a moment as my > point is not to start a comparison war. Instead I want to look at the > current CARD proposal and see if it can be simplified. I don't have the > answers, all I have are questions. > > Regarding the one question I can answer: > AJOY-> I did not follow this. If CARD function is extension of > > AAA function then why we need SA between embedded device and > > AAA server. > > exactly, if it's an extension to an AAA protocol, every AAA protocol that I > know requires some form of security relationship in order to communicate in > a secure fashion, either via shared secrets, or certs. So there's security > configuration required regardless of the approach. > > PatC > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 13:25:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22436 for ; Tue, 18 Mar 2003 13:25:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IIgAV05606 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 13:42:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIgAO05603 for ; Tue, 18 Mar 2003 13:42:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22429 for ; Tue, 18 Mar 2003 13:24:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIfrO05548; Tue, 18 Mar 2003 13:41:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIddO05269 for ; Tue, 18 Mar 2003 13:39:39 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22121 for ; Tue, 18 Mar 2003 13:22:08 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IIOMCx003599; Tue, 18 Mar 2003 19:24:22 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IIPx4J077507; Tue, 18 Mar 2003 18:26:00 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E7771F9.18E387AC@ccrle.nec.de> Date: Tue, 18 Mar 2003 20:22:33 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Eunsoo Shim CC: Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE78@IL27EXM10.cig.mot.com> <029e01c2ec1d$e985ec30$e26b0f8a@eunsoo> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Eunsoo, please find some comments below, marco Eunsoo Shim wrote: > > > > > > > > 1. Server based approach is able to provide seamless > > > handoff even if the CAR information is not available in > > > the current AR cache. This has been made clear > > > in previous discussion. > > > > > [eunsoo] This is about initial population of the cache. We had lots of > > discussion about this. There were arguements about whether we need initial > > population of the cache. However it was clear that any existing management > > tool can be used for the initial population from the discussion. It tells > us > > that we don't need to invenet the wheel for initial router configuration. > > > > AJOY-> Initial population of cache does not address the problems due to > > cache timeout as well as cases when a new AP is added or removed from > > the coverage area of an AR. Also, server less approach of initial cache > > population is very difficult and challenging task for the service > providers. > > > [eunsoo] Initial population in Dycard is just done by one handoff between > each pair of CARs. What is so difficult and challenging? Can you please > explain your claims? > [marco] I think the idea is good, but I have some doubts on how realistic and reliable such a dynamic learning approch is. Please correct me if I'm wrong. Now, first of all, AR caches are updated by MNs after a handover. This is done after each handover, independent of cache entries require an update or not. Each update makes use of high cost radio bandwidth. Furthermore, additional protocol handshakes are most probably required to allow newARs to check whether or not a MN has been really attached to the oldAR (kind of authenticity check). Last but not least, conveying cache info via a MN's handover requires this MN to be active (otherwise no real handover will be performed, the MN only attaches to the new AP/AR). Most of terminals are idle, so, most probably, future systems will support dormant mode for MNs. Now, looks very cost intensive to wake up MNs only to maintain caches in new ARs. > > It was pointed out that the cache (CAR table) would be refreshed by repeated > handoffs and thus we would see rarely timeout of the cache entries unless > there was no handoff between two CARs for a long time. Of couse, when a new > AP/AR is added, we need a learning period in Dycard like the dynamic IP > routing protocol. Because of tradeoffs between static and central system and > dynamic and distributed system, people have adopted dynamic and distributed > IP routing protocols in most cases. Also please notice that you need to > reconfigure the server whenever there is a change in AP/AR, like even simple > IP address change. > I don't think the learning period justifies any static and central system. > > > That is why we are defining CARD protocol in first place. If service > > provider would like to manually configure L2->L3 mapping at each and > > every ARs then there is no good reason for the existence of the CARD > > protocol. > > > [eunsoo] You are confused. In Dycard, the admin does NOT have to configure > L2-L3 mapping entries at each AR. It is discovered dynamically. Actually the > server approach require that it is manually entered in the server. > [marco] Sure, dycard is dynamic learning. But we have to evaluate both approaches, both have pros and cons. Just to clarify on your statement, server function does not require administrative configuration. ARs have certs and possibly the scope-ID configured. From then process is automatically performed, which is ARs register with the server function. This entry is also to be updated from time to time to avoid unrecognized death of a particular AR. This lifetime is much larger as ARs' cache entries time out. So, only administrative configuration to be done on ARs is when they are integrated with a system and this is the password/certs for initial weak authentication from the system and possibly kind of scope-ID, if we go for such an approach. > > > > 2. The servers are easier to configure and manage. > > > > > [eunsoo] It is arguable. If you have to figure out proper scope-ids for > > every AR whenever there is a change in the network, it is not a really > dummy > > job. > > Also we have to pay attention to the price of having a central server. In > > general it is easier to manage one entity than many entities but you have > to > > pay the price of reliability (single point of failure) and scalability. > > > > I don't think the price is smaller than the benefit of easiness. > > > > AJOY-> BTW, there is no additional price if the CARD is integrated > > with AAA function. On the contrary, I think probably managing 1000s of > > AR would be more expensive and error prone than managing a few > > servers. > > > [eunsoo] The fact there is an AAA server does not mean we should use it. Or > it does not mean we have to share (actually double) the price of reliability > and scalability with the AAA server. > Now the discussion is getting into somewhat philosophical stage: Dynamic and > distributed system versus static and central system.... > Also it sounds to me like this. We have a printer server. So let's build a > central file system. Also let's build a central routing system. All the > reliability and scalability cost was already paid by the printer server... > This is not a right approach. The central AAA server does not mean we can > make CARD also kind of a central system without any additional price. Now > you are putting the reliability and scalability cost on the CARD protocol as > well as the AAA protocol. > > > > 3. Server can be used for inter-AR authorization. > > > > > > > > [eunsoo] Again, if we need a AAA server, we use it. We don't have to > > introduce a new type of server functionality. > > > > AJOY-> If we need to use AAA server then > > why not enhance that to support CARD functionality as well. I do > > see any justification for deploying a complicated protocol such > > as dycard when we can achieve the same function my making some > > enhancements to AAA function. > > > [eunsoo] Please see my above comments. > > > An important point is that there is alternative requiring no central > server. > > Why should we bother ourselves with the server? > > > > AJOY-> This is because AAA servers are anyway required in an access > > network and can also be useful tool for providing inter-AR > > authorization. So, I do not see any convincing reason for deploying a > > complicated protocol like dycard. > > > [eunsoo] Can you please substantiate your claim that Dycard is a complicated > protocol? > > > We need compelling reasons > > such as something that should/can be provided only by the central server > and > > that is not feasible in a solution without the server. > > Certainly it should > > not be the case where there is already the wheel or the price is much > larger > > than the benefit. > > > > AJOY-> I guess my previous reply would have answered your question. > > > [eunsoo] Not really. The main argument was that there was a AAA server and > thus let's use it as the central CARD server. You did not say what could be > done by having the server which was not possible without the server. > Regarding the initial cache population, it was also mentioned many times > that we could use any existing management tool if we need it. > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 13:25:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22449 for ; Tue, 18 Mar 2003 13:25:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIfrO05548; Tue, 18 Mar 2003 13:41:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIddO05269 for ; Tue, 18 Mar 2003 13:39:39 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22121 for ; Tue, 18 Mar 2003 13:22:08 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IIOMCx003599; Tue, 18 Mar 2003 19:24:22 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IIPx4J077507; Tue, 18 Mar 2003 18:26:00 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E7771F9.18E387AC@ccrle.nec.de> Date: Tue, 18 Mar 2003 20:22:33 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Eunsoo Shim CC: Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE78@IL27EXM10.cig.mot.com> <029e01c2ec1d$e985ec30$e26b0f8a@eunsoo> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Eunsoo, please find some comments below, marco Eunsoo Shim wrote: > > > > > > > > 1. Server based approach is able to provide seamless > > > handoff even if the CAR information is not available in > > > the current AR cache. This has been made clear > > > in previous discussion. > > > > > [eunsoo] This is about initial population of the cache. We had lots of > > discussion about this. There were arguements about whether we need initial > > population of the cache. However it was clear that any existing management > > tool can be used for the initial population from the discussion. It tells > us > > that we don't need to invenet the wheel for initial router configuration. > > > > AJOY-> Initial population of cache does not address the problems due to > > cache timeout as well as cases when a new AP is added or removed from > > the coverage area of an AR. Also, server less approach of initial cache > > population is very difficult and challenging task for the service > providers. > > > [eunsoo] Initial population in Dycard is just done by one handoff between > each pair of CARs. What is so difficult and challenging? Can you please > explain your claims? > [marco] I think the idea is good, but I have some doubts on how realistic and reliable such a dynamic learning approch is. Please correct me if I'm wrong. Now, first of all, AR caches are updated by MNs after a handover. This is done after each handover, independent of cache entries require an update or not. Each update makes use of high cost radio bandwidth. Furthermore, additional protocol handshakes are most probably required to allow newARs to check whether or not a MN has been really attached to the oldAR (kind of authenticity check). Last but not least, conveying cache info via a MN's handover requires this MN to be active (otherwise no real handover will be performed, the MN only attaches to the new AP/AR). Most of terminals are idle, so, most probably, future systems will support dormant mode for MNs. Now, looks very cost intensive to wake up MNs only to maintain caches in new ARs. > > It was pointed out that the cache (CAR table) would be refreshed by repeated > handoffs and thus we would see rarely timeout of the cache entries unless > there was no handoff between two CARs for a long time. Of couse, when a new > AP/AR is added, we need a learning period in Dycard like the dynamic IP > routing protocol. Because of tradeoffs between static and central system and > dynamic and distributed system, people have adopted dynamic and distributed > IP routing protocols in most cases. Also please notice that you need to > reconfigure the server whenever there is a change in AP/AR, like even simple > IP address change. > I don't think the learning period justifies any static and central system. > > > That is why we are defining CARD protocol in first place. If service > > provider would like to manually configure L2->L3 mapping at each and > > every ARs then there is no good reason for the existence of the CARD > > protocol. > > > [eunsoo] You are confused. In Dycard, the admin does NOT have to configure > L2-L3 mapping entries at each AR. It is discovered dynamically. Actually the > server approach require that it is manually entered in the server. > [marco] Sure, dycard is dynamic learning. But we have to evaluate both approaches, both have pros and cons. Just to clarify on your statement, server function does not require administrative configuration. ARs have certs and possibly the scope-ID configured. From then process is automatically performed, which is ARs register with the server function. This entry is also to be updated from time to time to avoid unrecognized death of a particular AR. This lifetime is much larger as ARs' cache entries time out. So, only administrative configuration to be done on ARs is when they are integrated with a system and this is the password/certs for initial weak authentication from the system and possibly kind of scope-ID, if we go for such an approach. > > > > 2. The servers are easier to configure and manage. > > > > > [eunsoo] It is arguable. If you have to figure out proper scope-ids for > > every AR whenever there is a change in the network, it is not a really > dummy > > job. > > Also we have to pay attention to the price of having a central server. In > > general it is easier to manage one entity than many entities but you have > to > > pay the price of reliability (single point of failure) and scalability. > > > > I don't think the price is smaller than the benefit of easiness. > > > > AJOY-> BTW, there is no additional price if the CARD is integrated > > with AAA function. On the contrary, I think probably managing 1000s of > > AR would be more expensive and error prone than managing a few > > servers. > > > [eunsoo] The fact there is an AAA server does not mean we should use it. Or > it does not mean we have to share (actually double) the price of reliability > and scalability with the AAA server. > Now the discussion is getting into somewhat philosophical stage: Dynamic and > distributed system versus static and central system.... > Also it sounds to me like this. We have a printer server. So let's build a > central file system. Also let's build a central routing system. All the > reliability and scalability cost was already paid by the printer server... > This is not a right approach. The central AAA server does not mean we can > make CARD also kind of a central system without any additional price. Now > you are putting the reliability and scalability cost on the CARD protocol as > well as the AAA protocol. > > > > 3. Server can be used for inter-AR authorization. > > > > > > > > [eunsoo] Again, if we need a AAA server, we use it. We don't have to > > introduce a new type of server functionality. > > > > AJOY-> If we need to use AAA server then > > why not enhance that to support CARD functionality as well. I do > > see any justification for deploying a complicated protocol such > > as dycard when we can achieve the same function my making some > > enhancements to AAA function. > > > [eunsoo] Please see my above comments. > > > An important point is that there is alternative requiring no central > server. > > Why should we bother ourselves with the server? > > > > AJOY-> This is because AAA servers are anyway required in an access > > network and can also be useful tool for providing inter-AR > > authorization. So, I do not see any convincing reason for deploying a > > complicated protocol like dycard. > > > [eunsoo] Can you please substantiate your claim that Dycard is a complicated > protocol? > > > We need compelling reasons > > such as something that should/can be provided only by the central server > and > > that is not feasible in a solution without the server. > > Certainly it should > > not be the case where there is already the wheel or the price is much > larger > > than the benefit. > > > > AJOY-> I guess my previous reply would have answered your question. > > > [eunsoo] Not really. The main argument was that there was a AAA server and > thus let's use it as the central CARD server. You did not say what could be > done by having the server which was not possible without the server. > Regarding the initial cache population, it was also mentioned many times > that we could use any existing management tool if we need it. > > Eunsoo > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 13:39:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23008 for ; Tue, 18 Mar 2003 13:39:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IIuhQ06566 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 13:56:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIuhO06563 for ; Tue, 18 Mar 2003 13:56:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22982 for ; Tue, 18 Mar 2003 13:39:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIuQO06469; Tue, 18 Mar 2003 13:56:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIopO06139 for ; Tue, 18 Mar 2003 13:50:51 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22753 for ; Tue, 18 Mar 2003 13:33:20 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IIZRCx008025; Tue, 18 Mar 2003 19:35:27 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IIb54J077542; Tue, 18 Mar 2003 18:37:06 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E777497.7821472D@ccrle.nec.de> Date: Tue, 18 Mar 2003 20:33:44 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Eunsoo Shim CC: Singh Ajoy-ASINGH1 , "'Pat Calhoun'" , seamoby@ietf.org Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stu ff) References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7C@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, just to clarify on the 'static and inconvenient configuration' issue. Please see inline. marco Eunsoo Shim wrote: > Ajoy, > > Pease see my inline comments. > > > > > > My initial reaction is that mandating a server is the wrong approach. I > > > am not claiming that discovery over the air, or some other approach, is > > > better, but *requiring* a server is problematic. > > > > > > AJOY-> I agree that requiring a new server introduces a single point > > > of failure. But if we piggyback CARD function over the existing > > > server such as AAA, it will not have this problem though. BTW, > > > if WG decides not to that then I am fine with that too. But so > > > far I have only heard from dycard co-authors. BTW, the DT > > > proposed server based approach to get the feedback from WG. > > > The DT will be happy change the approach if WG decides that. > > Right, and I'm providing my feedback... but I'm just one of many. > > > > > > > > I agree that service > > > providers will most likely not have much of an issue with requiring a > > > server for their network, but I doubt that enterprises that require > > > mobility, really want more infrastructure to manage. > > > > > > AJOY-> Servers are easier to manage. BTW, if the CARD function > > > can be integrated with existing server function e.g., AAA, then I do > > > not see why enterprise will need to manage extra infrastructure. > > embedded devices need to be configured, regardless of whether a server > > is present or not. > > > > AJOY-> Yup. How much cost it will add over the configuration of > > base AAA server? > > > [eunsoo] The cost is not just the configuration effort of the server. The > cost of the central server is reliability, scalability, cache contamination, > inflexibility due to static configuration in addition to changing the AAA > server in my current view. > Also my understanding of Pat's comment in the above is that the presence of > the server does not remove the need to configure ARs and APs. > [marco] Do folks really think there is really full plug and play with future commercial systems? Miminal configuration is required and, I think, also justifiable. Operators want security, reliabliity, etc... Now, minimal configuration is reasonable, as passwords for initial authentication. Establishment of SAs for stronger authentication is then perfromed automatically. Since topological characteristics are operator driven, why not just assigning an ID (e.g. the scope-ID) to an AR? Situation won't be that one cell is supported by one AR ;-) Rather one AR will support a very large area by means of couple of APs. AP authentication at AR is another issue, which is to be solved for BOTH approaches, the server-function based and the dynamic, handover based one. > > > At a minimum, you'll want to create some form of > > security relationship between the embedded device and the server... so > > there's no way around it :( > > > > AJOY-> I did not follow this. If CARD function is extension of > > AAA function then why we need SA between embedded device and > > AAA server. > > > > > > > > One issue that I've heard in favor of a server approach is security. > > > I'll admit that I don't understand all of the issues, but there are > > > plenty of proof points where security can be provided without a backend > > > server. Whether it be peer-2-peer authentication via shared secrets, > > > certs, or what-have-you. In fact, maybe we should look at how OSPF > > > domains are created, and how routers communicate in a secure fashion? I > > > understand there are significant differences, but is there anything we > > > can learn from? > > > > > > AJOY-> I am not sure if comparing security requirements of intra-domain > > > routing protocol with that of CARD is fair. I will definitely like to > > > hear from the security experts because I do not consider myself > > > as a security expert. > > > > Well, maybe it's not a fair comparison, but I'd like to know why. If we > > are focused on intra-domain, then I see no difference. > > > > AJOY-> The dycard in initiated based upon trigger from a mobile node. > > The infrastructure does not have any control over what is provided by > mobile > > node. > > What happens when a mobile node provides IP address of malicious node as > > CAR and the somehow security of AR is compromised? In this case, current > AR > > will have to > > believe what is provided by the malicious CAR as valid > > information. This type of scenario may not be possible in > > intra-domain routing. But as I said before if security experts > > believe that this is not an issue and we can design a protocol > > assuming that security of AR will never be comprised, then I do > > NOT have any problem. > > > > [eunsoo] Are you saying that the server approach will work fine even when > the security of AR is broken? > If you assume the security of AR is broken, what is safe among whatever the > AR is seriously involved in? > How is the intra-domain routing system safe when the security of the AR is > broken? > BTW I am not sure whether this kind of extreme scenario should be > considered. > > > > > > > The next issue I have is what appears to be a requirement to build an > > > iron-clad protocol. I get very nervous when I hear that folks want to > > > create a protocol that cannot drop a single call (or packet!). > > > > > > AJOY-> I think here simplicity is the key. If we can get simpler > > > protocol that can guarantee less or zero call drop, then what is > > > wrong in using that. I would request you to read dycard as > > > well as DT draft to conclude which is more complicated protocol. > > > > There's nothing wrong with high availability, but there's a price to pay > > for that. If you're telling me that it's free... then I get really > > confused and am willing to be convinced :) > > > > AJOY-> You did not answer my question about the simplicity of protocol. > > The DT proposal of CARD is lot simpler than what is > > being proposed in dycard. BTW, I am not sure how much extra > > cost we will incur if just enhance the AAA server to provide > > CARD function. It does not look very expensive to me. I > > will be more concerned about the cost of high availability > > when the server is involved in routing such as HA. > > > > [eunsoo] Again, please substantiate your claim that the DT proposal is a lot > simpler than Dycard. > How come you ignore the cost of reliability, scalability, cache > contamination and inflexibility on the CARD protocol caused by the server? > > > > > > > Let's be > > > fair here folks, my cell phone drops calls all the time, regardless of > > > whether I'm doing a 911 call or not. That's just the nature of 1) really > > > complex systems, 2) unreliable code and 3) wireless is simply NOT > > > reliable. So in my opinion, we need to design a protocol that works > > > well, and can tolerate failures and recover from any problems. > > > > > > AJOY-> I agree that cell phone can drop the call due to poor > > > radio conditions. The radio conditions change due to many > > > factors which we cannot control sometime. But, cellular networks are > > > not designed to drop the call though. > > > > Ah, but that's my point exactly. They are designed to NOT drop calls, > > but they do. There's physics involved here, and there's nothing in the > > IETF we can do about it. So let's just keep that in mind while we decide > > how complex this needs to be. > > > > AJOY-> But we do have alternative which will reduce the chances > > of poor handoff. In dycard we know that some percentage of calls > > will be be affected due to lack of cache. This is in additional to the > > calls that are being dropped due to poor radio conditions. I know we can't > > control the radio conditions, but at least we should try to > > eliminate the poor performance that is being caused > > due to something that can be fixed. > > > > [eunsoo] What percentage of calls will be affected in Dycard? Can you > substantiate your claims? > > > > > > > I'm perfectly happy with a protocol that learns about it's neighbors. > > > It's all about trade-offs. Ethernet also has a cache, and has designed a > > > mechanism to re-validate the cache before it expires. Again, another > > > area that we should look into, and determine whether it can be applied > > > to this particular scenario. > > > > > > AJOY-> I will be happy with such protocol if the protocol in questions > > > is a simple protocol and provides significant benefit over > > > other protocol in consideration. > > Simplicity, in itself, is a significant benefit. > > > > AJOY-> That is what I am questioning about the dycard. Do we really > > need a complicated protocol to solve an easy problem? Please read > > the dycard draft and let me know if you still think dycard approach > > is simpler. > > Eunsoo > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 13:40:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23040 for ; Tue, 18 Mar 2003 13:40:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIuQO06469; Tue, 18 Mar 2003 13:56:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIopO06139 for ; Tue, 18 Mar 2003 13:50:51 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22753 for ; Tue, 18 Mar 2003 13:33:20 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IIZRCx008025; Tue, 18 Mar 2003 19:35:27 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IIb54J077542; Tue, 18 Mar 2003 18:37:06 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E777497.7821472D@ccrle.nec.de> Date: Tue, 18 Mar 2003 20:33:44 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Eunsoo Shim CC: Singh Ajoy-ASINGH1 , "'Pat Calhoun'" , seamoby@ietf.org Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stu ff) References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE7C@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, just to clarify on the 'static and inconvenient configuration' issue. Please see inline. marco Eunsoo Shim wrote: > Ajoy, > > Pease see my inline comments. > > > > > > My initial reaction is that mandating a server is the wrong approach. I > > > am not claiming that discovery over the air, or some other approach, is > > > better, but *requiring* a server is problematic. > > > > > > AJOY-> I agree that requiring a new server introduces a single point > > > of failure. But if we piggyback CARD function over the existing > > > server such as AAA, it will not have this problem though. BTW, > > > if WG decides not to that then I am fine with that too. But so > > > far I have only heard from dycard co-authors. BTW, the DT > > > proposed server based approach to get the feedback from WG. > > > The DT will be happy change the approach if WG decides that. > > Right, and I'm providing my feedback... but I'm just one of many. > > > > > > > > I agree that service > > > providers will most likely not have much of an issue with requiring a > > > server for their network, but I doubt that enterprises that require > > > mobility, really want more infrastructure to manage. > > > > > > AJOY-> Servers are easier to manage. BTW, if the CARD function > > > can be integrated with existing server function e.g., AAA, then I do > > > not see why enterprise will need to manage extra infrastructure. > > embedded devices need to be configured, regardless of whether a server > > is present or not. > > > > AJOY-> Yup. How much cost it will add over the configuration of > > base AAA server? > > > [eunsoo] The cost is not just the configuration effort of the server. The > cost of the central server is reliability, scalability, cache contamination, > inflexibility due to static configuration in addition to changing the AAA > server in my current view. > Also my understanding of Pat's comment in the above is that the presence of > the server does not remove the need to configure ARs and APs. > [marco] Do folks really think there is really full plug and play with future commercial systems? Miminal configuration is required and, I think, also justifiable. Operators want security, reliabliity, etc... Now, minimal configuration is reasonable, as passwords for initial authentication. Establishment of SAs for stronger authentication is then perfromed automatically. Since topological characteristics are operator driven, why not just assigning an ID (e.g. the scope-ID) to an AR? Situation won't be that one cell is supported by one AR ;-) Rather one AR will support a very large area by means of couple of APs. AP authentication at AR is another issue, which is to be solved for BOTH approaches, the server-function based and the dynamic, handover based one. > > > At a minimum, you'll want to create some form of > > security relationship between the embedded device and the server... so > > there's no way around it :( > > > > AJOY-> I did not follow this. If CARD function is extension of > > AAA function then why we need SA between embedded device and > > AAA server. > > > > > > > > One issue that I've heard in favor of a server approach is security. > > > I'll admit that I don't understand all of the issues, but there are > > > plenty of proof points where security can be provided without a backend > > > server. Whether it be peer-2-peer authentication via shared secrets, > > > certs, or what-have-you. In fact, maybe we should look at how OSPF > > > domains are created, and how routers communicate in a secure fashion? I > > > understand there are significant differences, but is there anything we > > > can learn from? > > > > > > AJOY-> I am not sure if comparing security requirements of intra-domain > > > routing protocol with that of CARD is fair. I will definitely like to > > > hear from the security experts because I do not consider myself > > > as a security expert. > > > > Well, maybe it's not a fair comparison, but I'd like to know why. If we > > are focused on intra-domain, then I see no difference. > > > > AJOY-> The dycard in initiated based upon trigger from a mobile node. > > The infrastructure does not have any control over what is provided by > mobile > > node. > > What happens when a mobile node provides IP address of malicious node as > > CAR and the somehow security of AR is compromised? In this case, current > AR > > will have to > > believe what is provided by the malicious CAR as valid > > information. This type of scenario may not be possible in > > intra-domain routing. But as I said before if security experts > > believe that this is not an issue and we can design a protocol > > assuming that security of AR will never be comprised, then I do > > NOT have any problem. > > > > [eunsoo] Are you saying that the server approach will work fine even when > the security of AR is broken? > If you assume the security of AR is broken, what is safe among whatever the > AR is seriously involved in? > How is the intra-domain routing system safe when the security of the AR is > broken? > BTW I am not sure whether this kind of extreme scenario should be > considered. > > > > > > > The next issue I have is what appears to be a requirement to build an > > > iron-clad protocol. I get very nervous when I hear that folks want to > > > create a protocol that cannot drop a single call (or packet!). > > > > > > AJOY-> I think here simplicity is the key. If we can get simpler > > > protocol that can guarantee less or zero call drop, then what is > > > wrong in using that. I would request you to read dycard as > > > well as DT draft to conclude which is more complicated protocol. > > > > There's nothing wrong with high availability, but there's a price to pay > > for that. If you're telling me that it's free... then I get really > > confused and am willing to be convinced :) > > > > AJOY-> You did not answer my question about the simplicity of protocol. > > The DT proposal of CARD is lot simpler than what is > > being proposed in dycard. BTW, I am not sure how much extra > > cost we will incur if just enhance the AAA server to provide > > CARD function. It does not look very expensive to me. I > > will be more concerned about the cost of high availability > > when the server is involved in routing such as HA. > > > > [eunsoo] Again, please substantiate your claim that the DT proposal is a lot > simpler than Dycard. > How come you ignore the cost of reliability, scalability, cache > contamination and inflexibility on the CARD protocol caused by the server? > > > > > > > Let's be > > > fair here folks, my cell phone drops calls all the time, regardless of > > > whether I'm doing a 911 call or not. That's just the nature of 1) really > > > complex systems, 2) unreliable code and 3) wireless is simply NOT > > > reliable. So in my opinion, we need to design a protocol that works > > > well, and can tolerate failures and recover from any problems. > > > > > > AJOY-> I agree that cell phone can drop the call due to poor > > > radio conditions. The radio conditions change due to many > > > factors which we cannot control sometime. But, cellular networks are > > > not designed to drop the call though. > > > > Ah, but that's my point exactly. They are designed to NOT drop calls, > > but they do. There's physics involved here, and there's nothing in the > > IETF we can do about it. So let's just keep that in mind while we decide > > how complex this needs to be. > > > > AJOY-> But we do have alternative which will reduce the chances > > of poor handoff. In dycard we know that some percentage of calls > > will be be affected due to lack of cache. This is in additional to the > > calls that are being dropped due to poor radio conditions. I know we can't > > control the radio conditions, but at least we should try to > > eliminate the poor performance that is being caused > > due to something that can be fixed. > > > > [eunsoo] What percentage of calls will be affected in Dycard? Can you > substantiate your claims? > > > > > > > I'm perfectly happy with a protocol that learns about it's neighbors. > > > It's all about trade-offs. Ethernet also has a cache, and has designed a > > > mechanism to re-validate the cache before it expires. Again, another > > > area that we should look into, and determine whether it can be applied > > > to this particular scenario. > > > > > > AJOY-> I will be happy with such protocol if the protocol in questions > > > is a simple protocol and provides significant benefit over > > > other protocol in consideration. > > Simplicity, in itself, is a significant benefit. > > > > AJOY-> That is what I am questioning about the dycard. Do we really > > need a complicated protocol to solve an easy problem? Please read > > the dycard draft and let me know if you still think dycard approach > > is simpler. > > Eunsoo > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 13:57:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23960 for ; Tue, 18 Mar 2003 13:57:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJEfA08617 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 14:14:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJEfO08614 for ; Tue, 18 Mar 2003 14:14:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23911 for ; Tue, 18 Mar 2003 13:57:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJESO08541; Tue, 18 Mar 2003 14:14:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJA9O08295 for ; Tue, 18 Mar 2003 14:10:09 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23759 for ; Tue, 18 Mar 2003 13:52:38 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IIscCx009353; Tue, 18 Mar 2003 19:54:38 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IIuF4J077606; Tue, 18 Mar 2003 18:56:16 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E777915.A0039948@ccrle.nec.de> Date: Tue, 18 Mar 2003 20:52:54 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: ASINGH1@motorola.com, eunsoo@nec-labs.com, Hemant.Chaskar@nokia.com, robertc@cs.ucsb.edu, seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Dirk, please see comment in line. marco Dirk.Trossen@nokia.com wrote: > Hi Ajoy, > > >AJOY-> I have indicated in my earlier email that we need > >discuss your so called cache contamination comments > >either offline to during IETF presentation. BTW, > >here a few reasons for having server (e.g., AAA) > >based CARD functions: > > > >1. Server based approach is able to provide seamless > >handoff even if the CAR information is not available in > >the current AR cache. This has been made clear > >in previous discussion. > > It was also made clear that this seamless first handoff only happens with > a probability that is smaller than 1, and that there might be situations in > which might not even happen. > > > > >2. The servers are easier to configure and manage. > > A server that does not exists is even easier to manage, namely not at all. Your statement > is really kind of funny. Instead of answering the fundamental question why we need the server, > you come over and over again with the argument that servers are easy to manage. This is fundamentally > wrong if we don't need the server. Hence, the concerns are not about manageability, there are about > necessity. As long as we haven't clarified the latter, the former doesn't matter. > Again, both approaches have pros and cons. Now, I agree that some issues might be easier to solve when having no server function. But what's the tradeoff with an alternative approach? DT just proposed the server function for this interface (and is open to modify in particular this interface when reasonable and when there is a consensus in the entire WG). But to just decry the proposed mechanism and to address negative characteristics is probably not the right way. We should also evaluate positive characteristics of the proposed mechnism and tradeoff when going for an alternative apporach. As I just indicated in a reply to Eunsoo, dynamic learning is a good idea, but we have to evaluate how realistic dynamic learning is to meet requirements on chache maintenance and scalability. I expect some additional protocol complexity with a dynamic learning approach to authenticate info filling ARs' caches. Now, this is not critical with regard to timing issues, but might drop down scalability within the access network. marco > > Dirk > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 13:58:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23991 for ; Tue, 18 Mar 2003 13:58:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJESO08541; Tue, 18 Mar 2003 14:14:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJA9O08295 for ; Tue, 18 Mar 2003 14:10:09 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23759 for ; Tue, 18 Mar 2003 13:52:38 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IIscCx009353; Tue, 18 Mar 2003 19:54:38 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IIuF4J077606; Tue, 18 Mar 2003 18:56:16 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E777915.A0039948@ccrle.nec.de> Date: Tue, 18 Mar 2003 20:52:54 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: ASINGH1@motorola.com, eunsoo@nec-labs.com, Hemant.Chaskar@nokia.com, robertc@cs.ucsb.edu, seamoby@ietf.org Subject: Re: [SeaMoby] Topic #3: Cache contamination References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Dirk, please see comment in line. marco Dirk.Trossen@nokia.com wrote: > Hi Ajoy, > > >AJOY-> I have indicated in my earlier email that we need > >discuss your so called cache contamination comments > >either offline to during IETF presentation. BTW, > >here a few reasons for having server (e.g., AAA) > >based CARD functions: > > > >1. Server based approach is able to provide seamless > >handoff even if the CAR information is not available in > >the current AR cache. This has been made clear > >in previous discussion. > > It was also made clear that this seamless first handoff only happens with > a probability that is smaller than 1, and that there might be situations in > which might not even happen. > > > > >2. The servers are easier to configure and manage. > > A server that does not exists is even easier to manage, namely not at all. Your statement > is really kind of funny. Instead of answering the fundamental question why we need the server, > you come over and over again with the argument that servers are easy to manage. This is fundamentally > wrong if we don't need the server. Hence, the concerns are not about manageability, there are about > necessity. As long as we haven't clarified the latter, the former doesn't matter. > Again, both approaches have pros and cons. Now, I agree that some issues might be easier to solve when having no server function. But what's the tradeoff with an alternative approach? DT just proposed the server function for this interface (and is open to modify in particular this interface when reasonable and when there is a consensus in the entire WG). But to just decry the proposed mechanism and to address negative characteristics is probably not the right way. We should also evaluate positive characteristics of the proposed mechnism and tradeoff when going for an alternative apporach. As I just indicated in a reply to Eunsoo, dynamic learning is a good idea, but we have to evaluate how realistic dynamic learning is to meet requirements on chache maintenance and scalability. I expect some additional protocol complexity with a dynamic learning approach to authenticate info filling ARs' caches. Now, this is not critical with regard to timing issues, but might drop down scalability within the access network. marco > > Dirk > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 13:59:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24137 for ; Tue, 18 Mar 2003 13:59:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJGLr08842 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 14:16:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJGLO08839 for ; Tue, 18 Mar 2003 14:16:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24078 for ; Tue, 18 Mar 2003 13:58:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJG9O08800; Tue, 18 Mar 2003 14:16:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJFkO08748 for ; Tue, 18 Mar 2003 14:15:46 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24013 for ; Tue, 18 Mar 2003 13:58:15 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJ0Wa25124 for ; Tue, 18 Mar 2003 13:00:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 13:00:27 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 12:59:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Tue, 18 Mar 2003 13:59:25 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLte/dxeIqE1cBtSqqUhmKgAhy4dgAA/S4g To: , Cc: , X-OriginalArrivalTime: 18 Mar 2003 18:59:26.0496 (UTC) FILETIME=[7F2BAA00:01C2ED80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IJFkO08749 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Marco, comments inline >-----Original Message----- >From: ext Liebsch [mailto:marco.liebsch@ccrle.nec.de] >Sent: Tuesday, March 18, 2003 2:23 PM >To: Eunsoo Shim >Cc: Singh Ajoy-ASINGH1; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #3: Cache contamination > > >Hi Eunsoo, >please find some comments below, > >marco > >Eunsoo Shim wrote: > >> > >> > > >> > > 1. Server based approach is able to provide seamless >> > > handoff even if the CAR information is not available in >> > > the current AR cache. This has been made clear >> > > in previous discussion. >> > > >> > [eunsoo] This is about initial population of the cache. We >had lots of >> > discussion about this. There were arguements about whether >we need initial >> > population of the cache. However it was clear that any >existing management >> > tool can be used for the initial population from the >discussion. It tells >> us >> > that we don't need to invenet the wheel for initial router >configuration. >> > >> > AJOY-> Initial population of cache does not address the >problems due to >> > cache timeout as well as cases when a new AP is added or >removed from >> > the coverage area of an AR. Also, server less approach of >initial cache >> > population is very difficult and challenging task for the service >> providers. >> > >> [eunsoo] Initial population in Dycard is just done by one >handoff between >> each pair of CARs. What is so difficult and challenging? Can >you please >> explain your claims? >> > >[marco] I think the idea is good, but I have some doubts on >how realistic and >reliable such a dynamic learning approch is. Please correct me if I'm >wrong. Now, first of all, AR caches are updated by MNs after a >handover. This is done after each handover, independent of >cache entries >require an update or not. Each update makes use of high cost >radio bandwidth. What amount of radio bandwidth are we talking about here? Sending a triple of new L2, old L2, and old AR to the access router? I don't think this is a large amount of bandwidth. >Furthermore, additional protocol handshakes are most probably required >to allow newARs to check whether or not a MN has been really attached >to the oldAR (kind of authenticity check). Why would this be necessary if we already have the cache entry? Hence, this check with the old AR would happen once. The cache entry is only refreshed upon reception of another report for this old AR, i.e., the lifetime of the entry is renewed, but I don't have to check again. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 13:59:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24180 for ; Tue, 18 Mar 2003 13:59:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJG9O08800; Tue, 18 Mar 2003 14:16:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJFkO08748 for ; Tue, 18 Mar 2003 14:15:46 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24013 for ; Tue, 18 Mar 2003 13:58:15 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJ0Wa25124 for ; Tue, 18 Mar 2003 13:00:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 13:00:27 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 12:59:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Tue, 18 Mar 2003 13:59:25 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLte/dxeIqE1cBtSqqUhmKgAhy4dgAA/S4g To: , Cc: , X-OriginalArrivalTime: 18 Mar 2003 18:59:26.0496 (UTC) FILETIME=[7F2BAA00:01C2ED80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IJFkO08749 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marco, comments inline >-----Original Message----- >From: ext Liebsch [mailto:marco.liebsch@ccrle.nec.de] >Sent: Tuesday, March 18, 2003 2:23 PM >To: Eunsoo Shim >Cc: Singh Ajoy-ASINGH1; seamoby@ietf.org >Subject: Re: [SeaMoby] Topic #3: Cache contamination > > >Hi Eunsoo, >please find some comments below, > >marco > >Eunsoo Shim wrote: > >> > >> > > >> > > 1. Server based approach is able to provide seamless >> > > handoff even if the CAR information is not available in >> > > the current AR cache. This has been made clear >> > > in previous discussion. >> > > >> > [eunsoo] This is about initial population of the cache. We >had lots of >> > discussion about this. There were arguements about whether >we need initial >> > population of the cache. However it was clear that any >existing management >> > tool can be used for the initial population from the >discussion. It tells >> us >> > that we don't need to invenet the wheel for initial router >configuration. >> > >> > AJOY-> Initial population of cache does not address the >problems due to >> > cache timeout as well as cases when a new AP is added or >removed from >> > the coverage area of an AR. Also, server less approach of >initial cache >> > population is very difficult and challenging task for the service >> providers. >> > >> [eunsoo] Initial population in Dycard is just done by one >handoff between >> each pair of CARs. What is so difficult and challenging? Can >you please >> explain your claims? >> > >[marco] I think the idea is good, but I have some doubts on >how realistic and >reliable such a dynamic learning approch is. Please correct me if I'm >wrong. Now, first of all, AR caches are updated by MNs after a >handover. This is done after each handover, independent of >cache entries >require an update or not. Each update makes use of high cost >radio bandwidth. What amount of radio bandwidth are we talking about here? Sending a triple of new L2, old L2, and old AR to the access router? I don't think this is a large amount of bandwidth. >Furthermore, additional protocol handshakes are most probably required >to allow newARs to check whether or not a MN has been really attached >to the oldAR (kind of authenticity check). Why would this be necessary if we already have the cache entry? Hence, this check with the old AR would happen once. The cache entry is only refreshed upon reception of another report for this old AR, i.e., the lifetime of the entry is renewed, but I don't have to check again. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 14:08:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24488 for ; Tue, 18 Mar 2003 14:08:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJPGr09347 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 14:25:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJPGO09344 for ; Tue, 18 Mar 2003 14:25:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24473 for ; Tue, 18 Mar 2003 14:07:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJP5O09336; Tue, 18 Mar 2003 14:25:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJOWO09281 for ; Tue, 18 Mar 2003 14:24:32 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24446 for ; Tue, 18 Mar 2003 14:07:01 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJ9Ia27219 for ; Tue, 18 Mar 2003 13:09:19 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 13:09:14 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 11:08:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Tue, 18 Mar 2003 14:08:17 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stu ff) Thread-Index: AcLtff75aL59hgHESPaaYNhf6UMVIAAAqYrw To: , Cc: , , X-OriginalArrivalTime: 18 Mar 2003 19:08:18.0623 (UTC) FILETIME=[BC57CCF0:01C2ED81] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IJOWO09282 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Marco, see comments inline [snip] >> [eunsoo] The cost is not just the configuration effort of >the server. The >> cost of the central server is reliability, scalability, >cache contamination, >> inflexibility due to static configuration in addition to >changing the AAA >> server in my current view. >> Also my understanding of Pat's comment in the above is that >the presence of >> the server does not remove the need to configure ARs and APs. >> > >[marco] Do folks really think there is really full plug and play with >future commercial systems? Miminal configuration is required and, >I think, also justifiable. Operators want security, reliabliity, etc... >Now, minimal configuration is reasonable, as passwords for initial >authentication. Establishment of SAs for stronger authentication is >then perfromed automatically. Since topological characteristics are >operator driven, why not just assigning an ID (e.g. the scope-ID) >to an AR? Situation won't be that one cell is supported by one AR ;-) >Rather one AR will support a very large area by means of couple of >APs. AP authentication at AR is another issue, which is to be solved >for BOTH approaches, the server-function based and the >dynamic, handover >based one. The need for configuration here mainly refers to the static configuration of neighborhood information in the server. The issue of how to tackle probable changes of such kind of neighborhood information (which was also one of the issues in the problem statement, and is also included in the requirements, i.e., the necessity to react upon changes in logical and physical topology) is right now hidden somehow in the definition of the scope-id, which has to be set somehow "properly" by the operator. Further, changes in topology are somehow taken care by updating the backend server through any means. We outlined this kind of static configuration solution already in the issues draft and called it undesirable, in particular when we look at inter-domain cases. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 14:08:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24524 for ; Tue, 18 Mar 2003 14:08:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJP5O09336; Tue, 18 Mar 2003 14:25:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJOWO09281 for ; Tue, 18 Mar 2003 14:24:32 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24446 for ; Tue, 18 Mar 2003 14:07:01 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJ9Ia27219 for ; Tue, 18 Mar 2003 13:09:19 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 13:09:14 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 11:08:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Tue, 18 Mar 2003 14:08:17 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stu ff) Thread-Index: AcLtff75aL59hgHESPaaYNhf6UMVIAAAqYrw To: , Cc: , , X-OriginalArrivalTime: 18 Mar 2003 19:08:18.0623 (UTC) FILETIME=[BC57CCF0:01C2ED81] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IJOWO09282 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marco, see comments inline [snip] >> [eunsoo] The cost is not just the configuration effort of >the server. The >> cost of the central server is reliability, scalability, >cache contamination, >> inflexibility due to static configuration in addition to >changing the AAA >> server in my current view. >> Also my understanding of Pat's comment in the above is that >the presence of >> the server does not remove the need to configure ARs and APs. >> > >[marco] Do folks really think there is really full plug and play with >future commercial systems? Miminal configuration is required and, >I think, also justifiable. Operators want security, reliabliity, etc... >Now, minimal configuration is reasonable, as passwords for initial >authentication. Establishment of SAs for stronger authentication is >then perfromed automatically. Since topological characteristics are >operator driven, why not just assigning an ID (e.g. the scope-ID) >to an AR? Situation won't be that one cell is supported by one AR ;-) >Rather one AR will support a very large area by means of couple of >APs. AP authentication at AR is another issue, which is to be solved >for BOTH approaches, the server-function based and the >dynamic, handover >based one. The need for configuration here mainly refers to the static configuration of neighborhood information in the server. The issue of how to tackle probable changes of such kind of neighborhood information (which was also one of the issues in the problem statement, and is also included in the requirements, i.e., the necessity to react upon changes in logical and physical topology) is right now hidden somehow in the definition of the scope-id, which has to be set somehow "properly" by the operator. Further, changes in topology are somehow taken care by updating the backend server through any means. We outlined this kind of static configuration solution already in the issues draft and called it undesirable, in particular when we look at inter-domain cases. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 14:28:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25337 for ; Tue, 18 Mar 2003 14:28:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJjZZ11493 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 14:45:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJjZO11490 for ; Tue, 18 Mar 2003 14:45:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25308 for ; Tue, 18 Mar 2003 14:28:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJjMO11424; Tue, 18 Mar 2003 14:45:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJZEO10092 for ; Tue, 18 Mar 2003 14:35:14 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25014 for ; Tue, 18 Mar 2003 14:17:42 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJJu822251 for ; Tue, 18 Mar 2003 13:19:56 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 13:19:56 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 13:19:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Tue, 18 Mar 2003 14:19:55 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLtgISbJt5usJHGSvq363h0ysrmegAAVxJw To: Cc: , , , , X-OriginalArrivalTime: 18 Mar 2003 19:19:56.0433 (UTC) FILETIME=[5C452810:01C2ED83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IJZEO10093 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Marco, >> >2. The servers are easier to configure and manage. >> >> A server that does not exists is even easier to manage, >namely not at all. Your statement >> is really kind of funny. Instead of answering the >fundamental question why we need the server, >> you come over and over again with the argument that servers >are easy to manage. This is fundamentally >> wrong if we don't need the server. Hence, the concerns are >not about manageability, there are about >> necessity. As long as we haven't clarified the latter, the >former doesn't matter. >> > >Again, both approaches have pros and cons. Now, I agree that >some issues >might be easier to solve when having no server function. But what's the >tradeoff with an alternative approach? DT just proposed the server >function for this interface (and is open to modify in >particular this interface >when reasonable and when there is a consensus in the entire WG). But to >just decry the proposed mechanism and to address negative >characteristics >is probably not the right way. The above statement of mine did not address a specific negative characteristic of servers. I just wanted to make clear that the argument of "easier to manage" is not proper when we first have to answer the question whether or not we need the server for performing the L2-L3 mapping. I'm not introducing a server in a certain scheme (even in parts of the overall scheme), if I don't need this server. The fact that the server is easy to manage, doesn't change that. >We should also evaluate positive >characteristics of the proposed mechnism and tradeoff when going for >an alternative apporach. I agree with you. If you review the discussion last week, the topic concentrated more on the issue of performing L2-L3 mapping through the server. Issues like the existence of a server for AP authentication is not explicitly addressed in the dycard approach since we assumed such authentication to exist. I expect that such evaluation as to what the tradeoff of different techniques for different problems within CAR would be, will be done. >As I just indicated in a reply to >Eunsoo, dynamic >learning is a good idea, but we have to evaluate how realistic >dynamic learning is >to meet requirements on chache maintenance and scalability. I >expect some >additional protocol complexity with a dynamic learning approach to >authenticate info filling ARs' caches. Now, this is not >critical with regard >to timing issues, but might drop down scalability within the >access network. We certainly want to help understanding these issues. But you must also understand that "expecting" protocol complexity is a not quite technical point to evaluate approaches. If you see concrete issues regarding complexity and scalability, please bring them up and let's discuss them. To some of the issues you brought, I've already replied in an earlier email. In general, please keep in mind that we should not see this discussion as an "either/or" question. There are valid points for either approach in certain fields, and we should see how to get the best out of both. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 14:28:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25360 for ; Tue, 18 Mar 2003 14:28:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJjbF11529 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 14:45:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJjbO11526 for ; Tue, 18 Mar 2003 14:45:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25315 for ; Tue, 18 Mar 2003 14:28:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJjNO11449; Tue, 18 Mar 2003 14:45:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJbYO10777 for ; Tue, 18 Mar 2003 14:37:34 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25045 for ; Tue, 18 Mar 2003 14:20:02 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Mar 2003 11:22:15 -0800 Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stu ff) From: Pat Calhoun To: Liebsch Cc: Dirk.Trossen@nokia.com, eunsooshim@hotmail.com, ASINGH1@motorola.com, seamoby@ietf.org In-Reply-To: <3E777EC2.88B50923@ccrle.nec.de> References: <3E777EC2.88B50923@ccrle.nec.de> Content-Type: text/plain Message-Id: <1048015235.16725.105.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 18 Mar 2003 11:20:35 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2003 19:22:15.0514 (UTC) FILETIME=[AF2B3BA0:01C2ED83] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think a list of the alternatives, and the cost associated with each alternatives, would be a VERY worthwhile discussion to have. PatC On Tue, 2003-03-18 at 12:17, Liebsch wrote: > Hi Dirk, > > I agree that it would be helpful to get some feedback from outside > DT and dycard authors. Now, hope we can get some opinion during > the Seamoby meeting. > Now, as you know, there are some characteristics of a server-function > approach that are not really convincing for reasons that are actually valid for > ALL server-based approaches. DT proposal tried to make the use of the server > function clear, keeping it restricted to very basic functionality to avoid > complexity. I wonder why statements like 'static config at the server' > and 'server is used for initial population of caches only' appear, this > is not what the server function is for, and DT doesn't introduce a server > function only to introduce additional complexity ;-), but to avoid protocol > complexity, ensure scalability and meet expectation on functional > requirements. > As referred to many times, if WG wants an alternative approach for > cache maintenance, DT is open for modification. But tradeoff coming with > a currently available alternative approach, that's what I tried to summarize > in my last mails. Maybe we should take them over to slides for > Thursday's meeting to not put bias on 'knocking on the server function > approach'. > > marco > > > Dirk.Trossen@nokia.com wrote: > > > >> AJOY-> You did not answer my question about the simplicity > > >of protocol. > > >> The DT proposal of CARD is lot simpler than what is > > >> being proposed in dycard. > > > > Do you have anything of substance here to say? Why on earth is a server-based > > approach simpler than an approach that does not require said server? Statements > > don't get right just because you post them. And rejecting our questions regarding the grounds > > for what you claim with "I would like to hear opinions of others" doesn't make it better. > > You post statements on the list with claims, and everybody, the silent WG members and the > > dycard authors, have a right to hear the grounds for your argument. Otherwise, it is nothing > > more than a simple, unproven claim which can easily be rejected. > > > > Thanks, > > > > Dirk > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 14:28:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25377 for ; Tue, 18 Mar 2003 14:28:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJjNO11449; Tue, 18 Mar 2003 14:45:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJbYO10777 for ; Tue, 18 Mar 2003 14:37:34 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25045 for ; Tue, 18 Mar 2003 14:20:02 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Mar 2003 11:22:15 -0800 Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stu ff) From: Pat Calhoun To: Liebsch Cc: Dirk.Trossen@nokia.com, eunsooshim@hotmail.com, ASINGH1@motorola.com, seamoby@ietf.org In-Reply-To: <3E777EC2.88B50923@ccrle.nec.de> References: <3E777EC2.88B50923@ccrle.nec.de> Content-Type: text/plain Message-Id: <1048015235.16725.105.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 18 Mar 2003 11:20:35 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2003 19:22:15.0514 (UTC) FILETIME=[AF2B3BA0:01C2ED83] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think a list of the alternatives, and the cost associated with each alternatives, would be a VERY worthwhile discussion to have. PatC On Tue, 2003-03-18 at 12:17, Liebsch wrote: > Hi Dirk, > > I agree that it would be helpful to get some feedback from outside > DT and dycard authors. Now, hope we can get some opinion during > the Seamoby meeting. > Now, as you know, there are some characteristics of a server-function > approach that are not really convincing for reasons that are actually valid for > ALL server-based approaches. DT proposal tried to make the use of the server > function clear, keeping it restricted to very basic functionality to avoid > complexity. I wonder why statements like 'static config at the server' > and 'server is used for initial population of caches only' appear, this > is not what the server function is for, and DT doesn't introduce a server > function only to introduce additional complexity ;-), but to avoid protocol > complexity, ensure scalability and meet expectation on functional > requirements. > As referred to many times, if WG wants an alternative approach for > cache maintenance, DT is open for modification. But tradeoff coming with > a currently available alternative approach, that's what I tried to summarize > in my last mails. Maybe we should take them over to slides for > Thursday's meeting to not put bias on 'knocking on the server function > approach'. > > marco > > > Dirk.Trossen@nokia.com wrote: > > > >> AJOY-> You did not answer my question about the simplicity > > >of protocol. > > >> The DT proposal of CARD is lot simpler than what is > > >> being proposed in dycard. > > > > Do you have anything of substance here to say? Why on earth is a server-based > > approach simpler than an approach that does not require said server? Statements > > don't get right just because you post them. And rejecting our questions regarding the grounds > > for what you claim with "I would like to hear opinions of others" doesn't make it better. > > You post statements on the list with claims, and everybody, the silent WG members and the > > dycard authors, have a right to hear the grounds for your argument. Otherwise, it is nothing > > more than a simple, unproven claim which can easily be rejected. > > > > Thanks, > > > > Dirk > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 14:29:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25391 for ; Tue, 18 Mar 2003 14:29:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJjMO11424; Tue, 18 Mar 2003 14:45:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJZEO10092 for ; Tue, 18 Mar 2003 14:35:14 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25014 for ; Tue, 18 Mar 2003 14:17:42 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJJu822251 for ; Tue, 18 Mar 2003 13:19:56 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 13:19:56 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 13:19:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SeaMoby] Topic #3: Cache contamination Date: Tue, 18 Mar 2003 14:19:55 -0500 Message-ID: Thread-Topic: [SeaMoby] Topic #3: Cache contamination Thread-Index: AcLtgISbJt5usJHGSvq363h0ysrmegAAVxJw To: Cc: , , , , X-OriginalArrivalTime: 18 Mar 2003 19:19:56.0433 (UTC) FILETIME=[5C452810:01C2ED83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IJZEO10093 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marco, >> >2. The servers are easier to configure and manage. >> >> A server that does not exists is even easier to manage, >namely not at all. Your statement >> is really kind of funny. Instead of answering the >fundamental question why we need the server, >> you come over and over again with the argument that servers >are easy to manage. This is fundamentally >> wrong if we don't need the server. Hence, the concerns are >not about manageability, there are about >> necessity. As long as we haven't clarified the latter, the >former doesn't matter. >> > >Again, both approaches have pros and cons. Now, I agree that >some issues >might be easier to solve when having no server function. But what's the >tradeoff with an alternative approach? DT just proposed the server >function for this interface (and is open to modify in >particular this interface >when reasonable and when there is a consensus in the entire WG). But to >just decry the proposed mechanism and to address negative >characteristics >is probably not the right way. The above statement of mine did not address a specific negative characteristic of servers. I just wanted to make clear that the argument of "easier to manage" is not proper when we first have to answer the question whether or not we need the server for performing the L2-L3 mapping. I'm not introducing a server in a certain scheme (even in parts of the overall scheme), if I don't need this server. The fact that the server is easy to manage, doesn't change that. >We should also evaluate positive >characteristics of the proposed mechnism and tradeoff when going for >an alternative apporach. I agree with you. If you review the discussion last week, the topic concentrated more on the issue of performing L2-L3 mapping through the server. Issues like the existence of a server for AP authentication is not explicitly addressed in the dycard approach since we assumed such authentication to exist. I expect that such evaluation as to what the tradeoff of different techniques for different problems within CAR would be, will be done. >As I just indicated in a reply to >Eunsoo, dynamic >learning is a good idea, but we have to evaluate how realistic >dynamic learning is >to meet requirements on chache maintenance and scalability. I >expect some >additional protocol complexity with a dynamic learning approach to >authenticate info filling ARs' caches. Now, this is not >critical with regard >to timing issues, but might drop down scalability within the >access network. We certainly want to help understanding these issues. But you must also understand that "expecting" protocol complexity is a not quite technical point to evaluate approaches. If you see concrete issues regarding complexity and scalability, please bring them up and let's discuss them. To some of the issues you brought, I've already replied in an earlier email. In general, please keep in mind that we should not see this discussion as an "either/or" question. There are valid points for either approach in certain fields, and we should see how to get the best out of both. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 14:29:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25399 for ; Tue, 18 Mar 2003 14:29:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJjKO11402; Tue, 18 Mar 2003 14:45:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJYHO10026 for ; Tue, 18 Mar 2003 14:34:17 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24972 for ; Tue, 18 Mar 2003 14:16:45 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IJIpCx009848; Tue, 18 Mar 2003 20:18:51 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IJKT4J077699; Tue, 18 Mar 2003 19:20:30 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E777EC2.88B50923@ccrle.nec.de> Date: Tue, 18 Mar 2003 21:17:06 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: eunsooshim@hotmail.com, ASINGH1@motorola.com, pcalhoun@bstormnetworks.com, seamoby@ietf.org Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stu ff) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Dirk, I agree that it would be helpful to get some feedback from outside DT and dycard authors. Now, hope we can get some opinion during the Seamoby meeting. Now, as you know, there are some characteristics of a server-function approach that are not really convincing for reasons that are actually valid for ALL server-based approaches. DT proposal tried to make the use of the server function clear, keeping it restricted to very basic functionality to avoid complexity. I wonder why statements like 'static config at the server' and 'server is used for initial population of caches only' appear, this is not what the server function is for, and DT doesn't introduce a server function only to introduce additional complexity ;-), but to avoid protocol complexity, ensure scalability and meet expectation on functional requirements. As referred to many times, if WG wants an alternative approach for cache maintenance, DT is open for modification. But tradeoff coming with a currently available alternative approach, that's what I tried to summarize in my last mails. Maybe we should take them over to slides for Thursday's meeting to not put bias on 'knocking on the server function approach'. marco Dirk.Trossen@nokia.com wrote: > >> AJOY-> You did not answer my question about the simplicity > >of protocol. > >> The DT proposal of CARD is lot simpler than what is > >> being proposed in dycard. > > Do you have anything of substance here to say? Why on earth is a server-based > approach simpler than an approach that does not require said server? Statements > don't get right just because you post them. And rejecting our questions regarding the grounds > for what you claim with "I would like to hear opinions of others" doesn't make it better. > You post statements on the list with claims, and everybody, the silent WG members and the > dycard authors, have a right to hear the grounds for your argument. Otherwise, it is nothing > more than a simple, unproven claim which can easily be rejected. > > Thanks, > > Dirk > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 14:30:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25560 for ; Tue, 18 Mar 2003 14:30:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJlfD11768 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 14:47:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJlfO11765 for ; Tue, 18 Mar 2003 14:47:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25497 for ; Tue, 18 Mar 2003 14:30:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJlTO11640; Tue, 18 Mar 2003 14:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJe1O11048 for ; Tue, 18 Mar 2003 14:40:01 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25121 for ; Tue, 18 Mar 2003 14:22:29 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJOla28908 for ; Tue, 18 Mar 2003 13:24:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 13:24:42 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 11:23:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Tue, 18 Mar 2003 14:23:28 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stu ff) Thread-Index: AcLtg0uJqb0jAGsiSK+vqSzDg7NGPwAADd8g To: Cc: , , , X-OriginalArrivalTime: 18 Mar 2003 19:23:28.0973 (UTC) FILETIME=[DAF42FD0:01C2ED83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IJe1O11049 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Marco, >-----Original Message----- >From: ext Liebsch [mailto:marco.liebsch@ccrle.nec.de] >Sent: Tuesday, March 18, 2003 3:17 PM >To: Trossen Dirk (NRC/Boston) >Cc: eunsooshim@hotmail.com; ASINGH1@motorola.com; >pcalhoun@bstormnetworks.com; seamoby@ietf.org >Subject: Re: [Seamoby] My thoughts on server approaches (and other fun >stu ff) > > >Hi Dirk, > >I agree that it would be helpful to get some feedback from outside >DT and dycard authors. Now, hope we can get some opinion during >the Seamoby meeting. >Now, as you know, there are some characteristics of a server-function >approach that are not really convincing for reasons that are >actually valid for >ALL server-based approaches. DT proposal tried to make the use >of the server >function clear, keeping it restricted to very basic >functionality to avoid >complexity. I wonder why statements like 'static config at the server' >and 'server is used for initial population of caches only' appear, this >is not what the server function is for, and DT doesn't >introduce a server >function only to introduce additional complexity ;-), but to >avoid protocol >complexity, ensure scalability and meet expectation on functional >requirements. >As referred to many times, if WG wants an alternative approach for >cache maintenance, DT is open for modification. But tradeoff >coming with >a currently available alternative approach, that's what I >tried to summarize >in my last mails. Maybe we should take them over to slides for >Thursday's meeting to not put bias on 'knocking on the server function >approach'. > >marco We're not trying to "knock out the server function". I agree that we have to put the different issues on the table, in particular separating the problem field for this. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 14:31:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25616 for ; Tue, 18 Mar 2003 14:31:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJlTO11640; Tue, 18 Mar 2003 14:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJe1O11048 for ; Tue, 18 Mar 2003 14:40:01 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25121 for ; Tue, 18 Mar 2003 14:22:29 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IJOla28908 for ; Tue, 18 Mar 2003 13:24:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 13:24:42 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 11:23:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Tue, 18 Mar 2003 14:23:28 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stu ff) Thread-Index: AcLtg0uJqb0jAGsiSK+vqSzDg7NGPwAADd8g To: Cc: , , , X-OriginalArrivalTime: 18 Mar 2003 19:23:28.0973 (UTC) FILETIME=[DAF42FD0:01C2ED83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IJe1O11049 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marco, >-----Original Message----- >From: ext Liebsch [mailto:marco.liebsch@ccrle.nec.de] >Sent: Tuesday, March 18, 2003 3:17 PM >To: Trossen Dirk (NRC/Boston) >Cc: eunsooshim@hotmail.com; ASINGH1@motorola.com; >pcalhoun@bstormnetworks.com; seamoby@ietf.org >Subject: Re: [Seamoby] My thoughts on server approaches (and other fun >stu ff) > > >Hi Dirk, > >I agree that it would be helpful to get some feedback from outside >DT and dycard authors. Now, hope we can get some opinion during >the Seamoby meeting. >Now, as you know, there are some characteristics of a server-function >approach that are not really convincing for reasons that are >actually valid for >ALL server-based approaches. DT proposal tried to make the use >of the server >function clear, keeping it restricted to very basic >functionality to avoid >complexity. I wonder why statements like 'static config at the server' >and 'server is used for initial population of caches only' appear, this >is not what the server function is for, and DT doesn't >introduce a server >function only to introduce additional complexity ;-), but to >avoid protocol >complexity, ensure scalability and meet expectation on functional >requirements. >As referred to many times, if WG wants an alternative approach for >cache maintenance, DT is open for modification. But tradeoff >coming with >a currently available alternative approach, that's what I >tried to summarize >in my last mails. Maybe we should take them over to slides for >Thursday's meeting to not put bias on 'knocking on the server function >approach'. > >marco We're not trying to "knock out the server function". I agree that we have to put the different issues on the table, in particular separating the problem field for this. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 15:26:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25338 for ; Tue, 18 Mar 2003 14:28:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJjZP11509 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 14:45:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJjZO11496 for ; Tue, 18 Mar 2003 14:45:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25309 for ; Tue, 18 Mar 2003 14:28:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJjKO11402; Tue, 18 Mar 2003 14:45:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJYHO10026 for ; Tue, 18 Mar 2003 14:34:17 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24972 for ; Tue, 18 Mar 2003 14:16:45 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IJIpCx009848; Tue, 18 Mar 2003 20:18:51 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IJKT4J077699; Tue, 18 Mar 2003 19:20:30 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E777EC2.88B50923@ccrle.nec.de> Date: Tue, 18 Mar 2003 21:17:06 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dirk.Trossen@nokia.com CC: eunsooshim@hotmail.com, ASINGH1@motorola.com, pcalhoun@bstormnetworks.com, seamoby@ietf.org Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stu ff) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Dirk, I agree that it would be helpful to get some feedback from outside DT and dycard authors. Now, hope we can get some opinion during the Seamoby meeting. Now, as you know, there are some characteristics of a server-function approach that are not really convincing for reasons that are actually valid for ALL server-based approaches. DT proposal tried to make the use of the server function clear, keeping it restricted to very basic functionality to avoid complexity. I wonder why statements like 'static config at the server' and 'server is used for initial population of caches only' appear, this is not what the server function is for, and DT doesn't introduce a server function only to introduce additional complexity ;-), but to avoid protocol complexity, ensure scalability and meet expectation on functional requirements. As referred to many times, if WG wants an alternative approach for cache maintenance, DT is open for modification. But tradeoff coming with a currently available alternative approach, that's what I tried to summarize in my last mails. Maybe we should take them over to slides for Thursday's meeting to not put bias on 'knocking on the server function approach'. marco Dirk.Trossen@nokia.com wrote: > >> AJOY-> You did not answer my question about the simplicity > >of protocol. > >> The DT proposal of CARD is lot simpler than what is > >> being proposed in dycard. > > Do you have anything of substance here to say? Why on earth is a server-based > approach simpler than an approach that does not require said server? Statements > don't get right just because you post them. And rejecting our questions regarding the grounds > for what you claim with "I would like to hear opinions of others" doesn't make it better. > You post statements on the list with claims, and everybody, the silent WG members and the > dycard authors, have a right to hear the grounds for your argument. Otherwise, it is nothing > more than a simple, unproven claim which can easily be rejected. > > Thanks, > > Dirk > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 20:43:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11358 for ; Tue, 18 Mar 2003 20:43:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J20pc07369 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 21:00:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J20pO07366 for ; Tue, 18 Mar 2003 21:00:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11338 for ; Tue, 18 Mar 2003 20:43:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J20aO07356; Tue, 18 Mar 2003 21:00:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J1rOO07064 for ; Tue, 18 Mar 2003 20:53:24 -0500 Received: from web13102.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11184 for ; Tue, 18 Mar 2003 20:35:45 -0500 (EST) Message-ID: <20030319013759.26357.qmail@web13102.mail.yahoo.com> Received: from [128.107.253.39] by web13102.mail.yahoo.com via HTTP; Tue, 18 Mar 2003 17:37:59 PST Date: Tue, 18 Mar 2003 17:37:59 -0800 (PST) From: Liwen Wu To: seamoby@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1596599191-1048037879=:23744" Subject: [Seamoby] Question on the meeting schedule? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --0-1596599191-1048037879=:23744 Content-Type: text/plain; charset=us-ascii What's the scedule for SeaMoby WG? http://www.ietf.org/meetings/agenda_56.html indicates it is 1300-1500 on Thursday, whereas http://www.ietf.org/ietf/03mar/seamoby.txt indicates it is 1300-1500 on Wednesday. Will it be on one day? or on both days? thanks --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! --0-1596599191-1048037879=:23744 Content-Type: text/html; charset=us-ascii

What's the scedule for SeaMoby WG?

http://www.ietf.org/meetings/agenda_56.html indicates it is 1300-1500 on Thursday,
whereas http://www.ietf.org/ietf/03mar/seamoby.txt indicates it is 1300-1500 on Wednesday.

Will it be on one day? or on both days?

thanks


Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! --0-1596599191-1048037879=:23744-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 20:43:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11398 for ; Tue, 18 Mar 2003 20:43:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J20aO07356; Tue, 18 Mar 2003 21:00:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J1rOO07064 for ; Tue, 18 Mar 2003 20:53:24 -0500 Received: from web13102.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11184 for ; Tue, 18 Mar 2003 20:35:45 -0500 (EST) Message-ID: <20030319013759.26357.qmail@web13102.mail.yahoo.com> Received: from [128.107.253.39] by web13102.mail.yahoo.com via HTTP; Tue, 18 Mar 2003 17:37:59 PST Date: Tue, 18 Mar 2003 17:37:59 -0800 (PST) From: Liwen Wu To: seamoby@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1596599191-1048037879=:23744" Subject: [Seamoby] Question on the meeting schedule? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --0-1596599191-1048037879=:23744 Content-Type: text/plain; charset=us-ascii What's the scedule for SeaMoby WG? http://www.ietf.org/meetings/agenda_56.html indicates it is 1300-1500 on Thursday, whereas http://www.ietf.org/ietf/03mar/seamoby.txt indicates it is 1300-1500 on Wednesday. Will it be on one day? or on both days? thanks --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! --0-1596599191-1048037879=:23744 Content-Type: text/html; charset=us-ascii

What's the scedule for SeaMoby WG?

http://www.ietf.org/meetings/agenda_56.html indicates it is 1300-1500 on Thursday,
whereas http://www.ietf.org/ietf/03mar/seamoby.txt indicates it is 1300-1500 on Wednesday.

Will it be on one day? or on both days?

thanks


Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! --0-1596599191-1048037879=:23744-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 21:20:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12237 for ; Tue, 18 Mar 2003 21:20:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J2bOK10036 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 21:37:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2bOO10028 for ; Tue, 18 Mar 2003 21:37:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12226 for ; Tue, 18 Mar 2003 21:19:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2bBO09792; Tue, 18 Mar 2003 21:37:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2aXO09443 for ; Tue, 18 Mar 2003 21:36:33 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12166 for ; Tue, 18 Mar 2003 21:18:53 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Mar 2003 18:21:06 -0800 Subject: Re: [Seamoby] Question on the meeting schedule? From: Pat Calhoun To: Liwen Wu Cc: seamoby@ietf.org In-Reply-To: <20030319013759.26357.qmail@web13102.mail.yahoo.com> References: <20030319013759.26357.qmail@web13102.mail.yahoo.com> Content-Type: text/plain Message-Id: <1048040364.16724.125.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 18 Mar 2003 18:19:25 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2003 02:21:07.0111 (UTC) FILETIME=[32C49B70:01C2EDBE] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thursday patC On Tue, 2003-03-18 at 17:37, Liwen Wu wrote: > What's the scedule for SeaMoby WG? > > http://www.ietf.org/meetings/agenda_56.html indicates it is 1300-1500 > on Thursday, > whereas http://www.ietf.org/ietf/03mar/seamoby.txt indicates it is > 1300-1500 on Wednesday. > > Will it be on one day? or on both days? > > thanks > > > > ______________________________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 21:20:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12253 for ; Tue, 18 Mar 2003 21:20:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2bBO09792; Tue, 18 Mar 2003 21:37:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2aXO09443 for ; Tue, 18 Mar 2003 21:36:33 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12166 for ; Tue, 18 Mar 2003 21:18:53 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Mar 2003 18:21:06 -0800 Subject: Re: [Seamoby] Question on the meeting schedule? From: Pat Calhoun To: Liwen Wu Cc: seamoby@ietf.org In-Reply-To: <20030319013759.26357.qmail@web13102.mail.yahoo.com> References: <20030319013759.26357.qmail@web13102.mail.yahoo.com> Content-Type: text/plain Message-Id: <1048040364.16724.125.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 18 Mar 2003 18:19:25 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2003 02:21:07.0111 (UTC) FILETIME=[32C49B70:01C2EDBE] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thursday patC On Tue, 2003-03-18 at 17:37, Liwen Wu wrote: > What's the scedule for SeaMoby WG? > > http://www.ietf.org/meetings/agenda_56.html indicates it is 1300-1500 > on Thursday, > whereas http://www.ietf.org/ietf/03mar/seamoby.txt indicates it is > 1300-1500 on Wednesday. > > Will it be on one day? or on both days? > > thanks > > > > ______________________________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Mar 18 21:58:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13184 for ; Tue, 18 Mar 2003 21:58:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J3Fbu12757 for seamoby-archive@odin.ietf.org; Tue, 18 Mar 2003 22:15:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J3FbO12754 for ; Tue, 18 Mar 2003 22:15:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13175 for ; Tue, 18 Mar 2003 21:57:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J3FLO12744; Tue, 18 Mar 2003 22:15:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J3EOO12710 for ; Tue, 18 Mar 2003 22:14:24 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13156 for ; Tue, 18 Mar 2003 21:56:43 -0500 (EST) Message-ID: <005d01c2edc3$455fff40$a66015ac@T23KEMPF> From: "James Kempf" To: "Liwen Wu" , References: <20030319013759.26357.qmail@web13102.mail.yahoo.com> Subject: Re: [Seamoby] Question on the meeting schedule? Date: Tue, 18 Mar 2003 18:51:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Liwen Wu" To: Sent: Tuesday, March 18, 2003 5:37 PM Subject: [Seamoby] Question on the meeting schedule? > > What's the scedule for SeaMoby WG? > > http://www.ietf.org/meetings/agenda_56.html indicates it is 1300-1500 on Thursday, This is right. jak > whereas http://www.ietf.org/ietf/03mar/seamoby.txt indicates it is 1300-1500 on Wednesday. > > Will it be on one day? or on both days? > > thanks > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 18 21:58:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13197 for ; Tue, 18 Mar 2003 21:58:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J3FLO12744; Tue, 18 Mar 2003 22:15:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J3EOO12710 for ; Tue, 18 Mar 2003 22:14:24 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13156 for ; Tue, 18 Mar 2003 21:56:43 -0500 (EST) Message-ID: <005d01c2edc3$455fff40$a66015ac@T23KEMPF> From: "James Kempf" To: "Liwen Wu" , References: <20030319013759.26357.qmail@web13102.mail.yahoo.com> Subject: Re: [Seamoby] Question on the meeting schedule? Date: Tue, 18 Mar 2003 18:51:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Liwen Wu" To: Sent: Tuesday, March 18, 2003 5:37 PM Subject: [Seamoby] Question on the meeting schedule? > > What's the scedule for SeaMoby WG? > > http://www.ietf.org/meetings/agenda_56.html indicates it is 1300-1500 on Thursday, This is right. jak > whereas http://www.ietf.org/ietf/03mar/seamoby.txt indicates it is 1300-1500 on Wednesday. > > Will it be on one day? or on both days? > > thanks > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 19 12:51:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27736 for ; Wed, 19 Mar 2003 12:51:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JI8r116975 for seamoby-archive@odin.ietf.org; Wed, 19 Mar 2003 13:08:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JI8rO16972 for ; Wed, 19 Mar 2003 13:08:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27709 for ; Wed, 19 Mar 2003 12:50:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JI8ZO16912; Wed, 19 Mar 2003 13:08:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JI6BO15937 for ; Wed, 19 Mar 2003 13:06:11 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27589 for ; Wed, 19 Mar 2003 12:48:10 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2JHoRbM012452 for ; Wed, 19 Mar 2003 10:50:27 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA05490 for ; Wed, 19 Mar 2003 10:48:14 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 19 Mar 2003 11:50:25 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE87@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Pat Calhoun'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Wed, 19 Mar 2003 11:50:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Pat, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 6:24 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Ajoy, Instead of answer my fairly point blank questions, you appear to be defending CARD against Dycar. AJOY-> I agree this was not a good strategy. Sorry about this. Let's put aside dycar for a moment as my point is not to start a comparison war. Instead I want to look at the current CARD proposal and see if it can be simplified. AJOY-> Ok. We will be glad to simplify the DT draft based upon the WG feedback, I don't have the answers, all I have are questions. Regarding the one question I can answer: AJOY-> I did not follow this. If CARD function is extension of > AAA function then why we need SA between embedded device and > AAA server. exactly, if it's an extension to an AAA protocol, every AAA protocol that I know requires some form of security relationship in order to communicate in a secure fashion, either via shared secrets, or certs. So there's security configuration required regardless of the approach. AJOY-> I do agree the AR will require some SA with AAA server. But such security should be readily available when AAA is being used in access network. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 19 12:51:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27750 for ; Wed, 19 Mar 2003 12:51:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JI8ZO16912; Wed, 19 Mar 2003 13:08:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JI6BO15937 for ; Wed, 19 Mar 2003 13:06:11 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27589 for ; Wed, 19 Mar 2003 12:48:10 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2JHoRbM012452 for ; Wed, 19 Mar 2003 10:50:27 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA05490 for ; Wed, 19 Mar 2003 10:48:14 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 19 Mar 2003 11:50:25 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BE87@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Pat Calhoun'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Date: Wed, 19 Mar 2003 11:50:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello Pat, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, March 16, 2003 6:24 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) Ajoy, Instead of answer my fairly point blank questions, you appear to be defending CARD against Dycar. AJOY-> I agree this was not a good strategy. Sorry about this. Let's put aside dycar for a moment as my point is not to start a comparison war. Instead I want to look at the current CARD proposal and see if it can be simplified. AJOY-> Ok. We will be glad to simplify the DT draft based upon the WG feedback, I don't have the answers, all I have are questions. Regarding the one question I can answer: AJOY-> I did not follow this. If CARD function is extension of > AAA function then why we need SA between embedded device and > AAA server. exactly, if it's an extension to an AAA protocol, every AAA protocol that I know requires some form of security relationship in order to communicate in a secure fashion, either via shared secrets, or certs. So there's security configuration required regardless of the approach. AJOY-> I do agree the AR will require some SA with AAA server. But such security should be readily available when AAA is being used in access network. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 19 13:04:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28311 for ; Wed, 19 Mar 2003 13:04:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JIM7X17847 for seamoby-archive@odin.ietf.org; Wed, 19 Mar 2003 13:22:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JIM7O17844 for ; Wed, 19 Mar 2003 13:22:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28297 for ; Wed, 19 Mar 2003 13:04:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JILjO17793; Wed, 19 Mar 2003 13:21:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JIIeO17566 for ; Wed, 19 Mar 2003 13:18:40 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28195 for ; Wed, 19 Mar 2003 13:00:42 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Mar 2003 10:02:55 -0800 Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) From: Pat Calhoun To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0CD4BE87@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE87@IL27EXM10.cig.mot.com> Content-Type: text/plain Message-Id: <1048096539.18497.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 19 Mar 2003 09:55:39 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2003 18:02:55.0552 (UTC) FILETIME=[C46C6C00:01C2EE41] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Regarding the one question I can answer: > AJOY-> I did not follow this. If CARD function is extension of > > AAA function then why we need SA between embedded device and > > AAA server. > > exactly, if it's an extension to an AAA protocol, every AAA protocol that I > know requires some form of security relationship in order to communicate in > a secure fashion, either via shared secrets, or certs. So there's security > configuration required regardless of the approach. > > AJOY-> I do agree the AR will require some SA with AAA server. But such security > should be readily available when AAA is being used in access network. ok... fair enough. So my question to the WG is whether it is a reasonable assumption that everyone will deploy AAA servers for mobility. If so, maybe it's a safe assumption, but I'm not convinced. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 19 13:04:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28339 for ; Wed, 19 Mar 2003 13:04:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JILjO17793; Wed, 19 Mar 2003 13:21:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JIIeO17566 for ; Wed, 19 Mar 2003 13:18:40 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28195 for ; Wed, 19 Mar 2003 13:00:42 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Mar 2003 10:02:55 -0800 Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff) From: Pat Calhoun To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0CD4BE87@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE87@IL27EXM10.cig.mot.com> Content-Type: text/plain Message-Id: <1048096539.18497.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 19 Mar 2003 09:55:39 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2003 18:02:55.0552 (UTC) FILETIME=[C46C6C00:01C2EE41] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Regarding the one question I can answer: > AJOY-> I did not follow this. If CARD function is extension of > > AAA function then why we need SA between embedded device and > > AAA server. > > exactly, if it's an extension to an AAA protocol, every AAA protocol that I > know requires some form of security relationship in order to communicate in > a secure fashion, either via shared secrets, or certs. So there's security > configuration required regardless of the approach. > > AJOY-> I do agree the AR will require some SA with AAA server. But such security > should be readily available when AAA is being used in access network. ok... fair enough. So my question to the WG is whether it is a reasonable assumption that everyone will deploy AAA servers for mobility. If so, maybe it's a safe assumption, but I'm not convinced. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 19 13:44:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00233 for ; Wed, 19 Mar 2003 13:44:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JJ2KR21750 for seamoby-archive@odin.ietf.org; Wed, 19 Mar 2003 14:02:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJ2JO21747 for ; Wed, 19 Mar 2003 14:02:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00204 for ; Wed, 19 Mar 2003 13:44:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJ26O21709; Wed, 19 Mar 2003 14:02:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJ1GO21629 for ; Wed, 19 Mar 2003 14:01:16 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00142 for ; Wed, 19 Mar 2003 13:43:16 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2JIjQCx061623; Wed, 19 Mar 2003 19:45:26 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2JIkx4J082867; Wed, 19 Mar 2003 18:47:04 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E78C860.C1853267@ccrle.nec.de> Date: Wed, 19 Mar 2003 20:43:28 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stuff) References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE87@IL27EXM10.cig.mot.com> <1048096539.18497.12.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just a brief comment on this. It's only one proposal to put the server-function on a server for AAA, assuming SAs to ARs are implicit. Now, alternatively, the server-function for CARD could be put on another node/server (not as extension to AAA function), which has either a SA with ARs, or SA is to be established, which should be provided any means for within a domain anyway. marco Pat Calhoun wrote: > > Regarding the one question I can answer: > > AJOY-> I did not follow this. If CARD function is extension of > > > AAA function then why we need SA between embedded device and > > > AAA server. > > > > exactly, if it's an extension to an AAA protocol, every AAA protocol that I > > know requires some form of security relationship in order to communicate in > > a secure fashion, either via shared secrets, or certs. So there's security > > configuration required regardless of the approach. > > > > AJOY-> I do agree the AR will require some SA with AAA server. But such security > > should be readily available when AAA is being used in access network. > > ok... fair enough. So my question to the WG is whether it is a > reasonable assumption that everyone will deploy AAA servers for > mobility. If so, maybe it's a safe assumption, but I'm not convinced. > > PatC > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 19 13:45:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00276 for ; Wed, 19 Mar 2003 13:45:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJ26O21709; Wed, 19 Mar 2003 14:02:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJ1GO21629 for ; Wed, 19 Mar 2003 14:01:16 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00142 for ; Wed, 19 Mar 2003 13:43:16 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2JIjQCx061623; Wed, 19 Mar 2003 19:45:26 +0100 (CET) Received: from ccrle.nec.de (wl-130-215.wireless.ietf56.ietf.org [130.129.130.215]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2JIkx4J082867; Wed, 19 Mar 2003 18:47:04 GMT (envelope-from marco.liebsch@ccrle.nec.de) Message-ID: <3E78C860.C1853267@ccrle.nec.de> Date: Wed, 19 Mar 2003 20:43:28 +0100 From: Liebsch Organization: NEC Network Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Singh Ajoy-ASINGH1 , seamoby@ietf.org Subject: Re: [Seamoby] My thoughts on server approaches (and other fun stuff) References: <35DBB8B7AC89D4118E98009027B1009B0CD4BE87@IL27EXM10.cig.mot.com> <1048096539.18497.12.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just a brief comment on this. It's only one proposal to put the server-function on a server for AAA, assuming SAs to ARs are implicit. Now, alternatively, the server-function for CARD could be put on another node/server (not as extension to AAA function), which has either a SA with ARs, or SA is to be established, which should be provided any means for within a domain anyway. marco Pat Calhoun wrote: > > Regarding the one question I can answer: > > AJOY-> I did not follow this. If CARD function is extension of > > > AAA function then why we need SA between embedded device and > > > AAA server. > > > > exactly, if it's an extension to an AAA protocol, every AAA protocol that I > > know requires some form of security relationship in order to communicate in > > a secure fashion, either via shared secrets, or certs. So there's security > > configuration required regardless of the approach. > > > > AJOY-> I do agree the AR will require some SA with AAA server. But such security > > should be readily available when AAA is being used in access network. > > ok... fair enough. So my question to the WG is whether it is a > reasonable assumption that everyone will deploy AAA servers for > mobility. If so, maybe it's a safe assumption, but I'm not convinced. > > PatC > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 19 16:47:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10762 for ; Wed, 19 Mar 2003 16:47:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JM4bJ10324 for seamoby-archive@odin.ietf.org; Wed, 19 Mar 2003 17:04:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM4bO10321 for ; Wed, 19 Mar 2003 17:04:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10720 for ; Wed, 19 Mar 2003 16:46:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM4JO10278; Wed, 19 Mar 2003 17:04:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM3PO10202 for ; Wed, 19 Mar 2003 17:03:25 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10669 for ; Wed, 19 Mar 2003 16:45:20 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JLpDu16273 for ; Wed, 19 Mar 2003 23:51:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 23:47:38 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 23:47:34 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 13:47:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stuff) Date: Wed, 19 Mar 2003 16:47:27 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stuff) Thread-Index: AcLuQj/xfwc1BQ6KTNiR6tGiRds1tQAHQEIg To: , Cc: X-OriginalArrivalTime: 19 Mar 2003 21:47:28.0695 (UTC) FILETIME=[230AE470:01C2EE61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2JM3PO10203 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi: CARD server is logical entity (a piece of software and IANA assigned UDP number) which can be put on any box. Security mechanism for AR-server exchange can be of operator's choice, e.g., if this box has IPSec stack and ARs have IPSec stack and they have configured credentials (passwords) it can use IPSec. In summary, I too am not convinced about tying CARD to AAA. I also don't get the argument that AAA servers make security readily available. If someone has an enterprise network that does not use AAA (Diameter server to be precise), but has Kerberos, for this person security is readily available in the form of Kerberos rather than Diameter. Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Wednesday, March 19, 2003 12:56 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stuff) > Regarding the one question I can answer: > AJOY-> I did not follow this. If CARD function is extension of > > AAA function then why we need SA between embedded device and > > AAA server. > > exactly, if it's an extension to an AAA protocol, every AAA protocol that I > know requires some form of security relationship in order to communicate in > a secure fashion, either via shared secrets, or certs. So there's security > configuration required regardless of the approach. > > AJOY-> I do agree the AR will require some SA with AAA server. But such security > should be readily available when AAA is being used in access network. ok... fair enough. So my question to the WG is whether it is a reasonable assumption that everyone will deploy AAA servers for mobility. If so, maybe it's a safe assumption, but I'm not convinced. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 19 16:47:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10789 for ; Wed, 19 Mar 2003 16:47:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM4JO10278; Wed, 19 Mar 2003 17:04:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM3PO10202 for ; Wed, 19 Mar 2003 17:03:25 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10669 for ; Wed, 19 Mar 2003 16:45:20 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JLpDu16273 for ; Wed, 19 Mar 2003 23:51:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 23:47:38 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 23:47:34 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 13:47:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stuff) Date: Wed, 19 Mar 2003 16:47:27 -0500 Message-ID: Thread-Topic: [Seamoby] My thoughts on server approaches (and other fun stuff) Thread-Index: AcLuQj/xfwc1BQ6KTNiR6tGiRds1tQAHQEIg To: , Cc: X-OriginalArrivalTime: 19 Mar 2003 21:47:28.0695 (UTC) FILETIME=[230AE470:01C2EE61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2JM3PO10203 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi: CARD server is logical entity (a piece of software and IANA assigned UDP number) which can be put on any box. Security mechanism for AR-server exchange can be of operator's choice, e.g., if this box has IPSec stack and ARs have IPSec stack and they have configured credentials (passwords) it can use IPSec. In summary, I too am not convinced about tying CARD to AAA. I also don't get the argument that AAA servers make security readily available. If someone has an enterprise network that does not use AAA (Diameter server to be precise), but has Kerberos, for this person security is readily available in the form of Kerberos rather than Diameter. Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Wednesday, March 19, 2003 12:56 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stuff) > Regarding the one question I can answer: > AJOY-> I did not follow this. If CARD function is extension of > > AAA function then why we need SA between embedded device and > > AAA server. > > exactly, if it's an extension to an AAA protocol, every AAA protocol that I > know requires some form of security relationship in order to communicate in > a secure fashion, either via shared secrets, or certs. So there's security > configuration required regardless of the approach. > > AJOY-> I do agree the AR will require some SA with AAA server. But such security > should be readily available when AAA is being used in access network. ok... fair enough. So my question to the WG is whether it is a reasonable assumption that everyone will deploy AAA servers for mobility. If so, maybe it's a safe assumption, but I'm not convinced. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 19 19:16:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17290 for ; Wed, 19 Mar 2003 19:16:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K0YYF22591 for seamoby-archive@odin.ietf.org; Wed, 19 Mar 2003 19:34:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0YYO22588 for ; Wed, 19 Mar 2003 19:34:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17284 for ; Wed, 19 Mar 2003 19:16:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0YHO22541; Wed, 19 Mar 2003 19:34:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0XFO22477 for ; Wed, 19 Mar 2003 19:33:15 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17263 for ; Wed, 19 Mar 2003 19:15:07 -0500 (EST) 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 QAA18435 for ; Wed, 19 Mar 2003 16:17:20 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2K0HJI01317 for ; Wed, 19 Mar 2003 16:17:19 -0800 X-mProtect: <200303200017> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.54.241, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdg0FFx8; Wed, 19 Mar 2003 16:17:17 PST Message-ID: <3E79088C.2010701@iprg.nokia.com> Date: Wed, 19 Mar 2003 16:17:16 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Dos Attack and rate limiting Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit you can also do rate limiting based on the MAC address of the MN. not too difficult to implement it. every known protocol suffers from DoS attacks, where there are numerous requests sent in a very short time. rate limiting is the only well known mechanism for handling it. Vijay ps: a lot of times, the DoS attack through numberous requests is not significant attack unless it creates some state at the node receiving the request. Govind.Krishnamurthi@nokia.com wrote: > Jim, > > >>Eunsoo, >> >>Now, that's not fair. You and Govind are claiming a DoS >>attack on the DT draft >>because the MN can make up its address. > > > [Govind] I can't speak for Eunsoo, but since my name is mentioned > here, I will respond. You have got my intention wrong here. > > It can do that with > >>Dycard too. > > > [Govind] I did not say that dycard is inherently immune to such > DoS attacks and we don't need to take care of it. > I never said that MNs cannot send in a slew of packets to the AR. > I also agreed that processing load is a concern anywhere. I just pointed > out that we have considered these attacks and are taking (and have taken) steps > to minimize the effect of these attacks. > > Whether > >>the server is involved or not is immaterial. A stream of >>packets bombarding the >>router will tie up the router regardless. > > > [Govind] I don't think anyone prevent this, the best we can do is silently > discard packets at the AR. > > >>What is to prevent a random MN from making up IP addresses >>and sending Dycard >>messages to the AR? The router needs to check the >>authentication, but that >>doesn't happen until the packet is at the router, and >>meantime, the router is >>tied up in authentication checking. > > > [Govind] Noone can prevent the MN from doing that. However, the protocol > can control what the router does on receiving the packets. > Spoofing IP addresses by MNs may not be too difficult to handle for dycard as > there are additional checks. But I'll think about this. > Ofcourse, there is processing needed to make these checks before silently > discarding the packets. > > >>My point is that CARD (regardless of the approach) needs to >>specify rate >>limiting for the MN to AR messages, and that the AR can >>selectively drop packets >>so that it can limit such an attack. > > > [Govind] I have no disagreement about this. Rate limiting is needed in both > approaches. The very fact that we say that dycard handles this in some way is > accepting the fact that this is to be handled. > The only point that is not clear to me, is that once a MN does > send multiple RI messages it is clearly a malicious MN, and you can > silently discard the packets from this MN after uniquely identifying this MN. > Hopefully, with the inbuilt checks dycard will be able to identify such MNs. > > However, a MN that supplies multiple APid messages is not necessarily > a malicious MN. One cannot have control on how many APids spring up in an AR's neighborhood that are not in the same domain. > Rate-limiting without taking this into consideration may not be the right approach, IMO. > > Thanks, > Govind. > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 19 19:17:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17313 for ; Wed, 19 Mar 2003 19:17:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0YHO22541; Wed, 19 Mar 2003 19:34:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0XFO22477 for ; Wed, 19 Mar 2003 19:33:15 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17263 for ; Wed, 19 Mar 2003 19:15:07 -0500 (EST) 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 QAA18435 for ; Wed, 19 Mar 2003 16:17:20 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2K0HJI01317 for ; Wed, 19 Mar 2003 16:17:19 -0800 X-mProtect: <200303200017> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.54.241, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdg0FFx8; Wed, 19 Mar 2003 16:17:17 PST Message-ID: <3E79088C.2010701@iprg.nokia.com> Date: Wed, 19 Mar 2003 16:17:16 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Dos Attack and rate limiting Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit you can also do rate limiting based on the MAC address of the MN. not too difficult to implement it. every known protocol suffers from DoS attacks, where there are numerous requests sent in a very short time. rate limiting is the only well known mechanism for handling it. Vijay ps: a lot of times, the DoS attack through numberous requests is not significant attack unless it creates some state at the node receiving the request. Govind.Krishnamurthi@nokia.com wrote: > Jim, > > >>Eunsoo, >> >>Now, that's not fair. You and Govind are claiming a DoS >>attack on the DT draft >>because the MN can make up its address. > > > [Govind] I can't speak for Eunsoo, but since my name is mentioned > here, I will respond. You have got my intention wrong here. > > It can do that with > >>Dycard too. > > > [Govind] I did not say that dycard is inherently immune to such > DoS attacks and we don't need to take care of it. > I never said that MNs cannot send in a slew of packets to the AR. > I also agreed that processing load is a concern anywhere. I just pointed > out that we have considered these attacks and are taking (and have taken) steps > to minimize the effect of these attacks. > > Whether > >>the server is involved or not is immaterial. A stream of >>packets bombarding the >>router will tie up the router regardless. > > > [Govind] I don't think anyone prevent this, the best we can do is silently > discard packets at the AR. > > >>What is to prevent a random MN from making up IP addresses >>and sending Dycard >>messages to the AR? The router needs to check the >>authentication, but that >>doesn't happen until the packet is at the router, and >>meantime, the router is >>tied up in authentication checking. > > > [Govind] Noone can prevent the MN from doing that. However, the protocol > can control what the router does on receiving the packets. > Spoofing IP addresses by MNs may not be too difficult to handle for dycard as > there are additional checks. But I'll think about this. > Ofcourse, there is processing needed to make these checks before silently > discarding the packets. > > >>My point is that CARD (regardless of the approach) needs to >>specify rate >>limiting for the MN to AR messages, and that the AR can >>selectively drop packets >>so that it can limit such an attack. > > > [Govind] I have no disagreement about this. Rate limiting is needed in both > approaches. The very fact that we say that dycard handles this in some way is > accepting the fact that this is to be handled. > The only point that is not clear to me, is that once a MN does > send multiple RI messages it is clearly a malicious MN, and you can > silently discard the packets from this MN after uniquely identifying this MN. > Hopefully, with the inbuilt checks dycard will be able to identify such MNs. > > However, a MN that supplies multiple APid messages is not necessarily > a malicious MN. One cannot have control on how many APids spring up in an AR's neighborhood that are not in the same domain. > Rate-limiting without taking this into consideration may not be the right approach, IMO. > > Thanks, > Govind. > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 19 19:17:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17344 for ; Wed, 19 Mar 2003 19:17:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K0ZDc22660 for seamoby-archive@odin.ietf.org; Wed, 19 Mar 2003 19:35:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0ZDO22657 for ; Wed, 19 Mar 2003 19:35:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17310 for ; Wed, 19 Mar 2003 19:17:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0Z2O22643; Wed, 19 Mar 2003 19:35:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0YFO22533 for ; Wed, 19 Mar 2003 19:34:15 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17274 for ; Wed, 19 Mar 2003 19:16:09 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Mar 2003 16:18:23 -0800 Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stuff) From: Pat Calhoun To: Hemant.Chaskar@nokia.com Cc: ASINGH1@motorola.com, seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1048119066.18497.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 19 Mar 2003 16:11:06 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2003 00:18:23.0236 (UTC) FILETIME=[37F83440:01C2EE76] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > In summary, I too am not convinced about tying CARD to AAA. I also > don't get the argument that AAA servers make security readily > available. If someone has an enterprise network that does not use AAA > (Diameter server to be precise), but has Kerberos, for this person > security is readily available in the form of Kerberos rather than > Diameter. > This is my point. Security is mandatory, of course, but I really don't understand why it has to be a separate physical entity. It complicates deployments, and doesn't allow one to build a single box solution. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 19 19:17:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17361 for ; Wed, 19 Mar 2003 19:17:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0Z2O22643; Wed, 19 Mar 2003 19:35:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0YFO22533 for ; Wed, 19 Mar 2003 19:34:15 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17274 for ; Wed, 19 Mar 2003 19:16:09 -0500 (EST) Received: from [172.16.8.102] ([172.16.8.102]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Mar 2003 16:18:23 -0800 Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stuff) From: Pat Calhoun To: Hemant.Chaskar@nokia.com Cc: ASINGH1@motorola.com, seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1048119066.18497.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 19 Mar 2003 16:11:06 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2003 00:18:23.0236 (UTC) FILETIME=[37F83440:01C2EE76] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In summary, I too am not convinced about tying CARD to AAA. I also > don't get the argument that AAA servers make security readily > available. If someone has an enterprise network that does not use AAA > (Diameter server to be precise), but has Kerberos, for this person > security is readily available in the form of Kerberos rather than > Diameter. > This is my point. Security is mandatory, of course, but I really don't understand why it has to be a separate physical entity. It complicates deployments, and doesn't allow one to build a single box solution. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Mar 19 22:37:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22486 for ; Wed, 19 Mar 2003 22:37:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K3tbN03798 for seamoby-archive@odin.ietf.org; Wed, 19 Mar 2003 22:55:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K3tbO03795 for ; Wed, 19 Mar 2003 22:55:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22474 for ; Wed, 19 Mar 2003 22:37:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K3tOO03779; Wed, 19 Mar 2003 22:55:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K3s8O03737 for ; Wed, 19 Mar 2003 22:54:08 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22463 for ; Wed, 19 Mar 2003 22:35:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Mar 2003 19:38:11 -0800 Received: from 63.78.179.4 by by2fd.bay2.hotmail.msn.com with HTTP; Thu, 20 Mar 2003 03:38:11 GMT X-Originating-IP: [63.78.179.4] X-Originating-Email: [hchaskar@hotmail.com] From: "Hemant Chaskar" To: vijayd@iprg.nokia.com, seamoby@ietf.org Subject: Re: [Seamoby] Dos Attack and rate limiting Date: Thu, 20 Mar 2003 03:38:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Mar 2003 03:38:11.0975 (UTC) FILETIME=[21D09970:01C2EE92] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Vijay: A situation where MN is connected to AR by L2-bridge, this may not be possible. Also, in GPRS for example, L2 adr is aka GTP tunnel number. To do the above, there needs to be communication between GTP layer and IP layer. Hemant >From: Vijay Devarapalli >To: seamoby@ietf.org >Subject: [Seamoby] Dos Attack and rate limiting >Date: Wed, 19 Mar 2003 16:17:16 -0800 > >you can also do rate limiting based on the MAC address of the >MN. not too difficult to implement it. > >every known protocol suffers from DoS attacks, where there are >numerous requests sent in a very short time. rate limiting is >the only well known mechanism for handling it. > >Vijay > >ps: a lot of times, the DoS attack through numberous requests >is not significant attack unless it creates some state at the >node receiving the request. > > >Govind.Krishnamurthi@nokia.com wrote: >>Jim, >> >> >>>Eunsoo, >>> >>>Now, that's not fair. You and Govind are claiming a DoS attack on the DT >>>draft >>>because the MN can make up its address. >> >> >>[Govind] I can't speak for Eunsoo, but since my name is mentioned >>here, I will respond. You have got my intention wrong here. >> >>It can do that with >> >>>Dycard too. >> >> [Govind] I did not say that dycard is inherently immune to such >>DoS attacks and we don't need to take care of it. I never said that MNs >>cannot send in a slew of packets to the AR. >>I also agreed that processing load is a concern anywhere. I just pointed >>out that we have considered these attacks and are taking (and have taken) >>steps to minimize the effect of these attacks. >> >>Whether >> >>>the server is involved or not is immaterial. A stream of packets >>>bombarding the >>>router will tie up the router regardless. >> >> >>[Govind] I don't think anyone prevent this, the best we can do is silently >>discard packets at the AR. >> >> >>>What is to prevent a random MN from making up IP addresses and sending >>>Dycard >>>messages to the AR? The router needs to check the authentication, but >>>that >>>doesn't happen until the packet is at the router, and meantime, the >>>router is >>>tied up in authentication checking. >> >> >>[Govind] Noone can prevent the MN from doing that. However, the protocol >>can control what the router does on receiving the packets. Spoofing IP >>addresses by MNs may not be too difficult to handle for dycard as there >>are additional checks. But I'll think about this. Ofcourse, there is >>processing needed to make these checks before silently discarding the >>packets. >> >> >>>My point is that CARD (regardless of the approach) needs to specify rate >>>limiting for the MN to AR messages, and that the AR can selectively drop >>>packets >>>so that it can limit such an attack. >> >> >>[Govind] I have no disagreement about this. Rate limiting is needed in >>both >>approaches. The very fact that we say that dycard handles this in some way >>is >>accepting the fact that this is to be handled. The only point that is not >>clear to me, is that once a MN does send multiple RI messages it is >>clearly a malicious MN, and you can >>silently discard the packets from this MN after uniquely identifying this >>MN. Hopefully, with the inbuilt checks dycard will be able to identify >>such MNs. >> >>However, a MN that supplies multiple APid messages is not necessarily a >>malicious MN. One cannot have control on how many APids spring up in an >>AR's neighborhood that are not in the same domain. >> Rate-limiting without taking this into consideration may not be the >>right approach, IMO. >> >>Thanks, >>Govind. >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 19 22:38:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22502 for ; Wed, 19 Mar 2003 22:38:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K3tOO03779; Wed, 19 Mar 2003 22:55:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K3s8O03737 for ; Wed, 19 Mar 2003 22:54:08 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22463 for ; Wed, 19 Mar 2003 22:35:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Mar 2003 19:38:11 -0800 Received: from 63.78.179.4 by by2fd.bay2.hotmail.msn.com with HTTP; Thu, 20 Mar 2003 03:38:11 GMT X-Originating-IP: [63.78.179.4] X-Originating-Email: [hchaskar@hotmail.com] From: "Hemant Chaskar" To: vijayd@iprg.nokia.com, seamoby@ietf.org Subject: Re: [Seamoby] Dos Attack and rate limiting Date: Thu, 20 Mar 2003 03:38:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Mar 2003 03:38:11.0975 (UTC) FILETIME=[21D09970:01C2EE92] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Vijay: A situation where MN is connected to AR by L2-bridge, this may not be possible. Also, in GPRS for example, L2 adr is aka GTP tunnel number. To do the above, there needs to be communication between GTP layer and IP layer. Hemant >From: Vijay Devarapalli >To: seamoby@ietf.org >Subject: [Seamoby] Dos Attack and rate limiting >Date: Wed, 19 Mar 2003 16:17:16 -0800 > >you can also do rate limiting based on the MAC address of the >MN. not too difficult to implement it. > >every known protocol suffers from DoS attacks, where there are >numerous requests sent in a very short time. rate limiting is >the only well known mechanism for handling it. > >Vijay > >ps: a lot of times, the DoS attack through numberous requests >is not significant attack unless it creates some state at the >node receiving the request. > > >Govind.Krishnamurthi@nokia.com wrote: >>Jim, >> >> >>>Eunsoo, >>> >>>Now, that's not fair. You and Govind are claiming a DoS attack on the DT >>>draft >>>because the MN can make up its address. >> >> >>[Govind] I can't speak for Eunsoo, but since my name is mentioned >>here, I will respond. You have got my intention wrong here. >> >>It can do that with >> >>>Dycard too. >> >> [Govind] I did not say that dycard is inherently immune to such >>DoS attacks and we don't need to take care of it. I never said that MNs >>cannot send in a slew of packets to the AR. >>I also agreed that processing load is a concern anywhere. I just pointed >>out that we have considered these attacks and are taking (and have taken) >>steps to minimize the effect of these attacks. >> >>Whether >> >>>the server is involved or not is immaterial. A stream of packets >>>bombarding the >>>router will tie up the router regardless. >> >> >>[Govind] I don't think anyone prevent this, the best we can do is silently >>discard packets at the AR. >> >> >>>What is to prevent a random MN from making up IP addresses and sending >>>Dycard >>>messages to the AR? The router needs to check the authentication, but >>>that >>>doesn't happen until the packet is at the router, and meantime, the >>>router is >>>tied up in authentication checking. >> >> >>[Govind] Noone can prevent the MN from doing that. However, the protocol >>can control what the router does on receiving the packets. Spoofing IP >>addresses by MNs may not be too difficult to handle for dycard as there >>are additional checks. But I'll think about this. Ofcourse, there is >>processing needed to make these checks before silently discarding the >>packets. >> >> >>>My point is that CARD (regardless of the approach) needs to specify rate >>>limiting for the MN to AR messages, and that the AR can selectively drop >>>packets >>>so that it can limit such an attack. >> >> >>[Govind] I have no disagreement about this. Rate limiting is needed in >>both >>approaches. The very fact that we say that dycard handles this in some way >>is >>accepting the fact that this is to be handled. The only point that is not >>clear to me, is that once a MN does send multiple RI messages it is >>clearly a malicious MN, and you can >>silently discard the packets from this MN after uniquely identifying this >>MN. Hopefully, with the inbuilt checks dycard will be able to identify >>such MNs. >> >>However, a MN that supplies multiple APid messages is not necessarily a >>malicious MN. One cannot have control on how many APids spring up in an >>AR's neighborhood that are not in the same domain. >> Rate-limiting without taking this into consideration may not be the >>right approach, IMO. >> >>Thanks, >>Govind. >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 20 20:17:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17134 for ; Thu, 20 Mar 2003 20:17:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L1ZfV15393 for seamoby-archive@odin.ietf.org; Thu, 20 Mar 2003 20:35:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L1ZfO15390 for ; Thu, 20 Mar 2003 20:35:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17127 for ; Thu, 20 Mar 2003 20:17:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L1ZSO15380; Thu, 20 Mar 2003 20:35:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L1VKO15270 for ; Thu, 20 Mar 2003 20:31:20 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16980 for ; Thu, 20 Mar 2003 20:12:42 -0500 (EST) Message-ID: <020101c2ef47$13a25f40$456015ac@T23KEMPF> From: "James Kempf" To: Cc: Date: Thu, 20 Mar 2003 17:13:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Proposal for CARD Information Algorithm Work Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Sorry for the cross posting, but it concerns both lists) Here's a more precisely worded suggestion for addition to the MIP IRTF group charter: The research group will also examine algorithms for automatic configuration of access routers with information of use to Mobile Nodes during fast handover. The Seamoby Working group is developing an Experimental protocol to distribute such information between routers and between the router and Mobile Node (Candidate Access Router Discovery, CARD), but the actual algorithms for determining whether a particular access point, seen by a Mobile Node and reported to the access router, is within range of a handover from the router is not in scope. Neither is determining whether a particular access point is authorized to provide service and therefore a candidate for handover. These topics will be material for the research group. The goal of the research is to characterize the currently proposed approaches (learning based or server based) and any other approaches, and determine under which conditions a particular algorithm is a superior solution. These results will be returned to the IETF if and when standardization of CARD is requested. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 20 20:17:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17147 for ; Thu, 20 Mar 2003 20:17:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L1ZSO15380; Thu, 20 Mar 2003 20:35:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L1VKO15270 for ; Thu, 20 Mar 2003 20:31:20 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16980 for ; Thu, 20 Mar 2003 20:12:42 -0500 (EST) Message-ID: <020101c2ef47$13a25f40$456015ac@T23KEMPF> From: "James Kempf" To: Cc: Date: Thu, 20 Mar 2003 17:13:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Proposal for CARD Information Algorithm Work Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit (Sorry for the cross posting, but it concerns both lists) Here's a more precisely worded suggestion for addition to the MIP IRTF group charter: The research group will also examine algorithms for automatic configuration of access routers with information of use to Mobile Nodes during fast handover. The Seamoby Working group is developing an Experimental protocol to distribute such information between routers and between the router and Mobile Node (Candidate Access Router Discovery, CARD), but the actual algorithms for determining whether a particular access point, seen by a Mobile Node and reported to the access router, is within range of a handover from the router is not in scope. Neither is determining whether a particular access point is authorized to provide service and therefore a candidate for handover. These topics will be material for the research group. The goal of the research is to characterize the currently proposed approaches (learning based or server based) and any other approaches, and determine under which conditions a particular algorithm is a superior solution. These results will be returned to the IETF if and when standardization of CARD is requested. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 03:55:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07959 for ; Fri, 21 Mar 2003 03:55:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L9DLv21689 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 04:13:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L9DKO21686 for ; Fri, 21 Mar 2003 04:13:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07955 for ; Fri, 21 Mar 2003 03:54:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L9BUO21617; Fri, 21 Mar 2003 04:11:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L9AgO21569 for ; Fri, 21 Mar 2003 04:10:42 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07926 for ; Fri, 21 Mar 2003 03:51:56 -0500 (EST) Date: Fri, 21 Mar 2003 00:54:23 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CT and access routers Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Regarding one of my comments today at the meeting: The context transfer draft only talks about "access routers." Readers get the impression that its applicability is limited to performing context transfer between routers and nothing more. I'm not sure if the protocol design limits itself to routers, but I don't see any reason why it could not be applied to other access network entities, such as access points, home agents, PANA authentication agents as long as they are IP capable. But I don't know, I might be missing something. My recommendation to the authors is to include either one of these texts in the draft: This protocol's applicability is limited to access routers, and using it with other access network entities such as home agents, access points, and authentication agents is outside the scope. Or: Although this protocol is initially designed for transfering context between access routers, it can also be applied to other access network entities such as home agents, access points, and authentication agents. Context information can be transfered from these entities to their peers in the destination network of a mobile node. (feel free to reword as needed) Is there any other possibility? If not, explicitly stating this in the specification will help people understand where to use this protocol, and where not to use it. Cheers, alper _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 03:55:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07972 for ; Fri, 21 Mar 2003 03:55:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L9BUO21617; Fri, 21 Mar 2003 04:11:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L9AgO21569 for ; Fri, 21 Mar 2003 04:10:42 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07926 for ; Fri, 21 Mar 2003 03:51:56 -0500 (EST) Date: Fri, 21 Mar 2003 00:54:23 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CT and access routers Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Regarding one of my comments today at the meeting: The context transfer draft only talks about "access routers." Readers get the impression that its applicability is limited to performing context transfer between routers and nothing more. I'm not sure if the protocol design limits itself to routers, but I don't see any reason why it could not be applied to other access network entities, such as access points, home agents, PANA authentication agents as long as they are IP capable. But I don't know, I might be missing something. My recommendation to the authors is to include either one of these texts in the draft: This protocol's applicability is limited to access routers, and using it with other access network entities such as home agents, access points, and authentication agents is outside the scope. Or: Although this protocol is initially designed for transfering context between access routers, it can also be applied to other access network entities such as home agents, access points, and authentication agents. Context information can be transfered from these entities to their peers in the destination network of a mobile node. (feel free to reword as needed) Is there any other possibility? If not, explicitly stating this in the specification will help people understand where to use this protocol, and where not to use it. Cheers, alper _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 10:45:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17276 for ; Fri, 21 Mar 2003 10:45:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LG3jO14083 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 11:03:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LG3jO14080 for ; Fri, 21 Mar 2003 11:03:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17243 for ; Fri, 21 Mar 2003 10:44:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LG3NO14072; Fri, 21 Mar 2003 11:03:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LG0aO13990 for ; Fri, 21 Mar 2003 11:00:36 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17205 for ; Fri, 21 Mar 2003 10:41:39 -0500 (EST) Message-ID: <005301c2efc0$777fd1e0$8b6015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 21 Mar 2003 07:42:21 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0050_01C2EF7D.6847ED90" Subject: [Seamoby] Minutes for IETF 56 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C2EF7D.6847ED90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached. Please send comments by next Tues. jak ------=_NextPart_000_0050_01C2EF7D.6847ED90 Content-Type: text/plain; name="seamobyMeetingMinutes.txt" Content-Disposition: attachment; filename="seamobyMeetingMinutes.txt" Content-Transfer-Encoding: quoted-printable Seamoby, Mar, 20, 2003 *Draft Status JK :=20 mobility terminology draft will be sent to iesg soon to be published as = informational, maybe 2 wks context transfer problem statemnet done -> RFC3374 Alper : what happens if someone wants to add to mobility terminalogy ? JK : this should be refered for general terminalogy, specific items = should be in specific WG drafts JK : carddiscover, ct-reqs are in AD evaluation, awaiting comments JK : car requirements comments -> doesn't align well with security = comments (Allision) JK : card protocol, ctp protocol will be discussed JK : as John is not here start with Ajoy * CARD protocol Ajoy : description of CARD protocol proposal on 2 operation modes to keep design flexibility server based CARD protocol - Network assisted mode MN orchestrated CARD most of discussion so far on ML has been server based solution but that = is not the only important issue WG issues=20 issue 1 : support of AP authorization at AR AP authorization is not supported in the current draft does this belong to scope of the CARD protocol PC : do we care about interoperability btw APs and ARs. AS : don't think that is in Seamoby scope difficult to authorize whether the AP is authorized or not PC : but do we care about interoperability ?=20 AS : no issue 2 : do we need server or not ?=20 characteristisc os server based approach=20 able to provide seamless handoff even if CAR info is not avaiable in = current AR cache server provides built in authorization function by using scope -id -> = inbuilt authorization (sort of) introduces single point of failure this can be solved by integrating = with AAA server Alper : don't understand how AAA server helps ? AS : we don't introduce extra points of failure if we add this to AAA = server as AAA server is already is there Alper : only looks like moving problem to another place, making a bigger = single point of failure, doesn't solve the basic problems, JK : as a general point it is a single point of failujre JL : it is a process running on a server, processes are able to die = independently issue 2 : handover base approach - no server required - seamless ho not possible until AR cache is populated - AR cache is only updated when MN performs active L3 handoff - additional protocol complexity for validating=20 PC : you are assuming dormant HO is more common than active HO, so don't = think this is true JK : depends on how you implement it, but don't see any dormant HO which = cannot do L3 HO signaling HS : where is the source of information that most handoffs is mostly = dormant : AS : from current voice network HS : please send link=20 issue 3 : DoS - possible to minimize by rate limiting the number of AR server requests = as well as MN-AR requests issue 4 : cache contamination issue AS : by properly using scope id it is possible to solve this problem need configuration, algorithm etc. JL : just as a point of suggestion, IPv6 group has realized that scoping = is an impossible problem, NSIS has also been told to not do scoping, so I suggest don't do any = scoping unless you have a real workable solutions Coven : If you can push everything down to AR at boot type won't it work = ?=20 Mark ? : Scoping is only to make sure cache contamination not be done .. JL : that's what site local tried and showed can't be done issue 5 : piggybacking CARD options - piggyback CARD onto FMIPv6 messages=20 - do we need to have some text to clarify - do we need to restrict piggybacking to FMIPv6 or should it be also = with RS / RA ? - "P" bit is used to discover the piggybacking capability of the CARD = communications peers Alper : I assume that your saying adding more info to RS / RA ? Why = change FMIPv6 spec ? Just add options to RA / RS ? AS : if we want CARD to be used, I think it should be tied with FMIPv6 = as much as possible so htat is widely adapted Alper : keep it separateHS : don't know why you are calling it = piggybacking ? Nodes will understand or ignore ? What's the problem ?=20 AS : we have to ensure implementers implement it. We don't want some = vendor's implementation to use CAR? FMIPv6 but some not used CARD ? Alper : piggybacking is the wrong term JK : this function is defined by ICMP so let's move on Issue 6 : What is function of lifetime ? - lifetime flag supports indication of dynamic / static capabilities AS : - think we need it but can remove it=20 IPR issues : do we need an IPR free draft ? JK : it's better to try to be free. PC : can we know which sections have it ? AS : caching and pre-filtering.. JK : maybe separate those out and not make it a base draft item JL : it would be nice to know what the parties are and how they will be = licensed .. JK : people in WG should notify=20 PC : without knowing what the IPR is it's hard to progress.. we need to = know what the IPRs and then WG should decide whether to go on or not.. JL : I thought procedure was to add standard IPR section to doc and then = submit to secretariat Erik N : most prefer not to have IPR, but it is upto the WG. If the WG = feels that the only reasonable solution is to use the solution with IPR, = then that is the way to go. Dirk : Cache Contamination Issue discussion cache entries might exist for ARs that are not geographically adjactent = to the AR problems :=20 memory consuption processing overhead problem with sleeping interface scenario you have 2 interface, A, B, B is sleeping getting CARs for interface B will end up scanning on A for CARs only visible from B this is only a problem for MN if the MN rceives a wrong L2-L3 mapping = result Solution Proposals : P1 : backend server configure backend server to used scope problems : malicious MN can req all "scope" ARs resolve L2-L3 requests would still happen in teh backend for = out-of-scope ARs aoltohough with negative server response rate limiting could effect actual semantics of protocol how to configure scope how to deal with dynamic changes in scope aging out of cache entries P2 : learning approach (dycard approach) - after ho send triplet (L2_new, L2-Old, IP_old) to new AR - if new cache entry new AR contacts old AR to verify etc. - assumes list of authenticated local APs withing each AR problesms ; -consumes BW - check with old AR - contaimination possible by provisioning triple at geographically = distant ARs=20 - "aging out" of cache entries would not help since an aged out AP could = be provided and stored again, assuming a succesufl check with old AR AS : if scope is limited to exactly to the neighbors this problem is = solved D : then this is static configuration with its problems AS : if you have a scope, then you can configure cache to ensure size = etc are correctly configured.=20 AS : reduce the scope or bigger scope (with cache contamination) is a = decission to be made=20 ? : I don't understand how the scope id affects the MN ? D : in order to keep my cache contamination low, operator would = configure scope very small, but MN may try to get an AR outside of that = scope, eg. an AR for the whole of SF=20 ? : there may be an entry of an old AR, but so what ? Not convinced that = we need to keep cache 100% clean ? D : ?=20 Coven : 1) MN can always contaminate cache w/o knowing scope , 2) can we = do better, such as dycard AS : more difficult problem of dycard is that any MN can say any router = on the internet is a CAR. Service provide does not want to be at the = mercy of the MN.. Server based approach does not have this weakness. Dycard is too = dynamic. Different from routing protocols they have implicit = connectivity. Dirk : new AR will have the ability to ignore based on authentication = etc. if MN sends 3 reports, AR should easily be able to identify = malicious nodes and ignore it.. AS : the network does not have any control .. Dirk : i'm checking with the old AR all the time so this is resolved... PC : while service providers may care about this, some operators will = not. C : everything depends on security, but if SA don't exist all schemes = fail AS : routing protocols have a more restricted case . PC : OSPF ASs can be very large so don't think this is true *** Context Transfer Protocol v01 JK : make sure you align terminology with the terminology draft JL : main issues - choice of transport - security modesl =3D message types and semantics - intra-domain / inter-domain discussions - failure model needs to be specified - handling multiple contexts when their reliability and / or performance = requirements are different Updates :=20 - added text on protocol overview, quite stable - improved the def of the messages - addes examples and singaling flowsw What's stable :=20 protocol overview msssages and defs examples JL : want some comments on these . TO DO :=20 more text on interaction with FMIP clarify autentication vs authorization clarify secure and non-secure context transfer (what it means etc.) reliability details terminology predictive better def of feature profile types & examples better clarification of scenarios SOME OPEN ISSUES for consensus : WG consensue on transport protocol : (UDP ?) WG consensus if the scenarios are sufficient WG consensus on reliability needs JL : authors feel individual contexts have different relibility needs JL : need review from WG and info on how it would be used Alper : is this protocol dealing with one context transfer from old AR = to new AR, various contexts realted to mobility, eg. state on old AR, = PANA state on old server, 802.11 state on APs etc. what is the approach to how to transfer these contexts ? Do we assume = peer-to-peer for these things ? Or single batch protocol ?=20 JL : personally : I want to do this peer to peer, walk before run... = some people have discussed using a centralized server Alper : that approach makes sense, just clarify in text, so that we show = the CTP is applicable to other entities rather than just ARs CP : aren't we being motivated by ARs ? JL : initial motiviations from ARs, but Alper wants to show that = interesting context may be on other entities.. CP : reliability of contetxt transfer, as well being motivated by moving = context btw ARs... but there also seems=20 to be concept that state is built up at an AR, if consequently if = context failure fails you always have the option of being able to rebuild context at the new AR. So this should guide us = in our design... JK : are you suggesting that be an invariant.. CP : we don't have to have "absolue guarantee" of transfer CP : clarifying interaction with FMIP.. I remebmer initial discussions = during SEAMOBY there was a strong feeling that SEAMOBY=20 should be independent from FMIP ? May be that has changed ? Can we guage = the WG's feeling ?=20 CP : One more thing, are we finished with requirements doc ?=20 JK : we'll go back to this ... PC : I don't think we need to have this discussion that different = reliability requirements... ? : I thought I heard someone form IEEE about context transfer ? During = EAP ?=20 JL : don't know.. Rajeev K : maybe yet another comment on reliability.. most of the = features we are trying to context, will have=20 the ability to reestablish. Draggging out context transfer for = reliability may make this more complicated. JL : I'm hearing discussion that context transfer should be a one-shot = deal. JK : other way to this is to tie this with FMIP signaling=20 RK : context batching... think this is unnecessary at this stage..=20 JL : I think that is what Alper was saying.. RK : OK. so we are agreed that we don't say anything in the draft .. RK : doesn't this put constraints in the design ? JL : I think future proof is important.. but just if it is extensibel it = is enough. JK : people read this group and post to ML... PLEASE !! PC : protocol abuse will occur. ?? : Isn't reliability and use of UDP contradictory ? JL : not the point i was going for. Is TCP helpful as retx etc can get = in the way.. *** MOVING FORWARD **** JK : CARD Architecture backend : learning based approach, server based approach frontedn : ICMP is basic consensus, maybe add to FMIP signaling (?) JK : Main problems is in backend. JK : Reorganization ? Freshness date is passed we are going stale.=20 Reorganization suggestion :=20 - use requirements draft as guideline, drop publication requirements aren't helpful for research, research questions are .. - frameworkd for research on both server-based and learning-based = approach - focus on IPv6 drop IPv4=20 wireless ISPs already have proprietary solutions anyway - submit protocol to IESG for publication as experimental after Vienna Proposal for experimental draft - complete CARD front end in Seamoby integrate FMIP and CARD one host to router IETF protocol for CARD - inter-router protocol Backend supporting both serfver based and = learning so people can use it as a vehicle for experiments - if deployment interest, restart in INTERNET area for PS Research - simulations to compare server-based and learning-based - develope design approache to solve AP auth/authz problem PS must solve - utilize framework to implement different approaches - joinw tihe MIP IRTF=20 - return later for PS if needed Context Transfer Interest - not much interest ? - no response on list to chair's extensive review of DT CT draft - competition from IAPP for 802.11 reduces market interest other tech have their own - is anybody interested in this work ? if not, let's drop it if so, do something similar to CARD use requirements draft as a guideline drop publication focus on IPv6 submit at Vienna for experimental JL : about interest for Context Transfer, I would like WG's comments .. JL : I would not concentrate only on IPv6.. as both 3GPP2, 3GPP will be = doing WLAN interop soon, so that will use IPv4. Just make framework able to carry v4 and v6 ... = Then if there is interest they will be able to use it. JK : why not use IAPP ?=20 JL : cannot use with 3GPP/ 3GPP2 entities such as GGSN ? I have never = heard SDOs discuss IAPP ? Session continuitiy ... PMcCann : Session continuity is really for IP address continuity. Don't = see any need for inter-technology handoff.. ??? : 3GPP is currently unable to say anything about this. So there is = no discussion on protocol yet. JK : don't have any real interest, so maybe just make experimental. GENERAL HANDS ... JK : general consensus in continuing work on CTP GENERAL HANDS ... JK : general consensus in going with proposal to goto experimental plan JK : now let's discuss CARD plan Marco : Is it intended to have 2 doc for front / backend or 1 doc ? JK : 1 doc but without specifying one of the backend NV : Not comfortable with removing IPv4 JL : Is it that hard to support both IPv4/v6 if it is frameworky ? 3GPP/ 3GPP2 : inter-tech handover will happen in near future JK : anyone else interested in CARD work ? At least from ML, there does = seem to be some interest at least from research perspective GENERAL HANDS ... JK : general consensus on going with proposal to goto experimental plan =20 =09 ------=_NextPart_000_0050_01C2EF7D.6847ED90-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 10:45:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17292 for ; Fri, 21 Mar 2003 10:45:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LG3NO14072; Fri, 21 Mar 2003 11:03:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LG0aO13990 for ; Fri, 21 Mar 2003 11:00:36 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17205 for ; Fri, 21 Mar 2003 10:41:39 -0500 (EST) Message-ID: <005301c2efc0$777fd1e0$8b6015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 21 Mar 2003 07:42:21 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0050_01C2EF7D.6847ED90" Subject: [Seamoby] Minutes for IETF 56 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C2EF7D.6847ED90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached. Please send comments by next Tues. jak ------=_NextPart_000_0050_01C2EF7D.6847ED90 Content-Type: text/plain; name="seamobyMeetingMinutes.txt" Content-Disposition: attachment; filename="seamobyMeetingMinutes.txt" Content-Transfer-Encoding: quoted-printable Seamoby, Mar, 20, 2003 *Draft Status JK :=20 mobility terminology draft will be sent to iesg soon to be published as = informational, maybe 2 wks context transfer problem statemnet done -> RFC3374 Alper : what happens if someone wants to add to mobility terminalogy ? JK : this should be refered for general terminalogy, specific items = should be in specific WG drafts JK : carddiscover, ct-reqs are in AD evaluation, awaiting comments JK : car requirements comments -> doesn't align well with security = comments (Allision) JK : card protocol, ctp protocol will be discussed JK : as John is not here start with Ajoy * CARD protocol Ajoy : description of CARD protocol proposal on 2 operation modes to keep design flexibility server based CARD protocol - Network assisted mode MN orchestrated CARD most of discussion so far on ML has been server based solution but that = is not the only important issue WG issues=20 issue 1 : support of AP authorization at AR AP authorization is not supported in the current draft does this belong to scope of the CARD protocol PC : do we care about interoperability btw APs and ARs. AS : don't think that is in Seamoby scope difficult to authorize whether the AP is authorized or not PC : but do we care about interoperability ?=20 AS : no issue 2 : do we need server or not ?=20 characteristisc os server based approach=20 able to provide seamless handoff even if CAR info is not avaiable in = current AR cache server provides built in authorization function by using scope -id -> = inbuilt authorization (sort of) introduces single point of failure this can be solved by integrating = with AAA server Alper : don't understand how AAA server helps ? AS : we don't introduce extra points of failure if we add this to AAA = server as AAA server is already is there Alper : only looks like moving problem to another place, making a bigger = single point of failure, doesn't solve the basic problems, JK : as a general point it is a single point of failujre JL : it is a process running on a server, processes are able to die = independently issue 2 : handover base approach - no server required - seamless ho not possible until AR cache is populated - AR cache is only updated when MN performs active L3 handoff - additional protocol complexity for validating=20 PC : you are assuming dormant HO is more common than active HO, so don't = think this is true JK : depends on how you implement it, but don't see any dormant HO which = cannot do L3 HO signaling HS : where is the source of information that most handoffs is mostly = dormant : AS : from current voice network HS : please send link=20 issue 3 : DoS - possible to minimize by rate limiting the number of AR server requests = as well as MN-AR requests issue 4 : cache contamination issue AS : by properly using scope id it is possible to solve this problem need configuration, algorithm etc. JL : just as a point of suggestion, IPv6 group has realized that scoping = is an impossible problem, NSIS has also been told to not do scoping, so I suggest don't do any = scoping unless you have a real workable solutions Coven : If you can push everything down to AR at boot type won't it work = ?=20 Mark ? : Scoping is only to make sure cache contamination not be done .. JL : that's what site local tried and showed can't be done issue 5 : piggybacking CARD options - piggyback CARD onto FMIPv6 messages=20 - do we need to have some text to clarify - do we need to restrict piggybacking to FMIPv6 or should it be also = with RS / RA ? - "P" bit is used to discover the piggybacking capability of the CARD = communications peers Alper : I assume that your saying adding more info to RS / RA ? Why = change FMIPv6 spec ? Just add options to RA / RS ? AS : if we want CARD to be used, I think it should be tied with FMIPv6 = as much as possible so htat is widely adapted Alper : keep it separateHS : don't know why you are calling it = piggybacking ? Nodes will understand or ignore ? What's the problem ?=20 AS : we have to ensure implementers implement it. We don't want some = vendor's implementation to use CAR? FMIPv6 but some not used CARD ? Alper : piggybacking is the wrong term JK : this function is defined by ICMP so let's move on Issue 6 : What is function of lifetime ? - lifetime flag supports indication of dynamic / static capabilities AS : - think we need it but can remove it=20 IPR issues : do we need an IPR free draft ? JK : it's better to try to be free. PC : can we know which sections have it ? AS : caching and pre-filtering.. JK : maybe separate those out and not make it a base draft item JL : it would be nice to know what the parties are and how they will be = licensed .. JK : people in WG should notify=20 PC : without knowing what the IPR is it's hard to progress.. we need to = know what the IPRs and then WG should decide whether to go on or not.. JL : I thought procedure was to add standard IPR section to doc and then = submit to secretariat Erik N : most prefer not to have IPR, but it is upto the WG. If the WG = feels that the only reasonable solution is to use the solution with IPR, = then that is the way to go. Dirk : Cache Contamination Issue discussion cache entries might exist for ARs that are not geographically adjactent = to the AR problems :=20 memory consuption processing overhead problem with sleeping interface scenario you have 2 interface, A, B, B is sleeping getting CARs for interface B will end up scanning on A for CARs only visible from B this is only a problem for MN if the MN rceives a wrong L2-L3 mapping = result Solution Proposals : P1 : backend server configure backend server to used scope problems : malicious MN can req all "scope" ARs resolve L2-L3 requests would still happen in teh backend for = out-of-scope ARs aoltohough with negative server response rate limiting could effect actual semantics of protocol how to configure scope how to deal with dynamic changes in scope aging out of cache entries P2 : learning approach (dycard approach) - after ho send triplet (L2_new, L2-Old, IP_old) to new AR - if new cache entry new AR contacts old AR to verify etc. - assumes list of authenticated local APs withing each AR problesms ; -consumes BW - check with old AR - contaimination possible by provisioning triple at geographically = distant ARs=20 - "aging out" of cache entries would not help since an aged out AP could = be provided and stored again, assuming a succesufl check with old AR AS : if scope is limited to exactly to the neighbors this problem is = solved D : then this is static configuration with its problems AS : if you have a scope, then you can configure cache to ensure size = etc are correctly configured.=20 AS : reduce the scope or bigger scope (with cache contamination) is a = decission to be made=20 ? : I don't understand how the scope id affects the MN ? D : in order to keep my cache contamination low, operator would = configure scope very small, but MN may try to get an AR outside of that = scope, eg. an AR for the whole of SF=20 ? : there may be an entry of an old AR, but so what ? Not convinced that = we need to keep cache 100% clean ? D : ?=20 Coven : 1) MN can always contaminate cache w/o knowing scope , 2) can we = do better, such as dycard AS : more difficult problem of dycard is that any MN can say any router = on the internet is a CAR. Service provide does not want to be at the = mercy of the MN.. Server based approach does not have this weakness. Dycard is too = dynamic. Different from routing protocols they have implicit = connectivity. Dirk : new AR will have the ability to ignore based on authentication = etc. if MN sends 3 reports, AR should easily be able to identify = malicious nodes and ignore it.. AS : the network does not have any control .. Dirk : i'm checking with the old AR all the time so this is resolved... PC : while service providers may care about this, some operators will = not. C : everything depends on security, but if SA don't exist all schemes = fail AS : routing protocols have a more restricted case . PC : OSPF ASs can be very large so don't think this is true *** Context Transfer Protocol v01 JK : make sure you align terminology with the terminology draft JL : main issues - choice of transport - security modesl =3D message types and semantics - intra-domain / inter-domain discussions - failure model needs to be specified - handling multiple contexts when their reliability and / or performance = requirements are different Updates :=20 - added text on protocol overview, quite stable - improved the def of the messages - addes examples and singaling flowsw What's stable :=20 protocol overview msssages and defs examples JL : want some comments on these . TO DO :=20 more text on interaction with FMIP clarify autentication vs authorization clarify secure and non-secure context transfer (what it means etc.) reliability details terminology predictive better def of feature profile types & examples better clarification of scenarios SOME OPEN ISSUES for consensus : WG consensue on transport protocol : (UDP ?) WG consensus if the scenarios are sufficient WG consensus on reliability needs JL : authors feel individual contexts have different relibility needs JL : need review from WG and info on how it would be used Alper : is this protocol dealing with one context transfer from old AR = to new AR, various contexts realted to mobility, eg. state on old AR, = PANA state on old server, 802.11 state on APs etc. what is the approach to how to transfer these contexts ? Do we assume = peer-to-peer for these things ? Or single batch protocol ?=20 JL : personally : I want to do this peer to peer, walk before run... = some people have discussed using a centralized server Alper : that approach makes sense, just clarify in text, so that we show = the CTP is applicable to other entities rather than just ARs CP : aren't we being motivated by ARs ? JL : initial motiviations from ARs, but Alper wants to show that = interesting context may be on other entities.. CP : reliability of contetxt transfer, as well being motivated by moving = context btw ARs... but there also seems=20 to be concept that state is built up at an AR, if consequently if = context failure fails you always have the option of being able to rebuild context at the new AR. So this should guide us = in our design... JK : are you suggesting that be an invariant.. CP : we don't have to have "absolue guarantee" of transfer CP : clarifying interaction with FMIP.. I remebmer initial discussions = during SEAMOBY there was a strong feeling that SEAMOBY=20 should be independent from FMIP ? May be that has changed ? Can we guage = the WG's feeling ?=20 CP : One more thing, are we finished with requirements doc ?=20 JK : we'll go back to this ... PC : I don't think we need to have this discussion that different = reliability requirements... ? : I thought I heard someone form IEEE about context transfer ? During = EAP ?=20 JL : don't know.. Rajeev K : maybe yet another comment on reliability.. most of the = features we are trying to context, will have=20 the ability to reestablish. Draggging out context transfer for = reliability may make this more complicated. JL : I'm hearing discussion that context transfer should be a one-shot = deal. JK : other way to this is to tie this with FMIP signaling=20 RK : context batching... think this is unnecessary at this stage..=20 JL : I think that is what Alper was saying.. RK : OK. so we are agreed that we don't say anything in the draft .. RK : doesn't this put constraints in the design ? JL : I think future proof is important.. but just if it is extensibel it = is enough. JK : people read this group and post to ML... PLEASE !! PC : protocol abuse will occur. ?? : Isn't reliability and use of UDP contradictory ? JL : not the point i was going for. Is TCP helpful as retx etc can get = in the way.. *** MOVING FORWARD **** JK : CARD Architecture backend : learning based approach, server based approach frontedn : ICMP is basic consensus, maybe add to FMIP signaling (?) JK : Main problems is in backend. JK : Reorganization ? Freshness date is passed we are going stale.=20 Reorganization suggestion :=20 - use requirements draft as guideline, drop publication requirements aren't helpful for research, research questions are .. - frameworkd for research on both server-based and learning-based = approach - focus on IPv6 drop IPv4=20 wireless ISPs already have proprietary solutions anyway - submit protocol to IESG for publication as experimental after Vienna Proposal for experimental draft - complete CARD front end in Seamoby integrate FMIP and CARD one host to router IETF protocol for CARD - inter-router protocol Backend supporting both serfver based and = learning so people can use it as a vehicle for experiments - if deployment interest, restart in INTERNET area for PS Research - simulations to compare server-based and learning-based - develope design approache to solve AP auth/authz problem PS must solve - utilize framework to implement different approaches - joinw tihe MIP IRTF=20 - return later for PS if needed Context Transfer Interest - not much interest ? - no response on list to chair's extensive review of DT CT draft - competition from IAPP for 802.11 reduces market interest other tech have their own - is anybody interested in this work ? if not, let's drop it if so, do something similar to CARD use requirements draft as a guideline drop publication focus on IPv6 submit at Vienna for experimental JL : about interest for Context Transfer, I would like WG's comments .. JL : I would not concentrate only on IPv6.. as both 3GPP2, 3GPP will be = doing WLAN interop soon, so that will use IPv4. Just make framework able to carry v4 and v6 ... = Then if there is interest they will be able to use it. JK : why not use IAPP ?=20 JL : cannot use with 3GPP/ 3GPP2 entities such as GGSN ? I have never = heard SDOs discuss IAPP ? Session continuitiy ... PMcCann : Session continuity is really for IP address continuity. Don't = see any need for inter-technology handoff.. ??? : 3GPP is currently unable to say anything about this. So there is = no discussion on protocol yet. JK : don't have any real interest, so maybe just make experimental. GENERAL HANDS ... JK : general consensus in continuing work on CTP GENERAL HANDS ... JK : general consensus in going with proposal to goto experimental plan JK : now let's discuss CARD plan Marco : Is it intended to have 2 doc for front / backend or 1 doc ? JK : 1 doc but without specifying one of the backend NV : Not comfortable with removing IPv4 JL : Is it that hard to support both IPv4/v6 if it is frameworky ? 3GPP/ 3GPP2 : inter-tech handover will happen in near future JK : anyone else interested in CARD work ? At least from ML, there does = seem to be some interest at least from research perspective GENERAL HANDS ... JK : general consensus on going with proposal to goto experimental plan =20 =09 ------=_NextPart_000_0050_01C2EF7D.6847ED90-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 12:04:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18933 for ; Fri, 21 Mar 2003 12:04:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LHMWH20189 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 12:22:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHMWO20186 for ; Fri, 21 Mar 2003 12:22:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18922 for ; Fri, 21 Mar 2003 12:03:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHMHO20153; Fri, 21 Mar 2003 12:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHLgO20127 for ; Fri, 21 Mar 2003 12:21:42 -0500 Received: from shonan.sfc.wide.ad.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18897 for ; Fri, 21 Mar 2003 12:02:44 -0500 (EST) Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 28ED75D10E; Sat, 22 Mar 2003 02:05:00 +0900 (JST) Date: Sat, 22 Mar 2003 02:04:59 +0900 (JST) Message-Id: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> To: jmanner@cs.Helsinki.FI, nemo@nal.motlabs.com, seamoby@ietf.org From: Thierry Ernst In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: The NEMO/Seamoby terminology Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jukka, all, From: Jukka MJ Manner > Hi Thierry, > I had a talk with Kempf and he would like to get the Seamoby terminology > document to Last Call as soon as possible. Thus, if you could tell me what > NEMO terms would be needed in the Seamoby terminology, please, let me know > as soon as possible. I'll add those and then submit a version for final > call. If the current terms are sufficient, then we can make the last call > immediately. The seamoby terminology contains a section about mobile networks. We, NEMO WG, should make sure those terms are consistent with ours. I was particularly slow reacting to Seamoby request to merge some of our terms, the opportunity window has reached end. So let's do it now to make sure we are consistent. The semoboby terminology already contains a number of terms which are basically cut-and-paste from the NEMO terminology draft, i.e. the most general ones, For consistency, those terms should be removed from the NEMO terminology. It also makes sense to move NEMO terms which have a general scope to draft-seamoby, while keeping the more specifi ones in NEMO. Thus, for consistency and improvement, I think both drafts should be updated the following way: draft-seamoby-mmobility-terminology-02.txt - add "fixed node" as opposed to "mobile node" - update definition of mobile router (Seamoby def not the same as NEMO def) - add network mobility, as opposed to "host mobility" - add egress interface - add ingress interface - add home link prefix - add foreign link prefix draft-ernst-nemo-terminology-01.txt: - update defintion of mobile network with text in NEMO terminology's introducion - remove definition of AR - remove or extend definition of mobile network, MR, MNN - move words about "maintain sessions" from definition MN to definition of LFN, VMN, LMN - remove egress interface - remove ingress interface - remove home subnet prefix - remove foreign subnet prefix - intra-domain mobility - inter-domain mobility Thierry _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 12:04:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18948 for ; Fri, 21 Mar 2003 12:04:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHMHO20153; Fri, 21 Mar 2003 12:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHLgO20127 for ; Fri, 21 Mar 2003 12:21:42 -0500 Received: from shonan.sfc.wide.ad.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18897 for ; Fri, 21 Mar 2003 12:02:44 -0500 (EST) Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 28ED75D10E; Sat, 22 Mar 2003 02:05:00 +0900 (JST) Date: Sat, 22 Mar 2003 02:04:59 +0900 (JST) Message-Id: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> To: jmanner@cs.Helsinki.FI, nemo@nal.motlabs.com, seamoby@ietf.org From: Thierry Ernst In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: The NEMO/Seamoby terminology Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jukka, all, From: Jukka MJ Manner > Hi Thierry, > I had a talk with Kempf and he would like to get the Seamoby terminology > document to Last Call as soon as possible. Thus, if you could tell me what > NEMO terms would be needed in the Seamoby terminology, please, let me know > as soon as possible. I'll add those and then submit a version for final > call. If the current terms are sufficient, then we can make the last call > immediately. The seamoby terminology contains a section about mobile networks. We, NEMO WG, should make sure those terms are consistent with ours. I was particularly slow reacting to Seamoby request to merge some of our terms, the opportunity window has reached end. So let's do it now to make sure we are consistent. The semoboby terminology already contains a number of terms which are basically cut-and-paste from the NEMO terminology draft, i.e. the most general ones, For consistency, those terms should be removed from the NEMO terminology. It also makes sense to move NEMO terms which have a general scope to draft-seamoby, while keeping the more specifi ones in NEMO. Thus, for consistency and improvement, I think both drafts should be updated the following way: draft-seamoby-mmobility-terminology-02.txt - add "fixed node" as opposed to "mobile node" - update definition of mobile router (Seamoby def not the same as NEMO def) - add network mobility, as opposed to "host mobility" - add egress interface - add ingress interface - add home link prefix - add foreign link prefix draft-ernst-nemo-terminology-01.txt: - update defintion of mobile network with text in NEMO terminology's introducion - remove definition of AR - remove or extend definition of mobile network, MR, MNN - move words about "maintain sessions" from definition MN to definition of LFN, VMN, LMN - remove egress interface - remove ingress interface - remove home subnet prefix - remove foreign subnet prefix - intra-domain mobility - inter-domain mobility Thierry _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 12:30:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19661 for ; Fri, 21 Mar 2003 12:30:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LHmeJ22074 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 12:48:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHmeO22071 for ; Fri, 21 Mar 2003 12:48:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19595 for ; Fri, 21 Mar 2003 12:29:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHmKO22008; Fri, 21 Mar 2003 12:48:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHcNO21595 for ; Fri, 21 Mar 2003 12:38:23 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19384 for ; Fri, 21 Mar 2003 12:19:26 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Mar 2003 19:21:42 +0200 Date: Fri, 21 Mar 2003 19:21:42 +0200 (EET) From: Jukka MJ Manner To: Thierry Ernst cc: nemo@nal.motlabs.com, seamoby@ietf.org In-Reply-To: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: The NEMO/Seamoby terminology Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, you proposal sounds good. Some questions/comments, though: - The "fixed node" term does not mention IPv4-based nodes? - The "network mobility" would fit into the section discussing personal and host mobility, I guess. - All interface and prefix terms would go into the Mobile Network section of the Seamoby draft, right? They are mainly (only?) used there? Regards, Jukka On Sat, 22 Mar 2003, Thierry Ernst wrote: > > Hi Jukka, all, > > From: Jukka MJ Manner > > Hi Thierry, > > I had a talk with Kempf and he would like to get the Seamoby terminology > > document to Last Call as soon as possible. Thus, if you could tell me what > > NEMO terms would be needed in the Seamoby terminology, please, let me know > > as soon as possible. I'll add those and then submit a version for final > > call. If the current terms are sufficient, then we can make the last call > > immediately. > > The seamoby terminology contains a section about mobile networks. We, > NEMO WG, should make sure those terms are consistent with ours. I was > particularly slow reacting to Seamoby request to merge some of our > terms, the opportunity window has reached end. So let's do it now to > make sure we are consistent. > > The semoboby terminology already contains a number of terms which are > basically cut-and-paste from the NEMO terminology draft, i.e. the most > general ones, For consistency, those terms should be removed from the > NEMO terminology. It also makes sense to move NEMO terms which have a > general scope to draft-seamoby, while keeping the more specifi ones in > NEMO. > > Thus, for consistency and improvement, I think both drafts should be > updated the following way: > > draft-seamoby-mmobility-terminology-02.txt > - add "fixed node" as opposed to "mobile node" > - update definition of mobile router (Seamoby def not the same as NEMO > def) > - add network mobility, as opposed to "host mobility" > - add egress interface > - add ingress interface > - add home link prefix > - add foreign link prefix > > draft-ernst-nemo-terminology-01.txt: > - update defintion of mobile network with text in NEMO terminology's > introducion > - remove definition of AR > - remove or extend definition of mobile network, MR, MNN > - move words about "maintain sessions" from definition MN to > definition of LFN, VMN, LMN > - remove egress interface > - remove ingress interface > - remove home subnet prefix > - remove foreign subnet prefix > - intra-domain mobility > - inter-domain mobility > > Thierry > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 12:30:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19710 for ; Fri, 21 Mar 2003 12:30:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHmKO22008; Fri, 21 Mar 2003 12:48:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHcNO21595 for ; Fri, 21 Mar 2003 12:38:23 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19384 for ; Fri, 21 Mar 2003 12:19:26 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Mar 2003 19:21:42 +0200 Date: Fri, 21 Mar 2003 19:21:42 +0200 (EET) From: Jukka MJ Manner To: Thierry Ernst cc: nemo@nal.motlabs.com, seamoby@ietf.org In-Reply-To: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: The NEMO/Seamoby terminology Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, you proposal sounds good. Some questions/comments, though: - The "fixed node" term does not mention IPv4-based nodes? - The "network mobility" would fit into the section discussing personal and host mobility, I guess. - All interface and prefix terms would go into the Mobile Network section of the Seamoby draft, right? They are mainly (only?) used there? Regards, Jukka On Sat, 22 Mar 2003, Thierry Ernst wrote: > > Hi Jukka, all, > > From: Jukka MJ Manner > > Hi Thierry, > > I had a talk with Kempf and he would like to get the Seamoby terminology > > document to Last Call as soon as possible. Thus, if you could tell me what > > NEMO terms would be needed in the Seamoby terminology, please, let me know > > as soon as possible. I'll add those and then submit a version for final > > call. If the current terms are sufficient, then we can make the last call > > immediately. > > The seamoby terminology contains a section about mobile networks. We, > NEMO WG, should make sure those terms are consistent with ours. I was > particularly slow reacting to Seamoby request to merge some of our > terms, the opportunity window has reached end. So let's do it now to > make sure we are consistent. > > The semoboby terminology already contains a number of terms which are > basically cut-and-paste from the NEMO terminology draft, i.e. the most > general ones, For consistency, those terms should be removed from the > NEMO terminology. It also makes sense to move NEMO terms which have a > general scope to draft-seamoby, while keeping the more specifi ones in > NEMO. > > Thus, for consistency and improvement, I think both drafts should be > updated the following way: > > draft-seamoby-mmobility-terminology-02.txt > - add "fixed node" as opposed to "mobile node" > - update definition of mobile router (Seamoby def not the same as NEMO > def) > - add network mobility, as opposed to "host mobility" > - add egress interface > - add ingress interface > - add home link prefix > - add foreign link prefix > > draft-ernst-nemo-terminology-01.txt: > - update defintion of mobile network with text in NEMO terminology's > introducion > - remove definition of AR > - remove or extend definition of mobile network, MR, MNN > - move words about "maintain sessions" from definition MN to > definition of LFN, VMN, LMN > - remove egress interface > - remove ingress interface > - remove home subnet prefix > - remove foreign subnet prefix > - intra-domain mobility > - inter-domain mobility > > Thierry > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 13:05:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20800 for ; Fri, 21 Mar 2003 13:05:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LINT624868 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 13:23:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LINTO24865 for ; Fri, 21 Mar 2003 13:23:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20776 for ; Fri, 21 Mar 2003 13:04:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LINIO24853; Fri, 21 Mar 2003 13:23:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIMvO24800 for ; Fri, 21 Mar 2003 13:22:57 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20729 for ; Fri, 21 Mar 2003 13:03:59 -0500 (EST) Message-ID: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 21 Aug 2003 10:03:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, This email is to confirm the concensus at the IETF 56 meeting to proceed toward completing the Seamoby work and closing the Working Group. This email also advances proposals for a couple of other issues that were not discussed at the meeting but are required to close out Seamoby. CARD: - Drop draft-ietf-seamoby-card-requirements-02.txt. - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather than Proposed Standard - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on AR-MN interface. Consult with FMIP draft editor about best way to do this.. - Complete protocol on AR-AR interface that will support both learning based and server based approaches. - Protocol design complete by IETF 57 in Vienna. CT: - Drop draft-ietf-seamoby-ct-reqs-05.txt. - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than Proposed Standard. - Complete protocol design by IETF 57 in Vienna. We did not discuss the following issues, here they are with some suggestions: about how to resolve them - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. Since a clear statement of the problem is necessary for formulating the research questions, continue to advance this document to Informational. - Relationship between CT and FMIP. Since the purpose of Seamoby is to support fast handover, focus on a design that integrated well with FMIP signaling. Discussion? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 13:05:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20840 for ; Fri, 21 Mar 2003 13:05:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LINIO24853; Fri, 21 Mar 2003 13:23:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIMvO24800 for ; Fri, 21 Mar 2003 13:22:57 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20729 for ; Fri, 21 Mar 2003 13:03:59 -0500 (EST) Message-ID: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 21 Aug 2003 10:03:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, This email is to confirm the concensus at the IETF 56 meeting to proceed toward completing the Seamoby work and closing the Working Group. This email also advances proposals for a couple of other issues that were not discussed at the meeting but are required to close out Seamoby. CARD: - Drop draft-ietf-seamoby-card-requirements-02.txt. - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather than Proposed Standard - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on AR-MN interface. Consult with FMIP draft editor about best way to do this.. - Complete protocol on AR-AR interface that will support both learning based and server based approaches. - Protocol design complete by IETF 57 in Vienna. CT: - Drop draft-ietf-seamoby-ct-reqs-05.txt. - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than Proposed Standard. - Complete protocol design by IETF 57 in Vienna. We did not discuss the following issues, here they are with some suggestions: about how to resolve them - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. Since a clear statement of the problem is necessary for formulating the research questions, continue to advance this document to Informational. - Relationship between CT and FMIP. Since the purpose of Seamoby is to support fast handover, focus on a design that integrated well with FMIP signaling. Discussion? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 13:26:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21663 for ; Fri, 21 Mar 2003 13:26:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LIjRT27278 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 13:45:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIjRO27275 for ; Fri, 21 Mar 2003 13:45:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21648 for ; Fri, 21 Mar 2003 13:26:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIjAO27255; Fri, 21 Mar 2003 13:45:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIi7O27176 for ; Fri, 21 Mar 2003 13:44:07 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21557 for ; Fri, 21 Mar 2003 13:25:07 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Mar 2003 20:27:24 +0200 Date: Fri, 21 Mar 2003 20:27:24 +0200 (EET) From: Jukka MJ Manner To: James Kempf cc: seamoby@ietf.org Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work In-Reply-To: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, maybe I'm out of line here, but I would really like to see that CARD and CT are not tied directly to (F)MIP. The reason is that there are other ways to support mobile hosts, where you don't need (F)MIPv4/6. You could use SIP to find the initial location of the user (if needed) and then use a local mobility management mechanism to support the mobility within the local domain. You would still need CARD and CT to enable seamless mobility, though. Regards, Jukka On Thu, 21 Aug 2003, James Kempf wrote: > Folks, > > This email is to confirm the concensus at the IETF 56 meeting to proceed toward > completing the Seamoby work and closing the Working Group. This email also > advances proposals for a couple of other issues that were not discussed at the > meeting but are required to close out Seamoby. > > CARD: > - Drop draft-ietf-seamoby-card-requirements-02.txt. > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather than > Proposed Standard > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on > AR-MN interface. Consult with FMIP draft editor about best way to do > this.. > - Complete protocol on AR-AR interface that will support both learning > based > and server based approaches. > - Protocol design complete by IETF 57 in Vienna. > > CT: > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > Proposed Standard. > - Complete protocol design by IETF 57 in Vienna. > > We did not discuss the following issues, here they are with some suggestions: > about how to resolve them > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > Since a clear statement of the problem is necessary for formulating > the research questions, continue to advance this document to > Informational. > > - Relationship between CT and FMIP. Since the purpose of > Seamoby is to support fast handover, focus on a design > that integrated well with FMIP signaling. > > Discussion? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 13:27:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21689 for ; Fri, 21 Mar 2003 13:27:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIjAO27255; Fri, 21 Mar 2003 13:45:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIi7O27176 for ; Fri, 21 Mar 2003 13:44:07 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21557 for ; Fri, 21 Mar 2003 13:25:07 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Mar 2003 20:27:24 +0200 Date: Fri, 21 Mar 2003 20:27:24 +0200 (EET) From: Jukka MJ Manner To: James Kempf cc: seamoby@ietf.org Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work In-Reply-To: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, maybe I'm out of line here, but I would really like to see that CARD and CT are not tied directly to (F)MIP. The reason is that there are other ways to support mobile hosts, where you don't need (F)MIPv4/6. You could use SIP to find the initial location of the user (if needed) and then use a local mobility management mechanism to support the mobility within the local domain. You would still need CARD and CT to enable seamless mobility, though. Regards, Jukka On Thu, 21 Aug 2003, James Kempf wrote: > Folks, > > This email is to confirm the concensus at the IETF 56 meeting to proceed toward > completing the Seamoby work and closing the Working Group. This email also > advances proposals for a couple of other issues that were not discussed at the > meeting but are required to close out Seamoby. > > CARD: > - Drop draft-ietf-seamoby-card-requirements-02.txt. > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather than > Proposed Standard > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on > AR-MN interface. Consult with FMIP draft editor about best way to do > this.. > - Complete protocol on AR-AR interface that will support both learning > based > and server based approaches. > - Protocol design complete by IETF 57 in Vienna. > > CT: > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > Proposed Standard. > - Complete protocol design by IETF 57 in Vienna. > > We did not discuss the following issues, here they are with some suggestions: > about how to resolve them > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > Since a clear statement of the problem is necessary for formulating > the research questions, continue to advance this document to > Informational. > > - Relationship between CT and FMIP. Since the purpose of > Seamoby is to support fast handover, focus on a design > that integrated well with FMIP signaling. > > Discussion? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 13:55:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22477 for ; Fri, 21 Mar 2003 13:55:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LJDVf29520 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 14:13:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJDUO29517 for ; Fri, 21 Mar 2003 14:13:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22465 for ; Fri, 21 Mar 2003 13:54:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJDAO29472; Fri, 21 Mar 2003 14:13:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJC1O29363 for ; Fri, 21 Mar 2003 14:12:01 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22429 for ; Fri, 21 Mar 2003 13:53:01 -0500 (EST) 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 KAA12300; Fri, 21 Mar 2003 10:55:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2LItHi26668; Fri, 21 Mar 2003 10:55:17 -0800 X-mProtect: <200303211855> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhxLZI5; Fri, 21 Mar 2003 10:55:15 PST Message-ID: <3E7B6013.40EDED5A@iprg.nokia.com> Date: Fri, 21 Mar 2003 10:55:15 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jukka MJ Manner CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jukka, Jukka MJ Manner wrote: > Hi, > > maybe I'm out of line here, but I would really like to see that CARD and > CT are not tied directly to (F)MIP. The reason is that there are other > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > use SIP to find the initial location of the user (if needed) and then use > a local mobility management mechanism to support the mobility within the > local domain. You would still need CARD and CT to enable seamless > Could you elaborate what you mean by "local mobility management mechanism" ? Thanks, -Rajeev > mobility, though. > > Regards, > Jukka > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 13:55:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22494 for ; Fri, 21 Mar 2003 13:55:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJDAO29472; Fri, 21 Mar 2003 14:13:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJC1O29363 for ; Fri, 21 Mar 2003 14:12:01 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22429 for ; Fri, 21 Mar 2003 13:53:01 -0500 (EST) 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 KAA12300; Fri, 21 Mar 2003 10:55:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2LItHi26668; Fri, 21 Mar 2003 10:55:17 -0800 X-mProtect: <200303211855> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhxLZI5; Fri, 21 Mar 2003 10:55:15 PST Message-ID: <3E7B6013.40EDED5A@iprg.nokia.com> Date: Fri, 21 Mar 2003 10:55:15 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jukka MJ Manner CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Jukka, Jukka MJ Manner wrote: > Hi, > > maybe I'm out of line here, but I would really like to see that CARD and > CT are not tied directly to (F)MIP. The reason is that there are other > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > use SIP to find the initial location of the user (if needed) and then use > a local mobility management mechanism to support the mobility within the > local domain. You would still need CARD and CT to enable seamless > Could you elaborate what you mean by "local mobility management mechanism" ? Thanks, -Rajeev > mobility, though. > > Regards, > Jukka > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 14:13:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23068 for ; Fri, 21 Mar 2003 14:13:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LJVWW30468 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 14:31:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJVWO30465 for ; Fri, 21 Mar 2003 14:31:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23032 for ; Fri, 21 Mar 2003 14:12:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJVGO30435; Fri, 21 Mar 2003 14:31:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJSTO30231 for ; Fri, 21 Mar 2003 14:28:29 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22901 for ; Fri, 21 Mar 2003 14:09:29 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Mar 2003 21:11:46 +0200 Date: Fri, 21 Mar 2003 21:11:45 +0200 (EET) From: Jukka MJ Manner To: Seamoby Working Group Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work In-Reply-To: <3E7B6013.40EDED5A@iprg.nokia.com> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, examples such as BCMP, Cellular IP, MER-TORA. Especially BCMP has been shown to be quite good for supporting local mobility, and it is one of the protocols that does not expect MIP to be available. May be I'm just an academic that has no sense of the "real world", but restricting CARD and CT to a spcecific mobility management mechanism (MIP) sounds somewhat narrow minded... Regards, Jukka On Fri, 21 Mar 2003, Rajeev Koodli wrote: > > Hello Jukka, > > Jukka MJ Manner wrote: > > > Hi, > > > > maybe I'm out of line here, but I would really like to see that CARD and > > CT are not tied directly to (F)MIP. The reason is that there are other > > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > > use SIP to find the initial location of the user (if needed) and then use > > a local mobility management mechanism to support the mobility within the > > local domain. You would still need CARD and CT to enable seamless > > > > Could you elaborate what you mean by "local mobility management > mechanism" ? > > Thanks, > > -Rajeev > > > > mobility, though. > > > > Regards, > > Jukka > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 14:13:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23095 for ; Fri, 21 Mar 2003 14:13:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJVGO30435; Fri, 21 Mar 2003 14:31:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJSTO30231 for ; Fri, 21 Mar 2003 14:28:29 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22901 for ; Fri, 21 Mar 2003 14:09:29 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Mar 2003 21:11:46 +0200 Date: Fri, 21 Mar 2003 21:11:45 +0200 (EET) From: Jukka MJ Manner To: Seamoby Working Group Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work In-Reply-To: <3E7B6013.40EDED5A@iprg.nokia.com> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, examples such as BCMP, Cellular IP, MER-TORA. Especially BCMP has been shown to be quite good for supporting local mobility, and it is one of the protocols that does not expect MIP to be available. May be I'm just an academic that has no sense of the "real world", but restricting CARD and CT to a spcecific mobility management mechanism (MIP) sounds somewhat narrow minded... Regards, Jukka On Fri, 21 Mar 2003, Rajeev Koodli wrote: > > Hello Jukka, > > Jukka MJ Manner wrote: > > > Hi, > > > > maybe I'm out of line here, but I would really like to see that CARD and > > CT are not tied directly to (F)MIP. The reason is that there are other > > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > > use SIP to find the initial location of the user (if needed) and then use > > a local mobility management mechanism to support the mobility within the > > local domain. You would still need CARD and CT to enable seamless > > > > Could you elaborate what you mean by "local mobility management > mechanism" ? > > Thanks, > > -Rajeev > > > > mobility, though. > > > > Regards, > > Jukka > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 14:16:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23258 for ; Fri, 21 Mar 2003 14:16:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LJZM330712 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 14:35:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJZMO30709 for ; Fri, 21 Mar 2003 14:35:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23209 for ; Fri, 21 Mar 2003 14:16:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJZ3O30668; Fri, 21 Mar 2003 14:35:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJW4O30489 for ; Fri, 21 Mar 2003 14:32:04 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23067 for ; Fri, 21 Mar 2003 14:13:03 -0500 (EST) 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 LAA13589; Fri, 21 Mar 2003 11:15:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2LJFKS15611; Fri, 21 Mar 2003 11:15:20 -0800 X-mProtect: <200303211915> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJ00bDn; Fri, 21 Mar 2003 11:15:18 PST Message-ID: <3E7B64C6.D7C35F69@iprg.nokia.com> Date: Fri, 21 Mar 2003 11:15:18 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alper Yegin CC: seamoby@ietf.org Subject: Re: [Seamoby] CT and access routers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper Yegin wrote: > > Regarding one of my comments today at the meeting: > > The context transfer draft only talks about "access routers." Readers get > the impression that its applicability is limited to performing context > transfer between routers and nothing more. I'm not sure if the protocol > design limits itself to routers, but I don't see any reason why it could not > be applied to other access network entities, such as access points, home > agents, PANA authentication agents as long as they are IP capable. But I > don't know, I might be missing something. > > My recommendation to the authors is to include either one of these texts in > the draft: > > This protocol's applicability is limited to access routers, and using it > with other access network entities such as home agents, access points, and > authentication agents is outside the scope. > > Or: > > Although this protocol is initially designed for transfering context between > access routers, it can also be applied to other access network entities such > as home agents, access points, and authentication agents. Context > information can be transfered from these entities to their peers in the > destination network of a mobile node. we dont have a protocol which can aggregate the context at the old access router. similarly we dont have a protocol that can distribute the context received at the new access router. ofcourse it is probably not difficult to specify. people who have such networks where context is distributed across many network elements can define their own protocols to do this aggregation and distribution. I dont think that needs to be specfied by this WG. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 14:16:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23273 for ; Fri, 21 Mar 2003 14:16:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LJZQW30732 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 14:35:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJZQO30727 for ; Fri, 21 Mar 2003 14:35:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23230 for ; Fri, 21 Mar 2003 14:16:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJZ4O30684; Fri, 21 Mar 2003 14:35:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJX0O30502 for ; Fri, 21 Mar 2003 14:33:00 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23119 for ; Fri, 21 Mar 2003 14:13:59 -0500 (EST) Message-ID: <012a01c36810$168d99d0$8b6015ac@T23KEMPF> From: "James Kempf" To: "Jukka MJ Manner" Cc: References: Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Thu, 21 Aug 2003 11:14:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jukka, For CARD, the problem is that if the FMIP prehandover information signaling is not specified as the vehicle, CARD must specify a separate protocol that performs a substantially identical function. This is in direct violation of RFC 1958 Principle 3.2 (and I quote): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Using the FMIP prehandover signaling does not mean that FMIP must be used for handover. One could use GPRS or any other protocol for that purpose. With respect to CT, its a bit murkier, since the proposal is to directly use the FMIP handover signaling (as opposed to the prehandover signaling) as transport for the context and for the signaling from the Mobile Node to trigger the context transfer. One way we could finesse this is to define CT as an extension mechanism, then define in an appendix how it would apply to FMIP. This would avoid the problem of tying the base design to FMIP, while still ensuring it would work well with FMIP. jak ----- Original Message ----- From: "Jukka MJ Manner" To: "James Kempf" Cc: Sent: Friday, March 21, 2003 11:27 AM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > Hi, > > maybe I'm out of line here, but I would really like to see that CARD and > CT are not tied directly to (F)MIP. The reason is that there are other > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > use SIP to find the initial location of the user (if needed) and then use > a local mobility management mechanism to support the mobility within the > local domain. You would still need CARD and CT to enable seamless > mobility, though. > > Regards, > Jukka > > On Thu, 21 Aug 2003, James Kempf wrote: > > > Folks, > > > > This email is to confirm the concensus at the IETF 56 meeting to proceed toward > > completing the Seamoby work and closing the Working Group. This email also > > advances proposals for a couple of other issues that were not discussed at the > > meeting but are required to close out Seamoby. > > > > CARD: > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather than > > Proposed Standard > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on > > AR-MN interface. Consult with FMIP draft editor about best way to do > > this.. > > - Complete protocol on AR-AR interface that will support both learning > > based > > and server based approaches. > > - Protocol design complete by IETF 57 in Vienna. > > > > CT: > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > Proposed Standard. > > - Complete protocol design by IETF 57 in Vienna. > > > > We did not discuss the following issues, here they are with some suggestions: > > about how to resolve them > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > Since a clear statement of the problem is necessary for formulating > > the research questions, continue to advance this document to > > Informational. > > > > - Relationship between CT and FMIP. Since the purpose of > > Seamoby is to support fast handover, focus on a design > > that integrated well with FMIP signaling. > > > > Discussion? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 14:17:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23290 for ; Fri, 21 Mar 2003 14:17:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJZ3O30668; Fri, 21 Mar 2003 14:35:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJW4O30489 for ; Fri, 21 Mar 2003 14:32:04 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23067 for ; Fri, 21 Mar 2003 14:13:03 -0500 (EST) 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 LAA13589; Fri, 21 Mar 2003 11:15:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2LJFKS15611; Fri, 21 Mar 2003 11:15:20 -0800 X-mProtect: <200303211915> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJ00bDn; Fri, 21 Mar 2003 11:15:18 PST Message-ID: <3E7B64C6.D7C35F69@iprg.nokia.com> Date: Fri, 21 Mar 2003 11:15:18 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alper Yegin CC: seamoby@ietf.org Subject: Re: [Seamoby] CT and access routers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alper Yegin wrote: > > Regarding one of my comments today at the meeting: > > The context transfer draft only talks about "access routers." Readers get > the impression that its applicability is limited to performing context > transfer between routers and nothing more. I'm not sure if the protocol > design limits itself to routers, but I don't see any reason why it could not > be applied to other access network entities, such as access points, home > agents, PANA authentication agents as long as they are IP capable. But I > don't know, I might be missing something. > > My recommendation to the authors is to include either one of these texts in > the draft: > > This protocol's applicability is limited to access routers, and using it > with other access network entities such as home agents, access points, and > authentication agents is outside the scope. > > Or: > > Although this protocol is initially designed for transfering context between > access routers, it can also be applied to other access network entities such > as home agents, access points, and authentication agents. Context > information can be transfered from these entities to their peers in the > destination network of a mobile node. we dont have a protocol which can aggregate the context at the old access router. similarly we dont have a protocol that can distribute the context received at the new access router. ofcourse it is probably not difficult to specify. people who have such networks where context is distributed across many network elements can define their own protocols to do this aggregation and distribution. I dont think that needs to be specfied by this WG. Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 14:17:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23320 for ; Fri, 21 Mar 2003 14:17:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJZ4O30684; Fri, 21 Mar 2003 14:35:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJX0O30502 for ; Fri, 21 Mar 2003 14:33:00 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23119 for ; Fri, 21 Mar 2003 14:13:59 -0500 (EST) Message-ID: <012a01c36810$168d99d0$8b6015ac@T23KEMPF> From: "James Kempf" To: "Jukka MJ Manner" Cc: References: Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Thu, 21 Aug 2003 11:14:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jukka, For CARD, the problem is that if the FMIP prehandover information signaling is not specified as the vehicle, CARD must specify a separate protocol that performs a substantially identical function. This is in direct violation of RFC 1958 Principle 3.2 (and I quote): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Using the FMIP prehandover signaling does not mean that FMIP must be used for handover. One could use GPRS or any other protocol for that purpose. With respect to CT, its a bit murkier, since the proposal is to directly use the FMIP handover signaling (as opposed to the prehandover signaling) as transport for the context and for the signaling from the Mobile Node to trigger the context transfer. One way we could finesse this is to define CT as an extension mechanism, then define in an appendix how it would apply to FMIP. This would avoid the problem of tying the base design to FMIP, while still ensuring it would work well with FMIP. jak ----- Original Message ----- From: "Jukka MJ Manner" To: "James Kempf" Cc: Sent: Friday, March 21, 2003 11:27 AM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > Hi, > > maybe I'm out of line here, but I would really like to see that CARD and > CT are not tied directly to (F)MIP. The reason is that there are other > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > use SIP to find the initial location of the user (if needed) and then use > a local mobility management mechanism to support the mobility within the > local domain. You would still need CARD and CT to enable seamless > mobility, though. > > Regards, > Jukka > > On Thu, 21 Aug 2003, James Kempf wrote: > > > Folks, > > > > This email is to confirm the concensus at the IETF 56 meeting to proceed toward > > completing the Seamoby work and closing the Working Group. This email also > > advances proposals for a couple of other issues that were not discussed at the > > meeting but are required to close out Seamoby. > > > > CARD: > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather than > > Proposed Standard > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on > > AR-MN interface. Consult with FMIP draft editor about best way to do > > this.. > > - Complete protocol on AR-AR interface that will support both learning > > based > > and server based approaches. > > - Protocol design complete by IETF 57 in Vienna. > > > > CT: > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > Proposed Standard. > > - Complete protocol design by IETF 57 in Vienna. > > > > We did not discuss the following issues, here they are with some suggestions: > > about how to resolve them > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > Since a clear statement of the problem is necessary for formulating > > the research questions, continue to advance this document to > > Informational. > > > > - Relationship between CT and FMIP. Since the purpose of > > Seamoby is to support fast handover, focus on a design > > that integrated well with FMIP signaling. > > > > Discussion? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 14:26:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23669 for ; Fri, 21 Mar 2003 14:26:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LJiTQ32005 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 14:44:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJiTO32002 for ; Fri, 21 Mar 2003 14:44:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23647 for ; Fri, 21 Mar 2003 14:25:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJiDO31963; Fri, 21 Mar 2003 14:44:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJftO31846 for ; Fri, 21 Mar 2003 14:41:55 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23546 for ; Fri, 21 Mar 2003 14:22:54 -0500 (EST) Date: Fri, 21 Mar 2003 11:25:22 -0800 Subject: Re: [Seamoby] CT and access routers From: Alper Yegin To: Vijay Devarapalli CC: Message-ID: In-Reply-To: <3E7B64C6.D7C35F69@iprg.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay, >> >> Regarding one of my comments today at the meeting: >> >> The context transfer draft only talks about "access routers." Readers get >> the impression that its applicability is limited to performing context >> transfer between routers and nothing more. I'm not sure if the protocol >> design limits itself to routers, but I don't see any reason why it could not >> be applied to other access network entities, such as access points, home >> agents, PANA authentication agents as long as they are IP capable. But I >> don't know, I might be missing something. >> >> My recommendation to the authors is to include either one of these texts in >> the draft: >> >> This protocol's applicability is limited to access routers, and using it >> with other access network entities such as home agents, access points, and >> authentication agents is outside the scope. >> >> Or: >> >> Although this protocol is initially designed for transfering context between >> access routers, it can also be applied to other access network entities such >> as home agents, access points, and authentication agents. Context >> information can be transfered from these entities to their peers in the >> destination network of a mobile node. > > we dont have a protocol which can aggregate the context at the > old access router. similarly we dont have a protocol that can > distribute the context received at the new access router. > ofcourse it is probably not difficult to specify. > > people who have such networks where context is distributed across > many network elements can define their own protocols to do this > aggregation and distribution. I dont think that needs to be > specfied by this WG. No, no, I'm not talking about "aggregating state on the access routers" at all. Please see above. It's all about stating whether CT can be used between an agent of type X on the old access network and same type agent on the new access network. Just say "yes it can be" or "no it can't be" in the spec, rather than leaving it open to speculation and abuse. alper _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 14:26:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23682 for ; Fri, 21 Mar 2003 14:26:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LJiVc32021 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 14:44:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJiVO32018 for ; Fri, 21 Mar 2003 14:44:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23651 for ; Fri, 21 Mar 2003 14:25:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJiFO31980; Fri, 21 Mar 2003 14:44:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJg0O31856 for ; Fri, 21 Mar 2003 14:42:00 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23576 for ; Fri, 21 Mar 2003 14:22:59 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Mar 2003 21:25:16 +0200 Date: Fri, 21 Mar 2003 21:25:16 +0200 (EET) From: Jukka MJ Manner To: James Kempf cc: seamoby@ietf.org Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work In-Reply-To: <012a01c36810$168d99d0$8b6015ac@T23KEMPF> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, your proposal is what I was looking forward to see: a generic architecture and protocol and then an example use case with FMIP, for example. Regards, Jukka On Thu, 21 Aug 2003, James Kempf wrote: > Jukka, > > For CARD, the problem is that if the FMIP prehandover information signaling is > not specified as the vehicle, CARD must specify a separate protocol that > performs a substantially identical function. This is in direct violation of RFC > 1958 Principle 3.2 (and I quote): > > 3.2 If there are several ways of doing the same thing, choose one. > If a previous design, in the Internet context or elsewhere, has > successfully solved the same problem, choose the same solution unless > there is a good technical reason not to. Duplication of the same > protocol functionality should be avoided as far as possible, without > of course using this argument to reject improvements. > > Using the FMIP prehandover signaling does not mean that FMIP must be used for > handover. One could use GPRS or any other protocol for that purpose. > > With respect to CT, its a bit murkier, since the proposal is to directly use the > FMIP handover signaling (as opposed to the prehandover signaling) as transport > for the context and for the signaling from the Mobile Node to trigger the > context transfer. > One way we could finesse this is to define CT as an extension mechanism, then > define in an appendix how it would apply to FMIP. This would avoid the problem > of tying the base design to FMIP, while still ensuring it would work well with > FMIP. > > jak > > > ----- Original Message ----- > From: "Jukka MJ Manner" > To: "James Kempf" > Cc: > Sent: Friday, March 21, 2003 11:27 AM > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > > > > > Hi, > > > > maybe I'm out of line here, but I would really like to see that CARD and > > CT are not tied directly to (F)MIP. The reason is that there are other > > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > > use SIP to find the initial location of the user (if needed) and then use > > a local mobility management mechanism to support the mobility within the > > local domain. You would still need CARD and CT to enable seamless > > mobility, though. > > > > Regards, > > Jukka > > > > On Thu, 21 Aug 2003, James Kempf wrote: > > > > > Folks, > > > > > > This email is to confirm the concensus at the IETF 56 meeting to proceed > toward > > > completing the Seamoby work and closing the Working Group. This email also > > > advances proposals for a couple of other issues that were not discussed at > the > > > meeting but are required to close out Seamoby. > > > > > > CARD: > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather > than > > > Proposed Standard > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on > > > AR-MN interface. Consult with FMIP draft editor about best way to do > > > this.. > > > - Complete protocol on AR-AR interface that will support both learning > > > based > > > and server based approaches. > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > CT: > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > > Proposed Standard. > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > We did not discuss the following issues, here they are with some > suggestions: > > > about how to resolve them > > > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > Since a clear statement of the problem is necessary for formulating > > > the research questions, continue to advance this document to > > > Informational. > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > Seamoby is to support fast handover, focus on a design > > > that integrated well with FMIP signaling. > > > > > > Discussion? > > > > > > jak > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 14:26:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23698 for ; Fri, 21 Mar 2003 14:26:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJiDO31963; Fri, 21 Mar 2003 14:44:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJftO31846 for ; Fri, 21 Mar 2003 14:41:55 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23546 for ; Fri, 21 Mar 2003 14:22:54 -0500 (EST) Date: Fri, 21 Mar 2003 11:25:22 -0800 Subject: Re: [Seamoby] CT and access routers From: Alper Yegin To: Vijay Devarapalli CC: Message-ID: In-Reply-To: <3E7B64C6.D7C35F69@iprg.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay, >> >> Regarding one of my comments today at the meeting: >> >> The context transfer draft only talks about "access routers." Readers get >> the impression that its applicability is limited to performing context >> transfer between routers and nothing more. I'm not sure if the protocol >> design limits itself to routers, but I don't see any reason why it could not >> be applied to other access network entities, such as access points, home >> agents, PANA authentication agents as long as they are IP capable. But I >> don't know, I might be missing something. >> >> My recommendation to the authors is to include either one of these texts in >> the draft: >> >> This protocol's applicability is limited to access routers, and using it >> with other access network entities such as home agents, access points, and >> authentication agents is outside the scope. >> >> Or: >> >> Although this protocol is initially designed for transfering context between >> access routers, it can also be applied to other access network entities such >> as home agents, access points, and authentication agents. Context >> information can be transfered from these entities to their peers in the >> destination network of a mobile node. > > we dont have a protocol which can aggregate the context at the > old access router. similarly we dont have a protocol that can > distribute the context received at the new access router. > ofcourse it is probably not difficult to specify. > > people who have such networks where context is distributed across > many network elements can define their own protocols to do this > aggregation and distribution. I dont think that needs to be > specfied by this WG. No, no, I'm not talking about "aggregating state on the access routers" at all. Please see above. It's all about stating whether CT can be used between an agent of type X on the old access network and same type agent on the new access network. Just say "yes it can be" or "no it can't be" in the spec, rather than leaving it open to speculation and abuse. alper _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 14:26:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23713 for ; Fri, 21 Mar 2003 14:26:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJiFO31980; Fri, 21 Mar 2003 14:44:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJg0O31856 for ; Fri, 21 Mar 2003 14:42:00 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23576 for ; Fri, 21 Mar 2003 14:22:59 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Mar 2003 21:25:16 +0200 Date: Fri, 21 Mar 2003 21:25:16 +0200 (EET) From: Jukka MJ Manner To: James Kempf cc: seamoby@ietf.org Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work In-Reply-To: <012a01c36810$168d99d0$8b6015ac@T23KEMPF> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, your proposal is what I was looking forward to see: a generic architecture and protocol and then an example use case with FMIP, for example. Regards, Jukka On Thu, 21 Aug 2003, James Kempf wrote: > Jukka, > > For CARD, the problem is that if the FMIP prehandover information signaling is > not specified as the vehicle, CARD must specify a separate protocol that > performs a substantially identical function. This is in direct violation of RFC > 1958 Principle 3.2 (and I quote): > > 3.2 If there are several ways of doing the same thing, choose one. > If a previous design, in the Internet context or elsewhere, has > successfully solved the same problem, choose the same solution unless > there is a good technical reason not to. Duplication of the same > protocol functionality should be avoided as far as possible, without > of course using this argument to reject improvements. > > Using the FMIP prehandover signaling does not mean that FMIP must be used for > handover. One could use GPRS or any other protocol for that purpose. > > With respect to CT, its a bit murkier, since the proposal is to directly use the > FMIP handover signaling (as opposed to the prehandover signaling) as transport > for the context and for the signaling from the Mobile Node to trigger the > context transfer. > One way we could finesse this is to define CT as an extension mechanism, then > define in an appendix how it would apply to FMIP. This would avoid the problem > of tying the base design to FMIP, while still ensuring it would work well with > FMIP. > > jak > > > ----- Original Message ----- > From: "Jukka MJ Manner" > To: "James Kempf" > Cc: > Sent: Friday, March 21, 2003 11:27 AM > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > > > > > Hi, > > > > maybe I'm out of line here, but I would really like to see that CARD and > > CT are not tied directly to (F)MIP. The reason is that there are other > > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > > use SIP to find the initial location of the user (if needed) and then use > > a local mobility management mechanism to support the mobility within the > > local domain. You would still need CARD and CT to enable seamless > > mobility, though. > > > > Regards, > > Jukka > > > > On Thu, 21 Aug 2003, James Kempf wrote: > > > > > Folks, > > > > > > This email is to confirm the concensus at the IETF 56 meeting to proceed > toward > > > completing the Seamoby work and closing the Working Group. This email also > > > advances proposals for a couple of other issues that were not discussed at > the > > > meeting but are required to close out Seamoby. > > > > > > CARD: > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather > than > > > Proposed Standard > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on > > > AR-MN interface. Consult with FMIP draft editor about best way to do > > > this.. > > > - Complete protocol on AR-AR interface that will support both learning > > > based > > > and server based approaches. > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > CT: > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > > Proposed Standard. > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > We did not discuss the following issues, here they are with some > suggestions: > > > about how to resolve them > > > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > Since a clear statement of the problem is necessary for formulating > > > the research questions, continue to advance this document to > > > Informational. > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > Seamoby is to support fast handover, focus on a design > > > that integrated well with FMIP signaling. > > > > > > Discussion? > > > > > > jak > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Mar 21 14:29:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23809 for ; Fri, 21 Mar 2003 14:29:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LJlXr32193 for seamoby-archive@odin.ietf.org; Fri, 21 Mar 2003 14:47:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJlXO32190 for ; Fri, 21 Mar 2003 14:47:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23771 for ; Fri, 21 Mar 2003 14:28:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJl7O32165; Fri, 21 Mar 2003 14:47:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJjZO32086 for ; Fri, 21 Mar 2003 14:45:35 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23733 for ; Fri, 21 Mar 2003 14:26:34 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2LJSHM25981; Fri, 21 Mar 2003 14:28:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Mar 2003 14:28:17 -0500 Message-ID: From: "Gary Kenward" To: "'Jukka MJ Manner'" , Seamoby Working Group Subject: RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Wor k Date: Fri, 21 Mar 2003 14:28:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EFDF.B0528A20" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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_01C2EFDF.B0528A20 Content-Type: text/plain; charset="iso-8859-1" I concur with Jukka. There are no deployed networks using MIP for local mobility. Effectively, the jury is still out, and the market will decide. A market - call it wireless IP access - that is arguably changing radically. Gary > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: March 21, 2003 14:12 > To: Seamoby Working Group > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > Work > > > > Hi, > > examples such as BCMP, Cellular IP, MER-TORA. Especially BCMP > has been > shown to be quite good for supporting local mobility, and it > is one of the > protocols that does not expect MIP to be available. May be > I'm just an > academic that has no sense of the "real world", but > restricting CARD and > CT to a spcecific mobility management mechanism (MIP) sounds somewhat > narrow minded... > > Regards, > Jukka > > On Fri, 21 Mar 2003, Rajeev Koodli wrote: > > > > > Hello Jukka, > > > > Jukka MJ Manner wrote: > > > > > Hi, > > > > > > maybe I'm out of line here, but I would really like to > see that CARD and > > > CT are not tied directly to (F)MIP. The reason is that > there are other > > > ways to support mobile hosts, where you don't need > (F)MIPv4/6. You could > > > use SIP to find the initial location of the user (if > needed) and then use > > > a local mobility management mechanism to support the > mobility within the > > > local domain. You would still need CARD and CT to enable seamless > > > > > > > Could you elaborate what you mean by "local mobility management > > mechanism" ? > > > > Thanks, > > > > -Rajeev > > > > > > > mobility, though. > > > > > > Regards, > > > Jukka > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C2EFDF.B0528A20 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Work

I concur with Jukka. There are no deployed networks using
MIP for local mobility. Effectively, the jury is still out,
and the market will decide. A market - call it wireless IP access - that is arguably changing radically.

Gary

> -----Original Message-----
> From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]
> Sent: March 21, 2003 14:12
> To: Seamoby Working Group
> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby
> Work
>
>
>
> Hi,
>
> examples such as BCMP, Cellular IP, MER-TORA. Especially BCMP
> has been
> shown to be quite good for supporting local mobility, and it
> is one of the
> protocols that does not expect MIP to be available. May be
> I'm just an
> academic that has no sense of the "real world", but
> restricting CARD and
> CT to a spcecific mobility management mechanism (MIP) sounds somewhat
> narrow minded...
>
> Regards,
> Jukka
>
> On Fri, 21 Mar 2003, Rajeev Koodli wrote:
>
> >
> > Hello Jukka,
> >
> > Jukka MJ Manner wrote:
> >
> > > Hi,
> > >
> > > maybe I'm out of line here, but I would really like to
> see that CARD and
> > > CT are not tied directly to (F)MIP. The reason is that
> there are other
> > > ways to support mobile hosts, where you don't need
> (F)MIPv4/6. You could
> > > use SIP to find the initial location of the user (if
> needed) and then use
> > > a local mobility management mechanism to support the
> mobility within the
> > > local domain. You would still need CARD and CT to enable seamless
> > >
> >
> > Could you elaborate what you mean by "local mobility management
> > mechanism" ?
> >
> > Thanks,
> >
> > -Rajeev
> >
> >
> > > mobility, though.
> > >
> > > Regards,
> > > Jukka
> > >
> >
> >
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C2EFDF.B0528A20-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 21 14:29:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23826 for ; Fri, 21 Mar 2003 14:29:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJl7O32165; Fri, 21 Mar 2003 14:47:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJjZO32086 for ; Fri, 21 Mar 2003 14:45:35 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23733 for ; Fri, 21 Mar 2003 14:26:34 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2LJSHM25981; Fri, 21 Mar 2003 14:28:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Mar 2003 14:28:17 -0500 Message-ID: From: "Gary Kenward" To: "'Jukka MJ Manner'" , Seamoby Working Group Subject: RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Wor k Date: Fri, 21 Mar 2003 14:28:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EFDF.B0528A20" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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_01C2EFDF.B0528A20 Content-Type: text/plain; charset="iso-8859-1" I concur with Jukka. There are no deployed networks using MIP for local mobility. Effectively, the jury is still out, and the market will decide. A market - call it wireless IP access - that is arguably changing radically. Gary > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: March 21, 2003 14:12 > To: Seamoby Working Group > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > Work > > > > Hi, > > examples such as BCMP, Cellular IP, MER-TORA. Especially BCMP > has been > shown to be quite good for supporting local mobility, and it > is one of the > protocols that does not expect MIP to be available. May be > I'm just an > academic that has no sense of the "real world", but > restricting CARD and > CT to a spcecific mobility management mechanism (MIP) sounds somewhat > narrow minded... > > Regards, > Jukka > > On Fri, 21 Mar 2003, Rajeev Koodli wrote: > > > > > Hello Jukka, > > > > Jukka MJ Manner wrote: > > > > > Hi, > > > > > > maybe I'm out of line here, but I would really like to > see that CARD and > > > CT are not tied directly to (F)MIP. The reason is that > there are other > > > ways to support mobile hosts, where you don't need > (F)MIPv4/6. You could > > > use SIP to find the initial location of the user (if > needed) and then use > > > a local mobility management mechanism to support the > mobility within the > > > local domain. You would still need CARD and CT to enable seamless > > > > > > > Could you elaborate what you mean by "local mobility management > > mechanism" ? > > > > Thanks, > > > > -Rajeev > > > > > > > mobility, though. > > > > > > Regards, > > > Jukka > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C2EFDF.B0528A20 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Work

I concur with Jukka. There are no deployed networks using
MIP for local mobility. Effectively, the jury is still out,
and the market will decide. A market - call it wireless IP access - that is arguably changing radically.

Gary

> -----Original Message-----
> From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]
> Sent: March 21, 2003 14:12
> To: Seamoby Working Group
> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby
> Work
>
>
>
> Hi,
>
> examples such as BCMP, Cellular IP, MER-TORA. Especially BCMP
> has been
> shown to be quite good for supporting local mobility, and it
> is one of the
> protocols that does not expect MIP to be available. May be
> I'm just an
> academic that has no sense of the "real world", but
> restricting CARD and
> CT to a spcecific mobility management mechanism (MIP) sounds somewhat
> narrow minded...
>
> Regards,
> Jukka
>
> On Fri, 21 Mar 2003, Rajeev Koodli wrote:
>
> >
> > Hello Jukka,
> >
> > Jukka MJ Manner wrote:
> >
> > > Hi,
> > >
> > > maybe I'm out of line here, but I would really like to
> see that CARD and
> > > CT are not tied directly to (F)MIP. The reason is that
> there are other
> > > ways to support mobile hosts, where you don't need
> (F)MIPv4/6. You could
> > > use SIP to find the initial location of the user (if
> needed) and then use
> > > a local mobility management mechanism to support the
> mobility within the
> > > local domain. You would still need CARD and CT to enable seamless
> > >
> >
> > Could you elaborate what you mean by "local mobility management
> > mechanism" ?
> >
> > Thanks,
> >
> > -Rajeev
> >
> >
> > > mobility, though.
> > >
> > > Regards,
> > > Jukka
> > >
> >
> >
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C2EFDF.B0528A20-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 22 12:13:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00069 for ; Sat, 22 Mar 2003 12:13:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2MHWdI22277 for seamoby-archive@odin.ietf.org; Sat, 22 Mar 2003 12:32:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MHWcO22274 for ; Sat, 22 Mar 2003 12:32:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00061 for ; Sat, 22 Mar 2003 12:13:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MHWMO22252; Sat, 22 Mar 2003 12:32:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MHTGO22151 for ; Sat, 22 Mar 2003 12:29:16 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00036 for ; Sat, 22 Mar 2003 12:09:51 -0500 (EST) Received: from eunsoo ([138.15.98.122] unverified) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 22 Mar 2003 12:12:07 -0500 Message-ID: <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sat, 22 Mar 2003 12:13:16 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 22 Mar 2003 17:12:07.0709 (UTC) FILETIME=[2B01BCD0:01C2F096] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information after discovery. In Dycard, the discovery requires messages between MN and AR for delivering the IP address of the previous AR to the current AR. This is beyond the purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. I wonder whether the proposal is to extend the semantics of FMIP PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between AR and MN for CARD. Eunsoo > Folks, > > This email is to confirm the concensus at the IETF 56 meeting to proceed toward > completing the Seamoby work and closing the Working Group. This email also > advances proposals for a couple of other issues that were not discussed at the > meeting but are required to close out Seamoby. > > CARD: > - Drop draft-ietf-seamoby-card-requirements-02.txt. > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather than > Proposed Standard > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on > AR-MN interface. Consult with FMIP draft editor about best way to do > this.. > - Complete protocol on AR-AR interface that will support both learning > based > and server based approaches. > - Protocol design complete by IETF 57 in Vienna. > > CT: > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > Proposed Standard. > - Complete protocol design by IETF 57 in Vienna. > > We did not discuss the following issues, here they are with some suggestions: > about how to resolve them > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > Since a clear statement of the problem is necessary for formulating > the research questions, continue to advance this document to > Informational. > > - Relationship between CT and FMIP. Since the purpose of > Seamoby is to support fast handover, focus on a design > that integrated well with FMIP signaling. > > Discussion? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 22 12:17:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00212 for ; Sat, 22 Mar 2003 12:17:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MHWMO22252; Sat, 22 Mar 2003 12:32:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MHTGO22151 for ; Sat, 22 Mar 2003 12:29:16 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00036 for ; Sat, 22 Mar 2003 12:09:51 -0500 (EST) Received: from eunsoo ([138.15.98.122] unverified) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 22 Mar 2003 12:12:07 -0500 Message-ID: <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sat, 22 Mar 2003 12:13:16 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 22 Mar 2003 17:12:07.0709 (UTC) FILETIME=[2B01BCD0:01C2F096] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information after discovery. In Dycard, the discovery requires messages between MN and AR for delivering the IP address of the previous AR to the current AR. This is beyond the purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. I wonder whether the proposal is to extend the semantics of FMIP PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between AR and MN for CARD. Eunsoo > Folks, > > This email is to confirm the concensus at the IETF 56 meeting to proceed toward > completing the Seamoby work and closing the Working Group. This email also > advances proposals for a couple of other issues that were not discussed at the > meeting but are required to close out Seamoby. > > CARD: > - Drop draft-ietf-seamoby-card-requirements-02.txt. > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather than > Proposed Standard > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on > AR-MN interface. Consult with FMIP draft editor about best way to do > this.. > - Complete protocol on AR-AR interface that will support both learning > based > and server based approaches. > - Protocol design complete by IETF 57 in Vienna. > > CT: > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > Proposed Standard. > - Complete protocol design by IETF 57 in Vienna. > > We did not discuss the following issues, here they are with some suggestions: > about how to resolve them > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > Since a clear statement of the problem is necessary for formulating > the research questions, continue to advance this document to > Informational. > > - Relationship between CT and FMIP. Since the purpose of > Seamoby is to support fast handover, focus on a design > that integrated well with FMIP signaling. > > Discussion? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 22 23:44:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12857 for ; Sat, 22 Mar 2003 23:44:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2N53wU29190 for seamoby-archive@odin.ietf.org; Sun, 23 Mar 2003 00:03:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N53wO29187 for ; Sun, 23 Mar 2003 00:03:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12847 for ; Sat, 22 Mar 2003 23:44:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N53SO29178; Sun, 23 Mar 2003 00:03:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N50rO29118 for ; Sun, 23 Mar 2003 00:00:53 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12805 for ; Sat, 22 Mar 2003 23:41:13 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2N4lCu20073 for ; Sun, 23 Mar 2003 06:47:12 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 23 Mar 2003 06:43:28 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 06:43:29 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 06:43:28 +0200 Subject: RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sun, 23 Mar 2003 06:43:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Thread-Index: AcLv17UwvUWYgJFSQOCZrtinQ+ZIYABHvpuQ To: , Cc: X-OriginalArrivalTime: 23 Mar 2003 04:43:29.0179 (UTC) FILETIME=[BFE3BEB0:01C2F0F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2N50rO29119 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, > maybe I'm out of line here, but I would really like to see that CARD and > CT are not tied directly to (F)MIP. The reason is that there are other > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > use SIP to find the initial location of the user (if needed) and then use > a local mobility management mechanism to support the mobility within the > local domain. You would still need CARD and CT to enable seamless > mobility, though. I agree. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 22 23:44:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12871 for ; Sat, 22 Mar 2003 23:44:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N53SO29178; Sun, 23 Mar 2003 00:03:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N50rO29118 for ; Sun, 23 Mar 2003 00:00:53 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12805 for ; Sat, 22 Mar 2003 23:41:13 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2N4lCu20073 for ; Sun, 23 Mar 2003 06:47:12 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 23 Mar 2003 06:43:28 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 06:43:29 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 06:43:28 +0200 Subject: RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sun, 23 Mar 2003 06:43:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Thread-Index: AcLv17UwvUWYgJFSQOCZrtinQ+ZIYABHvpuQ To: , Cc: X-OriginalArrivalTime: 23 Mar 2003 04:43:29.0179 (UTC) FILETIME=[BFE3BEB0:01C2F0F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2N50rO29119 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, > maybe I'm out of line here, but I would really like to see that CARD and > CT are not tied directly to (F)MIP. The reason is that there are other > ways to support mobile hosts, where you don't need (F)MIPv4/6. You could > use SIP to find the initial location of the user (if needed) and then use > a local mobility management mechanism to support the mobility within the > local domain. You would still need CARD and CT to enable seamless > mobility, though. I agree. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 22 23:53:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13052 for ; Sat, 22 Mar 2003 23:53:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2N5Cxc30276 for seamoby-archive@odin.ietf.org; Sun, 23 Mar 2003 00:12:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5CxO30273 for ; Sun, 23 Mar 2003 00:12:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13039 for ; Sat, 22 Mar 2003 23:53:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5ClO30263; Sun, 23 Mar 2003 00:12:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5AMO30209 for ; Sun, 23 Mar 2003 00:10:22 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13016 for ; Sat, 22 Mar 2003 23:50:41 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2N4ueu21479 for ; Sun, 23 Mar 2003 06:56:40 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 23 Mar 2003 06:53:02 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 06:52:56 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 06:52:57 +0200 Subject: RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sun, 23 Mar 2003 06:52:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Thread-Index: AcLv3quk1Scn2JqJRka36UvAt0wKzQBGRYow To: , Cc: X-OriginalArrivalTime: 23 Mar 2003 04:52:57.0008 (UTC) FILETIME=[12579300:01C2F0F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2N5AMO30210 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit James, > With respect to CT, its a bit murkier, since the proposal is to directly use the > FMIP handover signaling (as opposed to the prehandover signaling) as transport > for the context and for the signaling from the Mobile Node to trigger the > context transfer. > One way we could finesse this is to define CT as an extension mechanism, then > define in an appendix how it would apply to FMIP. This would avoid the problem > of tying the base design to FMIP, while still ensuring it would work well with > FMIP. I thought that consensus was to define the CT protocol, but make it a bit 'frameworky' and provide an appendix with FMIP applicability. As FMIP is still a moving target, I think this is the best way to go, especially as others have expressed interest in CTP for other handoff / mobility solutions. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 22 23:54:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13065 for ; Sat, 22 Mar 2003 23:54:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5ClO30263; Sun, 23 Mar 2003 00:12:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5AMO30209 for ; Sun, 23 Mar 2003 00:10:22 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13016 for ; Sat, 22 Mar 2003 23:50:41 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2N4ueu21479 for ; Sun, 23 Mar 2003 06:56:40 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 23 Mar 2003 06:53:02 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 06:52:56 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 06:52:57 +0200 Subject: RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sun, 23 Mar 2003 06:52:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Thread-Index: AcLv3quk1Scn2JqJRka36UvAt0wKzQBGRYow To: , Cc: X-OriginalArrivalTime: 23 Mar 2003 04:52:57.0008 (UTC) FILETIME=[12579300:01C2F0F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2N5AMO30210 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, > With respect to CT, its a bit murkier, since the proposal is to directly use the > FMIP handover signaling (as opposed to the prehandover signaling) as transport > for the context and for the signaling from the Mobile Node to trigger the > context transfer. > One way we could finesse this is to define CT as an extension mechanism, then > define in an appendix how it would apply to FMIP. This would avoid the problem > of tying the base design to FMIP, while still ensuring it would work well with > FMIP. I thought that consensus was to define the CT protocol, but make it a bit 'frameworky' and provide an appendix with FMIP applicability. As FMIP is still a moving target, I think this is the best way to go, especially as others have expressed interest in CTP for other handoff / mobility solutions. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Mar 22 23:59:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13122 for ; Sat, 22 Mar 2003 23:59:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2N5J0Q30446 for seamoby-archive@odin.ietf.org; Sun, 23 Mar 2003 00:19:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5J0O30438 for ; Sun, 23 Mar 2003 00:19:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13115 for ; Sat, 22 Mar 2003 23:59:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5InO30420; Sun, 23 Mar 2003 00:18:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5GkO30372 for ; Sun, 23 Mar 2003 00:16:46 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13097 for ; Sat, 22 Mar 2003 23:57:06 -0500 (EST) Message-ID: <009f01c3692a$b74a7940$a06015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Fri, 22 Aug 2003 20:57:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Extending the semantics is the proposal. Or, alternatively, delivering the learning-based information via a RS. If it turns out not to be a good match, then an additional message could be added for the learning based approach. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Saturday, March 22, 2003 1:13 PM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information > after discovery. > In Dycard, the discovery requires messages between MN and AR for delivering > the IP address of the previous AR to the current AR. This is beyond the > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > I wonder whether the proposal is to extend the semantics of FMIP > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between AR > and MN for CARD. > > Eunsoo > > > > Folks, > > > > This email is to confirm the concensus at the IETF 56 meeting to proceed > toward > > completing the Seamoby work and closing the Working Group. This email also > > advances proposals for a couple of other issues that were not discussed at > the > > meeting but are required to close out Seamoby. > > > > CARD: > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental > rather than > > Proposed Standard > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information > on > > AR-MN interface. Consult with FMIP draft editor about best way to > do > > this.. > > - Complete protocol on AR-AR interface that will support both > learning > > based > > and server based approaches. > > - Protocol design complete by IETF 57 in Vienna. > > > > CT: > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > Proposed Standard. > > - Complete protocol design by IETF 57 in Vienna. > > > > We did not discuss the following issues, here they are with some > suggestions: > > about how to resolve them > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > Since a clear statement of the problem is necessary for formulating > > the research questions, continue to advance this document to > > Informational. > > > > - Relationship between CT and FMIP. Since the purpose of > > Seamoby is to support fast handover, focus on a design > > that integrated well with FMIP signaling. > > > > Discussion? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 22 23:59:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13135 for ; Sat, 22 Mar 2003 23:59:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5InO30420; Sun, 23 Mar 2003 00:18:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5GkO30372 for ; Sun, 23 Mar 2003 00:16:46 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13097 for ; Sat, 22 Mar 2003 23:57:06 -0500 (EST) Message-ID: <009f01c3692a$b74a7940$a06015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Fri, 22 Aug 2003 20:57:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Extending the semantics is the proposal. Or, alternatively, delivering the learning-based information via a RS. If it turns out not to be a good match, then an additional message could be added for the learning based approach. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Saturday, March 22, 2003 1:13 PM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information > after discovery. > In Dycard, the discovery requires messages between MN and AR for delivering > the IP address of the previous AR to the current AR. This is beyond the > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > I wonder whether the proposal is to extend the semantics of FMIP > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between AR > and MN for CARD. > > Eunsoo > > > > Folks, > > > > This email is to confirm the concensus at the IETF 56 meeting to proceed > toward > > completing the Seamoby work and closing the Working Group. This email also > > advances proposals for a couple of other issues that were not discussed at > the > > meeting but are required to close out Seamoby. > > > > CARD: > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental > rather than > > Proposed Standard > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information > on > > AR-MN interface. Consult with FMIP draft editor about best way to > do > > this.. > > - Complete protocol on AR-AR interface that will support both > learning > > based > > and server based approaches. > > - Protocol design complete by IETF 57 in Vienna. > > > > CT: > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > Proposed Standard. > > - Complete protocol design by IETF 57 in Vienna. > > > > We did not discuss the following issues, here they are with some > suggestions: > > about how to resolve them > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > Since a clear statement of the problem is necessary for formulating > > the research questions, continue to advance this document to > > Informational. > > > > - Relationship between CT and FMIP. Since the purpose of > > Seamoby is to support fast handover, focus on a design > > that integrated well with FMIP signaling. > > > > Discussion? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 23 00:23:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13467 for ; Sun, 23 Mar 2003 00:23:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2N5h8j31767 for seamoby-archive@odin.ietf.org; Sun, 23 Mar 2003 00:43:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5h8O31764 for ; Sun, 23 Mar 2003 00:43:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13462 for ; Sun, 23 Mar 2003 00:23:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5gvO31745; Sun, 23 Mar 2003 00:42:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5eDO31688 for ; Sun, 23 Mar 2003 00:40:13 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13428 for ; Sun, 23 Mar 2003 00:20:32 -0500 (EST) Message-ID: <012201c3692d$fc1d9db0$a06015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Fri, 22 Aug 2003 21:20:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, > I thought that consensus was to define the CT protocol, but make > it a bit 'frameworky' and provide an appendix with FMIP applicability. > As FMIP is still a moving target, I think this is the best way to go, > especially as others have expressed interest in CTP for other > handoff / mobility solutions. > I think I would like to see a precise definition of "frameworky". As for FMIP applicability, putting it in an appendix to illustrate how the protocol would apply to FMIP is a good idea. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 23 00:30:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13550 for ; Sun, 23 Mar 2003 00:30:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5gvO31745; Sun, 23 Mar 2003 00:42:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N5eDO31688 for ; Sun, 23 Mar 2003 00:40:13 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13428 for ; Sun, 23 Mar 2003 00:20:32 -0500 (EST) Message-ID: <012201c3692d$fc1d9db0$a06015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Fri, 22 Aug 2003 21:20:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, > I thought that consensus was to define the CT protocol, but make > it a bit 'frameworky' and provide an appendix with FMIP applicability. > As FMIP is still a moving target, I think this is the best way to go, > especially as others have expressed interest in CTP for other > handoff / mobility solutions. > I think I would like to see a precise definition of "frameworky". As for FMIP applicability, putting it in an appendix to illustrate how the protocol would apply to FMIP is a good idea. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Mar 23 07:35:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00935 for ; Sun, 23 Mar 2003 07:35:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NCsbu02508 for seamoby-archive@odin.ietf.org; Sun, 23 Mar 2003 07:54:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NCsbO02505 for ; Sun, 23 Mar 2003 07:54:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00931 for ; Sun, 23 Mar 2003 07:34:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NCsNO02497; Sun, 23 Mar 2003 07:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NCrZO02444 for ; Sun, 23 Mar 2003 07:53:35 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00909 for ; Sun, 23 Mar 2003 07:33:45 -0500 (EST) Received: from eunsoo ([138.15.98.104] unverified) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 23 Mar 2003 07:36:01 -0500 Message-ID: <002901c2f152$11dd4000$68620f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> <009f01c3692a$b74a7940$a06015ac@T23KEMPF> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sun, 23 Mar 2003 07:37:07 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 23 Mar 2003 12:36:02.0271 (UTC) FILETIME=[C3A63EF0:01C2F138] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It was agreed to make the CARD messages piggyback-able in the past. Then the CARD messages could be transported even on top of other messages than FMIP messages. Also we don't have to worry about how FMIP will turn out in the future. Or the FMIP designers don't have to worry about the semantics change required by the CARD protocol. Piggybacking wouldn't be better than tight-coupling with FMIP? Eunsoo > Extending the semantics is the proposal. Or, alternatively, delivering the > learning-based information via a RS. > > If it turns out not to be a good match, then an additional message could be > added for the learning based approach. > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Saturday, March 22, 2003 1:13 PM > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > > > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information > > after discovery. > > In Dycard, the discovery requires messages between MN and AR for delivering > > the IP address of the previous AR to the current AR. This is beyond the > > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > > I wonder whether the proposal is to extend the semantics of FMIP > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between AR > > and MN for CARD. > > > > Eunsoo > > > > > > > Folks, > > > > > > This email is to confirm the concensus at the IETF 56 meeting to proceed > > toward > > > completing the Seamoby work and closing the Working Group. This email also > > > advances proposals for a couple of other issues that were not discussed at > > the > > > meeting but are required to close out Seamoby. > > > > > > CARD: > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental > > rather than > > > Proposed Standard > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information > > on > > > AR-MN interface. Consult with FMIP draft editor about best way to > > do > > > this.. > > > - Complete protocol on AR-AR interface that will support both > > learning > > > based > > > and server based approaches. > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > CT: > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > > Proposed Standard. > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > We did not discuss the following issues, here they are with some > > suggestions: > > > about how to resolve them > > > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > Since a clear statement of the problem is necessary for formulating > > > the research questions, continue to advance this document to > > > Informational. > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > Seamoby is to support fast handover, focus on a design > > > that integrated well with FMIP signaling. > > > > > > Discussion? > > > > > > jak > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 23 07:35:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00948 for ; Sun, 23 Mar 2003 07:35:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NCsNO02497; Sun, 23 Mar 2003 07:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NCrZO02444 for ; Sun, 23 Mar 2003 07:53:35 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00909 for ; Sun, 23 Mar 2003 07:33:45 -0500 (EST) Received: from eunsoo ([138.15.98.104] unverified) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 23 Mar 2003 07:36:01 -0500 Message-ID: <002901c2f152$11dd4000$68620f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> <009f01c3692a$b74a7940$a06015ac@T23KEMPF> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sun, 23 Mar 2003 07:37:07 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 23 Mar 2003 12:36:02.0271 (UTC) FILETIME=[C3A63EF0:01C2F138] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It was agreed to make the CARD messages piggyback-able in the past. Then the CARD messages could be transported even on top of other messages than FMIP messages. Also we don't have to worry about how FMIP will turn out in the future. Or the FMIP designers don't have to worry about the semantics change required by the CARD protocol. Piggybacking wouldn't be better than tight-coupling with FMIP? Eunsoo > Extending the semantics is the proposal. Or, alternatively, delivering the > learning-based information via a RS. > > If it turns out not to be a good match, then an additional message could be > added for the learning based approach. > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Saturday, March 22, 2003 1:13 PM > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > > > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information > > after discovery. > > In Dycard, the discovery requires messages between MN and AR for delivering > > the IP address of the previous AR to the current AR. This is beyond the > > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > > I wonder whether the proposal is to extend the semantics of FMIP > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between AR > > and MN for CARD. > > > > Eunsoo > > > > > > > Folks, > > > > > > This email is to confirm the concensus at the IETF 56 meeting to proceed > > toward > > > completing the Seamoby work and closing the Working Group. This email also > > > advances proposals for a couple of other issues that were not discussed at > > the > > > meeting but are required to close out Seamoby. > > > > > > CARD: > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental > > rather than > > > Proposed Standard > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information > > on > > > AR-MN interface. Consult with FMIP draft editor about best way to > > do > > > this.. > > > - Complete protocol on AR-AR interface that will support both > > learning > > > based > > > and server based approaches. > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > CT: > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > > Proposed Standard. > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > We did not discuss the following issues, here they are with some > > suggestions: > > > about how to resolve them > > > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > Since a clear statement of the problem is necessary for formulating > > > the research questions, continue to advance this document to > > > Informational. > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > Seamoby is to support fast handover, focus on a design > > > that integrated well with FMIP signaling. > > > > > > Discussion? > > > > > > jak > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 24 06:08:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10299 for ; Mon, 24 Mar 2003 06:08:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OBSMk24139 for seamoby-archive@odin.ietf.org; Mon, 24 Mar 2003 06:28:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OBSMO24136 for ; Mon, 24 Mar 2003 06:28:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10288 for ; Mon, 24 Mar 2003 06:08:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OBQeO24054; Mon, 24 Mar 2003 06:26:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OBPLO24019 for ; Mon, 24 Mar 2003 06:25:21 -0500 Received: from shonan.sfc.wide.ad.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10221 for ; Mon, 24 Mar 2003 06:05:02 -0500 (EST) Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 1E51F5D0AB; Mon, 24 Mar 2003 20:07:21 +0900 (JST) Date: Mon, 24 Mar 2003 20:07:20 +0900 (JST) Message-Id: <20030324.200720.26220860.ernst@sfc.wide.ad.jp> To: jmanner@cs.Helsinki.FI Cc: nemo@nal.motlabs.com, seamoby@ietf.org From: Thierry Ernst In-Reply-To: References: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: The NEMO/Seamoby terminology Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jukka, all, [NEMO folks involve in terminology, please review suggestions below] From: Jukka MJ Manner > you proposal sounds good. Some questions/comments, though: > - The "fixed node" term does not mention IPv4-based nodes? Right. We don't need such details, so, in the seamoby document, we can make it simpler, as the definition for mobile nodes. I don't know if the mention "continuous sessions" we have in draft-nemo is relevant or not in draft-seamoby. To what extent a node is fixed or mobile ? With respect to its address or only with respect to its point of attachment ? Should the definition also cover MANET nodes and thus be general enough ? Tentatively, I propose the following text for draft-seamoby. Text between brackets is optional and could be added/removed: o Fixed Node (FN) A node, either a host or a router, unable to change its point of attachment to the network and its IP address [without breaking open sessions] o Mobile Node (MN) An IP node, either a host or a router, capable of changing its point of attachment to the network, moving from one link to another link [while maintaining continuous sessions] o Mobile Router (MR) A router capable of changing its point of attachment to the network, moving from one link to another link. The MR is capable of forwarding packets between two or more interfaces, and possibly running a dynamic routing protocol modifying the state by which to do packet forwarding. A MR acting as a gateway between an entire mobile network and the rest of the Internet has one or more egress interface(s) and one or more ingress interface(s). [Packets forwarded upstream to the rest of the Internet are transmitted through one of the MR's egress interface; packets forwarded downstream to the mobile network are transmitted through one of the MR's ingress interface.] o Mobile Network An entire network, moving as a unit, which dynamically changes its point of attachment to the Internet and thus its reachability in the topology. The mobile network is composed by one or more IP-subnets and is connected to the global Internet via one or more Mobile Routers (MR). The internal configuration of the mobile network is assumed to be relatively stable with respect to the MR. o Mobile Network Node (MNN) Any node (host or router) located within a mobile network, either permanently or temporarily. MNNs may either be mobile nodes (host or router) or fixed nodes. o Ingress interface The interface of a MR attached to a link inside the mobile network. o Egress interface The interface of a MR attached to the home link if the MR is at home, or attached to a foreign link if the MR is in a foreign network. It would be useful to indicate ingress and egress intefaces on the figure. > - The "network mobility" would fit into the section discussing personal > and host mobility, I guess. Yes. > - All interface and prefix terms would go into the Mobile Network section > of the Seamoby draft, right? They are mainly (only?) used there? I think "home subnet prefix" and "foreign subnet prefix" are general to mobility, not only to network mobility. Moreover, those terms appear in section 2 of draft-seamoby, thus they should be defined in section 2. Thierry > On Sat, 22 Mar 2003, Thierry Ernst wrote: > > Thus, for consistency and improvement, I think both drafts should be > > updated the following way: > > > > draft-seamoby-mmobility-terminology-02.txt > > - add "fixed node" as opposed to "mobile node" > > - update definition of mobile router (Seamoby def not the same as NEMO > > def) > > - add network mobility, as opposed to "host mobility" > > - add egress interface > > - add ingress interface > > - add home link prefix > > - add foreign link prefix > > > > draft-ernst-nemo-terminology-01.txt: > > - update defintion of mobile network with text in NEMO terminology's > > introducion > > - remove definition of AR > > - remove or extend definition of mobile network, MR, MNN > > - move words about "maintain sessions" from definition MN to > > definition of LFN, VMN, LMN > > - remove egress interface > > - remove ingress interface > > - remove home subnet prefix > > - remove foreign subnet prefix > > - intra-domain mobility > > - inter-domain mobility _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 24 06:15:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10445 for ; Mon, 24 Mar 2003 06:15:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OBQeO24054; Mon, 24 Mar 2003 06:26:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OBPLO24019 for ; Mon, 24 Mar 2003 06:25:21 -0500 Received: from shonan.sfc.wide.ad.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10221 for ; Mon, 24 Mar 2003 06:05:02 -0500 (EST) Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 1E51F5D0AB; Mon, 24 Mar 2003 20:07:21 +0900 (JST) Date: Mon, 24 Mar 2003 20:07:20 +0900 (JST) Message-Id: <20030324.200720.26220860.ernst@sfc.wide.ad.jp> To: jmanner@cs.Helsinki.FI Cc: nemo@nal.motlabs.com, seamoby@ietf.org From: Thierry Ernst In-Reply-To: References: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: The NEMO/Seamoby terminology Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jukka, all, [NEMO folks involve in terminology, please review suggestions below] From: Jukka MJ Manner > you proposal sounds good. Some questions/comments, though: > - The "fixed node" term does not mention IPv4-based nodes? Right. We don't need such details, so, in the seamoby document, we can make it simpler, as the definition for mobile nodes. I don't know if the mention "continuous sessions" we have in draft-nemo is relevant or not in draft-seamoby. To what extent a node is fixed or mobile ? With respect to its address or only with respect to its point of attachment ? Should the definition also cover MANET nodes and thus be general enough ? Tentatively, I propose the following text for draft-seamoby. Text between brackets is optional and could be added/removed: o Fixed Node (FN) A node, either a host or a router, unable to change its point of attachment to the network and its IP address [without breaking open sessions] o Mobile Node (MN) An IP node, either a host or a router, capable of changing its point of attachment to the network, moving from one link to another link [while maintaining continuous sessions] o Mobile Router (MR) A router capable of changing its point of attachment to the network, moving from one link to another link. The MR is capable of forwarding packets between two or more interfaces, and possibly running a dynamic routing protocol modifying the state by which to do packet forwarding. A MR acting as a gateway between an entire mobile network and the rest of the Internet has one or more egress interface(s) and one or more ingress interface(s). [Packets forwarded upstream to the rest of the Internet are transmitted through one of the MR's egress interface; packets forwarded downstream to the mobile network are transmitted through one of the MR's ingress interface.] o Mobile Network An entire network, moving as a unit, which dynamically changes its point of attachment to the Internet and thus its reachability in the topology. The mobile network is composed by one or more IP-subnets and is connected to the global Internet via one or more Mobile Routers (MR). The internal configuration of the mobile network is assumed to be relatively stable with respect to the MR. o Mobile Network Node (MNN) Any node (host or router) located within a mobile network, either permanently or temporarily. MNNs may either be mobile nodes (host or router) or fixed nodes. o Ingress interface The interface of a MR attached to a link inside the mobile network. o Egress interface The interface of a MR attached to the home link if the MR is at home, or attached to a foreign link if the MR is in a foreign network. It would be useful to indicate ingress and egress intefaces on the figure. > - The "network mobility" would fit into the section discussing personal > and host mobility, I guess. Yes. > - All interface and prefix terms would go into the Mobile Network section > of the Seamoby draft, right? They are mainly (only?) used there? I think "home subnet prefix" and "foreign subnet prefix" are general to mobility, not only to network mobility. Moreover, those terms appear in section 2 of draft-seamoby, thus they should be defined in section 2. Thierry > On Sat, 22 Mar 2003, Thierry Ernst wrote: > > Thus, for consistency and improvement, I think both drafts should be > > updated the following way: > > > > draft-seamoby-mmobility-terminology-02.txt > > - add "fixed node" as opposed to "mobile node" > > - update definition of mobile router (Seamoby def not the same as NEMO > > def) > > - add network mobility, as opposed to "host mobility" > > - add egress interface > > - add ingress interface > > - add home link prefix > > - add foreign link prefix > > > > draft-ernst-nemo-terminology-01.txt: > > - update defintion of mobile network with text in NEMO terminology's > > introducion > > - remove definition of AR > > - remove or extend definition of mobile network, MR, MNN > > - move words about "maintain sessions" from definition MN to > > definition of LFN, VMN, LMN > > - remove egress interface > > - remove ingress interface > > - remove home subnet prefix > > - remove foreign subnet prefix > > - intra-domain mobility > > - inter-domain mobility _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 24 08:12:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15526 for ; Mon, 24 Mar 2003 08:12:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ODVxx32595 for seamoby-archive@odin.ietf.org; Mon, 24 Mar 2003 08:31:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODVwO32592 for ; Mon, 24 Mar 2003 08:31:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15520 for ; Mon, 24 Mar 2003 08:11:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODUQO32504; Mon, 24 Mar 2003 08:30:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODTLO32451 for ; Mon, 24 Mar 2003 08:29:21 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15405 for ; Mon, 24 Mar 2003 08:09:02 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2ODF5u09741 for ; Mon, 24 Mar 2003 15:15:05 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Mar 2003 15:11:19 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Mar 2003 15:11:19 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Mar 2003 15:11:19 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Work X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 24 Mar 2003 15:11:18 +0200 Message-ID: Thread-Topic: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Thread-Index: AcLw/EIhUg2X4GELSEeme8Lzg5eyVgBCjziA To: Cc: X-OriginalArrivalTime: 24 Mar 2003 13:11:19.0385 (UTC) FILETIME=[DBF5F490:01C2F206] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ODTLO32452 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit James, > I think I would like to see a precise definition of "frameworky". So would I! I think by calling something 'frameworky' there is an implication of something a bit fuzzy involved. That being said, what I would like to do is get the basic protocol mechanisms (messages, data types, parameters, etc.) defined and then have an appendix where we map the protocol to certain mobility signaling protocols, like FMIP. This would give an opportunity for others to 'map' the CTP to their particular needs, in future documents. > As for FMIP applicability, putting it in an appendix to illustrate how the > protocol would apply to FMIP is a good idea. agreed. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 24 08:12:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15540 for ; Mon, 24 Mar 2003 08:12:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODUQO32504; Mon, 24 Mar 2003 08:30:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODTLO32451 for ; Mon, 24 Mar 2003 08:29:21 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15405 for ; Mon, 24 Mar 2003 08:09:02 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2ODF5u09741 for ; Mon, 24 Mar 2003 15:15:05 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Mar 2003 15:11:19 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Mar 2003 15:11:19 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Mar 2003 15:11:19 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Confirmation of Concensus on Completing Seamoby Work X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 24 Mar 2003 15:11:18 +0200 Message-ID: Thread-Topic: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Thread-Index: AcLw/EIhUg2X4GELSEeme8Lzg5eyVgBCjziA To: Cc: X-OriginalArrivalTime: 24 Mar 2003 13:11:19.0385 (UTC) FILETIME=[DBF5F490:01C2F206] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ODTLO32452 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, > I think I would like to see a precise definition of "frameworky". So would I! I think by calling something 'frameworky' there is an implication of something a bit fuzzy involved. That being said, what I would like to do is get the basic protocol mechanisms (messages, data types, parameters, etc.) defined and then have an appendix where we map the protocol to certain mobility signaling protocols, like FMIP. This would give an opportunity for others to 'map' the CTP to their particular needs, in future documents. > As for FMIP applicability, putting it in an appendix to illustrate how the > protocol would apply to FMIP is a good idea. agreed. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 24 12:23:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26069 for ; Mon, 24 Mar 2003 12:23:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OHhiS18574 for seamoby-archive@odin.ietf.org; Mon, 24 Mar 2003 12:43:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHhiO18571 for ; Mon, 24 Mar 2003 12:43:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26055 for ; Mon, 24 Mar 2003 12:23:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHg2O18477; Mon, 24 Mar 2003 12:42:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHemO18404 for ; Mon, 24 Mar 2003 12:40:48 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25952 for ; Mon, 24 Mar 2003 12:20:22 -0500 (EST) Message-ID: <003901c36a5b$ba176750$036015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> <009f01c3692a$b74a7940$a06015ac@T23KEMPF> <002901c2f152$11dd4000$68620f8a@eunsoo> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sun, 24 Aug 2003 09:21:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Defining the CARD messages as generalized ICMP options for RFC 2461 and associated extentions is acceptable. I presume this is what you mean by "piggybacking". jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Sunday, March 23, 2003 8:37 AM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > It was agreed to make the CARD messages piggyback-able in the past. > Then the CARD messages could be transported even on top of other messages > than FMIP messages. > Also we don't have to worry about how FMIP will turn out in the future. Or > the FMIP designers don't have to worry about the semantics change required > by the CARD protocol. > Piggybacking wouldn't be better than tight-coupling with FMIP? > > Eunsoo > > > Extending the semantics is the proposal. Or, alternatively, delivering the > > learning-based information via a RS. > > > > If it turns out not to be a good match, then an additional message could > be > > added for the learning based approach. > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "James Kempf" ; > > Sent: Saturday, March 22, 2003 1:13 PM > > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > Work > > > > > > > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information > > > after discovery. > > > In Dycard, the discovery requires messages between MN and AR for > delivering > > > the IP address of the previous AR to the current AR. This is beyond the > > > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > > > I wonder whether the proposal is to extend the semantics of FMIP > > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between > AR > > > and MN for CARD. > > > > > > Eunsoo > > > > > > > > > > Folks, > > > > > > > > This email is to confirm the concensus at the IETF 56 meeting to > proceed > > > toward > > > > completing the Seamoby work and closing the Working Group. This email > also > > > > advances proposals for a couple of other issues that were not > discussed at > > > the > > > > meeting but are required to close out Seamoby. > > > > > > > > CARD: > > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental > > > rather than > > > > Proposed Standard > > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD > information > > > on > > > > AR-MN interface. Consult with FMIP draft editor about best way > to > > > do > > > > this.. > > > > - Complete protocol on AR-AR interface that will support both > > > learning > > > > based > > > > and server based approaches. > > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > > > CT: > > > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > > > Proposed Standard. > > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > > > We did not discuss the following issues, here they are with some > > > suggestions: > > > > about how to resolve them > > > > > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > > Since a clear statement of the problem is necessary for > formulating > > > > the research questions, continue to advance this document to > > > > Informational. > > > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > > Seamoby is to support fast handover, focus on a design > > > > that integrated well with FMIP signaling. > > > > > > > > Discussion? > > > > > > > > jak > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 24 12:24:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26086 for ; Mon, 24 Mar 2003 12:24:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHg2O18477; Mon, 24 Mar 2003 12:42:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHemO18404 for ; Mon, 24 Mar 2003 12:40:48 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25952 for ; Mon, 24 Mar 2003 12:20:22 -0500 (EST) Message-ID: <003901c36a5b$ba176750$036015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> <009f01c3692a$b74a7940$a06015ac@T23KEMPF> <002901c2f152$11dd4000$68620f8a@eunsoo> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Sun, 24 Aug 2003 09:21:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Defining the CARD messages as generalized ICMP options for RFC 2461 and associated extentions is acceptable. I presume this is what you mean by "piggybacking". jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Sunday, March 23, 2003 8:37 AM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > It was agreed to make the CARD messages piggyback-able in the past. > Then the CARD messages could be transported even on top of other messages > than FMIP messages. > Also we don't have to worry about how FMIP will turn out in the future. Or > the FMIP designers don't have to worry about the semantics change required > by the CARD protocol. > Piggybacking wouldn't be better than tight-coupling with FMIP? > > Eunsoo > > > Extending the semantics is the proposal. Or, alternatively, delivering the > > learning-based information via a RS. > > > > If it turns out not to be a good match, then an additional message could > be > > added for the learning based approach. > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "James Kempf" ; > > Sent: Saturday, March 22, 2003 1:13 PM > > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > Work > > > > > > > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information > > > after discovery. > > > In Dycard, the discovery requires messages between MN and AR for > delivering > > > the IP address of the previous AR to the current AR. This is beyond the > > > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > > > I wonder whether the proposal is to extend the semantics of FMIP > > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between > AR > > > and MN for CARD. > > > > > > Eunsoo > > > > > > > > > > Folks, > > > > > > > > This email is to confirm the concensus at the IETF 56 meeting to > proceed > > > toward > > > > completing the Seamoby work and closing the Working Group. This email > also > > > > advances proposals for a couple of other issues that were not > discussed at > > > the > > > > meeting but are required to close out Seamoby. > > > > > > > > CARD: > > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental > > > rather than > > > > Proposed Standard > > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD > information > > > on > > > > AR-MN interface. Consult with FMIP draft editor about best way > to > > > do > > > > this.. > > > > - Complete protocol on AR-AR interface that will support both > > > learning > > > > based > > > > and server based approaches. > > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > > > CT: > > > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > > > Proposed Standard. > > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > > > We did not discuss the following issues, here they are with some > > > suggestions: > > > > about how to resolve them > > > > > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > > Since a clear statement of the problem is necessary for > formulating > > > > the research questions, continue to advance this document to > > > > Informational. > > > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > > Seamoby is to support fast handover, focus on a design > > > > that integrated well with FMIP signaling. > > > > > > > > Discussion? > > > > > > > > jak > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 24 12:33:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26387 for ; Mon, 24 Mar 2003 12:33:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OHrgR19128 for seamoby-archive@odin.ietf.org; Mon, 24 Mar 2003 12:53:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHrgO19125 for ; Mon, 24 Mar 2003 12:53:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26379 for ; Mon, 24 Mar 2003 12:33:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHq7O19041; Mon, 24 Mar 2003 12:52:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHpBO18957 for ; Mon, 24 Mar 2003 12:51:11 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26291 for ; Mon, 24 Mar 2003 12:30:44 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 Mar 2003 12:33:04 -0500 Message-ID: <00cc01c2f244$be58be20$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> <009f01c3692a$b74a7940$a06015ac@T23KEMPF> <002901c2f152$11dd4000$68620f8a@eunsoo> <003901c36a5b$ba176750$036015ac@T23KEMPF> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Mon, 24 Mar 2003 12:34:18 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 24 Mar 2003 17:33:04.0594 (UTC) FILETIME=[6CFEAB20:01C2F22B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, Right.The design team proposed that the specification allows two options: piggybacking as ICMP options and stand-alone messages. I think this is a good approach that can satisfy many things. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; Sent: Sunday, August 24, 2003 8:21 AM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > Defining the CARD messages as generalized ICMP options for RFC 2461 and > associated extentions is acceptable. I presume this is what you mean by > "piggybacking". > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Sunday, March 23, 2003 8:37 AM > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > > > It was agreed to make the CARD messages piggyback-able in the past. > > Then the CARD messages could be transported even on top of other messages > > than FMIP messages. > > Also we don't have to worry about how FMIP will turn out in the future. Or > > the FMIP designers don't have to worry about the semantics change required > > by the CARD protocol. > > Piggybacking wouldn't be better than tight-coupling with FMIP? > > > > Eunsoo > > > > > Extending the semantics is the proposal. Or, alternatively, delivering the > > > learning-based information via a RS. > > > > > > If it turns out not to be a good match, then an additional message could > > be > > > added for the learning based approach. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Eunsoo Shim" > > > To: "James Kempf" ; > > > Sent: Saturday, March 22, 2003 1:13 PM > > > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > > Work > > > > > > > > > > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information > > > > after discovery. > > > > In Dycard, the discovery requires messages between MN and AR for > > delivering > > > > the IP address of the previous AR to the current AR. This is beyond the > > > > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > > > > I wonder whether the proposal is to extend the semantics of FMIP > > > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between > > AR > > > > and MN for CARD. > > > > > > > > Eunsoo > > > > > > > > > > > > > Folks, > > > > > > > > > > This email is to confirm the concensus at the IETF 56 meeting to > > proceed > > > > toward > > > > > completing the Seamoby work and closing the Working Group. This email > > also > > > > > advances proposals for a couple of other issues that were not > > discussed at > > > > the > > > > > meeting but are required to close out Seamoby. > > > > > > > > > > CARD: > > > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental > > > > rather than > > > > > Proposed Standard > > > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD > > information > > > > on > > > > > AR-MN interface. Consult with FMIP draft editor about best way > > to > > > > do > > > > > this.. > > > > > - Complete protocol on AR-AR interface that will support both > > > > learning > > > > > based > > > > > and server based approaches. > > > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > > > > > CT: > > > > > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > > > > Proposed Standard. > > > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > > > > > We did not discuss the following issues, here they are with some > > > > suggestions: > > > > > about how to resolve them > > > > > > > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > > > Since a clear statement of the problem is necessary for > > formulating > > > > > the research questions, continue to advance this document to > > > > > Informational. > > > > > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > > > Seamoby is to support fast handover, focus on a design > > > > > that integrated well with FMIP signaling. > > > > > > > > > > Discussion? > > > > > > > > > > jak > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 24 12:34:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26403 for ; Mon, 24 Mar 2003 12:34:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHq7O19041; Mon, 24 Mar 2003 12:52:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OHpBO18957 for ; Mon, 24 Mar 2003 12:51:11 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26291 for ; Mon, 24 Mar 2003 12:30:44 -0500 (EST) Received: from eunsoo ([138.15.107.226]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 Mar 2003 12:33:04 -0500 Message-ID: <00cc01c2f244$be58be20$e26b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> <009f01c3692a$b74a7940$a06015ac@T23KEMPF> <002901c2f152$11dd4000$68620f8a@eunsoo> <003901c36a5b$ba176750$036015ac@T23KEMPF> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Mon, 24 Mar 2003 12:34:18 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 24 Mar 2003 17:33:04.0594 (UTC) FILETIME=[6CFEAB20:01C2F22B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, Right.The design team proposed that the specification allows two options: piggybacking as ICMP options and stand-alone messages. I think this is a good approach that can satisfy many things. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; Sent: Sunday, August 24, 2003 8:21 AM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > Defining the CARD messages as generalized ICMP options for RFC 2461 and > associated extentions is acceptable. I presume this is what you mean by > "piggybacking". > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Sunday, March 23, 2003 8:37 AM > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > > > It was agreed to make the CARD messages piggyback-able in the past. > > Then the CARD messages could be transported even on top of other messages > > than FMIP messages. > > Also we don't have to worry about how FMIP will turn out in the future. Or > > the FMIP designers don't have to worry about the semantics change required > > by the CARD protocol. > > Piggybacking wouldn't be better than tight-coupling with FMIP? > > > > Eunsoo > > > > > Extending the semantics is the proposal. Or, alternatively, delivering the > > > learning-based information via a RS. > > > > > > If it turns out not to be a good match, then an additional message could > > be > > > added for the learning based approach. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Eunsoo Shim" > > > To: "James Kempf" ; > > > Sent: Saturday, March 22, 2003 1:13 PM > > > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > > Work > > > > > > > > > > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information > > > > after discovery. > > > > In Dycard, the discovery requires messages between MN and AR for > > delivering > > > > the IP address of the previous AR to the current AR. This is beyond the > > > > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > > > > I wonder whether the proposal is to extend the semantics of FMIP > > > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between > > AR > > > > and MN for CARD. > > > > > > > > Eunsoo > > > > > > > > > > > > > Folks, > > > > > > > > > > This email is to confirm the concensus at the IETF 56 meeting to > > proceed > > > > toward > > > > > completing the Seamoby work and closing the Working Group. This email > > also > > > > > advances proposals for a couple of other issues that were not > > discussed at > > > > the > > > > > meeting but are required to close out Seamoby. > > > > > > > > > > CARD: > > > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > > > - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental > > > > rather than > > > > > Proposed Standard > > > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD > > information > > > > on > > > > > AR-MN interface. Consult with FMIP draft editor about best way > > to > > > > do > > > > > this.. > > > > > - Complete protocol on AR-AR interface that will support both > > > > learning > > > > > based > > > > > and server based approaches. > > > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > > > > > CT: > > > > > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than > > > > > Proposed Standard. > > > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > > > > > We did not discuss the following issues, here they are with some > > > > suggestions: > > > > > about how to resolve them > > > > > > > > > > - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > > > Since a clear statement of the problem is necessary for > > formulating > > > > > the research questions, continue to advance this document to > > > > > Informational. > > > > > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > > > Seamoby is to support fast handover, focus on a design > > > > > that integrated well with FMIP signaling. > > > > > > > > > > Discussion? > > > > > > > > > > jak > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 24 13:52:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28793 for ; Mon, 24 Mar 2003 13:52:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OJCs424615 for seamoby-archive@odin.ietf.org; Mon, 24 Mar 2003 14:12:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJCsO24612 for ; Mon, 24 Mar 2003 14:12:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28780 for ; Mon, 24 Mar 2003 13:52:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJBJO24570; Mon, 24 Mar 2003 14:11:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJAeO24533 for ; Mon, 24 Mar 2003 14:10:40 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28722 for ; Mon, 24 Mar 2003 13:50:13 -0500 (EST) Message-ID: <014901c2f236$4f32cbc0$036015ac@T23KEMPF> From: "James Kempf" To: Cc: References: Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Mon, 24 Mar 2003 10:50:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > I think I would like to see a precise definition of "frameworky". > > So would I! I think by calling something 'frameworky' there is an implication > of something a bit fuzzy involved. > Seamoby is now beyond the point where fuzzy is acceptable. We need a precise definition, so that the design team can execute on defining the protocol in the next three to four months, so that we can close the working group by fall. > That being said, what I would like to do is get the basic protocol > mechanisms (messages, data types, parameters, etc.) defined and > then have an appendix where we map the protocol to certain mobility > signaling protocols, like FMIP. This would give an opportunity for > others to 'map' the CTP to their particular needs, in future > documents. > This is an acceptable beginning. Pat and I will be working with the ADs over the next week or so to come up with a proposed charter revision that defines exactly what will be in the protocol documents, and what the schedule is for delivering them, based on the concensus established in SFO. When we have agreement, we will be posting the new charter to the mailing list. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 24 13:53:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28811 for ; Mon, 24 Mar 2003 13:53:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJBJO24570; Mon, 24 Mar 2003 14:11:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJAeO24533 for ; Mon, 24 Mar 2003 14:10:40 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28722 for ; Mon, 24 Mar 2003 13:50:13 -0500 (EST) Message-ID: <014901c2f236$4f32cbc0$036015ac@T23KEMPF> From: "James Kempf" To: Cc: References: Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Mon, 24 Mar 2003 10:50:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > I think I would like to see a precise definition of "frameworky". > > So would I! I think by calling something 'frameworky' there is an implication > of something a bit fuzzy involved. > Seamoby is now beyond the point where fuzzy is acceptable. We need a precise definition, so that the design team can execute on defining the protocol in the next three to four months, so that we can close the working group by fall. > That being said, what I would like to do is get the basic protocol > mechanisms (messages, data types, parameters, etc.) defined and > then have an appendix where we map the protocol to certain mobility > signaling protocols, like FMIP. This would give an opportunity for > others to 'map' the CTP to their particular needs, in future > documents. > This is an acceptable beginning. Pat and I will be working with the ADs over the next week or so to come up with a proposed charter revision that defines exactly what will be in the protocol documents, and what the schedule is for delivering them, based on the concensus established in SFO. When we have agreement, we will be posting the new charter to the mailing list. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Mar 24 14:22:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29640 for ; Mon, 24 Mar 2003 14:22:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OJghY26531 for seamoby-archive@odin.ietf.org; Mon, 24 Mar 2003 14:42:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJghO26528 for ; Mon, 24 Mar 2003 14:42:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29627 for ; Mon, 24 Mar 2003 14:22:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJf8O26476; Mon, 24 Mar 2003 14:41:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJe1O26427 for ; Mon, 24 Mar 2003 14:40:01 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29551 for ; Mon, 24 Mar 2003 14:19:33 -0500 (EST) Message-ID: <01b301c2f23a$686b6990$036015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> <009f01c3692a$b74a7940$a06015ac@T23KEMPF> <002901c2f152$11dd4000$68620f8a@eunsoo> <003901c36a5b$ba176750$036015ac@T23KEMPF> <00cc01c2f244$be58be20$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Mon, 24 Mar 2003 11:20:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So that there is no misunderstanding... I don't think having a new ICMP message is necessary. That's what I meant by the "one protocol" statement in RFC 1958. If there is a protocol, such as FMIP PrxyRtAdv/SolPrxyRtAdv, that performs a particular function, then don't invent another one. For learning-based information distribution, SolRtAdv would work as well. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Monday, March 24, 2003 12:34 PM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > James, > > Right.The design team proposed that the specification allows two options: > piggybacking as ICMP options and stand-alone messages. > I think this is a good approach that can satisfy many things. > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: "Eunsoo Shim" ; > Sent: Sunday, August 24, 2003 8:21 AM > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > > > Defining the CARD messages as generalized ICMP options for RFC 2461 and > > associated extentions is acceptable. I presume this is what you mean by > > "piggybacking". > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "James Kempf" ; > > Sent: Sunday, March 23, 2003 8:37 AM > > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > Work > > > > > > > It was agreed to make the CARD messages piggyback-able in the past. > > > Then the CARD messages could be transported even on top of other > messages > > > than FMIP messages. > > > Also we don't have to worry about how FMIP will turn out in the future. > Or > > > the FMIP designers don't have to worry about the semantics change > required > > > by the CARD protocol. > > > Piggybacking wouldn't be better than tight-coupling with FMIP? > > > > > > Eunsoo > > > > > > > Extending the semantics is the proposal. Or, alternatively, delivering > the > > > > learning-based information via a RS. > > > > > > > > If it turns out not to be a good match, then an additional message > could > > > be > > > > added for the learning based approach. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Eunsoo Shim" > > > > To: "James Kempf" ; > > > > Sent: Saturday, March 22, 2003 1:13 PM > > > > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > > > Work > > > > > > > > > > > > > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR > information > > > > > after discovery. > > > > > In Dycard, the discovery requires messages between MN and AR for > > > delivering > > > > > the IP address of the previous AR to the current AR. This is beyond > the > > > > > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > > > > > I wonder whether the proposal is to extend the semantics of FMIP > > > > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages > between > > > AR > > > > > and MN for CARD. > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > This email is to confirm the concensus at the IETF 56 meeting to > > > proceed > > > > > toward > > > > > > completing the Seamoby work and closing the Working Group. This > email > > > also > > > > > > advances proposals for a couple of other issues that were not > > > discussed at > > > > > the > > > > > > meeting but are required to close out Seamoby. > > > > > > > > > > > > CARD: > > > > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > > > > - Take draft-ietf-seamoby-card-protocol-01.txt to > Experimental > > > > > rather than > > > > > > Proposed Standard > > > > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD > > > information > > > > > on > > > > > > AR-MN interface. Consult with FMIP draft editor about best > way > > > to > > > > > do > > > > > > this.. > > > > > > - Complete protocol on AR-AR interface that will support > both > > > > > learning > > > > > > based > > > > > > and server based approaches. > > > > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > > > > > > > CT: > > > > > > > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather > than > > > > > > Proposed Standard. > > > > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > > > > > > > We did not discuss the following issues, here they are with some > > > > > suggestions: > > > > > > about how to resolve them > > > > > > > > > > > > - What to do with > draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > > > > Since a clear statement of the problem is necessary for > > > formulating > > > > > > the research questions, continue to advance this document > to > > > > > > Informational. > > > > > > > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > > > > Seamoby is to support fast handover, focus on a design > > > > > > that integrated well with FMIP signaling. > > > > > > > > > > > > Discussion? > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 24 14:23:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29661 for ; Mon, 24 Mar 2003 14:23:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJf8O26476; Mon, 24 Mar 2003 14:41:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OJe1O26427 for ; Mon, 24 Mar 2003 14:40:01 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29551 for ; Mon, 24 Mar 2003 14:19:33 -0500 (EST) Message-ID: <01b301c2f23a$686b6990$036015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <00ba01c36806$50f2fca0$8b6015ac@T23KEMPF> <001e01c2f0af$7bbb4a10$7a620f8a@eunsoo> <009f01c3692a$b74a7940$a06015ac@T23KEMPF> <002901c2f152$11dd4000$68620f8a@eunsoo> <003901c36a5b$ba176750$036015ac@T23KEMPF> <00cc01c2f244$be58be20$e26b0f8a@eunsoo> Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work Date: Mon, 24 Mar 2003 11:20:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So that there is no misunderstanding... I don't think having a new ICMP message is necessary. That's what I meant by the "one protocol" statement in RFC 1958. If there is a protocol, such as FMIP PrxyRtAdv/SolPrxyRtAdv, that performs a particular function, then don't invent another one. For learning-based information distribution, SolRtAdv would work as well. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Monday, March 24, 2003 12:34 PM Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > James, > > Right.The design team proposed that the specification allows two options: > piggybacking as ICMP options and stand-alone messages. > I think this is a good approach that can satisfy many things. > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: "Eunsoo Shim" ; > Sent: Sunday, August 24, 2003 8:21 AM > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work > > > > Defining the CARD messages as generalized ICMP options for RFC 2461 and > > associated extentions is acceptable. I presume this is what you mean by > > "piggybacking". > > > > jak > > > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "James Kempf" ; > > Sent: Sunday, March 23, 2003 8:37 AM > > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > Work > > > > > > > It was agreed to make the CARD messages piggyback-able in the past. > > > Then the CARD messages could be transported even on top of other > messages > > > than FMIP messages. > > > Also we don't have to worry about how FMIP will turn out in the future. > Or > > > the FMIP designers don't have to worry about the semantics change > required > > > by the CARD protocol. > > > Piggybacking wouldn't be better than tight-coupling with FMIP? > > > > > > Eunsoo > > > > > > > Extending the semantics is the proposal. Or, alternatively, delivering > the > > > > learning-based information via a RS. > > > > > > > > If it turns out not to be a good match, then an additional message > could > > > be > > > > added for the learning based approach. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Eunsoo Shim" > > > > To: "James Kempf" ; > > > > Sent: Saturday, March 22, 2003 1:13 PM > > > > Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby > > > Work > > > > > > > > > > > > > FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR > information > > > > > after discovery. > > > > > In Dycard, the discovery requires messages between MN and AR for > > > delivering > > > > > the IP address of the previous AR to the current AR. This is beyond > the > > > > > purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages. > > > > > I wonder whether the proposal is to extend the semantics of FMIP > > > > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages > between > > > AR > > > > > and MN for CARD. > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > This email is to confirm the concensus at the IETF 56 meeting to > > > proceed > > > > > toward > > > > > > completing the Seamoby work and closing the Working Group. This > email > > > also > > > > > > advances proposals for a couple of other issues that were not > > > discussed at > > > > > the > > > > > > meeting but are required to close out Seamoby. > > > > > > > > > > > > CARD: > > > > > > - Drop draft-ietf-seamoby-card-requirements-02.txt. > > > > > > - Take draft-ietf-seamoby-card-protocol-01.txt to > Experimental > > > > > rather than > > > > > > Proposed Standard > > > > > > - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD > > > information > > > > > on > > > > > > AR-MN interface. Consult with FMIP draft editor about best > way > > > to > > > > > do > > > > > > this.. > > > > > > - Complete protocol on AR-AR interface that will support > both > > > > > learning > > > > > > based > > > > > > and server based approaches. > > > > > > - Protocol design complete by IETF 57 in Vienna. > > > > > > > > > > > > CT: > > > > > > > > > > > > - Drop draft-ietf-seamoby-ct-reqs-05.txt. > > > > > > - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather > than > > > > > > Proposed Standard. > > > > > > - Complete protocol design by IETF 57 in Vienna. > > > > > > > > > > > > We did not discuss the following issues, here they are with some > > > > > suggestions: > > > > > > about how to resolve them > > > > > > > > > > > > - What to do with > draft-ietf-seamoby-cardiscovery-issues-04.txt. > > > > > > Since a clear statement of the problem is necessary for > > > formulating > > > > > > the research questions, continue to advance this document > to > > > > > > Informational. > > > > > > > > > > > > - Relationship between CT and FMIP. Since the purpose of > > > > > > Seamoby is to support fast handover, focus on a design > > > > > > that integrated well with FMIP signaling. > > > > > > > > > > > > Discussion? > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Mar 27 21:31:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01706 for ; Thu, 27 Mar 2003 21:31:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S2qmB14617 for seamoby-archive@odin.ietf.org; Thu, 27 Mar 2003 21:52:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2qlO14614 for ; Thu, 27 Mar 2003 21:52:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01687 for ; Thu, 27 Mar 2003 21:30:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2qWO14601; Thu, 27 Mar 2003 21:52:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2ppO14572 for ; Thu, 27 Mar 2003 21:51:51 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01650 for ; Thu, 27 Mar 2003 21:29:46 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2S2WBB6004589; Thu, 27 Mar 2003 19:32:12 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id TAA04462; Thu, 27 Mar 2003 19:31:51 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.115]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h2S2Vql25182; Thu, 27 Mar 2003 20:31:53 -0600 Message-ID: <3E83C220.4060101@nal.motlabs.com> Date: Fri, 28 Mar 2003 04:31:44 +0100 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: , , References: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> <20030324.200720.26220860.ernst@sfc.wide.ad.jp> In-Reply-To: <20030324.200720.26220860.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: MN defined twice and lack of MH (was: The NEMO/Seamoby terminology) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > [NEMO folks involve in terminology, please review suggestions > below] Sorry for following up late on this, and posting on both lists is not good from my part, sorry. > o Mobile Node (MN) An IP node, either a host or a router, capable > of changing its point of attachment to the network, moving from one > link to another link [while maintaining continuous sessions] Mobile IPv6 draft 21 has this: "mobile node A node that can change its point of attachment from one link to another, while still being reachable via its home address." Which is basically the same thing said twice? What would be helpful for me, at this moment, is a help to be able to talk about MR contrasted to a MN that is not a router. Normally, MN can be either a mobile host, or a mobile router, because node is an entity that runs IP, and a host is a node that is not a router. So, I would like to be able to say "contrary to a MN implementation, an MR implementation will send RAs on the home link (if at home)". And I can not say that, because a MN can be a MR as well as a mobile host. A better formulation would be: "contrary to a MH implementation, an MR implementation will send RAs on the home link (if at home)". So I was trying to talk about MH to stand for mobile host only; (this might conflict with Mobility Header abbreviating MH too). Alex -- Message Classification: GBU _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 27 21:31:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01720 for ; Thu, 27 Mar 2003 21:31:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2qWO14601; Thu, 27 Mar 2003 21:52:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2ppO14572 for ; Thu, 27 Mar 2003 21:51:51 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01650 for ; Thu, 27 Mar 2003 21:29:46 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2S2WBB6004589; Thu, 27 Mar 2003 19:32:12 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id TAA04462; Thu, 27 Mar 2003 19:31:51 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.115]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h2S2Vql25182; Thu, 27 Mar 2003 20:31:53 -0600 Message-ID: <3E83C220.4060101@nal.motlabs.com> Date: Fri, 28 Mar 2003 04:31:44 +0100 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: , , References: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> <20030324.200720.26220860.ernst@sfc.wide.ad.jp> In-Reply-To: <20030324.200720.26220860.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: MN defined twice and lack of MH (was: The NEMO/Seamoby terminology) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > [NEMO folks involve in terminology, please review suggestions > below] Sorry for following up late on this, and posting on both lists is not good from my part, sorry. > o Mobile Node (MN) An IP node, either a host or a router, capable > of changing its point of attachment to the network, moving from one > link to another link [while maintaining continuous sessions] Mobile IPv6 draft 21 has this: "mobile node A node that can change its point of attachment from one link to another, while still being reachable via its home address." Which is basically the same thing said twice? What would be helpful for me, at this moment, is a help to be able to talk about MR contrasted to a MN that is not a router. Normally, MN can be either a mobile host, or a mobile router, because node is an entity that runs IP, and a host is a node that is not a router. So, I would like to be able to say "contrary to a MN implementation, an MR implementation will send RAs on the home link (if at home)". And I can not say that, because a MN can be a MR as well as a mobile host. A better formulation would be: "contrary to a MH implementation, an MR implementation will send RAs on the home link (if at home)". So I was trying to talk about MH to stand for mobile host only; (this might conflict with Mobility Header abbreviating MH too). Alex -- Message Classification: GBU _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby