From mailman-bounces@ietf.org Sat Jan 1 05:55:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08614 for ; Sat, 1 Jan 2005 05:55:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ckh6y-00075H-5c for mip4-web-archive@ietf.org; Sat, 01 Jan 2005 06:07:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgEV-0006t2-4x for mip4-web-archive@ietf.org; Sat, 01 Jan 2005 05:11:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: mip4-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:03:09 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for mip4-web-archive@ietf.org: List Password // URL ---- -------- mip4@ietf.org imreeb https://www1.ietf.org/mailman/options/mip4/mip4-web-archive%40ietf.org From mip4-bounces@ietf.org Tue Jan 4 04:55:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27900 for ; Tue, 4 Jan 2005 04:55:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cllbp-0001CL-9e for mip4-web-archive@ietf.org; Tue, 04 Jan 2005 05:08:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CllHd-0007gD-E4; Tue, 04 Jan 2005 04:47:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CllFb-000732-P8 for mip4@megatron.ietf.org; Tue, 04 Jan 2005 04:45:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27203 for ; Tue, 4 Jan 2005 04:45:13 -0500 (EST) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CllRw-0000yI-1y for mip4@ietf.org; Tue, 04 Jan 2005 04:58:00 -0500 Received: from celerio.ucdavis.edu (celerio.ucdavis.edu [169.237.104.178]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j049jBF5022724 for ; Tue, 4 Jan 2005 01:45:12 -0800 (PST) Received: from celerio.ucdavis.edu (localhost [127.0.0.1]) by celerio.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j049jB24029289 for ; Tue, 4 Jan 2005 01:45:11 -0800 (PST) Received: (from www@localhost) by celerio.ucdavis.edu (8.12.10/8.12.9/Submit) id j049jB4g029288; Tue, 4 Jan 2005 01:45:11 -0800 (PST) Date: Tue, 4 Jan 2005 01:45:11 -0800 (PST) Message-Id: <200501040945.j049jB4g029288@celerio.ucdavis.edu> To: mip4@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Mip4] Call for Papers: IEEE JSAC MRNM X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 4 16:18:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23021 for ; Tue, 4 Jan 2005 16:18:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClwGr-0000Xe-Ub for mip4-web-archive@ietf.org; Tue, 04 Jan 2005 16:31:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clvma-00073Q-2u; Tue, 04 Jan 2005 16:00:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClUvR-00011I-1M; Mon, 03 Jan 2005 11:19:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10667; Mon, 3 Jan 2005 11:19:18 -0500 (EST) Received: from nova.ceas.rochester.edu ([128.151.162.1] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClV7Z-0007r5-BX; Mon, 03 Jan 2005 11:31:56 -0500 Received: from nova.ceas.rochester.edu (smlist@nova.ceas.rochester.edu [128.151.162.1]) by nova.ceas.rochester.edu (8.13.1/8.13.0) with ESMTP id j03G9nKS016845; Mon, 3 Jan 2005 11:09:51 -0500 (EST) Received: (from smlist@localhost) by nova.ceas.rochester.edu (8.13.1/8.13.0/Submit) id j03G8NGc016661; Mon, 3 Jan 2005 11:08:23 -0500 (EST) Resent-Date: Mon, 3 Jan 2005 11:08:23 -0500 (EST) X-Authentication-Warning: nova.ceas.rochester.edu: smlist set sender to dcoss05-request@seas.rochester.edu using -f Message-ID: <41D96DF6.1090104@ece.rochester.edu> Date: Mon, 03 Jan 2005 11:08:22 -0500 From: Wendi Heinzelman User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wendi Heinzelman Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Resent-Message-ID: Resent-From: dcoss05@seas.rochester.edu X-Mailing-List: archive/latest/8 X-Loop: dcoss05@seas.rochester.edu Precedence: list Resent-Sender: dcoss05-request@seas.rochester.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 04 Jan 2005 15:59:58 -0500 Subject: [Mip4] Call for Papers-- IEEE International Conference on Distributed Computing in Sensor Systems X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Content-Transfer-Encoding: 7bit [Apologies if you receive multiple copies of this CFP] ========================================= IEEE International Conference on Distributed Computing in Sensor Systems June 30 - July 1, 2005 Marina del Rey, California, USA ========================================= ********** Paper submission deadline: January 10, 2005 ********** WWW.DCOSS.ORG The 2005 International Conference on Distributed Computing in Sensor Systems (DCOSS '05) will take place in Marina del Rey during June 30 - July 1, 2005. DCOSS is motivated by the successful ALGOSENSORS '04 (Algorithmic aspects of wireless sensor networks) workshop, which was co-located with ICALP and LICS in Finland on 16 July, 2004. While the scope of ALGOSENSORS was focused on algorithms for wireless sensor networks, DCOSS '05 is intended to cover several aspects of distributed computing in sensor systems such as high level abstractions, computational models, systematic design methodologies, algorithms, analysis and applications. The conference will provide a forum for researchers and practitioners to present their contributions related to the above high-level aspects of distributed sensor systems. In addition to contributed papers, the meeting will also include keynote addresses by leading researchers, a panel discussion, and a poster/presentation session. Located in Marina del Rey, a beach side community that is the home of the world's largest man-made harbor, the meeting venue can be easily reached from the Los Angeles International Airport (LAX). Most of the world famous attractions of the greater Los Angeles area - including the Santa Monica mountains, the Getty Center, Hollywood, Venice Beach, Disneyland, and Universal Studios can be easily reached from the Marina. SPONSORED BY IEEE Computer Society Technical Committee on Parallel Processing (TCPP) IEEE Computer Society Technical Committee on Distributed Processing (TCDP) Held in co-operation with ACM SIGARCH ACM SIGBED European Association for Theoretical Computer Science (EATCS) IFIP WG 10.3 MEETING INFORMATION The advance program will be available in April 2005. Check http://www.dcoss.org/ for updated information. IMPORTANT DATES January 10, 2005 Conference Submission Due March 15, 2005 Notification of Acceptance/Rejection April 15, 2005 Camera-Ready Paper Due ------------------------------------------------------------------------ ============================== CALL FOR PARTICIPATION ============================== CALL FOR PAPERS Distributed sensor systems have become a highly active research area due to their potential for providing diverse new capabilities. Such systems allow intelligent dense monitoring of physical environments, which makes them immensely useful for data collection and analysis. While much ongoing research has addressed networking, communication and low-level self-configuration issues in such systems, there are also significant challenges pertaining to systematic design, algorithm development and analysis, and abstract modeling in order to achieve efficient and robust realizations of large-scale distributed sensor systems. The large number of sensor devices involved, severe power, computational and memory limitations, resource heterogeneity, dense deployment and frequent failures pose novel challenges to design, algorithms, analysis and implementation. The focus of the conference is on distributed computing issues in large-scale networked sensor systems (including algorithms, applications, and systematic design techniques and tools), but networking-related contributions that support high level abstractions are also welcome. Topics of interest include but are not limited to: - Computation and programming models - Energy models, minimization, awareness - Distributed algorithms for collaborative information processing - Theoretical performance analysis: complexity, correctness, scalability, fault-tolerance - Abstractions for modular design - Languages, operating systems - Task allocation, reprogramming and reconfiguration - Dynamic resource management - Scalable, heterogeneous architectures (node and system-level) - Middleware interfaces, communication and processing primitives - Design, simulation and optimization tools for deployment and operation - Design automation and application synthesis techniques - Case studies: lessons from real world deployments Authors are invited to submit original unpublished manuscripts that demonstrate current research on computational aspects of distributed sensor systems. Submitted manuscripts may not exceed 14 single-spaced pages using 12-point size font on 8.5x11 inch pages, including figures and tables. References may be included in addition to the 14 pages. Authors need to make sure that the electronically submitted files are formatted for 8.5x11 inch paper. Submissions will be judged on correctness, originality, technical strength, significance, quality of presentation, and interest and relevance to the conference attendees. Submitted papers may not have appeared in or be under consideration for another conference or a journal. Submission procedures are available via Web access at http://www.dcoss.org/ All manuscripts will be reviewed. Manuscripts must be received by January 10, 2005, by 5 p.m. U.S. Pacific Coast Time. Notification of review decisions will be mailed by March 15, 2005. Camera-ready papers will be due April 15, 2005. DCOSS '05 Proceedings will be distributed at the Conference. PROGRAM CHAIR Viktor K. Prasanna University of Southern California USA PROGRAM VICE CHAIRS Algorithms: Paul Spirakis, CTI and University of Patras, Greece Applications: Sitharama Iyengar, Louisiana State University, USA Systems: Matt Welsh, Harvard University, USA PROGRAM COMMITTEE Tarek Abdelzaher, University of Virginia, USA Micah Adler, University of Massachusetts, Amherst, USA Prathima Agrawal, Auburn University, USA James Aspnes, Yale University, USA N. Balakrishnan, Indian Institute of Science, India Azzedine Boukerche, University of Ottawa, Canada Richard Brooks, Clemson University, USA John Byers, Boston University, USA Krishnendu Chakrabarty, Duke University, USA David Culler, University of California, Berkeley, USA Kevin A. Delin, NASA/JPL, USA Josep Diaz, Technical University of Catalonia, Spain Jeremy Elson, Microsoft Research, USA Deborah Estrin, University of California, Los Angeles, USA Deepak Ganesan, University of Massachusetts, Amherst, USA Johannes Gehrke, Cornell University, USA Phil Gibbons, Intel Research, Pittsburgh, USA Ashish Goel, Stanford University, USA Wendi Heinzelman, University of Rochester, USA Jennifer Hou, University of Illinois, Urbana Champaign, USA R. Kannan, Louisiana State University, USA Elias Koutsoupias, University of Athens, Greece Evangelos Kranakis, Carleton University, Canada P. R. Kumar, University of Illinois, Urbana Champaign, USA Margaret Martonosi, Princeton University, USA Rajeev Motwani, Stanford University, USA Badri Nath, Rutgers University, USA Stephan Olariu, Old Dominion University, USA David Peleg, Weizmann Institute of Science, Israel S. Phoha, Pennsylvania State University, USA Cristina Pinotti, University of Trento, Italy Kris Pister, University of California, Berkeley, and Dust, Inc., USA S. V. N. Rao, Oak Ridge National Lab, USA Satish Rao, University of California, Berkeley, USA Jim Reich, Palo Alto Research Center, USA Shivakumar Sastry, University of Akron, USA Christian Scheideler, Johns Hopkins University, USA John A. Stankovic, University of Virginia, USA Janos Sztipanovits, Vanderbilt University, USA Bhavani Thuraisingham, National Science Foundation, USA Jan van Leeuwen, Utrecht University, The Netherlands Jay Warrior, Agilent Labs, USA Peter Widmayer, ETH Zurich, Switzerland Jie Wu, Florida Atlantic University, USA Feng Zhao, Microsoft Research, USA POSTER/PRESENTATION SESSION The conference will also include a special plenary session with select presentations and posters from industry and academia. The focus of this session will be on practical applications of sensor systems and experience with real deployments. This will include a short overview talk, followed by audience interactions with the speakers in a "walk-up-and-talk" setting. Participation in this session is primarily by invitation, but interested parties are encouraged to contact the poster/presentation chair. ================================= DCOSS '05 ORGANIZATION ================================= GENERAL CHAIR Jose Rolim University of Geneva Switzerland VICE GENERAL CHAIR Sotiris Nikoletseas University of Patras and CTI Greece PROGRAM CHAIR Viktor K. Prasanna University of Southern California USA POSTER/PRESENTATION CHAIR Bhaskar Krishnamachari University of Southern California USA PROCEEDINGS CHAIR Pierre Leone EIG Switzerland STUDENT SCHOLARSHIPS CHAIR Loren Schwiebert Wayne State University USA PUBLICITY CHAIR Wendi Heinzelman University of Rochester USA PUBLICITY CO-CHAIRS Erdal Cayirci Yeditepe University and Istanbul Technical University Turkey Sanjay Jha University of New South Wales Australia FINANCE CHAIR Germaine Gusthiot University of Geneva Switzerland STEERING COMMITTEE Josep Diaz, UPC Barcelona, Spain Deborah Estrin, University of California, Los Angeles, USA Phil Gibbons, Intel Research, Pittsburgh, USA Sotiris Nikoletseas, University of Patras and CTI, Greece Christos Papadimitriou, University of California, Berkeley, USA Kris Pister, University of California, Berkeley, and Dust, Inc., USA Viktor Prasanna, University of Southern California, Los Angeles, USA Jose Rolim, University of Geneva, Switzerland (CHAIR) ---------------------------------------------------------- Wendi B. Heinzelman Assistant Professor of Electrical and Computer Engineering University of Rochester P.O. Box 270126, Hopeman Building, Room 307 Rochester, NY 14627-0126 Phone: 585-275-4053 Fax: 585-273-4919 http://www.ece.rochester.edu/~wheinzel ---------------------------------------------------------- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 5 13:28:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28137 for ; Wed, 5 Jan 2005 13:28:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmG5w-0008Qe-8v for mip4-web-archive@ietf.org; Wed, 05 Jan 2005 13:41:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFpM-0006B3-IE; Wed, 05 Jan 2005 13:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmDXz-0005IK-M5 for mip4@megatron.ietf.org; Wed, 05 Jan 2005 10:58:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15854 for ; Wed, 5 Jan 2005 10:58:02 -0500 (EST) Received: from kronos.cti.gr ([150.140.1.25]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmDkX-0008Gp-Jl for mip4@ietf.org; Wed, 05 Jan 2005 11:11:06 -0500 Received: (qmail 12462 invoked from network); 5 Jan 2005 15:52:01 -0000 Received: from hermes.cti.gr (150.140.7.30) by kronos.cti.gr with SMTP; 5 Jan 2005 15:52:01 -0000 Received: (qmail 16335 invoked by uid 41021); 5 Jan 2005 15:48:30 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Jan 2005 15:48:30 -0000 Date: Wed, 5 Jan 2005 17:48:30 +0200 (EET) From: Ioannis Chatzigiannakis To: ichatz@cti.gr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd X-Mailman-Approved-At: Wed, 05 Jan 2005 13:24:11 -0500 Subject: [Mip4] Final CFP: WEA 2004 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 [Apologies for multiple copies] FINAL CALL FOR PAPERS WEA 2005 4th International Workshop on Efficient and Experimental Algorithms Santorini Island, Greece May 10 to 13, 2005 http://ru1.cti.gr/wea05/ The WEA Workshops are intended to be an international forum for researchers in the area of design, analysis, and experimental evaluation and engineering of algorithms, as well as in various aspects of computational optimization and its applications. The three preceding Workshops in this series were held in Riga (2001), Monte Verita (2003, http://www.idsia.ch/wea2003/) and Rio de Janeiro (2004, http://wea2004.inf.puc-rio.br/). The WEA 2005 Workshop is sponsored by the European Association for Theoretical Computer Science (EATCS) and the EU IST/FET R&D Projects FLAGS ("Foundational Aspects of Global Computing Systems") and DELIS ("Dynamically Evolving Large-scale Information Systems") and the Research Academic Computer Technology Institute (RACTI). TOPICS Original research contributions are solicited covering a variety of topics including but not limited to: - Algorithm Engineering - Algorithmic Mechanism Design - Analysis of Algorithms - Approximation Techniques - Branch and Bound Algorithms - Combinatorial Structures and Graphs - Combinatorial and Irregular Problems - Communication Networks - Computational Learning Theory - Computational Optimization - Computer Systems - Cryptography and Security - Data Structures - Distributed Algorithms - Evaluation of Algorithms for Realistic Environments - Graph Drawing - Heuristics for Combinatorial Optimization - Implementation, Testing, Evaluation and Fine-tuning of Algorithms - Information Retrieval - Integer Programming - Logistics and Operations Management - Machine Learning and Data Mining - Mathematical Programming - Metaheuristic Methodologies - Network Analysis - Novel Applications of Algorithms in Other Disciplines - On-line Problems - Parallel Algorithms and Computing - Railway Optimization using Algorithmic Methods - Randomized Techniques - Robotics - Semidefinite Programming - Simulation - Software Repositories and Platforms for using Algorithms - Telecommunications and Networking - World Wide Web Algorithms GENERAL and PC CHAIR Sotiris Nikoletseas, University of Patras and CTI, Greece PROGRAM COMMITTEE - Edoardo Amaldi, Politecnico di Milano, Italy - Evripidis Bampis, University d'Evry, France - David A. Bader, University of New Mexico, USA - Cynthia Barnhart, MIT, USA - Azzedine Boukerche, SITE, University of Ottawa, Canada - Gerth Brodal, University of Aarhus, Denmark - Rainer Burkard, Graz University of Technology, Austria - Giuseppe Di Battista, Universita' degli Studi Roma Tre, Italy - Rudolf Fleischer, Fudan University, Shanghai, P.R.C. - Pierre Fraigniaud, CNRS, Universite Paris-Sud, France - Mark Goldberg, Rensselaer Polytechnic Institute, USA - Juraj Hromkovic, ETH Zurich, Switzerland - Giuseppe Italiano, Universita' di Roma Tor Vergata, Italy - Christos Kaklamanis, University of Patras and CTI, Greece - Helen Karatza, Aristotle University of Thessaloniki, Greece - Ludek Kucera, Charles University, Czech Republic - Shay Kutten, Technion - Israel Institute of Technology, Israel - Catherine McGeoch, Amherst College, USA - Simone Martins, Universidade Federal Fluminense, Brasil - Bernard Moret, University of New Mexico, USA - Ian Munro, University of Waterloo, Canada - Sotiris Nikoletseas, University of Patras and CTI, Greece (Chair) - Andrea Pietracaprina, University of Padova, Italy - Tomasz Radzik, King's College London, UK - Rajeev Raman, University of Leicester, UK - Mauricio Resende, AT&T Labs Research, USA - Maria Serna, T.U. of Catalonia, Spain - Paul Spirakis, University of Patras and CTI, Greece - Eric Taillard, EIVD, University of Applied Sciences of Western Switzerland - Dorothea Wagner, University Karlsruhe, Germany - Stefan Voss, University of Hamburg, Germany - Christos Zaroliagis, University of Patras and CTI, Greece INVITED SPEAKERS: - Christos Papadimitriou, University of California at Berkeley, USA - Celso Ribeiro, Catholic University of Rio de Janeiro, Brasil - David A. Bader, University of New Mexico, USA STEERING COMMITTEE CHAIRS - Klaus Jansen, University of Kiel, Germany - Jose Rolim, University of Geneva, Switzerland PROCEEDINGS AND JEA SPECIAL ISSUE The Proceedings of WEA 2005 will be published in the Series Lecture Notes in Computer Science (LNCS), by Springer Verlag. Selected papers from WEA 2005 will be considered for a Special Issue of the ACM Journal of Experimental Algorithmics (JEA, http://www.jea.acm.org/). SUBMISSION GUIDELINES Authors are invited to submit manuscripts reporting original unpublished research and recent developments in the topics related to the Workshop. Simultaneous submission to conferences with published proceedings is not allowed. Papers should not exceed twelve (12) SINGLE-spaced pages of text, using at least 11 point size type on 8.5 x 11 inch pages, including references, figures, tables, etc. It is highly recommended to use the Springer LNCS LATEX style format (www.springer.de/comp/lncs/authors.html). Additional material may be added at a clearly marked Appendix to be read at the discretion of the Program Committee Members. Authors must submit their papers electronically via EDAS (http://edas.info/) All papers will be peer reviewed and comments will be provided to the authors. Authors need to make sure that for each accepted paper at least one author will attend the Workshop. IMPORTANT DATES: - Submission Deadline: January 17, 2005, 11pm GMT - Author Notification: February 28, 2005 - Final Manuscript Due: March 14, 2005 LOCAL AND HOTEL INFORMATION Useful hotel and local information can be found at the following site: http://wea2005.conferences.gr ORGANIZING COMMITTEE: - Ioannis Chatzigiannakis, CTI, Greece (Co-Chair) - Rozina Efstathiadou, CTI, Greece, (Co-chair) - Athanassios Kinalis, CTI and U. of Patras, Greece, Webmaster - Lena Gourdoupi, CTI, Greece, Registration and Hotel - TBA, Proceedings and Systems -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 5 18:02:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28269 for ; Wed, 5 Jan 2005 18:02:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmKNN-00016A-DO for mip4-web-archive@ietf.org; Wed, 05 Jan 2005 18:15:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmK9Y-0004T5-TU; Wed, 05 Jan 2005 18:01:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmK6N-0003VE-SO for mip4@megatron.ietf.org; Wed, 05 Jan 2005 17:58:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27988 for ; Wed, 5 Jan 2005 17:58:00 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmKJ0-0008MH-D2 for mip4@ietf.org; Wed, 05 Jan 2005 18:11:09 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j05MtpTh021877; Wed, 5 Jan 2005 16:55:51 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j05Mtn810663; Wed, 5 Jan 2005 16:55:49 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I9V90X-00021S-00; Wed, 05 Jan 2005 17:55:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16860.28783.634374.722633@gargle.gargle.HOWL> Date: Wed, 5 Jan 2005 16:55:43 -0600 From: Pete McCann To: Charlie P Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <41DC5E5E.6000003@iprg.nokia.com> References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: Kent Leung , mip4@ietf.org, henrik@levkowetz.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Bringing some off-list discussion back into the fold... Charlie P writes: > Pete McCann wrote: > > >After mulling over this issue some more, I am tending to agree with > >Kent's reasoning below. We had talked about allowing some exceptions > >to the SA processing, but the exact conditions under which the > >exceptions apply seem fuzzy to me (remember, they have to be identical > >and computable at both the FA and HA). > > > > > I don't see anything wrong with the idea of prohibiting FHAE > on deregistrations for external care-of addresses. The home > agent will have no difficulty with this. At the last IETF, and > during the discussion in the room, this seemed like a workable > solution without any technical diffculties raised. I am still having trouble with the definition of "external care-of addresses". (see my previous e-mail to the list). Is it possible to define this set such that both the FA and HA are in agreement on which de-registrations are excluded from security processing? How does the HA know which care-of addresses are "external" to a given FA? Even if we could define this properly, I am having more and more doubts that this sort of processing belongs at the Mobile IP security layer. Imagine if we were using IPSec for security (which, thankfully, we are not right now) and trying to convince an IPSec implementor to put exceptions into the SAD based on the contents of the message... it would be absolutely, totally, and in all other ways inconceivable. I understand the motivation here; we don't want the FA to be able to disrupt a de-registration that doesn't concern it. However, modifying the security processing in the FA and HA doesn't really achieve that goal; the FA could still, for example, drop the packet without forwarding it to the HA, as could any router along the e2e path. Maybe the real problem here is the 'R' bit. I proposed once before that we allow de-registrations to go directly to the HA, even if the 'R' bit is set, but there was at least one objection. Can someone remind me what was the basis for it? > Regards, > Charlie P. -Pete Kent Leung writes: > Hi Charlie. > > I was addressing the issue from the context of a NAT environment > by using the CoA field for indexing the security association. But > realize that I should not be bundling the NAT issue with the > deregistration and CCoA mode. The NAT problem should be > dealt with in 3519bis (likely adding a new source IP address field in the > extension for detection). > > Leaving the NAT issue aside, I agree with both you and Pete that the > the security association should be indexed by the source IP address > and SPI. This means that the FA can be identified by the source > IP address of the RRQ. Both registrations and deregistration are > protected by the SA. If there is any problem in the SA between HA and > FA, then both registration and deregistration will be problematic. This > problem needs to be fixed by the administrator. I think > if the SA exists, then FA and HA must append the FHAE when sending > message, as well as check for FHAE upon reception. Can't think of > good reasons why there should be exceptions. > > Kent > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 5 19:03:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06035 for ; Wed, 5 Jan 2005 19:03:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmLK7-00067F-JC for mip4-web-archive@ietf.org; Wed, 05 Jan 2005 19:16:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmKtx-000774-6o; Wed, 05 Jan 2005 18:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmKrh-0006VF-Jx for mip4@megatron.ietf.org; Wed, 05 Jan 2005 18:46:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05079 for ; Wed, 5 Jan 2005 18:46:54 -0500 (EST) Received: from av1-1-sn1.fre.skanova.net ([81.228.11.107]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmL4M-00021x-OF for mip4@ietf.org; Wed, 05 Jan 2005 19:00:03 -0500 Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id D8F0537FDE; Thu, 6 Jan 2005 00:46:22 +0100 (CET) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id CA96C37E48; Thu, 6 Jan 2005 00:46:22 +0100 (CET) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id B50F237E43; Thu, 6 Jan 2005 00:46:22 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1CmKr8-00016W-FX; Thu, 06 Jan 2005 00:46:22 +0100 Message-ID: <41DC7C4F.9020402@levkowetz.com> Date: Thu, 06 Jan 2005 00:46:23 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> In-Reply-To: <16860.28783.634374.722633@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Hi Pete, inline... on 2005-01-05 11:55 pm Pete McCann said the following: > Bringing some off-list discussion back into the fold... > > > > Charlie P writes: > > Pete McCann wrote: > > > > >After mulling over this issue some more, I am tending to agree with > > >Kent's reasoning below. We had talked about allowing some exceptions > > >to the SA processing, but the exact conditions under which the > > >exceptions apply seem fuzzy to me (remember, they have to be identical > > >and computable at both the FA and HA). > > > > > > > > I don't see anything wrong with the idea of prohibiting FHAE > > on deregistrations for external care-of addresses. The home > > agent will have no difficulty with this. At the last IETF, and > > during the discussion in the room, this seemed like a workable > > solution without any technical diffculties raised. > > I am still having trouble with the definition of "external care-of > addresses". (see my previous e-mail to the list). Is it possible to > define this set such that both the FA and HA are in agreement on which > de-registrations are excluded from security processing? How does the > HA know which care-of addresses are "external" to a given FA? Well, we could easily say that any care-of address which doesn't match the source address of the packet is an external address. This is a bit simplistic, but actually can be made to work also for FAs which have multiple care-of addresses (which is not a common thing in my experience) buy having the FA take care to always match source IP with care-of address when the care-of address is it's own. > Even if we could define this properly, I am having more and more > doubts that this sort of processing belongs at the Mobile IP security > layer. Imagine if we were using IPSec for security (which, > thankfully, we are not right now) and trying to convince an IPSec > implementor to put exceptions into the SAD based on the contents of > the message... it would be absolutely, totally, and in all other ways > inconceivable. Yes, but the analogy is flawed. With IPsec, you would not have the case that all traffic went through the tunnel, except for some particular messages which were dropped due to their content -- which would be closer to the case we are experiencing here. Anything like that should indeed be regarded as a flaw in IPsec. > I understand the motivation here; we don't want the FA to be able to > disrupt a de-registration that doesn't concern it. However, modifying > the security processing in the FA and HA doesn't really achieve that > goal; the FA could still, for example, drop the packet without > forwarding it to the HA, as could any router along the e2e path. Yes, but the big, huge difference is that consistently dropping certain packages would either be hostile or a bug in implementation, set-up, or administrator attitude ;-) To not only condone but actively choose to codify a practice which denies service to a MN in certain cases is improper, I believe. > Maybe the real problem here is the 'R' bit. I proposed once before > that we allow de-registrations to go directly to the HA, even if the > 'R' bit is set, but there was at least one objection. Can someone > remind me what was the basis for it? I have no objection - but I don't think it solves the problem in all cases. Some nets may very well permit egress only through the FA, so there may not be any route past the FA. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 5 19:22:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07369 for ; Wed, 5 Jan 2005 19:22:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmLcT-0001w6-Be for mip4-web-archive@ietf.org; Wed, 05 Jan 2005 19:35:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmLMW-00067g-Dg; Wed, 05 Jan 2005 19:18:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmLHe-00051S-AA for mip4@megatron.ietf.org; Wed, 05 Jan 2005 19:13:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07018 for ; Wed, 5 Jan 2005 19:13:42 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmLUH-0008HG-15 for mip4@ietf.org; Wed, 05 Jan 2005 19:26:52 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Jan 2005 16:21:25 -0800 Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j060D5l3018043; Wed, 5 Jan 2005 16:13:05 -0800 (PST) Date: Wed, 5 Jan 2005 16:13:09 -0800 (PST) From: Sri Gundavelli To: Pete McCann Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <16860.28783.634374.722633@gargle.gargle.HOWL> Message-ID: References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Kent Leung , mip4@ietf.org, henrik@levkowetz.com, Charlie P X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi Pete, On Wed, 5 Jan 2005, Pete McCann wrote: ... > forwarding it to the HA, as could any router along the e2e path. > > Maybe the real problem here is the 'R' bit. I proposed once before > that we allow de-registrations to go directly to the HA, even if the > 'R' bit is set, but there was at least one objection. Can someone > remind me what was the basis for it? > Some one could potentially enforce fire policies filtering all MIP control traffic originating from non FA-COA addresses and by enabling "R" bit for administrative control. So, allowing De-reg traffic directly ignoring the "R" bit may introduce problems. Sri. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 6 10:55:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18142 for ; Thu, 6 Jan 2005 10:55:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmaCB-0003uw-8R for mip4-web-archive@ietf.org; Thu, 06 Jan 2005 11:09:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZuW-0007fr-7L; Thu, 06 Jan 2005 10:50:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZqh-0006Qo-RH for mip4@megatron.ietf.org; Thu, 06 Jan 2005 10:46:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17274 for ; Thu, 6 Jan 2005 10:46:53 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cma3Q-0006pM-Lc for mip4@ietf.org; Thu, 06 Jan 2005 11:00:10 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j06FkGb5020362; Thu, 6 Jan 2005 09:46:17 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j06FkDO23437; Thu, 6 Jan 2005 09:46:13 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I9WJSS-0001WK-00; Thu, 06 Jan 2005 10:46:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16861.23867.168374.904893@gargle.gargle.HOWL> Date: Thu, 6 Jan 2005 09:46:03 -0600 From: Pete McCann To: Henrik Levkowetz Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <41DC7C4F.9020402@levkowetz.com> References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Hi, Henrik, Henrik Levkowetz writes: > Hi Pete, > > inline... > > on 2005-01-05 11:55 pm Pete McCann said the following: > > Bringing some off-list discussion back into the fold... > > > > > > > > Charlie P writes: > > > Pete McCann wrote: > > > > > > >After mulling over this issue some more, I am tending to agree with > > > >Kent's reasoning below. We had talked about allowing some exceptions > > > >to the SA processing, but the exact conditions under which the > > > >exceptions apply seem fuzzy to me (remember, they have to be identical > > > >and computable at both the FA and HA). > > > > > > > > > > > I don't see anything wrong with the idea of prohibiting FHAE > > > on deregistrations for external care-of addresses. The home > > > agent will have no difficulty with this. At the last IETF, and > > > during the discussion in the room, this seemed like a workable > > > solution without any technical diffculties raised. > > > > I am still having trouble with the definition of "external care-of > > addresses". (see my previous e-mail to the list). Is it possible to > > define this set such that both the FA and HA are in agreement on which > > de-registrations are excluded from security processing? How does the > > HA know which care-of addresses are "external" to a given FA? > > Well, we could easily say that any care-of address which doesn't match > the source address of the packet is an external address. This is a > bit simplistic, but actually can be made to work also for FAs which > have multiple care-of addresses (which is not a common thing in my > experience) buy having the FA take care to always match source IP > with care-of address when the care-of address is it's own. Ok, your assumptions about the security policy are slightly different from mine. I thought we were allowing an exemption for the case where the MN is de-registering an address that it obtained while connected to a different network (this is how I interpreted "external"). Addresses on the current subnet (even co-located CoAs) would NOT be exempted from security processing because they are "owned" in some sense by that FA, even though they are not the address of any interface of the FA. Clearly, this policy would be difficult or impossible to process at the HA because it can't know what addresses are on the same subnet as the FA. I agree your policy is easier to implement, but it effectively prohibits FHAE on any de-registration of a co-located COA. Is that what we want? If so, it could certainly be stated more clearly in the text than it is right now. > > Even if we could define this properly, I am having more and more > > doubts that this sort of processing belongs at the Mobile IP security > > layer. Imagine if we were using IPSec for security (which, > > thankfully, we are not right now) and trying to convince an IPSec > > implementor to put exceptions into the SAD based on the contents of > > the message... it would be absolutely, totally, and in all other ways > > inconceivable. > > Yes, but the analogy is flawed. > > With IPsec, you would not have the case that all traffic went through > the tunnel, except for some particular messages which were dropped > due to their content -- which would be closer to the case we are > experiencing here. Anything like that should indeed be regarded as > a flaw in IPsec. I don't understand how my proposal leads to dropped messages, as long as the SAs are properly configured between the FAs and HAs. > > I understand the motivation here; we don't want the FA to be able to > > disrupt a de-registration that doesn't concern it. However, modifying > > the security processing in the FA and HA doesn't really achieve that > > goal; the FA could still, for example, drop the packet without > > forwarding it to the HA, as could any router along the e2e path. > > Yes, but the big, huge difference is that consistently dropping > certain packages would either be hostile or a bug in implementation, > set-up, or administrator attitude ;-) > > To not only condone but actively choose to codify a practice which > denies service to a MN in certain cases is improper, I believe. That's not at all what I am suggesting. If the SA between the FA and HA is good then the packet won't be dropped. If the SA isn't working then the administrator needs to fix something. > > Maybe the real problem here is the 'R' bit. I proposed once before > > that we allow de-registrations to go directly to the HA, even if the > > 'R' bit is set, but there was at least one objection. Can someone > > remind me what was the basis for it? > > I have no objection - but I don't think it solves the problem in all > cases. Some nets may very well permit egress only through the FA, > so there may not be any route past the FA. Sure, the packets go through the FA, but I would argue that a policy (even with the 'R' bit set) that drops de-registration requests directed to the home agent is hostile or a bug in implementation, set-up, or administrator attitude. Maybe it would be easier to change those policies (with a recommendation/clarification about the meaning of the 'R' bit in 3344bis) than to make deep changes in the security association processing code. -Pete > Henrik > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 6 10:57:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18242 for ; Thu, 6 Jan 2005 10:57:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmaDH-0005JJ-Ff for mip4-web-archive@ietf.org; Thu, 06 Jan 2005 11:10:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZyt-0000T6-Tx; Thu, 06 Jan 2005 10:55:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZsK-0006sU-PK for mip4@megatron.ietf.org; Thu, 06 Jan 2005 10:48:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17459 for ; Thu, 6 Jan 2005 10:48:34 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cma55-00006C-Iu for mip4@ietf.org; Thu, 06 Jan 2005 11:01:51 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j06Flxrn021442; Thu, 6 Jan 2005 09:47:59 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j06FlsO26843; Thu, 6 Jan 2005 09:47:54 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I9WJVL-0001ZC-00; Thu, 06 Jan 2005 10:47:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16861.23968.208374.888917@gargle.gargle.HOWL> Date: Thu, 6 Jan 2005 09:47:44 -0600 From: Pete McCann To: Sri Gundavelli Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Kent Leung , mip4@ietf.org, henrik@levkowetz.com, Charlie P X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Hi, Sri, Sri Gundavelli writes: > > > Hi Pete, > > > On Wed, 5 Jan 2005, Pete McCann wrote: > > ... > > > forwarding it to the HA, as could any router along the e2e path. > > > > Maybe the real problem here is the 'R' bit. I proposed once before > > that we allow de-registrations to go directly to the HA, even if the > > 'R' bit is set, but there was at least one objection. Can someone > > remind me what was the basis for it? > > > > > Some one could potentially enforce fire policies filtering > all MIP control traffic originating from non FA-COA addresses > and by enabling "R" bit for administrative control. So, > allowing De-reg traffic directly ignoring the "R" bit may > introduce problems. Wouldn't it be easier to change those policies than to change the security association processing code? See my response to Henrik. -Pete > Sri. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 6 12:28:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25950 for ; Thu, 6 Jan 2005 12:28:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmbdz-0004zZ-31 for mip4-web-archive@ietf.org; Thu, 06 Jan 2005 12:41:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmbHU-0002cn-Ag; Thu, 06 Jan 2005 12:18:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmb2k-0004Ii-2P for mip4@megatron.ietf.org; Thu, 06 Jan 2005 12:03:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24440 for ; Thu, 6 Jan 2005 12:03:23 -0500 (EST) Received: from av1-2-sn4.m-sp.skanova.net ([81.228.10.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmbFX-0002RH-Bf for mip4@ietf.org; Thu, 06 Jan 2005 12:16:41 -0500 Received: by av1-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id A07B03801D; Thu, 6 Jan 2005 18:02:50 +0100 (CET) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av1-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 8FCD337F0E; Thu, 6 Jan 2005 18:02:50 +0100 (CET) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 6F33137E4C; Thu, 6 Jan 2005 18:02:50 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1Cmb29-0004Uq-TB; Thu, 06 Jan 2005 18:02:50 +0100 Message-ID: <41DD6F39.3000602@levkowetz.com> Date: Thu, 06 Jan 2005 18:02:49 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> In-Reply-To: <16861.23867.168374.904893@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 2.0 (++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit on 2005-01-06 4:46 pm Pete McCann said the following: > Hi, Henrik, > > > > Henrik Levkowetz writes: > > Hi Pete, > > > > inline... > > > > on 2005-01-05 11:55 pm Pete McCann said the following: > > > Bringing some off-list discussion back into the fold... > > > > > > > > > > > > Charlie P writes: > > > > Pete McCann wrote: > > > > > > > > >After mulling over this issue some more, I am tending to agree with > > > > >Kent's reasoning below. We had talked about allowing some exceptions > > > > >to the SA processing, but the exact conditions under which the > > > > >exceptions apply seem fuzzy to me (remember, they have to be identical > > > > >and computable at both the FA and HA). > > > > > > > > > > > > > > I don't see anything wrong with the idea of prohibiting FHAE > > > > on deregistrations for external care-of addresses. The home > > > > agent will have no difficulty with this. At the last IETF, and > > > > during the discussion in the room, this seemed like a workable > > > > solution without any technical diffculties raised. > > > > > > I am still having trouble with the definition of "external care-of > > > addresses". (see my previous e-mail to the list). Is it possible to > > > define this set such that both the FA and HA are in agreement on which > > > de-registrations are excluded from security processing? How does the > > > HA know which care-of addresses are "external" to a given FA? > > > > Well, we could easily say that any care-of address which doesn't match > > the source address of the packet is an external address. This is a > > bit simplistic, but actually can be made to work also for FAs which > > have multiple care-of addresses (which is not a common thing in my > > experience) buy having the FA take care to always match source IP > > with care-of address when the care-of address is it's own. > > Ok, your assumptions about the security policy are slightly different > from mine. I thought we were allowing an exemption for the case where > the MN is de-registering an address that it obtained while connected > to a different network (this is how I interpreted "external"). > Addresses on the current subnet (even co-located CoAs) would NOT be > exempted from security processing because they are "owned" in some > sense by that FA, even though they are not the address of any > interface of the FA. Clearly, this policy would be difficult or > impossible to process at the HA because it can't know what addresses > are on the same subnet as the FA. True; so this sounds as if we have a potential solution for the regular case (CoA belongs to the FA) but not for the R-bit case. > I agree your policy is easier to implement, but it effectively > prohibits FHAE on any de-registration of a co-located COA. Is that > what we want? If so, it could certainly be stated more clearly in the > text than it is right now. Yes. For not the first time I'm so tempted to advocate ripping out the R-bit... It causes such a lot of grief. Anyway, for Co-located CoA with registration through FA, we can then proceed by a. Disallowing FHAE on these de-registrations b. Defining a new extension to handle this case c. Restricting the use of the R-bit together with FHAE d. Grip the nettle and remove the R-bit from 3344bis e. Come up with another solution > > > Even if we could define this properly, I am having more and more > > > doubts that this sort of processing belongs at the Mobile IP security > > > layer. Imagine if we were using IPSec for security (which, > > > thankfully, we are not right now) and trying to convince an IPSec > > > implementor to put exceptions into the SAD based on the contents of > > > the message... it would be absolutely, totally, and in all other ways > > > inconceivable. > > > > Yes, but the analogy is flawed. > > > > With IPsec, you would not have the case that all traffic went through > > the tunnel, except for some particular messages which were dropped > > due to their content -- which would be closer to the case we are > > experiencing here. Anything like that should indeed be regarded as > > a flaw in IPsec. > > I don't understand how my proposal leads to dropped messages, as long > as the SAs are properly configured between the FAs and HAs. Mmm? With FHAE always used, the de-registrations of external CoAs get dropped, no? (Are we talking past each other here?) > > > I understand the motivation here; we don't want the FA to be able to > > > disrupt a de-registration that doesn't concern it. However, modifying > > > the security processing in the FA and HA doesn't really achieve that > > > goal; the FA could still, for example, drop the packet without > > > forwarding it to the HA, as could any router along the e2e path. > > > > Yes, but the big, huge difference is that consistently dropping > > certain packages would either be hostile or a bug in implementation, > > set-up, or administrator attitude ;-) > > > > To not only condone but actively choose to codify a practice which > > denies service to a MN in certain cases is improper, I believe. > > That's not at all what I am suggesting. If the SA between the FA and > HA is good then the packet won't be dropped. If the SA isn't working > then the administrator needs to fix something. Hmm, then I don't think I know exactly what you're suggesting (but see below) > > > Maybe the real problem here is the 'R' bit. I proposed once before > > > that we allow de-registrations to go directly to the HA, even if the > > > 'R' bit is set, but there was at least one objection. Can someone > > > remind me what was the basis for it? > > > > I have no objection - but I don't think it solves the problem in all > > cases. Some nets may very well permit egress only through the FA, > > so there may not be any route past the FA. > > Sure, the packets go through the FA, but I would argue that a policy > (even with the 'R' bit set) that drops de-registration requests > directed to the home agent is hostile or a bug in implementation, > set-up, or administrator attitude. Maybe it would be easier to change > those policies (with a recommendation/clarification about the meaning > of the 'R' bit in 3344bis) than to make deep changes in the security > association processing code. Ok, I see. Hmm, this sounds like a slightly new variation on the theme, and one which I've unfortunately not seen before. Do we have proposed text for this? From this first impression, it sounds to me as if it could be workable. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 6 14:05:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02672 for ; Thu, 6 Jan 2005 14:05:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmdAA-0001Fl-3t for mip4-web-archive@ietf.org; Thu, 06 Jan 2005 14:19:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcwF-00014i-TS; Thu, 06 Jan 2005 14:04:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcjH-0005iH-PM for mip4@megatron.ietf.org; Thu, 06 Jan 2005 13:51:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01635 for ; Thu, 6 Jan 2005 13:51:26 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmcw6-0008Bj-71 for mip4@ietf.org; Thu, 06 Jan 2005 14:04:43 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Jan 2005 10:59:18 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j06Ionvn018008; Thu, 6 Jan 2005 10:50:51 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-253.cisco.com [128.107.163.253]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAK43482; Thu, 6 Jan 2005 10:50:51 -0800 (PST) Message-Id: <4.3.2.7.2.20050106091852.0395ec08@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Jan 2005 10:50:50 -0800 To: Pete McCann From: Kent Leung Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <16860.28783.634374.722633@gargle.gargle.HOWL> References: <41DC5E5E.6000003@iprg.nokia.com> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: mip4@ietf.org, henrik@levkowetz.com, Charlie P X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Let's confirm what's agreed and what's not. Is there agreement that FHAE is used to protect message exchange between the FA and HA? Now seems there could possibly be an exception based on the following. >I understand the motivation here; we don't want the FA to be able to >disrupt a de-registration that doesn't concern it. This problem would not exist if the SA between FA and HA is legitimate, which is the common case. If there is a bad SA, then even registrations would fail. This would be completely noticeable, and the situation should be fixed by administrator. Deregistration is a corner case as described below. List of all deregistration cases: 1) MN returned home MN deregisters when back at home network. This is not applicable. 2) Single binding support a) MN deregisters from foreign network. Since MN is on newFA, there is no reason to deregister from oldFA because the only binding is for newFA. The deregistration may have CoA set to HoA or newFA. This is not applicable. b) MN moves to newFA and only deregister without registering on this FA. I think this is very uncommon case (pls correct me if wrong). Only in this corner case *and* the existence of a bad SA between newFA and HA (which must be fixed for mobility service to be available), will the problem statement apply. The harm is the HA would age out the binding entry later. Much as if MN had lost all network access, which this would be equivalent to since MN could not register to the newFA. IMHO, this should be just handled by having operational SA and not over-specification. 3) Simultaneous binding support Pretty sure that there's no deployment of simultaneous binding (S bit) between HA and FA/MN currently. MN deregisters another binding from current foreign network. But for MN to be registered on current foreign network, the SA between newFA and HA must be valid. Let's say that SA is good, then there is no problem with deregistering the oldFA. Let's say that SA is bad, then MN would not be able to register to newFA either. It would make sense for MN to find a FA that can be registered before deregistering an old binding. If this is the case, then there is no problem. I just can't think of good reason to have any exception to the simple rule of FHAE protecting message exchange between FA and HA, given my opinion on case #2b. Kent At 04:55 PM 1/5/2005 -0600, Pete McCann wrote: >Bringing some off-list discussion back into the fold... > > > >Charlie P writes: > > Pete McCann wrote: > > > > >After mulling over this issue some more, I am tending to agree with > > >Kent's reasoning below. We had talked about allowing some exceptions > > >to the SA processing, but the exact conditions under which the > > >exceptions apply seem fuzzy to me (remember, they have to be identical > > >and computable at both the FA and HA). > > > > > > > > I don't see anything wrong with the idea of prohibiting FHAE > > on deregistrations for external care-of addresses. The home > > agent will have no difficulty with this. At the last IETF, and > > during the discussion in the room, this seemed like a workable > > solution without any technical diffculties raised. > >I am still having trouble with the definition of "external care-of >addresses". (see my previous e-mail to the list). Is it possible to >define this set such that both the FA and HA are in agreement on which >de-registrations are excluded from security processing? How does the >HA know which care-of addresses are "external" to a given FA? > >Even if we could define this properly, I am having more and more >doubts that this sort of processing belongs at the Mobile IP security >layer. Imagine if we were using IPSec for security (which, >thankfully, we are not right now) and trying to convince an IPSec >implementor to put exceptions into the SAD based on the contents of >the message... it would be absolutely, totally, and in all other ways >inconceivable. > >I understand the motivation here; we don't want the FA to be able to >disrupt a de-registration that doesn't concern it. However, modifying >the security processing in the FA and HA doesn't really achieve that >goal; the FA could still, for example, drop the packet without >forwarding it to the HA, as could any router along the e2e path. > >Maybe the real problem here is the 'R' bit. I proposed once before >that we allow de-registrations to go directly to the HA, even if the >'R' bit is set, but there was at least one objection. Can someone >remind me what was the basis for it? > > > Regards, > > Charlie P. > >-Pete > > >Kent Leung writes: > > Hi Charlie. > > > > I was addressing the issue from the context of a NAT environment > > by using the CoA field for indexing the security association. But > > realize that I should not be bundling the NAT issue with the > > deregistration and CCoA mode. The NAT problem should be > > dealt with in 3519bis (likely adding a new source IP address field in the > > extension for detection). > > > > Leaving the NAT issue aside, I agree with both you and Pete that the > > the security association should be indexed by the source IP address > > and SPI. This means that the FA can be identified by the source > > IP address of the RRQ. Both registrations and deregistration are > > protected by the SA. If there is any problem in the SA between HA and > > FA, then both registration and deregistration will be problematic. This > > problem needs to be fixed by the administrator. I think > > if the SA exists, then FA and HA must append the FHAE when sending > > message, as well as check for FHAE upon reception. Can't think of > > good reasons why there should be exceptions. > > > > Kent > > > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 6 14:11:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03423 for ; Thu, 6 Jan 2005 14:11:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmdFw-0002c5-9j for mip4-web-archive@ietf.org; Thu, 06 Jan 2005 14:25:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmcws-0001GO-ET; Thu, 06 Jan 2005 14:05:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmcra-0007Xp-3r for mip4@megatron.ietf.org; Thu, 06 Jan 2005 14:00:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02134 for ; Thu, 6 Jan 2005 14:00:00 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmd4N-00012f-As for mip4@ietf.org; Thu, 06 Jan 2005 14:13:17 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 06 Jan 2005 10:59:58 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j06IxEl2017373; Thu, 6 Jan 2005 10:59:14 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-253.cisco.com [128.107.163.253]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAK44478; Thu, 6 Jan 2005 10:59:18 -0800 (PST) Message-Id: <4.3.2.7.2.20050106105350.02e8f0b8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Jan 2005 10:59:17 -0800 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <41DD6F39.3000602@levkowetz.com> References: <16861.23867.168374.904893@gargle.gargle.HOWL> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Pete McCann , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Hi Henrik. I'm in total agreement on getting rid of the R bit. Is anyone deploying this scheme? I doubt it. This bit makes specifications and coding much more complicated. There is little return on investment here. Removing the R bit in 3344bis would make our lives healthier, richer, safer, happier, etc. OK, maybe just drafts and code simpler. ;) It's such an annoying bit..... I think it's a case of over-specification. :) Kent At 06:02 PM 1/6/2005 +0100, Henrik Levkowetz wrote: >on 2005-01-06 4:46 pm Pete McCann said the following: > > Hi, Henrik, > > > > > > > > Henrik Levkowetz writes: > > > Hi Pete, > > > > > > inline... > > > > > > on 2005-01-05 11:55 pm Pete McCann said the following: > > > > Bringing some off-list discussion back into the fold... > > > > > > > > > > > > > > > > Charlie P writes: > > > > > Pete McCann wrote: > > > > > > > > > > >After mulling over this issue some more, I am tending to agree > with > > > > > >Kent's reasoning below. We had talked about allowing some > exceptions > > > > > >to the SA processing, but the exact conditions under which the > > > > > >exceptions apply seem fuzzy to me (remember, they have to be > identical > > > > > >and computable at both the FA and HA). > > > > > > > > > > > > > > > > > I don't see anything wrong with the idea of prohibiting FHAE > > > > > on deregistrations for external care-of addresses. The home > > > > > agent will have no difficulty with this. At the last IETF, and > > > > > during the discussion in the room, this seemed like a workable > > > > > solution without any technical diffculties raised. > > > > > > > > I am still having trouble with the definition of "external care-of > > > > addresses". (see my previous e-mail to the list). Is it possible to > > > > define this set such that both the FA and HA are in agreement on which > > > > de-registrations are excluded from security processing? How does the > > > > HA know which care-of addresses are "external" to a given FA? > > > > > > Well, we could easily say that any care-of address which doesn't match > > > the source address of the packet is an external address. This is a > > > bit simplistic, but actually can be made to work also for FAs which > > > have multiple care-of addresses (which is not a common thing in my > > > experience) buy having the FA take care to always match source IP > > > with care-of address when the care-of address is it's own. > > > > Ok, your assumptions about the security policy are slightly different > > from mine. I thought we were allowing an exemption for the case where > > the MN is de-registering an address that it obtained while connected > > to a different network (this is how I interpreted "external"). > > Addresses on the current subnet (even co-located CoAs) would NOT be > > exempted from security processing because they are "owned" in some > > sense by that FA, even though they are not the address of any > > interface of the FA. Clearly, this policy would be difficult or > > impossible to process at the HA because it can't know what addresses > > are on the same subnet as the FA. > >True; so this sounds as if we have a potential solution for the regular >case (CoA belongs to the FA) but not for the R-bit case. > > > I agree your policy is easier to implement, but it effectively > > prohibits FHAE on any de-registration of a co-located COA. Is that > > what we want? If so, it could certainly be stated more clearly in the > > text than it is right now. > >Yes. For not the first time I'm so tempted to advocate ripping out the >R-bit... It causes such a lot of grief. Anyway, for Co-located CoA >with registration through FA, we can then proceed by > > a. Disallowing FHAE on these de-registrations > b. Defining a new extension to handle this case > c. Restricting the use of the R-bit together with FHAE > d. Grip the nettle and remove the R-bit from 3344bis > e. Come up with another solution > > > > > > Even if we could define this properly, I am having more and more > > > > doubts that this sort of processing belongs at the Mobile IP security > > > > layer. Imagine if we were using IPSec for security (which, > > > > thankfully, we are not right now) and trying to convince an IPSec > > > > implementor to put exceptions into the SAD based on the contents of > > > > the message... it would be absolutely, totally, and in all other ways > > > > inconceivable. > > > > > > Yes, but the analogy is flawed. > > > > > > With IPsec, you would not have the case that all traffic went through > > > the tunnel, except for some particular messages which were dropped > > > due to their content -- which would be closer to the case we are > > > experiencing here. Anything like that should indeed be regarded as > > > a flaw in IPsec. > > > > I don't understand how my proposal leads to dropped messages, as long > > as the SAs are properly configured between the FAs and HAs. > >Mmm? With FHAE always used, the de-registrations of external CoAs get >dropped, no? (Are we talking past each other here?) > > > > > I understand the motivation here; we don't want the FA to be able to > > > > disrupt a de-registration that doesn't concern it. However, modifying > > > > the security processing in the FA and HA doesn't really achieve that > > > > goal; the FA could still, for example, drop the packet without > > > > forwarding it to the HA, as could any router along the e2e path. > > > > > > Yes, but the big, huge difference is that consistently dropping > > > certain packages would either be hostile or a bug in implementation, > > > set-up, or administrator attitude ;-) > > > > > > To not only condone but actively choose to codify a practice which > > > denies service to a MN in certain cases is improper, I believe. > > > > That's not at all what I am suggesting. If the SA between the FA and > > HA is good then the packet won't be dropped. If the SA isn't working > > then the administrator needs to fix something. > >Hmm, then I don't think I know exactly what you're suggesting (but see >below) > > > > > Maybe the real problem here is the 'R' bit. I proposed once before > > > > that we allow de-registrations to go directly to the HA, even if the > > > > 'R' bit is set, but there was at least one objection. Can someone > > > > remind me what was the basis for it? > > > > > > I have no objection - but I don't think it solves the problem in all > > > cases. Some nets may very well permit egress only through the FA, > > > so there may not be any route past the FA. > > > > Sure, the packets go through the FA, but I would argue that a policy > > (even with the 'R' bit set) that drops de-registration requests > > directed to the home agent is hostile or a bug in implementation, > > set-up, or administrator attitude. Maybe it would be easier to change > > those policies (with a recommendation/clarification about the meaning > > of the 'R' bit in 3344bis) than to make deep changes in the security > > association processing code. > >Ok, I see. Hmm, this sounds like a slightly new variation on the theme, >and one which I've unfortunately not seen before. Do we have proposed >text for this? From this first impression, it sounds to me as if it >could be workable. > > > Henrik > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 6 17:38:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01628 for ; Thu, 6 Jan 2005 17:38:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgTS-0005oP-L4 for mip4-web-archive@ietf.org; Thu, 06 Jan 2005 17:51:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgES-000355-Mr; Thu, 06 Jan 2005 17:35:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgE0-0002jb-Hz for mip4@megatron.ietf.org; Thu, 06 Jan 2005 17:35:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01478 for ; Thu, 6 Jan 2005 17:35:22 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgQr-0005k6-Su for mip4@ietf.org; Thu, 06 Jan 2005 17:48:42 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j06MYo9j006186; Thu, 6 Jan 2005 16:34:51 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j06MYnO19361; Thu, 6 Jan 2005 16:34:50 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I9X2PX-000224-00; Thu, 06 Jan 2005 17:34:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16861.48387.626374.280537@gargle.gargle.HOWL> Date: Thu, 6 Jan 2005 16:34:43 -0600 From: Pete McCann To: Henrik Levkowetz Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <41DD6F39.3000602@levkowetz.com> References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> <41DD6F39.3000602@levkowetz.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 2.0 (++) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Hi, Henrik, Some comments below... Henrik Levkowetz writes: > on 2005-01-06 4:46 pm Pete McCann said the following: > > Hi, Henrik, > > > > > > > > Henrik Levkowetz writes: > > > Hi Pete, > > > > > > inline... > > > > > > on 2005-01-05 11:55 pm Pete McCann said the following: > > > > Bringing some off-list discussion back into the fold... > > > > > > > > > > > > > > > > Charlie P writes: > > > > > Pete McCann wrote: > > > > > > > > > > >After mulling over this issue some more, I am tending to agree with > > > > > >Kent's reasoning below. We had talked about allowing some exceptions > > > > > >to the SA processing, but the exact conditions under which the > > > > > >exceptions apply seem fuzzy to me (remember, they have to be identical > > > > > >and computable at both the FA and HA). > > > > > > > > > > > > > > > > > I don't see anything wrong with the idea of prohibiting FHAE > > > > > on deregistrations for external care-of addresses. The home > > > > > agent will have no difficulty with this. At the last IETF, and > > > > > during the discussion in the room, this seemed like a workable > > > > > solution without any technical diffculties raised. > > > > > > > > I am still having trouble with the definition of "external care-of > > > > addresses". (see my previous e-mail to the list). Is it possible to > > > > define this set such that both the FA and HA are in agreement on which > > > > de-registrations are excluded from security processing? How does the > > > > HA know which care-of addresses are "external" to a given FA? > > > > > > Well, we could easily say that any care-of address which doesn't match > > > the source address of the packet is an external address. This is a > > > bit simplistic, but actually can be made to work also for FAs which > > > have multiple care-of addresses (which is not a common thing in my > > > experience) buy having the FA take care to always match source IP > > > with care-of address when the care-of address is it's own. > > > > Ok, your assumptions about the security policy are slightly different > > from mine. I thought we were allowing an exemption for the case where > > the MN is de-registering an address that it obtained while connected > > to a different network (this is how I interpreted "external"). > > Addresses on the current subnet (even co-located CoAs) would NOT be > > exempted from security processing because they are "owned" in some > > sense by that FA, even though they are not the address of any > > interface of the FA. Clearly, this policy would be difficult or > > impossible to process at the HA because it can't know what addresses > > are on the same subnet as the FA. > > True; so this sounds as if we have a potential solution for the regular > case (CoA belongs to the FA) but not for the R-bit case. It seems like the only policy that can be checked by both the FA and HA is to check the CoA against the source IP address of the Registration Request between the FA and HA. If they differ, and if it is a de-registration, then omit the FHAE. Of course, any NAT along the path will change the source IP address... this really throws a monkey wrench into my understanding and I'm not sure of all the security implications. > > I agree your policy is easier to implement, but it effectively > > prohibits FHAE on any de-registration of a co-located COA. Is that > > what we want? If so, it could certainly be stated more clearly in the > > text than it is right now. > > Yes. For not the first time I'm so tempted to advocate ripping out the > R-bit... It causes such a lot of grief. Anyway, for Co-located CoA > with registration through FA, we can then proceed by > > a. Disallowing FHAE on these de-registrations > b. Defining a new extension to handle this case > c. Restricting the use of the R-bit together with FHAE > d. Grip the nettle and remove the R-bit from 3344bis > e. Come up with another solution I think (a) is the result of the policy I outlined above. > > > > Even if we could define this properly, I am having more and more > > > > doubts that this sort of processing belongs at the Mobile IP security > > > > layer. Imagine if we were using IPSec for security (which, > > > > thankfully, we are not right now) and trying to convince an IPSec > > > > implementor to put exceptions into the SAD based on the contents of > > > > the message... it would be absolutely, totally, and in all other ways > > > > inconceivable. > > > > > > Yes, but the analogy is flawed. > > > > > > With IPsec, you would not have the case that all traffic went through > > > the tunnel, except for some particular messages which were dropped > > > due to their content -- which would be closer to the case we are > > > experiencing here. Anything like that should indeed be regarded as > > > a flaw in IPsec. > > > > I don't understand how my proposal leads to dropped messages, as long > > as the SAs are properly configured between the FAs and HAs. > > Mmm? With FHAE always used, the de-registrations of external CoAs get > dropped, no? (Are we talking past each other here?) Why would they? The HA looks up the SA based on the source IP address of the packet (the FA) and if it checks out, then the message is processed like any other. What is the problem? You may be bringing in a NAT-related issue here... > > > > I understand the motivation here; we don't want the FA to be able to > > > > disrupt a de-registration that doesn't concern it. However, modifying > > > > the security processing in the FA and HA doesn't really achieve that > > > > goal; the FA could still, for example, drop the packet without > > > > forwarding it to the HA, as could any router along the e2e path. > > > > > > Yes, but the big, huge difference is that consistently dropping > > > certain packages would either be hostile or a bug in implementation, > > > set-up, or administrator attitude ;-) > > > > > > To not only condone but actively choose to codify a practice which > > > denies service to a MN in certain cases is improper, I believe. > > > > That's not at all what I am suggesting. If the SA between the FA and > > HA is good then the packet won't be dropped. If the SA isn't working > > then the administrator needs to fix something. > > Hmm, then I don't think I know exactly what you're suggesting (but see > below) > > > > > Maybe the real problem here is the 'R' bit. I proposed once before > > > > that we allow de-registrations to go directly to the HA, even if the > > > > 'R' bit is set, but there was at least one objection. Can someone > > > > remind me what was the basis for it? > > > > > > I have no objection - but I don't think it solves the problem in all > > > cases. Some nets may very well permit egress only through the FA, > > > so there may not be any route past the FA. > > > > Sure, the packets go through the FA, but I would argue that a policy > > (even with the 'R' bit set) that drops de-registration requests > > directed to the home agent is hostile or a bug in implementation, > > set-up, or administrator attitude. Maybe it would be easier to change > > those policies (with a recommendation/clarification about the meaning > > of the 'R' bit in 3344bis) than to make deep changes in the security > > association processing code. > > Ok, I see. Hmm, this sounds like a slightly new variation on the theme, > and one which I've unfortunately not seen before. Do we have proposed > text for this? From this first impression, it sounds to me as if it > could be workable. The text would be to clarify the meaning of the 'R' bit: it would really be "Registration Required" but not "Deregistration Required". -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 6 19:14:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08524 for ; Thu, 6 Jan 2005 19:14:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmhyP-0008Mh-0s for mip4-web-archive@ietf.org; Thu, 06 Jan 2005 19:27:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmhhG-0007J2-BW; Thu, 06 Jan 2005 19:09:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmhcY-0005ML-O3 for mip4@megatron.ietf.org; Thu, 06 Jan 2005 19:04:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08089 for ; Thu, 6 Jan 2005 19:04:47 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmhpQ-0008D1-5O for mip4@ietf.org; Thu, 06 Jan 2005 19:18:09 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2005 17:15:26 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0704Gjw001724; Thu, 6 Jan 2005 16:04:16 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-178-67.cisco.com [128.107.178.67]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAK78371; Thu, 6 Jan 2005 16:04:14 -0800 (PST) Message-Id: <4.3.2.7.2.20050106144331.01dc1ee8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Jan 2005 16:04:14 -0800 To: Pete McCann From: Kent Leung Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <16861.48387.626374.280537@gargle.gargle.HOWL> References: <41DD6F39.3000602@levkowetz.com> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> <41DD6F39.3000602@levkowetz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 A few issues with this FHAE policy solution: - All deregistrations are unnecessarily constraint to use the CoA as the source IP address of RRQ. Typically, the egress interface's IP address is used. See Alan Oneill's thread on this topic of allowing CoA and source address to be different. Same argument should apply for registration and deregistration. - If deregistrations are confined to CoA as source IP address of RRQ, deregistrations of binding on current FA using HoA in CoA field would not be protected by FHAE. Shouldn't deregistration of binding for current FA be protected when SA exists between FA and HA? - If deregistrations are sent with source IP address that is not the CoA (assuming this is still allowed), then deregistration with CoA of current FA would not be protected by FHAE. It would make sense to protect this type of message exchange. - When administrator creates an SA between HA and FA, isn't there a security agreement that should be maintained for communications between them? Is it up to us to decide that deregistrations don't need to be secured? Note FHAE omission happens also for MN deregistering the current FA (when CoA is HoA or CoA is not same as src address). The reason we are introducing this new FHAE policy is because the fear that FA has a bad SA? Any other circumstances that mandate disabling of the security enforcement? Kent At 04:34 PM 1/6/2005 -0600, Pete McCann wrote: >It seems like the only policy that can be checked by both the FA and >HA is to check the CoA against the source IP address of the >Registration Request between the FA and HA. If they differ, and if it >is a de-registration, then omit the FHAE. -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Jan 8 08:03:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05067 for ; Sat, 8 Jan 2005 08:03:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnGSZ-00068A-VS for mip4-web-archive@ietf.org; Sat, 08 Jan 2005 08:16:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnGAy-0007bP-Gl; Sat, 08 Jan 2005 07:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnG9R-0007M6-Bf for mip4@megatron.ietf.org; Sat, 08 Jan 2005 07:57:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04771 for ; Sat, 8 Jan 2005 07:57:04 -0500 (EST) Received: from smtp-1.hut.fi ([130.233.228.91]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnGMa-00061H-4L for mip4@ietf.org; Sat, 08 Jan 2005 08:10:43 -0500 Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id j08CuUHT028704 for ; Sat, 8 Jan 2005 14:56:30 +0200 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 13328-03 for ; Sat, 8 Jan 2005 14:56:29 +0200 (EET) Received: from baresi.hut.fi (baresi-m.hut.fi [130.233.228.121]) by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id j08CsMaV028287 for ; Sat, 8 Jan 2005 14:54:22 +0200 Received: (from apache@localhost) by baresi.hut.fi (8.12.10/8.12.6/Submit) id j08CsMar011517 for mip4@ietf.org; Sat, 8 Jan 2005 14:54:22 +0200 To: mip4@ietf.org Message-ID: <1105188862.41dfd7feb5cc8@webmail1.hut.fi> Date: Sat, 08 Jan 2005 14:54:22 +0200 (EET) From: sami.vaarala@iki.fi MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: HUT webmail, IMP 2.2.6 X-Authenticated-Sender: svaarala@cc.hut.fi X-Originating-IP: 82.133.140.87 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 8bit Subject: [Mip4] draft-ietf-mip4-vpn-problem-solution-01 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit Hi, I just submitted a revised version of the MIP/VPN solution document (draft-ietf-mip4-vpn-problem-solution-01). Espen, the new co-editor, did a read through and a number of presentational and structural changes were made as a result. The document should now be in quite good shape for wider review. Let's get this document out the door asap :-) Best regards, -Sami -- Sami Vaarala Chief Technology Officer Stinghorn -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Jan 8 09:10:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08446 for ; Sat, 8 Jan 2005 09:10:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnHW4-0002d5-QA for mip4-web-archive@ietf.org; Sat, 08 Jan 2005 09:24:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnHHg-00032g-Mz; Sat, 08 Jan 2005 09:09:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0oD-0008Vf-Kk; Fri, 07 Jan 2005 15:34:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19018; Fri, 7 Jan 2005 15:34:07 -0500 (EST) Received: from ms-smtp-03.nyroc.rr.com ([24.24.2.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn11D-0006Ex-J4; Fri, 07 Jan 2005 15:47:38 -0500 Received: from hpn307pc2 (roc-66-67-117-45.rochester.rr.com [66.67.117.45]) by ms-smtp-03.nyroc.rr.com (8.12.10/8.12.10) with SMTP id j07KWwP4007699; Fri, 7 Jan 2005 15:32:58 -0500 (EST) Message-ID: <01f201c4f4f8$1aead1c0$7901a8c0@hpn307pc2> From: "Wendi Heinzelman" To: "Wendi Heinzelman" Date: Fri, 7 Jan 2005 15:33:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 08 Jan 2005 09:09:40 -0500 Cc: suman@cs.wisc.edu, zit@tm.uka.de, bettstetter@ieee.org Subject: [Mip4] MobiCom 2005 Call for Workshop Proposals X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit ******************************************************************* Call for Workshops 11th International Conference on Mobile Computing and Networking (ACM MobiCom 2005) August 28 - September 2, 2005 Cologne, Germany http://www.sigmobile.org/mobicom/2005/ ******************************************************************* The ACM Mobicom 2005 conference will host a day of workshops on technical areas related to mobile and wireless networking. SIGMOBILE invites workshop proposals from interested communities. New workshops in emerging areas that can engage participants in greater interaction are welcome. General information: The purpose of the workshop proposal is to describe the research topics covered by the workshop and how the workshop will be organized. ACM Mobicom will provide basic support for the workshop in the form of registration, publicity, a meeting room, and help in arranging meal service for the workshop at the ACM Mobicom conference. To encourage flexibility, the details of the format of the workshop, the form of submissions and presentations, and the likes is left to the workshop organizers. Because workshops are meant to foster discussions on emerging topics of interest among the broader SIGMOBILE community, workshops are encouraged to be inclusive rather than exclusive in their solicitation of material. In addition, targeting more interactive forums such as presentations of short papers rather than traditional presentations of full-length papers can be more conducive to successful workshops. Detailed guidelines: Proposals for workshops should be sent to the ACM Mobicom workshop co-chairs Suman Banerjee (suman@cs.wisc.edu) or Martina Zitterbart (zit@tm.uka.de) by January 31, 2005, 5pm EST and should contain: * A description of the workshop's technical area, its scope, its history (if any), and why it is important in mobile and wireless networking. * A description of the workshop program (e.g., paper presentations, poster presentations, panel sessions) and expected attendance. The workshop program should fill one day and SIGMOBILE encourages programs that require only one meeting room (for simplified logistics). You should indicate if you have any other requirements, e.g., hall for poster presentations. * The names of key workshop volunteers, e.g., the workshop chair, program chair and possible program committee members. * A draft call for papers or participation. * A completed preliminary TMRF which is available from ACM at: http://www.acm.org/sig_volunteer_info/conference_manual/prelimpage.htm. * Opportunities for sponsorship from corporate donors. ---------------------------------------------------------- Wendi B. Heinzelman Assistant Professor of Electrical and Computer Engineering University of Rochester P.O. Box 270126, Hopeman Building, Room 307 Rochester, NY 14627-0126 Phone: 585-275-4053 Fax: 585-273-4919 http://www.ece.rochester.edu/~wheinzel ---------------------------------------------------------- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Jan 8 09:17:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08744 for ; Sat, 8 Jan 2005 09:17:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnHcV-0003Iy-KC for mip4-web-archive@ietf.org; Sat, 08 Jan 2005 09:31:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnHIB-000362-Vn; Sat, 08 Jan 2005 09:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn12A-0000B3-I2 for mip4@megatron.ietf.org; Fri, 07 Jan 2005 15:48:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23345 for ; Fri, 7 Jan 2005 15:48:32 -0500 (EST) Received: from pantheon-po07.its.yale.edu ([130.132.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn1FA-00085v-Dk for mip4@ietf.org; Fri, 07 Jan 2005 16:02:03 -0500 Received: from websrv3a.its.yale.edu (websrv3a.its.yale.edu [130.132.41.112]) by pantheon-po07.its.yale.edu (8.12.11/8.12.11) with ESMTP id j07KmQXV032031 for ; Fri, 7 Jan 2005 15:48:27 -0500 Received: from mail pickup service by websrv3a.its.yale.edu with Microsoft SMTPSVC; Fri, 7 Jan 2005 15:46:43 -0500 From: "Andreas Sawides" To: "Colleagues" Date: Fri, 7 Jan 2005 15:46:42 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 List-Software: Yale ITS Message II System (6303) Message-ID: X-OriginalArrivalTime: 07 Jan 2005 20:46:43.0080 (UTC) FILETIME=[FEB93080:01C4F4F9] X-YaleITSMailFilter: Version 1.2a (attachment(s) not renamed) X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd X-Mailman-Approved-At: Sat, 08 Jan 2005 09:10:10 -0500 Subject: [Mip4] MobiQuitous 2005 Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Dear Colleague, Enclosed below please find a Preliminary Announcement and Call for Papers for the Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services, to be held in San Diego, California from July 17-21, 2005. For complete information about the upcoming conference, please visit: http://www.mobiquitous.org/ A printer friendly version of this CFP is available at: http://www.mobiquitous.org/MQ2005-CFP.pdf (PDF) We apologize if you received multiple copies of this Call for Papers. Please feel free to distribute it to those who might be interested. Best regards, Mobiquitous 2005 Organizing Committee *********************************************************************** MobiQuitous 2005 CALL FOR PAPERS The Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services http://www.mobiquitous.org July 17-21, 2005, San Diego, California PAPER SUBMISSION DEADLINE: February 2, 2005 Sponsored by: CreateNet (www.create-net.it) and ICST Technically Co-Sponsored by IEEE Computer Society (Pending) Technically Co-Sponsored by IEEE Communications Society (Pending) In Cooperation with ACM SIGMOBILE (Pending) Technically Co-Sponsored by AAAI (Pending) Proceedings to be published by IEEE Computer Society Press and to be made available on IEEE Explore **************************************** The combination of mobile and ubiquitous computing is emerging as a promising new paradigm with the goal to provide computing and communication services all the time, everywhere, transparently and invisibly to the user, using devices embedded in the surrounding physical environment. In this context, the communication devices, the objects with which they interact, or both may be mobile. The implementation of such a paradigm requires advances in wireless network technologies and devices, development of infrastructures supporting cognitive environments, and discovery and identification of ubiquitous computing applications and services. The second Annual International Conference on Mobile and Ubiquitous Systems: networking and services (Mobiquitous-05) will cover all these aspects, representing a forum where practitioners and researchers coming from the many areas involved in ubiquitous solutions design and deployment will be able to interact exchanging the cross-layer experiences needed to build the overall ubiquitous systems. Areas addressed by the conference include: applications, service-oriented computing, middleware, networking, agents, knowledge management and databases. PAPERS: Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. The conference is interested in contributions addressing all the areas associated with mobile and ubiquitous architectures, infrastructure and services. Technical works clearly identifying how the specific contributions fit to an overall working solution are particularly of interest. Topics include, but are not limited to, the following: * Ubiquitous architectures and systems * Wearable computing and personal area network * Wireless technologies for mobile and ubiquitous (Bluetooth, ZigBee, 802.15.x, WiFi) * Incentive-based deployment of ad hoc networks * Reconfigurability and personalization of wireless network * Service discovery mechanisms, knowledge discovery, matching and composition mechanisms * Wireless/mobile service management and delivery * Security, privacy and social issues of mobile and ubiquitous systems * Peer-to-peer knowledge management * Emerging industrial/business scenarios * Multimodal interfaces (speech, video kinetic, tactile) * Smart spaces * Ad hoc and sensor networking * Localization and tracking * Context and location aware application * Multimedia encoding and transcoding * Middleware services * Agent technologies in ubiquitous, wearable, andmobile systems * Hardware and software platforms for ubiquitous systems, and testbeds * User interfaces * Toolkits, development environments, and languages for ubiquitous computing * Ontologies for mobile and ubiquitous computing SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically (see the conference web page for details). Authors should prepare a Portable Document Format (PDF) or postscript version of their full paper. Papers must not exceed 8 pages double column (US Letter size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 10 points. The deadline for registering the title and the abstract of the paper with our electronic submission system is February 2, 2005. The deadline for submitting the actual paper is February 9, 2005. All deadlines are 11:59PM PST. PUBLICATION: All submitted papers will be rigorously reviewed by technical program committee members. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in a ACM/Kluwer MONET special issue. WORKSHOPS: Proposals for one-day workshops to be held in conjunction with the conference are solicited. A maximum of 2 pages should be submitted which include the workshop name, its scope and a list of topic of interests. Proposals should be submitted to both the Workshop co-Chairs by December 17 2004. DEMOS: Proposals for research and industrial demos are solicited. A maximum of 2 pages should be submitted which include a description of the demo and needed resources from the conference organizers. Proposals should be submitted to Dr. Ramiro Liscano (Demo Chair) rliscano@ieee.org by May 29th, 2005. IMPORTANT DATES: Paper registration deadline: February 2, 2005 Full paper submission deadline: February 9, 2005 Notification of acceptance: April 29, 2005 Camera-ready version due: May 15, 2005 ORGANIZING COMMITTEE General Chair: Ramesh Rao (Univ. of California, San Diego) General Co-Vice-Chairs: Chiara Petrioli (Universit di Roma La Sapienza) Krishna Sivalingam (University of Maryland, Baltimore County) Technical Program Co-Chairs: Networking: Suresh Singh (Portland State University) Philippe Bonnet (University of Copenhagen) Services/Knowledge Management: Anupam Joshi (University of Maryland, Baltimore County) Ryusuke Masuoka (Fujitsu Labs of America) Publicity Co-Chairs: Andreas Savvides (Yale University) and Mohamed Younis (University of Maryland, Baltimore County) Panels Chairs: TBA Workshop Chairs: Stefano Basagni (Northeastern University) Prithwish Basu (BBN Technologies) Demos Chair: Ramiro Liscano (University of Ottawa) Publications Chair: Antonis Kalis (Athens Information Technology) Local Arrangements Chair: Kang Wang, Qualcomm Inc. Finance Chair: Karen Decker (ICST Texas,USA) Accommodations Chair: Kathy Kunz (ICST California,USA) Registration Chair: Vishal Anand, SUNY College at Brockport Steering Committee: Imrich Chlamtac (CreateNet, Inc.), Chair Michele Zorzi (Universita di Padova) -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 10 16:34:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03287 for ; Mon, 10 Jan 2005 16:34:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co7PQ-0002iM-Fu for mip4-web-archive@ietf.org; Mon, 10 Jan 2005 16:49:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co6YJ-0006nZ-Hv; Mon, 10 Jan 2005 15:54:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co6UV-0004gw-CO; Mon, 10 Jan 2005 15:50:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23681; Mon, 10 Jan 2005 15:50:17 -0500 (EST) Message-Id: <200501102050.PAA23681@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 10 Jan 2005 15:50:17 -0500 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-vpn-problem-solution-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Traversal Across IPsec-based VPN Gateways Author(s) : S. Vaarala, E. Klovning Filename : draft-ietf-mip4-vpn-problem-solution-01.txt Pages : 39 Date : 2005-1-10 This document outlines the proposed solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec are not required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-vpn-problem-solution-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-vpn-problem-solution-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-mip4-vpn-problem-solution-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: <2005-1-10153254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-vpn-problem-solution-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-vpn-problem-solution-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-10153254.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Mon Jan 10 17:28:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08856 for ; Mon, 10 Jan 2005 17:28:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8Eo-0004X5-Jv for mip4-web-archive@ietf.org; Mon, 10 Jan 2005 17:42:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co7uN-0007MY-FD; Mon, 10 Jan 2005 17:21:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co7ky-0005Gx-Ij for mip4@megatron.ietf.org; Mon, 10 Jan 2005 17:11:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07949 for ; Mon, 10 Jan 2005 17:11:22 -0500 (EST) Received: from av5-2-sn3.vrr.skanova.net ([81.228.9.114]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co7yf-0004AX-3l for mip4@ietf.org; Mon, 10 Jan 2005 17:25:33 -0500 Received: by av5-2-sn3.vrr.skanova.net (Postfix, from userid 502) id C54B437E6F; Mon, 10 Jan 2005 23:10:49 +0100 (CET) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av5-2-sn3.vrr.skanova.net (Postfix) with ESMTP id B7D7637E48; Mon, 10 Jan 2005 23:10:49 +0100 (CET) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 6B67A38010; Mon, 10 Jan 2005 23:10:49 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1Co7kO-0002Vy-QO; Mon, 10 Jan 2005 23:10:49 +0100 Message-ID: <41E2FD67.5000209@levkowetz.com> Date: Mon, 10 Jan 2005 23:10:47 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> <41DD6F39.3000602@levkowetz.com> <16861.48387.626374.280537@gargle.gargle.HOWL> In-Reply-To: <16861.48387.626374.280537@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 2.0 (++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Getting back to this issue after a long weekend... On 2005-01-06 11:34 pm Pete McCann said the following: > Hi, Henrik, > > Some comments below... > > Henrik Levkowetz writes: ... > > True; so this sounds as if we have a potential solution for the regular > > case (CoA belongs to the FA) but not for the R-bit case. > > It seems like the only policy that can be checked by both the FA and > HA is to check the CoA against the source IP address of the > Registration Request between the FA and HA. If they differ, and if it > is a de-registration, then omit the FHAE. > > Of course, any NAT along the path will change the source IP address... > this really throws a monkey wrench into my understanding and I'm not > sure of all the security implications. Yes. I think we need to back up and look at what we want to accomplish, and where we want to accomplish it. > > > I agree your policy is easier to implement, but it effectively > > > prohibits FHAE on any de-registration of a co-located COA. Is that > > > what we want? If so, it could certainly be stated more clearly in the > > > text than it is right now. > > > > Yes. For not the first time I'm so tempted to advocate ripping out the > > R-bit... It causes such a lot of grief. Anyway, for Co-located CoA > > with registration through FA, we can then proceed by > > > > a. Disallowing FHAE on these de-registrations > > b. Defining a new extension to handle this case > > c. Restricting the use of the R-bit together with FHAE > > d. Grip the nettle and remove the R-bit from 3344bis > > e. Come up with another solution > > I think (a) is the result of the policy I outlined above. Yes, that is the way I saw it and what I was thinking of for A. > > > > > Even if we could define this properly, I am having more and more > > > > > doubts that this sort of processing belongs at the Mobile IP security > > > > > layer. Imagine if we were using IPSec for security (which, > > > > > thankfully, we are not right now) and trying to convince an IPSec > > > > > implementor to put exceptions into the SAD based on the contents of > > > > > the message... it would be absolutely, totally, and in all other ways > > > > > inconceivable. > > > > > > > > Yes, but the analogy is flawed. > > > > > > > > With IPsec, you would not have the case that all traffic went through > > > > the tunnel, except for some particular messages which were dropped > > > > due to their content -- which would be closer to the case we are > > > > experiencing here. Anything like that should indeed be regarded as > > > > a flaw in IPsec. > > > > > > I don't understand how my proposal leads to dropped messages, as long > > > as the SAs are properly configured between the FAs and HAs. > > > > Mmm? With FHAE always used, the de-registrations of external CoAs get > > dropped, no? (Are we talking past each other here?) > > Why would they? The HA looks up the SA based on the source IP address > of the packet (the FA) and if it checks out, then the message is > processed like any other. What is the problem? > > You may be bringing in a NAT-related issue here... Yes, I'm afraid I was thinking of that. ... > > > > > Maybe the real problem here is the 'R' bit. I proposed once before > > > > > that we allow de-registrations to go directly to the HA, even if the > > > > > 'R' bit is set, but there was at least one objection. Can someone > > > > > remind me what was the basis for it? > > > > > > > > I have no objection - but I don't think it solves the problem in all > > > > cases. Some nets may very well permit egress only through the FA, > > > > so there may not be any route past the FA. > > > > > > Sure, the packets go through the FA, but I would argue that a policy > > > (even with the 'R' bit set) that drops de-registration requests > > > directed to the home agent is hostile or a bug in implementation, > > > set-up, or administrator attitude. Maybe it would be easier to change > > > those policies (with a recommendation/clarification about the meaning > > > of the 'R' bit in 3344bis) than to make deep changes in the security > > > association processing code. > > > > Ok, I see. Hmm, this sounds like a slightly new variation on the theme, > > and one which I've unfortunately not seen before. Do we have proposed > > text for this? From this first impression, it sounds to me as if it > > could be workable. > > The text would be to clarify the meaning of the 'R' bit: it would > really be "Registration Required" but not "Deregistration Required". Yes, that could be one way to go. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 10 17:44:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09857 for ; Mon, 10 Jan 2005 17:44:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8VA-0004uL-Tp for mip4-web-archive@ietf.org; Mon, 10 Jan 2005 17:59:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8G2-00047Y-L4; Mon, 10 Jan 2005 17:43:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co88O-0002c0-7l for mip4@megatron.ietf.org; Mon, 10 Jan 2005 17:35:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09411 for ; Mon, 10 Jan 2005 17:35:33 -0500 (EST) Received: from av5-1-sn3.vrr.skanova.net ([81.228.9.113]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8M3-0004id-6p for mip4@ietf.org; Mon, 10 Jan 2005 17:49:45 -0500 Received: by av5-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 6A9F737E4E; Mon, 10 Jan 2005 23:35:02 +0100 (CET) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av5-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5CE3D37E4B; Mon, 10 Jan 2005 23:35:02 +0100 (CET) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 42F2838009; Mon, 10 Jan 2005 23:35:02 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1Co87p-0002xe-Tp; Mon, 10 Jan 2005 23:35:01 +0100 Message-ID: <41E30315.8060100@levkowetz.com> Date: Mon, 10 Jan 2005 23:35:01 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> <41DD6F39.3000602@levkowetz.com> <16861.48387.626374.280537@gargle.gargle.HOWL> In-Reply-To: <16861.48387.626374.280537@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Pete McCann , Kent Leung , "Charles E. Perkins" , Sri Gundavelli X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Pete, Charlie, Kent, Sri, Let me see if I have understood the issues here, and where we stand, by trying to sum everything up the way I see things. If I've missed something, please correct me. 1. The issues involved here occurs when there is a SA between HA and FA. Currently the FA adds a FA-HA Auth. Ext to messages to the HA, and the HA expects to be able to verify the Auth. Ext appended to any message from this FA. 2. We have two cases where this breaks down: a. The FA is behind a NAT, and the MN is de-registering a CoA which is different from the CoA used by the current FA. In this case neither source address nor CoA will be usable for finding the correct SA in order to verify the FA-HA Auth. Ext. b. The FA has the R-bit set, and the MN is registered with a Co- located CoA. It then tries to de-register a CoA which does not match any CoA used by the current FA. Again the result is that neither source address nor CoA matches any address belonging to the FA, and it is not possible to match an SA with the FA-HA Auth. Ext. 3. For the NAT case, 2.a., it is proposed that it should be handled by a 3519bis, not by the 3344bis. 4. For the R-bit case, we currently have 2 proposals which seems to both permit de-registration in case 2.b. and not require a more complicated security policy. i. Change the meaning of the R-bit to be "Registration through the FA required, but de-registrations MAY be sent directly." ii. Remove the R-bit completely from 3344bis. Have I captured this correctly? Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 10 18:15:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12879 for ; Mon, 10 Jan 2005 18:15:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8yg-0005dY-W8 for mip4-web-archive@ietf.org; Mon, 10 Jan 2005 18:29:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8aV-0002Ab-Oq; Mon, 10 Jan 2005 18:04:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8Vf-0007BJ-Qj for mip4@megatron.ietf.org; Mon, 10 Jan 2005 17:59:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10932 for ; Mon, 10 Jan 2005 17:59:37 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8jL-0005Gj-3O for mip4@ietf.org; Mon, 10 Jan 2005 18:13:49 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Jan 2005 16:10:59 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0AMwxjx029277; Mon, 10 Jan 2005 14:59:02 -0800 (PST) Date: Mon, 10 Jan 2005 14:58:59 -0800 (PST) From: Sri Gundavelli To: Henrik Levkowetz Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <41E30315.8060100@levkowetz.com> Message-ID: References: <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> <41DD6F39.3000602@levkowetz.com> <16861.48387.626374.280537@gargle.gargle.HOWL> <41E30315.8060100@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Pete McCann , mip4@ietf.org, Kent Leung , "Charles E. Perkins" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi Henrik, Please see inline ... I think you summarized it quite right. Sri On Mon, 10 Jan 2005, Henrik Levkowetz wrote: > Pete, Charlie, Kent, Sri, > > > Let me see if I have understood the issues here, and where we stand, > by trying to sum everything up the way I see things. If I've missed > something, please correct me. > > > 1. The issues involved here occurs when there is a SA between HA and > FA. Currently the FA adds a FA-HA Auth. Ext to messages to the HA, > and the HA expects to be able to verify the Auth. Ext appended to > any message from this FA. There needs to be a way for locating the SA's for the peer. > > 2. We have two cases where this breaks down: > > a. The FA is behind a NAT, and the MN is de-registering a CoA > which is different from the CoA used by the current FA. In > this case neither source address nor CoA will be usable for > finding the correct SA in order to verify the FA-HA Auth. Ext. > Yes ! > b. The FA has the R-bit set, and the MN is registered with a Co- > located CoA. It then tries to de-register a CoA which does > not match any CoA used by the current FA. Again the result > is that neither source address nor CoA matches any address > belonging to the FA, and it is not possible to match an SA > with the FA-HA Auth. Ext. > Assuming NAT here ? > 3. For the NAT case, 2.a., it is proposed that it should be handled > by a 3519bis, not by the 3344bis. > If we incorporate the Source Address/Port of the tunnel peer in the UDP Tunnel Request extension, we can solve this in 3519bis. Probably, the source address is always the right way to locate Security Associations. 3519 introduced this issue and probably we can solve it by fixing the issue there. > 4. For the R-bit case, we currently have 2 proposals which seems to > both permit de-registration in case 2.b. and not require a > more complicated security policy. > > i. Change the meaning of the R-bit to be "Registration through > the FA required, but de-registrations MAY be sent directly." > > ii. Remove the R-bit completely from 3344bis. > Removing it completely is not a bad idea, unless there are tons of implementations supporting this monster bit. > > Have I captured this correctly? > > > Henrik > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 10 21:05:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24536 for ; Mon, 10 Jan 2005 21:05:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoBcn-0000Ws-Ek for mip4-web-archive@ietf.org; Mon, 10 Jan 2005 21:19:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoBMj-0007YX-CF; Mon, 10 Jan 2005 21:02:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoBHR-0006zb-6X for mip4@megatron.ietf.org; Mon, 10 Jan 2005 20:57:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24095 for ; Mon, 10 Jan 2005 20:57:04 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoBV4-0000MT-09 for mip4@ietf.org; Mon, 10 Jan 2005 21:11:17 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2005 17:58:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0B1uSjw024706; Mon, 10 Jan 2005 17:56:29 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-171-71-203-212.cisco.com [171.71.203.212]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAN33919; Mon, 10 Jan 2005 17:56:28 -0800 (PST) Message-Id: <4.3.2.7.2.20050110174705.02eca6f8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Jan 2005 17:56:28 -0800 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <41E30315.8060100@levkowetz.com> References: <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> <41DD6F39.3000602@levkowetz.com> <16861.48387.626374.280537@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Pete McCann , mip4@ietf.org, "Charles E. Perkins" , Sri Gundavelli X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 At 11:35 PM 1/10/2005 +0100, Henrik Levkowetz wrote: >Pete, Charlie, Kent, Sri, > > >Let me see if I have understood the issues here, and where we stand, >by trying to sum everything up the way I see things. If I've missed >something, please correct me. > > >1. The issues involved here occurs when there is a SA between HA and > FA. Currently the FA adds a FA-HA Auth. Ext to messages to the HA, > and the HA expects to be able to verify the Auth. Ext appended to > any message from this FA. > >2. We have two cases where this breaks down: > > a. The FA is behind a NAT, and the MN is de-registering a CoA > which is different from the CoA used by the current FA. In > this case neither source address nor CoA will be usable for > finding the correct SA in order to verify the FA-HA Auth. Ext. > > b. The FA has the R-bit set, and the MN is registered with a Co- > located CoA. It then tries to de-register a CoA which does > not match any CoA used by the current FA. Again the result > is that neither source address nor CoA matches any address > belonging to the FA, and it is not possible to match an SA > with the FA-HA Auth. Ext. Actually, the deregistration will work fine when the SA between FA and HA is valid. The SA is indexed by the source IP address of the RRQ on the HA. This IP address is the FA. The NAT issue will be dealt with in 3519bis as you said. >3. For the NAT case, 2.a., it is proposed that it should be handled > by a 3519bis, not by the 3344bis. > >4. For the R-bit case, we currently have 2 proposals which seems to > both permit de-registration in case 2.b. and not require a > more complicated security policy. > > i. Change the meaning of the R-bit to be "Registration through > the FA required, but de-registrations MAY be sent directly." > > ii. Remove the R-bit completely from 3344bis. > I agree with removing R-bit. Just to be clear, one other optino is to leave RFC 3344 as is. This means the FHAE is always added by FA when relaying to an HA which it has an SA. And that the HA will authenticate the FHAE since it has an SA with the FA. This is what is already defined. Charlie is requesting to loosen up the security checks between the FA and HA (even if SA exists) for the case of deregistering an CoA that's no the FA. This problem doesn't happen if the SA between FA and HA is valid, which would be expected for mobility service between them. Kent >Have I captured this correctly? > > > Henrik -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 11 11:04:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03980 for ; Tue, 11 Jan 2005 11:04:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoOjk-0008SF-Sz for mip4-web-archive@ietf.org; Tue, 11 Jan 2005 11:19:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoORq-0001JT-QA; Tue, 11 Jan 2005 11:00:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoOP9-0000dL-De for mip4@megatron.ietf.org; Tue, 11 Jan 2005 10:57:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03366 for ; Tue, 11 Jan 2005 10:57:57 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoOcz-0008J8-Rk for mip4@ietf.org; Tue, 11 Jan 2005 11:12:18 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0BFus82004545; Tue, 11 Jan 2005 09:56:54 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j0BFurG23242; Tue, 11 Jan 2005 09:56:53 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IA5TMQ-000114-00; Tue, 11 Jan 2005 10:56:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16867.63297.73374.317759@gargle.gargle.HOWL> Date: Tue, 11 Jan 2005 09:56:49 -0600 From: Pete McCann To: Kent Leung Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <4.3.2.7.2.20050110174705.02eca6f8@mira-sjcm-2.cisco.com> References: <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> <41DD6F39.3000602@levkowetz.com> <4.3.2.7.2.20050110174705.02eca6f8@mira-sjcm-2.cisco.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Henrik Levkowetz , "Charles E. Perkins" , Sri Gundavelli X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Hi, Kent Leung writes: > At 11:35 PM 1/10/2005 +0100, Henrik Levkowetz wrote: > >Pete, Charlie, Kent, Sri, > > > > > >Let me see if I have understood the issues here, and where we stand, > >by trying to sum everything up the way I see things. If I've missed > >something, please correct me. > > > > > >1. The issues involved here occurs when there is a SA between HA and > > FA. Currently the FA adds a FA-HA Auth. Ext to messages to the HA, > > and the HA expects to be able to verify the Auth. Ext appended to > > any message from this FA. > > > >2. We have two cases where this breaks down: > > > > a. The FA is behind a NAT, and the MN is de-registering a CoA > > which is different from the CoA used by the current FA. In > > this case neither source address nor CoA will be usable for > > finding the correct SA in order to verify the FA-HA Auth. Ext. If this point is used as justification for disabling the FA-HA Auth extension, then to me this seems like saying "security is too hard, therefore we should turn it off." There are other fixes here; one that comes to mind is to require the administrator to configure a duplicate SA where the IP address matches that of the NAT but the keys/algorithms/SPIs are the same. This would have zero impact on the Mobile IP spec but would increase the burden on administrators to know about the NATs. Another solution would be to make the SPIs globally unique (not indexed per-FA) and use that as the uniform mechanism to find an SA. However, this would be more of an impact to the base spec and existing implementations. Using the CoA to index the FA-HA SAD doesn't work for the case of co-located CoA, whether we are talking about Registrations or Deregistrations. Don't we need to solve this problem for *Registrations* before we consider kludges to handle the failed Deregistrations? > > b. The FA has the R-bit set, and the MN is registered with a Co- > > located CoA. It then tries to de-register a CoA which does > > not match any CoA used by the current FA. Again the result > > is that neither source address nor CoA matches any address > > belonging to the FA, and it is not possible to match an SA > > with the FA-HA Auth. Ext. > > > Actually, the deregistration will work fine when the SA between FA > and HA is valid. The SA is indexed by the source IP address of the > RRQ on the HA. This IP address is the FA. > > The NAT issue will be dealt with in 3519bis as you said. I agree with these two points. > >3. For the NAT case, 2.a., it is proposed that it should be handled > > by a 3519bis, not by the 3344bis. And this one. > >4. For the R-bit case, we currently have 2 proposals which seems to > > both permit de-registration in case 2.b. and not require a > > more complicated security policy. > > > > i. Change the meaning of the R-bit to be "Registration through > > the FA required, but de-registrations MAY be sent directly." > > > > ii. Remove the R-bit completely from 3344bis. > > > > I agree with removing R-bit. We might want to be careful here; I know that 3GPP2 currently specifies the use of the R-bit for PDSNs and there may be other deployments that use it as well. Personally I would rather relax the semantics in the minimal way needed to fix this problem than to get rid of it entirely. -Pete > Just to be clear, one other optino is to leave RFC 3344 as is. This means > the FHAE is always added by FA when relaying to an HA which it has an > SA. And that the HA will authenticate the FHAE since it has an SA with > the FA. This is what is already defined. > > Charlie is requesting to loosen up the security checks between the > FA and HA (even if SA exists) for the case of deregistering an CoA that's > no the FA. > > This problem doesn't happen if the SA between FA and HA is valid, which > would be expected for mobility service between them. > > Kent > > > >Have I captured this correctly? > > > > > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 11 16:39:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06592 for ; Tue, 11 Jan 2005 16:39:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoTxu-0001hF-C2 for mip4-web-archive@ietf.org; Tue, 11 Jan 2005 16:54:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoT92-0007RT-TK; Tue, 11 Jan 2005 16:01:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSyB-0000CQ-Bt for mip4@megatron.ietf.org; Tue, 11 Jan 2005 15:50:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26135 for ; Tue, 11 Jan 2005 15:50:25 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoTC3-0006iP-1Q for mip4@ietf.org; Tue, 11 Jan 2005 16:04:48 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0BLLUY00483; Tue, 11 Jan 2005 13:21:30 -0800 X-mProtect: <200501112121> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpde5MjiT; Tue, 11 Jan 2005 13:21:29 PST Message-ID: <41E43CCF.B1A0D53@iprg.nokia.com> Date: Tue, 11 Jan 2005 12:53:35 -0800 From: "Charles E.Perkins" 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: Kent Leung Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure References: <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> <41DD6F39.3000602@levkowetz.com> <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050110174705.02eca6f8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Hello Kent, One more thought on this... Kent Leung wrote: > Charlie is requesting to loosen up the security checks between the > FA and HA (even if SA exists) for the case of deregistering an CoA that's > no the FA. It's also good to keep in mind what FHAE does. It allows the home agent to verify the identity of the foreign agent that claims to relay the deregistration. But, in the case under discussion the home agent doesn't care which foreign agent sent the deregistration. I believe it's always better to eliminate wasteful work when it doesn't have any beneficial effect. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 11 20:51:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25743 for ; Tue, 11 Jan 2005 20:51:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoXsz-0007KS-Fo for mip4-web-archive@ietf.org; Tue, 11 Jan 2005 21:05:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoXVV-0001cL-Vc; Tue, 11 Jan 2005 20:41:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoXMc-0007t5-Qw for mip4@megatron.ietf.org; Tue, 11 Jan 2005 20:31:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24384 for ; Tue, 11 Jan 2005 20:31:57 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoXaV-0006tE-8T for mip4@ietf.org; Tue, 11 Jan 2005 20:46:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Jan 2005 18:43:30 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0C1VLl2012726; Tue, 11 Jan 2005 17:31:21 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-63.cisco.com [128.107.163.63]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAO26862; Tue, 11 Jan 2005 17:31:20 -0800 (PST) Message-Id: <4.3.2.7.2.20050111170556.03976dc0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Jan 2005 17:31:20 -0800 To: "Charles E.Perkins" From: Kent Leung Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <41E43CCF.B1A0D53@iprg.nokia.com> References: <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748460@gargle.gargle.HOWL> <41DC5E5E.6000003@iprg.nokia.com> <16860.28783.634374.722633@gargle.gargle.HOWL> <41DC7C4F.9020402@levkowetz.com> <16861.23867.168374.904893@gargle.gargle.HOWL> <41DD6F39.3000602@levkowetz.com> <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050110174705.02eca6f8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Thanks Charlie. I contend if there's a security relationship set up between HA and FA, then message exchanges should always abide by this policy. And that operationally, the SA is valid and deregistrations of old CoA, HoA, CCoA will all work. One more thought is for such corner case (my humble opinion) where nothing is broken (unless administrator makes mistake which prevents general mobility service), it's best to leave specification as-is. If there is overwhelming evidence or deployment feedback that this is operational issue, then we can address this. Last 2 cents on this topic ... :) Kent At 12:53 PM 1/11/2005 -0800, Charles E.Perkins wrote: >Hello Kent, > >One more thought on this... > >Kent Leung wrote: > > > Charlie is requesting to loosen up the security checks between the > > FA and HA (even if SA exists) for the case of deregistering an CoA that's > > no the FA. > >It's also good to keep in mind what FHAE does. >It allows the home agent to verify the identity of the >foreign agent that claims to relay the deregistration. > >But, in the case under discussion the home agent doesn't >care which foreign agent sent the deregistration. >I believe it's always better to eliminate wasteful >work when it doesn't have any beneficial effect. > >Regards, >Charlie P. > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 11 23:45:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06448 for ; Tue, 11 Jan 2005 23:45:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoacK-0002IE-MG for mip4-web-archive@ietf.org; Wed, 12 Jan 2005 00:00:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoaDJ-0007mD-Tr; Tue, 11 Jan 2005 23:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoZzg-0004X2-Kw for mip4@megatron.ietf.org; Tue, 11 Jan 2005 23:20:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04934 for ; Tue, 11 Jan 2005 23:20:26 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoaDa-0001pr-DV for mip4@ietf.org; Tue, 11 Jan 2005 23:34:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j0C4oP017442; Tue, 11 Jan 2005 20:50:25 -0800 X-mProtect: <200501120450> Nokia Silicon Valley Messaging Protection Received: from danira-pool05056.americas.nokia.com (10.241.50.56, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdb4Njrb; Tue, 11 Jan 2005 20:50:23 PST Message-ID: <41E4A51B.10701@iprg.nokia.com> Date: Tue, 11 Jan 2005 20:18:35 -0800 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure References: <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748 In-Reply-To: <4.3.2.7.2.20050111170556.03976dc0@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.0 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hello Kent, What you say is certainly correct, depending on _what kind_ of messages. For instance, you probably meant only messages that are sent to a particular port. But I would be equally well justified to say that the messages to be validated are those which are specified in the Mobile IP document. To go farther than this, I would most likely get into a discussion about what's wrong with IPsec, and I reckon neither one of us wants to swim around there. As a thought experiment, suppose that the Mobile IP specification had defined _two_ port numbers for operations between the mobile node and the home agent. In fact, this was discussed a long time ago. What would the force of your argument be in that case? Regards, Charlie P. Kent Leung wrote: > Thanks Charlie. I contend if there's a security relationship > set up between HA and FA, then message exchanges > should always abide by this policy. And that operationally, the > SA is valid and deregistrations of old CoA, HoA, CCoA > will all work. > > One more thought is for such corner case (my humble opinion) > where nothing is broken (unless administrator makes mistake > which prevents general mobility service), it's best to leave > specification as-is. If there is overwhelming evidence or deployment > feedback that this is operational issue, then we can address this. > > Last 2 cents on this topic ... :) > > Kent > > At 12:53 PM 1/11/2005 -0800, Charles E.Perkins wrote: > >> Hello Kent, >> >> One more thought on this... >> >> Kent Leung wrote: >> >> > Charlie is requesting to loosen up the security checks between the >> > FA and HA (even if SA exists) for the case of deregistering an CoA >> that's >> > no the FA. >> >> It's also good to keep in mind what FHAE does. >> It allows the home agent to verify the identity of the >> foreign agent that claims to relay the deregistration. >> >> But, in the case under discussion the home agent doesn't >> care which foreign agent sent the deregistration. >> I believe it's always better to eliminate wasteful >> work when it doesn't have any beneficial effect. >> >> Regards, >> Charlie P. >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ > > > -- > | | Kent Leung > :|: :|: IP Mobility Development > :|||: :|||: IOS Technologies Division > :|||||||: :|||||||: Voice: 408.526.5030 > .:|||||||||:.:|||||||||:. Fax: 408.525.1653 > c i s c o S y s t e m s Email: kleung@cisco.com > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 12 11:16:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25332 for ; Wed, 12 Jan 2005 11:16:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ColOx-00014R-BK for mip4-web-archive@ietf.org; Wed, 12 Jan 2005 11:31:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CokyF-00039q-Oc; Wed, 12 Jan 2005 11:03:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoktT-0002Cw-Vx; Wed, 12 Jan 2005 10:58:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24119; Wed, 12 Jan 2005 10:58:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Col7X-0000g7-A4; Wed, 12 Jan 2005 11:13:19 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CokoI-0006Wv-P0; Wed, 12 Jan 2005 10:53:26 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 12 Jan 2005 10:53:26 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mip4@ietf.org Subject: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 The IESG has received a request from the Mobility for IPv4 WG to consider the following document: - 'Mobile IPv4 Dynamic Home Agent Assignment ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-26. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-03.txt -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 12 12:19:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29786 for ; Wed, 12 Jan 2005 12:19:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ComNr-0002Zk-6C for mip4-web-archive@ietf.org; Wed, 12 Jan 2005 12:34:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ColtX-0001hC-29; Wed, 12 Jan 2005 12:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ColkI-0008Rb-BD for mip4@megatron.ietf.org; Wed, 12 Jan 2005 11:53:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28205 for ; Wed, 12 Jan 2005 11:53:20 -0500 (EST) Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ColyJ-00023i-0C for mip4@ietf.org; Wed, 12 Jan 2005 12:07:54 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0CGqkFM017264; Wed, 12 Jan 2005 10:52:46 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j0CGqUZ06866; Wed, 12 Jan 2005 10:52:30 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IA7QVE-00025S-00; Wed, 12 Jan 2005 11:52:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16869.21957.924374.622945@gargle.gargle.HOWL> Date: Wed, 12 Jan 2005 10:52:21 -0600 From: Pete McCann To: mip4@ietf.org X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: henrik@levkowetz.com Subject: [Mip4] AD review of draft-ietf-mip4-dynamic-assignment-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Hello, Thomas Narten has agreed to start IETF last call for draft-ietf-mip4-dynamic-assignment-03.txt. However, he did have one substantive comment during his review that we should discuss on the list. Here is his review: > 2004-10-11: review of 03 (WG says advance) > > There are references in abstract > > > Legacy Foreign Agent: > > > > Legacy foreign agents may forward a Registration Request with home > > agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP > > address to ALL-ZERO-ONE-ADDR. This will result packet being dropped > > or incidentally handled by a next hop HA, adjacent to the FA. > > hmm. how does one distinguish network connectivity problems from "not > implemented"? I.e, what recovery action does a MN take in this > situation? > > If the answer to the last one is straightforward (i.e., this is > covered elsewhere in the draft), I'll go ahead and start the LC. > > Thomas So the question is, do we need to add some text to the draft to cover this backwards-compatibility question? If so, what should it say? -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 12 13:21:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03307 for ; Wed, 12 Jan 2005 13:21:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ConM5-0003rB-AH for mip4-web-archive@ietf.org; Wed, 12 Jan 2005 13:36:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Con73-0005tY-EE; Wed, 12 Jan 2005 13:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Con3q-0004dA-AQ for mip4@megatron.ietf.org; Wed, 12 Jan 2005 13:17:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03055 for ; Wed, 12 Jan 2005 13:17:35 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ConHt-0003k9-7D for mip4@ietf.org; Wed, 12 Jan 2005 13:32:11 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 12 Jan 2005 10:27:56 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0CIH3jw008252; Wed, 12 Jan 2005 10:17:03 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-178-189.cisco.com [128.107.178.189]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAO75546; Wed, 12 Jan 2005 10:17:01 -0800 (PST) Message-Id: <4.3.2.7.2.20050112094941.02a37718@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jan 2005 10:17:01 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] Issue #45; Deregistration vs. Foreign-Home Authentication failure In-Reply-To: <41E4A51B.10701@iprg.nokia.com> References: <4.3.2.7.2.20050111170556.03976dc0@mira-sjcm-2.cisco.com> <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050104171617.02afa688@mira-sjcm-2.cisco.com> <16860.3652.719374.748> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Hi Charlie. Since the source port of the Mobile IP registration message is at times set to a variable number, the security association is not binded to a particular port but based on the protocol type. For example, an MN may use different UDP port number for each registration request and authenticate the registration reply destined to that port using the same SA for the HA. The same case exists between FA and HA. The index of the SA is based on the IP address and SPI, so the port number is not directly linked to the security relationship. I see the port number mainly as a transport for messages between mobility entities. I think we're in agreement here? Kent At 08:18 PM 1/11/2005 -0800, Charles E. Perkins wrote: >Hello Kent, > >What you say is certainly correct, depending on _what kind_ >of messages. For instance, you probably meant only >messages that are sent to a particular port. But I would >be equally well justified to say that the messages to be >validated are those which are specified in the Mobile IP >document. To go farther than this, I would most likely >get into a discussion about what's wrong with IPsec, and >I reckon neither one of us wants to swim around there. > >As a thought experiment, suppose that the Mobile IP >specification had defined _two_ port numbers for >operations between the mobile node and the home agent. >In fact, this was discussed a long time ago. What would >the force of your argument be in that case? > >Regards, >Charlie P. > > >Kent Leung wrote: > >>Thanks Charlie. I contend if there's a security relationship >>set up between HA and FA, then message exchanges >>should always abide by this policy. And that operationally, the >>SA is valid and deregistrations of old CoA, HoA, CCoA >>will all work. >> >>One more thought is for such corner case (my humble opinion) >>where nothing is broken (unless administrator makes mistake >>which prevents general mobility service), it's best to leave >>specification as-is. If there is overwhelming evidence or deployment >>feedback that this is operational issue, then we can address this. >> >>Last 2 cents on this topic ... :) >> >>Kent >> >>At 12:53 PM 1/11/2005 -0800, Charles E.Perkins wrote: >> >>>Hello Kent, >>> >>>One more thought on this... >>> >>>Kent Leung wrote: >>> >>> > Charlie is requesting to loosen up the security checks between the >>> > FA and HA (even if SA exists) for the case of deregistering an CoA that's >>> > no the FA. >>> >>>It's also good to keep in mind what FHAE does. >>>It allows the home agent to verify the identity of the >>>foreign agent that claims to relay the deregistration. >>> >>>But, in the case under discussion the home agent doesn't >>>care which foreign agent sent the deregistration. >>>I believe it's always better to eliminate wasteful >>>work when it doesn't have any beneficial effect. >>> >>>Regards, >>>Charlie P. >>> >>>-- >>>Mip4 mailing list: Mip4@ietf.org >>> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>>Supplemental site: http://www.mip4.org/ >> >> >>-- >> | | Kent Leung >> :|: :|: IP Mobility Development >> :|||: :|||: IOS Technologies Division >> :|||||||: :|||||||: Voice: 408.526.5030 >>.:|||||||||:.:|||||||||:. Fax: 408.525.1653 >> c i s c o S y s t e m s Email: kleung@cisco.com > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 12 16:45:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20265 for ; Wed, 12 Jan 2005 16:45:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqX9-0000xf-B9 for mip4-web-archive@ietf.org; Wed, 12 Jan 2005 17:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coq3A-0004wC-Lq; Wed, 12 Jan 2005 16:29:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopwB-0000pG-ON for mip4@megatron.ietf.org; Wed, 12 Jan 2005 16:21:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17813 for ; Wed, 12 Jan 2005 16:21:54 -0500 (EST) Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqAH-00009b-Lk for mip4@ietf.org; Wed, 12 Jan 2005 16:36:30 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j0CLLMo4016302; Wed, 12 Jan 2005 15:21:22 -0600 (CST) Message-ID: <41E594D2.C52B565A@alcatel.com> Date: Wed, 12 Jan 2005 15:21:22 -0600 From: Tim Ozugur X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds951.usa.alcatel.com id j0CLLMo4016302 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Subject: [Mip4] CFP: International Workshop on Broadband Wireless Access Network on fixed network (BWAN 2005) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable (Apologies if you are receiving this message more than once) ------------------------------------------------------------------ CALL FOR PAPERS International Workshop on=20 Broadband Wireless Access Network on fixed network (BWAN 2005) (http://www.bwan.org/) ORLANDO, FL - JUNE 12, 2005 co-located with International Conference on Multimedia Services=20 Access Networks (MSAN '05: http://www.msan.org) CO_SPONSORED BY IEEE ****** Submission Deadline: February 4, 2005 ****** ------------------------------------------------------------------- Scope: Workshop: Broadband Wireless Access based on fixed Network=20 (xDSL, FTTx, etc ).=20 This Workshop will deal about complementary wireless broadband access network based on wired network (xDSL, FTTx, etc), 3G/4G and also about different techniques that can solved the tremendous challenges making the sharing of each phone line accessible through wireless access with a minimum guarantee of service for any connected user. In this workshop, the challenges to develop a new low cost mobile or semi-mobile access network with low powering unit will be explored and that may complement UMTS.=20 The workshop is intended to present new architectures of fixed network supporting mobility and/or nomadic features for wireless access (802.11, WiMax,=85802.20=85.), the sharing of the network access, bandwidth sharin= g on radio access. (Single Hop, mesh,=85) and discuss about the perspective= s of shared access network enhanced with wireless extension based on technologies such as WiFi,.. 802.16,.. 802.20, etc to maximize the performance of the overall link and reduce the costs. Within the framework of BWAN 2005, a new research field to prepare the next generation of network access.=20 Topics of interest to this workshop include (but are not limited to) performance studies and solutions (algorithms, protocols, architectures) that tend to improve experience of users of services and applications based on Internet.=20 Workshop Topics: - New Architectures and technologies for broadband wireless=20 access on fixed network(xDSL/FTTx,etc) with mobility features=20 - AAA (Authentification, Authorization, Accounting)=20 - Micro and macro mobility=20 - Medium access control (QoS, bandwidth sharing, fairness)=20 - End to end security and privacy issues on Mobile and/or nomadic=20 Access Network=20 - Low cost and low power integrated xDSL/FTTx+WiFi modem with=20 mobility enhancement=20 - Network cost performance and Business Models SLA-based services=20 - Radio extension such as 802.xy (WiFi, WiMax, etc) Relating Topics:=20 - Modulation, coding and antennas (MIMO)=20 - Interference mitigation for multiple access=20 - Complementary solutions to UMTS=20 - Location-Based Services Applications=20 - Scalability issues to large number of sites=20 - Standard and regulations=20 - IPv6 impact=20 - Mesh extensions =20 Publication:=20 The submissions to be presented at the workshop will be selected,=20 based on their originality, technical merit and topical relevance=20 of their contents. All accepted papers will be published in the=20 conference proceedings that will be available at the workshop.=20 Important Dates: - Submission Deadline: February 4, 2005=20 - Notification of acceptance: March 31, 2005=20 - Camera ready due: April 30, 2005=20 - Workshop date: June 12, 2005=20 Submission Guidelines: We encourage full papers that present well-developed research results (up to 4 pages double column, including figures and references), but also short papers that are more speculative in nature, works in progress and position papers are solicited.=20 Submitted papers must be unpublished and must not be currently under review for any other publication. If you are unsure whether your work falls within the scope of the conference, please contact the Program Co-Chairs.=20 All paper submissions will be carefully reviewed by experts. The authors of accepted papers must guarantee that their paper will be presented at the workshop. At least one author of each accepted paper must be registered for the workshop in order for that paper to appear in the proceedings and to be scheduled for presentation.=20 All submissions should be sent electronically in Postscript or Adobe PDF format. Detailed instructions about submissions are available at the submission page. The electronic submission is available at EDAS.=20 _____________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jan 14 08:53:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14872 for ; Fri, 14 Jan 2005 08:53:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpS7S-0003Rb-Vc for mip4-web-archive@ietf.org; Fri, 14 Jan 2005 09:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpRiZ-0006IT-Sh; Fri, 14 Jan 2005 08:42:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpItP-0006eC-K1 for mip4@megatron.ietf.org; Thu, 13 Jan 2005 23:17:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23805 for ; Thu, 13 Jan 2005 23:16:56 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpJ7l-0000wL-74 for mip4@ietf.org; Thu, 13 Jan 2005 23:31:50 -0500 Received: by rproxy.gmail.com with SMTP id r35so296531rna for ; Thu, 13 Jan 2005 20:16:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=fjMLVmgiMIoS9CHP9k/aZ8nzQAojBysIXXCFro2w+HaWv+Tfhf+4wDvgfPKMWs02XdK0bfheKZhrJ4EskD6Xni8m2s9slJHeA3Tp6eIREf9UmxBe6PybecK5JZUeDc8W3RxSrMSXFWpBi0qZskamytw5cIJr9mJ+LIPZ74vyV4k= Received: by 10.38.74.2 with SMTP id w2mr483153rna; Thu, 13 Jan 2005 20:16:56 -0800 (PST) Received: by 10.38.161.59 with HTTP; Thu, 13 Jan 2005 20:16:56 -0800 (PST) Message-ID: <23cf3aa505011320164bd1953@mail.gmail.com> Date: Thu, 13 Jan 2005 20:16:56 -0800 From: Marco Zuniga To: marco.zuniga@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Jan 2005 08:42:21 -0500 Subject: [Mip4] Call For Papers: Symposium on Wireless Sensor Networks (IEEE WirelessCom 2005) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marco Zuniga List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Dear Colleagues, This is the Call For Papers for the Symposium on Wireless Sensor Networks to be held at Sheraton Maui Resort, Kaanapali Beach, Maui, Hawaii, USA in conjunction with IEEE WirelessCom 2005, June 13-16, 2005. http://bit.csc.lsu.edu/WirelessComm05/WSNsymposium/ We apologize if you have received multiple copies of this CFP. Scope Wireless Sensor Networks have received tremendous attention over the past few years. These systems can potentially benefit a variety of scientific, military and commercial applications. Recent years have seen tremendous advancement to this vision and have offered the ability to deploy networks of densely deployed, inexpensive sensor nodes. The vast potential for this research area has been demonstrated by numerous scientific and commercial applications that have emerged in recent years, as well as by the number of industrial and research institutions working in this area. Sensor networks combine distributed sensing, computation, storage, and wireless multi hop communication. Many challenges need to be overcome in this research area to realize its potential. Original papers are invited on a broad range of research topics relating to wireless sensor networks. Papers must represent high-quality and previously unpublished work. Topics of interest include, but are not limited to, the following: * Communication techniques and protocols * Scalable architectures and programming models * Energy and resource management * In-network processing and data aggregation * Distributed query processing and data storage * Applications of wireless sensor networks * Localization, time-synchronization and calibration * Simulation tools, operating systems and middleware * Collaborative signal processing * Distributed control and actuation * Security * Cross-layer design and optimization Important Dates Paper Submission Deadline: March 10, 2005 Notification of Acceptance: April 15, 2005 Camera-Ready Papers: May 1, 2005 Committee: * Co-Chairs Rajgopal Kannan, LSU, rkannan@bit.csc.lsu.edu Bhaskar Krishnamachari, USC, bkrishna@usc.edu Yi Pan, Georgia State University, cscyip@techie.cs.gsu.edu Pingzhi Fan, Southwest Jiaotong University, p.fan@ieee.org * Vice Chairs Deepak Ganesan, U Mass Amherst, dganesan@cs.umass.edu Chiti Francesco, Universit di Firenze, chiti@lenst.det.unifi.it Narayanan Sadagopan, USC, narayans@usc.edu * Publicity Chairs Shuangqing Wei, LSU, swei@ece.lsu.edu Marco Zuniga, USC, marcozun@usc.edu More details can be found at: http://bit.csc.lsu.edu/WirelessComm05/WSNsymposium/ Regards, Organizing Committee (Symposium on Wireless Sensor Networks) -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 17 05:08:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22311 for ; Mon, 17 Jan 2005 05:08:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqU3l-0000KB-Do for mip4-web-archive@ietf.org; Mon, 17 Jan 2005 05:24:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqThd-0001GA-Ie; Mon, 17 Jan 2005 05:01:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqTah-0000Ur-2h for mip4@megatron.ietf.org; Mon, 17 Jan 2005 04:54:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21183 for ; Mon, 17 Jan 2005 04:54:28 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqTpj-0008QT-1J for mip4@ietf.org; Mon, 17 Jan 2005 05:10:03 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0H9uNJD003387; Mon, 17 Jan 2005 02:56:23 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id j0H9r6fD004713; Mon, 17 Jan 2005 03:53:07 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 89D5586602A; Mon, 17 Jan 2005 10:54:27 +0100 (CET) Message-ID: <41EB8B4E.2010205@motorola.com> Date: Mon, 17 Jan 2005 10:54:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] DRAFT Minutes from MIP4 meeting in Washington References: <41B76050.8080709@levkowetz.com> In-Reply-To: <41B76050.8080709@levkowetz.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1932449800==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1932449800== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09CEA5E05D0D7600824DE562" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09CEA5E05D0D7600824DE562 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear Henrik, Charles, Where are the slides of the "Adapting FMIPv6 for MIPv4" presentation at Washington DC? Specifically I'm looking for the comparisons and the figures. I can not find them on the mip4.org site. Thanks, Alex Henrik Levkowetz wrote: > Below are the minutes from the MIP4 WG meeting in Washington. [...] > The minutes are also available here in three different formats: > > http://www.mip4.org/ietf61/minutes.pyht > http://www.mip4.org/ietf61/minutes.html > http://www.mip4.org/ietf61/minutes.txt [...] > ======================================================================== > MIP4 WG Minutes (Thursday, November 11, 2004, 1300-1500) > ======================================================================== [...] > 9. Adapting MIPv6 Fast Handover for MIP4: Charlie Perkins > ------------------------------------------------------------------------ > > Issue: > > FMIPv4 motivation and design ideas, implementation benchmarks. > Available for anyone to work on - will not push this. --------------enig09CEA5E05D0D7600824DE562 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB64tTMmC0w56zj54RAtlXAJ0YhFgQ8tH1Bs5JItSuLywwwJ06awCg03/y cNdbPFyXv+zuIIUWHTTH6XY= =56eH -----END PGP SIGNATURE----- --------------enig09CEA5E05D0D7600824DE562-- --===============1932449800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1932449800==-- From mip4-bounces@ietf.org Tue Jan 18 17:13:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12422 for ; Tue, 18 Jan 2005 17:13:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr1rC-00072j-LN for mip4-web-archive@ietf.org; Tue, 18 Jan 2005 17:29:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr1XN-0004Mg-Ie; Tue, 18 Jan 2005 17:09:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqz1n-0006ki-Bj for mip4@megatron.ietf.org; Tue, 18 Jan 2005 14:28:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22662 for ; Tue, 18 Jan 2005 14:28:33 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqzH7-0000nY-1x for mip4@ietf.org; Tue, 18 Jan 2005 14:44:25 -0500 Received: by wproxy.gmail.com with SMTP id 71so751892wri for ; Tue, 18 Jan 2005 11:28:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=rSCIQgYQD+B5405Utcj2GmNGbhXSMpO88pV/upRiYJmDDTXkX32wpvmbvLvRx/vXakLfb9U6vW4V7G9IQ3/uOSIElbIfepkr4ObgRr0HxoNtWV+0bBXLRcWwbyCQwttxZizfkkHu3OcMtrayBxSiy6HLkY2aQ6M6V9KCeZ/fooI= Received: by 10.54.37.68 with SMTP id k68mr226525wrk; Tue, 18 Jan 2005 11:28:03 -0800 (PST) Received: by 10.54.10.18 with HTTP; Tue, 18 Jan 2005 11:28:03 -0800 (PST) Message-ID: <88b9e99205011811286c32918c@mail.gmail.com> Date: Tue, 18 Jan 2005 14:28:03 -0500 From: B Krishnamachari To: mip4@ietf.org, manet@ietf.org, performance@haven.epm.ornl.gov.cnri.reston.va.us, tel-bcn@mat.upc.es, tel-vil@mat.upc.es, disc-delegates@disc2000.org.cnri.reston.va.us, alg@comm.toronto.edu, cabernet-events@ncl.ac.uk, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, end2end-interest@isi.edu, announce@tcos.org, testnet@canarie.ca, eapls-request@mailbase.ac.uk, dbworld@cs.wisc.edu, xtp-relay@cs.concordia.ca, siksleden@cs.uu.nl, int-serv@isi.edu, comm-theory@ieee.org, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsys@brunet.bn, comswtc@ieee.org, sigcomm-members@acm.org, noe-one@prezzemolo.polito.it, sigmob@acm.org, news-announce-conferences@uunet.uu.net, stds-802-wpan@ieee.org In-Reply-To: <88b9e992050118112779bccc73@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <88b9e992041202030222a47c64@mail.gmail.com> <88b9e992050118112538643ac0@mail.gmail.com> <88b9e992050118112542866dbb@mail.gmail.com> <88b9e9920501181125567090f8@mail.gmail.com> <88b9e99205011811263596158a@mail.gmail.com> <88b9e99205011811265f20aa77@mail.gmail.com> <88b9e992050118112779bccc73@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 18 Jan 2005 17:09:21 -0500 Subject: [Mip4] CFP: BroadNets 2005 Broadband Applications and Services Symposium X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: B Krishnamachari List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------------------- CALL FOR PAPERS Second Annual International Conference on Broadband Networks (BroadNets 2005) Broadband Applications and Services Symposium October 3 - 7, 2005 Boston, Massachusetts, USA http://www.broadnets.org/2005 Submission Deadline: February 1, 2005 ----------------------------------------------------------------------- SCOPE ----- BroadNets 2005 is an international conference focusing on broadband networking and covers the entire gamut of next generation networks with high bandwidth available for both wireless and wireline networks. The conference will consist of the following three symposia: ** Broadband Wireless Networking Symposium: It covers mobility, routing for multihop, multimedia QoS and traffic management, cross-layer optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed wireless networking. ** Broadband Optical Networking Symposium: It covers WDM technologies, Ethernet and MPLS integration into the optical layer, Next-Generation SONET/SDH, as well as SAN extensions over DWDM/SONET/SDH. ** Broadband Applications/Services Symposium: It covers middleware and service architectures for broadband applications, pervasive computing and ubiquitous communications, and universal broadband access for information services. BroadNets 2005 will thus offer a unique forum for researchers from academia, government and industry to share ideas and disseminate new results in these important areas. This Call for Papers describes the details for the Broadband Applications/Services Symposium ONLY. (Refer to the www.broadnets.org/2005 website for the details of Broadband Optical Networking Symposium and Broadband Wireless Networking Symposium.) This Symposium invites academic and industry researchers to present issues and opportunities for tomorrow?s IT infrastructure as driven by broadband applications and services. We invite the research community to present the most recent advances in this field, to discuss exciting research topics and development of testbeds and applications, and to share their research and development experiences. We hope to organize one or more panel sessions of industry leaders to offer them an opportunity to outline their vision for future broadband networks, as well as to offer academic and national laboratory researchers an opportunity to ask questions/provide feedback to these industry leaders. Our goal is to raise the awareness of new industry developments in the academic community, and, at the same time, to establish a sound link between applied and theoretical research. Topics of interest for which we are soliciting full-length papers include, but are not limited to, the following: =B7 Applications for security and privacy =B7 Applications and services for grid networks =B7 Grid middleware =B7 Collaborative remote visualization and virtual reality =B7 Data mining and high-speed file transfer applications =B7 Collaborative computational steering =B7 Multimedia applications for wireless networks =B7 Multimedia applications for optical networks =B7 Video-conferencing and video-telephony =B7 Video-on-demand, TV-on-demand =B7 Ultra Wideband (UWB) applications =B7 Applications in 3G/4G networks =B7 Applications and services in integrated 3GPP-WLAN networks =B7 Applications for wireless indoor & home networks =B7 Applications in large-scale sensor networks =B7 P2P applications =B7 Applications for overlay networks =B7 Multicast applications =B7 Broadband access applications =B7 Pricing models for new services =B7 Standards, licensing and regulation =B7 Economics and business cases =B7 Applications for e-government, e-health and e-science =B7 Storage applications IMPORTANT DATES --------------- Submission Deadline: February 1, 2005 Acceptance Notification: May 1, 2005 Final Manuscript Due: June 1, 2005 PAPER SUBMISSION INSTRUCTIONS ----------------------------- Authors are invited to submit full papers of up to 10 pages in IEEE conference proceedings format. Papers should be submitted in PDF format to the respective symposium through the EDAS system at http://edas.info/Conference.cgi. CONFERENCE ORGANIZING COMMITTEE ------------------------------- General Chair: Dr. Arun Somani, Iowa State University, arun@iastate.edu General Vice Chair: Dr. Thomas Hou, Virginia Tech, thou@vt.edu Technical Program Chairs - Services and Applications Symposium Dr. Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu Dr. Admela Jukan, NSF, ajukan@nsf.gov Technical Program Chair- Wireless Networking Symposium: Dr. Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca Technical Program Chairs - Optical Networking Symposium Dr. David Griffith, NIST, david.griffith@nist.gov Dr. Srini Ramasubramanian, Univ. of Arizona, srini@ece.arizona.edu Workshops Chair: Dr. Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu Dr. Byrav Ramamurthy, University of Nebraska-Lincoln, byrav@cse.unl.edu Dr. Behcet Sarikaya, University of Northern British Columbia, sarikaya@unbc.ca Tutorials Chair: Dr. Steven Low, Cal. Tech., slow@caltech.edu Panels Chairs: Dr. Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu Dr. Rudra Dutta, NCSU, dutta@csc.ncsu.edu Publicity Chairs: Dr. Bhaskar Krishnamachari, USC, bkrishna@usc.edu Dr. Takeo Hamada, Fujitsu Labs of America, thamada@fla.fujitsu.com Website/Information Systems Chair: Dr. Shiwen Mao, Virginia Tech, smao@vt.edu Publications Chairs: Dr. Ahmed Kamal, Iowa State University, kamal@iastate.edu Dr. Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com Exhibits and Sponsorships Chair: Dr. Sai Shankar N, Philips Research USA, sai.shankar@philips.com Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, Univ. of Maryland, Baltimore County, krishna@umbc.edu -------------------------------------------------------------------------- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 19 18:34:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09332 for ; Wed, 19 Jan 2005 18:34:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrPak-0002k0-1P for mip4-web-archive@ietf.org; Wed, 19 Jan 2005 18:50:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrPF4-0001n0-3I; Wed, 19 Jan 2005 18:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrPD3-0001Q0-La for mip4@megatron.ietf.org; Wed, 19 Jan 2005 18:25:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08837 for ; Wed, 19 Jan 2005 18:25:55 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrPSb-0002XM-I4 for mip4@ietf.org; Wed, 19 Jan 2005 18:42:02 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 Jan 2005 16:33:04 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0JNPLMA029021 for ; Wed, 19 Jan 2005 15:25:23 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-211.cisco.com [128.107.163.211]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAU27417; Wed, 19 Jan 2005 15:25:21 -0800 (PST) Message-Id: <4.3.2.7.2.20050119151642.02b41798@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jan 2005 15:25:20 -0800 To: mip4@ietf.org From: Kent Leung In-Reply-To: <41EB8B4E.2010205@motorola.com> References: <41B76050.8080709@levkowetz.com> <41B76050.8080709@levkowetz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Mip4] 3344bis clarification on identifying the FA's SA X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi. I realized during our Deregistration/FHAE discussions that we assumed that the FA's SA is indexed by the source IP address of the RRQ on the HA. But it's not explicitly clear in RFC 3344 (going back to RFC 2002) that source IP address is the method to identify the FA since CoA may also be used. So this leaves ambiguity in implementation and also introduces deployment issues where the SA is configured based on CoA. I think we should clearly state some text to avoid ambiguity? Something like "The FA or HA is identified by the source IP address of the registration message. This IP address and the SPI is used to index the security association to authenticate the message." Thoughts? Kent -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 19 19:43:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14072 for ; Wed, 19 Jan 2005 19:43:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrQfw-0004Pa-6X for mip4-web-archive@ietf.org; Wed, 19 Jan 2005 19:59:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrQJ9-0007YW-DL; Wed, 19 Jan 2005 19:36:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrQGk-0006jC-Rd for mip4@megatron.ietf.org; Wed, 19 Jan 2005 19:33:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13436 for ; Wed, 19 Jan 2005 19:33:47 -0500 (EST) Received: from av2-1-sn3.vrr.skanova.net ([81.228.9.107]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrQWJ-00048q-7n for mip4@ietf.org; Wed, 19 Jan 2005 19:49:56 -0500 Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 4995337F00; Thu, 20 Jan 2005 01:33:13 +0100 (CET) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 3B67F37E50; Thu, 20 Jan 2005 01:33:13 +0100 (CET) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 26FCD38008; Thu, 20 Jan 2005 01:33:13 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1CrQG8-0001Nn-La; Thu, 20 Jan 2005 01:33:12 +0100 Message-ID: <41EEFC3F.9000808@levkowetz.com> Date: Thu, 20 Jan 2005 01:33:03 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung Subject: Re: [Mip4] 3344bis clarification on identifying the FA's SA References: <41B76050.8080709@levkowetz.com> <41B76050.8080709@levkowetz.com> <4.3.2.7.2.20050119151642.02b41798@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20050119151642.02b41798@mira-sjcm-2.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1463976312==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1463976312== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA34F30B2C8A5802ACA2B1D1C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA34F30B2C8A5802ACA2B1D1C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kent, On 2005-01-20 12:25 am Kent Leung said the following: > Hi. I realized during our Deregistration/FHAE discussions that > we assumed that the FA's SA is indexed by the source IP address of the > RRQ on the HA. But it's not explicitly clear in RFC 3344 (going back to > RFC 2002) that source IP address is the method to identify the FA since > CoA may also be used. > > So this leaves ambiguity in implementation and also introduces deployment > issues where the SA is configured based on CoA. > > I think we should clearly state some text to avoid ambiguity? Something like > "The FA or HA is identified by the source IP address of the registration > message. This IP address and the SPI is used to index the security > association to authenticate the message." > > Thoughts? I suspect that the reason this has not been raised before is that before we introduced NAT traversal into the equation, it was an unstated assumption that the source IP address and the CoA address would be the same. Indeed, it is this assumption which is the base for detection of NATs in 3519 - if src address and CoA address differ, then you say "Ah, this packet has gone through a NAT". So one way of clearing up the ambiguity could be the text you propose; another could be to clearly state that the FA sends the reply with the source address equal to the Care-of Address, typically through the interface having this address. There may be other ones too, and I'm not sure which is the best way to go here. One question which pops into my head, though, is why base this on the src address, in preference to the CoA? It would be interesting to hear your reasoning here. Which one we pick may impact a 3519bis (NAT traversal) document more or less... Henrik --------------enigA34F30B2C8A5802ACA2B1D1C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFB7vxIeVhrtTJkXCMRAp/iAKCq7vstR0aA7l6fUtuTSAlc9saOPQCg9msa 4EwB6aK3apr509USPn12ZcI= =mZx/ -----END PGP SIGNATURE----- --------------enigA34F30B2C8A5802ACA2B1D1C-- --===============1463976312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1463976312==-- From mip4-bounces@ietf.org Thu Jan 20 02:52:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02117 for ; Thu, 20 Jan 2005 02:52:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrXMn-0006Jz-Sq for mip4-web-archive@ietf.org; Thu, 20 Jan 2005 03:08:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrX4L-0002dR-TK; Thu, 20 Jan 2005 02:49:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrX1z-0002Ei-Eq for mip4@megatron.ietf.org; Thu, 20 Jan 2005 02:47:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01770 for ; Thu, 20 Jan 2005 02:47:00 -0500 (EST) Received: from 213.80.52.78.dataphone.se ([213.80.52.78] helo=mailgw.local.ipunplugged.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrXHa-0006BE-Ah for mip4@ietf.org; Thu, 20 Jan 2005 03:03:11 -0500 Received: from pcfrej (rd4.ipunplugged.com [213.80.52.85]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id j0K7krdM015139; Thu, 20 Jan 2005 08:46:58 +0100 Message-Id: <200501200746.j0K7krdM015139@mailgw.local.ipunplugged.com> From: "Fredrik Johansson" To: "'Kent Leung'" , Subject: RE: [Mip4] 3344bis clarification on identifying the FA's SA Date: Thu, 20 Jan 2005 08:46:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4.3.2.7.2.20050119151642.02b41798@mira-sjcm-2.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT+f3+z/zeLEzU9Quuc8vRSpu6cQgAREbLA X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on mailgw.local.ipunplugged.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fredrik@ipunplugged.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Kent, Just a thought, what happens when you have a FA with multiple interfaces that all utilize the same CoA? Do you have to have multiple SAs for what is basically one FA? /Fredrik > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > Behalf Of Kent Leung > Sent: den 20 januari 2005 00:25 > To: mip4@ietf.org > Subject: [Mip4] 3344bis clarification on identifying the FA's SA > > Hi. I realized during our Deregistration/FHAE discussions > that we assumed that the FA's SA is indexed by the source IP > address of the RRQ on the HA. But it's not explicitly clear > in RFC 3344 (going back to RFC 2002) that source IP address > is the method to identify the FA since CoA may also be used. > > So this leaves ambiguity in implementation and also > introduces deployment issues where the SA is configured based on CoA. > > I think we should clearly state some text to avoid ambiguity? > Something like "The FA or HA is identified by the source IP > address of the registration message. This IP address and the > SPI is used to index the security association to authenticate > the message." > > Thoughts? > > Kent > > -- > | | Kent Leung > :|: :|: IP Mobility Development > :|||: :|||: IOS Technologies Division > :|||||||: :|||||||: Voice: 408.526.5030 > .:|||||||||:.:|||||||||:. Fax: 408.525.1653 > c i s c o S y s t e m s Email: kleung@cisco.com > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 20 12:33:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18687 for ; Thu, 20 Jan 2005 12:33:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrgRb-0004rs-9X for mip4-web-archive@ietf.org; Thu, 20 Jan 2005 12:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crg9b-0002VJ-BJ; Thu, 20 Jan 2005 12:31:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrUTz-0001My-JQ for mip4@megatron.ietf.org; Thu, 20 Jan 2005 00:03:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05465 for ; Thu, 20 Jan 2005 00:03:44 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrUjW-0002MJ-Bi for mip4@ietf.org; Thu, 20 Jan 2005 00:19:55 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAL00HZJNEGTX@szxga02-in.huawei.com> for mip4@ietf.org; Thu, 20 Jan 2005 13:03:52 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAL00APINEGZU@szxga02-in.huawei.com> for mip4@ietf.org; Thu, 20 Jan 2005 13:03:52 +0800 (CST) Received: from keshavaak ([10.18.4.181]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IAL00B08NEC6N@szxml02-in.huawei.com> for mip4@ietf.org; Thu, 20 Jan 2005 13:03:49 +0800 (CST) Date: Thu, 20 Jan 2005 10:39:23 +0530 From: keshav To: mip4@ietf.org Message-id: <000001c4feae$35ecea20$b504120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a X-Mailman-Approved-At: Thu, 20 Jan 2005 12:31:30 -0500 Cc: vikasg@huawei.com, "'Keshav'" Subject: [Mip4] MIP4 if the Homenetwork(interface) is down . X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavak@huawei.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0128195423==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 This is a multi-part message in MIME format. --===============0128195423== Content-type: multipart/alternative; boundary="Boundary_(ID_agfcfNADrR1xYltBMCIQkA)" This is a multi-part message in MIME format. --Boundary_(ID_agfcfNADrR1xYltBMCIQkA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, For the Home interface network down scenario I am not able find in the RFC 3344, 1) Should the Registration be accepted for that Mobile Node? 2) For already registered Mobile node should we clear the binding entries? Can some one please clarify this. Regards, Keshava --Boundary_(ID_agfcfNADrR1xYltBMCIQkA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi,

            For the Home interface network down scenario I am not able find in the RFC 3344,

 

1)   Should the Registration be accepted for that Mobile Node?

2)       For already registered Mobile node should we clear the binding entries?

           

Can some one please clarify this.

 

Regards,

Keshava

           

           

 

--Boundary_(ID_agfcfNADrR1xYltBMCIQkA)-- --===============0128195423== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0128195423==-- From mip4-bounces@ietf.org Thu Jan 20 14:19:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26982 for ; Thu, 20 Jan 2005 14:19:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cri64-0007mB-9J for mip4-web-archive@ietf.org; Thu, 20 Jan 2005 14:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crhej-0006Tx-Sc; Thu, 20 Jan 2005 14:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrhXc-0004NB-DF for mip4@megatron.ietf.org; Thu, 20 Jan 2005 14:00:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24960 for ; Thu, 20 Jan 2005 14:00:23 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrhnL-00071k-Iv for mip4@ietf.org; Thu, 20 Jan 2005 14:16:40 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2005 11:04:41 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0KIxoNt029120; Thu, 20 Jan 2005 10:59:51 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-211.cisco.com [128.107.163.211]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAU97217; Thu, 20 Jan 2005 10:59:47 -0800 (PST) Message-Id: <4.3.2.7.2.20050120105033.02d75e60@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jan 2005 10:59:47 -0800 To: keshavak@huawei.com From: Kent Leung Subject: Re: [Mip4] MIP4 if the Homenetwork(interface) is down . In-Reply-To: <000001c4feae$35ecea20$b504120a@in.huawei.com> Mime-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: vikasg@huawei.com, "'Keshav'" , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1132869539==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 --===============1132869539== Content-Type: multipart/alternative; boundary="=====================_92118208==_.ALT" --=====================_92118208==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Keshava. At 10:39 AM 1/20/2005 +0530, keshav wrote: >Hi, > > For the Home interface network down scenario I am not able > find in the RFC 3344, > > That's because it's not explicitly specified in the RFC. :) >1) Should the Registration be accepted for that Mobile Node? If the home interface is down, then routing is affected and traffic to MN can't reach the HA. The mobility service for the MN is disabled regardless if the MN is registered or not. I think it's better to deny the registration to notify the MN that service is not available on the HA. >2) For already registered Mobile node should we clear the binding >entries? > > I think this is implementation details. Kent >Can some one please clarify this. > > > >Regards, > >Keshava > > > > > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com --=====================_92118208==_.ALT Content-Type: text/html; charset="us-ascii" Hi Keshava.

At 10:39 AM 1/20/2005 +0530, keshav wrote:

Hi,

            For the Home interface network down scenario I am not able find in the RFC 3344,

 


That's because it's not explicitly specified in the RFC. :)



1)   Should the Registration be accepted for that Mobile Node?


If the home interface is down, then routing is affected and traffic to
MN can't reach the HA.  The mobility service for the MN is disabled
regardless if the MN is registered or not. I think it's better to deny
the registration to notify the MN that service is not available on the
HA.


2)       For already registered Mobile node should we clear the binding entries?

           

I think this is implementation details.

Kent



Can some one please clarify this.

 

Regards,

Keshava

           

           

 
--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

--
     |           |                   Kent Leung
    :|:         :|:                  IP Mobility Development
   :|||:       :|||:                 IOS Technologies Division
  :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
 c i s c o S y s t e m s             Email: kleung@cisco.com --=====================_92118208==_.ALT-- --===============1132869539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1132869539==-- From mip4-bounces@ietf.org Thu Jan 20 14:42:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28235 for ; Thu, 20 Jan 2005 14:42:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CriRe-0008FJ-12 for mip4-web-archive@ietf.org; Thu, 20 Jan 2005 14:58:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cri7F-000432-5o; Thu, 20 Jan 2005 14:37:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cri4r-0003If-Fp for mip4@megatron.ietf.org; Thu, 20 Jan 2005 14:34:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27864 for ; Thu, 20 Jan 2005 14:34:43 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CriKZ-00083q-0G for mip4@ietf.org; Thu, 20 Jan 2005 14:51:01 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2005 12:40:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0KJX51M017993; Thu, 20 Jan 2005 11:33:05 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-211.cisco.com [128.107.163.211]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAV01266; Thu, 20 Jan 2005 11:33:04 -0800 (PST) Message-Id: <4.3.2.7.2.20050120110108.02b3f568@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jan 2005 11:33:03 -0800 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] 3344bis clarification on identifying the FA's SA In-Reply-To: <41EEFC3F.9000808@levkowetz.com> References: <4.3.2.7.2.20050119151642.02b41798@mira-sjcm-2.cisco.com> <41B76050.8080709@levkowetz.com> <41B76050.8080709@levkowetz.com> <4.3.2.7.2.20050119151642.02b41798@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Hi Henrik. At 01:33 AM 1/20/2005 +0100, Henrik Levkowetz wrote: >I suspect that the reason this has not been raised before is that before >we introduced NAT traversal into the equation, it was an unstated >assumption that the source IP address and the CoA address would be the same. KL> Actually, RFC 2002/3344 states to use the egress interface's IP address as the source IP address of the RRQ (sect. 3.7.2.2). When RFC 3519 was introduced, the mandate for the addressed to be the same was added. >Indeed, it is this assumption which is the base for detection of NATs in >3519 - if src address and CoA address differ, then you say "Ah, this >packet has gone through a NAT". KL> Yes. There has been contention on this matching address requirement. Excerpt from "[issue44] RFC 3344 - Source Address of the RRQ & FHAE issues" thread: >Keeping RFC3344 text as is presently enables a vendor/operator to use >different IP addresses for the signaling control and the data forwarding >plane which might be useful in a number of configurations and operational >environments. In addition, removing the general assumption that the outgoing >source IP address is associated with the outgoing interface (a fairly common >IP configuration) and replacing it with a nailed up source address because of >a bug in NAT Traversal, may well cause us future problems. There was general agreement to untie this link in 3519bis to allow the source IP address to be the egress interface's for NAT Traversal case. >So one way of clearing up the ambiguity could be the text you propose; >another could be to clearly state that the FA sends the reply with the >source address equal to the Care-of Address, typically through the >interface having this address. KL> See above. I think we should not force this binding of addresses. >There may be other ones too, and I'm not sure which is the best way to go >here. > >One question which pops into my head, though, is why base this on the src >address, in preference to the CoA? It would be interesting to hear your >reasoning here. Which one we pick may impact a 3519bis (NAT traversal) >document more or less... KL> Good question. Just to point out it's not just me. >At 09:39 AM 12/15/2004 -0600, Pete McCann wrote: >But the FA can be identified from its source IP address in the RRQ >(absent NAT considerations). At 01:21 PM 12/17/2004 -0800, Charles E.Perkins wrote: >Up until now, I have thought that the mobility security association >was selected based on the source IP address of the IP packet, >since it was a security association for a network-layer protocol. Since RFC was ambiguous on how exactly to identify the FA, I came up with logic that works in all cases. However, it became apparent during the discussion on deregistration of previous CoA using FHAE that source IP address of packet works while the CoA will not. Kent -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 20 14:50:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28854 for ; Thu, 20 Jan 2005 14:50:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CriZq-0008SV-W5 for mip4-web-archive@ietf.org; Thu, 20 Jan 2005 15:06:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CriFf-0005FG-Po; Thu, 20 Jan 2005 14:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CriCp-0004nY-CC for mip4@megatron.ietf.org; Thu, 20 Jan 2005 14:42:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28275 for ; Thu, 20 Jan 2005 14:42:57 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CriSZ-0008Fa-1c for mip4@ietf.org; Thu, 20 Jan 2005 14:59:15 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2005 11:43:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0KJgORQ021702; Thu, 20 Jan 2005 11:42:26 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-211.cisco.com [128.107.163.211]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAV02319; Thu, 20 Jan 2005 11:42:23 -0800 (PST) Message-Id: <4.3.2.7.2.20050120113323.02d48f40@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jan 2005 11:42:23 -0800 To: fredrik@ipunplugged.com From: Kent Leung Subject: RE: [Mip4] 3344bis clarification on identifying the FA's SA In-Reply-To: <200501200746.j0K7krdM015139@mailgw.local.ipunplugged.com> References: <4.3.2.7.2.20050119151642.02b41798@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Hi Fredrik. Yes, unfortunately that would be the case when using the source IP address for indexing the SA. BTW, there were discussions of using FA NAI to identify the FA for authentication. This would allow one SA per FA. Subject was "[Issue 45] RFC 3344 - FHAE issue when using a different careofaddress". >At 01:03 PM 3/16/2004 -0800, Kent Leung wrote: >Use of FA NAI sounds reasonable and generic FA identifier will >come in handy for future features. But this is outside the scope of 3344bis. I'm seeking a clarification in 3344bis. Kent At 08:46 AM 1/20/2005 +0100, Fredrik Johansson wrote: >Kent, > >Just a thought, what happens when you have a FA with multiple interfaces >that all utilize the same CoA? Do you have to have multiple SAs for what is >basically one FA? > >/Fredrik > > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > > Behalf Of Kent Leung > > Sent: den 20 januari 2005 00:25 > > To: mip4@ietf.org > > Subject: [Mip4] 3344bis clarification on identifying the FA's SA > > > > Hi. I realized during our Deregistration/FHAE discussions > > that we assumed that the FA's SA is indexed by the source IP > > address of the RRQ on the HA. But it's not explicitly clear > > in RFC 3344 (going back to RFC 2002) that source IP address > > is the method to identify the FA since CoA may also be used. > > > > So this leaves ambiguity in implementation and also > > introduces deployment issues where the SA is configured based on CoA. > > > > I think we should clearly state some text to avoid ambiguity? > > Something like "The FA or HA is identified by the source IP > > address of the registration message. This IP address and the > > SPI is used to index the security association to authenticate > > the message." > > > > Thoughts? > > > > Kent > > > > -- > > | | Kent Leung > > :|: :|: IP Mobility Development > > :|||: :|||: IOS Technologies Division > > :|||||||: :|||||||: Voice: 408.526.5030 > > .:|||||||||:.:|||||||||:. Fax: 408.525.1653 > > c i s c o S y s t e m s Email: kleung@cisco.com > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > > > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 24 08:03:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04967 for ; Mon, 24 Jan 2005 08:03:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct48l-00024P-K6 for mip4-web-archive@ietf.org; Mon, 24 Jan 2005 08:20:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct3pO-0000tJ-2B; Mon, 24 Jan 2005 08:00:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct3ld-0000cr-PS; Mon, 24 Jan 2005 07:56:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04228; Mon, 24 Jan 2005 07:56:27 -0500 (EST) Received: from smtp-out.nebula.fi ([217.30.180.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct428-0001rD-K3; Mon, 24 Jan 2005 08:13:33 -0500 Received: from smtp2.nblnetworks.fi (smtp2.nblnetworks.fi [217.30.182.231]) by smtp-out.nebula.fi (8.12.11/8.12.11) with ESMTP id j0OCpBtO008212; Mon, 24 Jan 2005 14:51:11 +0200 Received: from yin.bjorns.net (xdsl-178-232.nblnetworks.fi [217.30.178.232]) by smtp2.nblnetworks.fi (8.12.8/8.12.8) with ESMTP id j0OCuKwI027374; Mon, 24 Jan 2005 14:56:20 +0200 Received: from bjorn by yin.bjorns.net with local (Exim 3.36 #1 (Debian)) id 1Ct3lV-0001Vo-00; Mon, 24 Jan 2005 14:56:21 +0200 Date: Mon, 24 Jan 2005 14:56:21 +0200 From: bjorn@iki.fi To: iesg@ietf.org Subject: Re: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard Message-ID: <20050124125621.GB5599@yin.bjorns.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp-out.nebula.fi id j0OCpBtO008212 X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Figures 2 and 3 and bullet 5 for the figures give the impression that the second registraiton request bypasses the foreign agent. Surly all requests must traverse the FA (if one is present), mustn't they? Just as a note, a simpler and perhaps more backward compatible way to add= ress=20 one of the issues addressed in the draft is to use subnet directed broadcast method described in RFC3344 but with a unicast address: 1. The MN sends a RRQ to a unicast HA address 2. If the HA that receives the RRQ wants to redirect the MN to another HA it replies with the "unknown HA" failure code and sets the redirected = HA in the HA field of the RRP as specified in RFC3344. 3. The MN registrers with the new HA. The unicast address used in step 1 may either be an address owned by a single specific HA, or it may be a virtual HA cluster address which is directed to an appropriate HA address in the home network (with whatever means, e.g. ARP or routing tables). This way one can achieve lightweight load balancing and high-availability while providing backward compatiblity. We have a couple of years of good real-world experiences using this method in our product. This method is of course not as flexible as the one described in the draft and does not address all issues. But it may perhaps be worthwhile to consider the method I described in scenarios where it is sufficient as it is (nearly) backwards compatible from the MN point-of-view (provided it does not differient between broadcast addresses and unicast addresses) and does not introduce new registration message extensions. Bjorn Andersson On Wed, Jan 12 2005, at 10:53:26 -0500, The IESG wrote: > The IESG has received a request from the Mobility for IPv4 WG to consid= er the=20 > following document: >=20 > - 'Mobile IPv4 Dynamic Home Agent Assignment ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-26. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-= 03.txt >=20 >=20 > --=20 > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ --=20 Bj=F6rn Andersson PGP id 5AFC144B Mobile +358 40 7723074 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 24 11:41:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28387 for ; Mon, 24 Jan 2005 11:41:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7XY-0002VS-0o for mip4-web-archive@ietf.org; Mon, 24 Jan 2005 11:58:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7B0-0004fb-CP; Mon, 24 Jan 2005 11:34:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct73l-0000sG-Cy for mip4@megatron.ietf.org; Mon, 24 Jan 2005 11:27:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27359 for ; Mon, 24 Jan 2005 11:27:22 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7KH-0001zZ-BG for mip4@ietf.org; Mon, 24 Jan 2005 11:44:30 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j0OGQnUt009060; Mon, 24 Jan 2005 10:26:50 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j0OGQn208075; Mon, 24 Jan 2005 10:26:49 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IATXOL-000544-00; Mon, 24 Jan 2005 11:26:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16885.8644.146401.668240@gargle.gargle.HOWL> Date: Mon, 24 Jan 2005 10:26:44 -0600 From: Pete McCann To: Kent Leung Subject: Re: [Mip4] 3344bis clarification on identifying the FA's SA In-Reply-To: <4.3.2.7.2.20050120110108.02b3f568@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20050119151642.02b41798@mira-sjcm-2.cisco.com> <41B76050.8080709@levkowetz.com> <4.3.2.7.2.20050120110108.02b3f568@mira-sjcm-2.cisco.com> X-Mailer: VM 7.17 under 21.5 (beta14) "cassava" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Hi, all, Kent Leung writes: > Hi Henrik. > > At 01:33 AM 1/20/2005 +0100, Henrik Levkowetz wrote: > > > >I suspect that the reason this has not been raised before is that before > >we introduced NAT traversal into the equation, it was an unstated > >assumption that the source IP address and the CoA address would be the same. > > KL> > > Actually, RFC 2002/3344 states to use the egress interface's IP address as the > source IP address of the RRQ (sect. 3.7.2.2). When RFC 3519 was introduced, > the mandate for the addressed to be the same was added. Clearly, this only applies when using an FA-located CoA, right? For Co-located CoA (in an R-bit environment) the FA must relay the message with a different source IP address and CoA. > >Indeed, it is this assumption which is the base for detection of NATs in > >3519 - if src address and CoA address differ, then you say "Ah, this > >packet has gone through a NAT". > > KL> > > Yes. There has been contention on this matching address requirement. > Excerpt from "[issue44] RFC 3344 - Source Address of the RRQ & FHAE > issues" thread: > > >Keeping RFC3344 text as is presently enables a vendor/operator to use > >different IP addresses for the signaling control and the data forwarding > >plane which might be useful in a number of configurations and operational > >environments. In addition, removing the general assumption that the outgoing > >source IP address is associated with the outgoing interface (a fairly common > >IP configuration) and replacing it with a nailed up source address because of > >a bug in NAT Traversal, may well cause us future problems. > > There was general agreement to untie this link in 3519bis to allow the > source IP address to be the egress interface's for NAT Traversal case. > > > >So one way of clearing up the ambiguity could be the text you propose; > >another could be to clearly state that the FA sends the reply with the > >source address equal to the Care-of Address, typically through the > >interface having this address. > > KL> > > See above. I think we should not force this binding of addresses. > > > >There may be other ones too, and I'm not sure which is the best way to go > >here. > > > >One question which pops into my head, though, is why base this on the src > >address, in preference to the CoA? It would be interesting to hear your > >reasoning here. Which one we pick may impact a 3519bis (NAT traversal) > >document more or less... Just to amplify the choice quotes that Kent prints below: the source IP address is really all that you have to go on when registering a co-located CoA via the FA. I don't think we should be adding logic that checks the 'D' bit before deciding what to use as the index to the SA. For the NAT case, the right solution might be to program the SAs into the HA with the IP address of the NAT. This is sort of like logically extending the FA to include an extra interface which happens to be on another box. -Pete > KL> > > Good question. Just to point out it's not just me. > > >At 09:39 AM 12/15/2004 -0600, Pete McCann wrote: > >But the FA can be identified from its source IP address in the RRQ > >(absent NAT considerations). > > At 01:21 PM 12/17/2004 -0800, Charles E.Perkins wrote: > >Up until now, I have thought that the mobility security association > >was selected based on the source IP address of the IP packet, > >since it was a security association for a network-layer protocol. > > Since RFC was ambiguous on how exactly to identify > the FA, I came up with logic that works in all cases. However, > it became apparent during the discussion on deregistration of > previous CoA using FHAE that source IP address of packet > works while the CoA will not. > > Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 24 13:18:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08323 for ; Mon, 24 Jan 2005 13:18:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct93L-0006X0-F8 for mip4-web-archive@ietf.org; Mon, 24 Jan 2005 13:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8iY-0003N3-Ng; Mon, 24 Jan 2005 13:13:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8Wn-0000bJ-Pi for mip4@megatron.ietf.org; Mon, 24 Jan 2005 13:01:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06700 for ; Mon, 24 Jan 2005 13:01:26 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8nK-0005mV-M5 for mip4@ietf.org; Mon, 24 Jan 2005 13:18:36 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 24 Jan 2005 10:08:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0OI0mM8010964; Mon, 24 Jan 2005 10:00:50 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-176.cisco.com [128.107.163.176]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAX78645; Mon, 24 Jan 2005 10:00:49 -0800 (PST) Message-Id: <4.3.2.7.2.20050124095136.02d36a20@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jan 2005 10:00:49 -0800 To: Pete McCann From: Kent Leung Subject: Re: [Mip4] 3344bis clarification on identifying the FA's SA In-Reply-To: <16885.8644.146401.668240@gargle.gargle.HOWL> References: <4.3.2.7.2.20050120110108.02b3f568@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050119151642.02b41798@mira-sjcm-2.cisco.com> <41B76050.8080709@levkowetz.com> <4.3.2.7.2.20050120110108.02b3f568@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 At 10:26 AM 1/24/2005 -0600, Pete McCann wrote: >Hi, all, > >Kent Leung writes: > > Hi Henrik. > > > > At 01:33 AM 1/20/2005 +0100, Henrik Levkowetz wrote: > > > > > > >I suspect that the reason this has not been raised before is that before > > >we introduced NAT traversal into the equation, it was an unstated > > >assumption that the source IP address and the CoA address would be > the same. > > > > KL> > > > > Actually, RFC 2002/3344 states to use the egress interface's IP > address as the > > source IP address of the RRQ (sect. 3.7.2.2). When RFC 3519 was > introduced, > > the mandate for the addressed to be the same was added. > >Clearly, this only applies when using an FA-located CoA, right? >For Co-located CoA (in an R-bit environment) the FA must relay the >message with a different source IP address and CoA. Yes. The behavior of the R-bit is documented in Sect. 4.11 in RFC 3519. Kent -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 27 12:20:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01904 for ; Thu, 27 Jan 2005 12:20:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuDaf-0000vE-5U for mip4-web-archive@ietf.org; Thu, 27 Jan 2005 12:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDCB-00036o-A6; Thu, 27 Jan 2005 12:12:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu1zi-0005Kn-Iq for mip4@megatron.ietf.org; Thu, 27 Jan 2005 00:15:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02672 for ; Thu, 27 Jan 2005 00:14:58 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu2Gj-0007dq-KM for mip4@ietf.org; Thu, 27 Jan 2005 00:32:39 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAY00ANUMF8DB@szxga03-in.huawei.com> for mip4@ietf.org; Thu, 27 Jan 2005 13:11:33 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAY00LOEMF8B6@szxga03-in.huawei.com> for mip4@ietf.org; Thu, 27 Jan 2005 13:11:32 +0800 (CST) Received: from keshavaak ([10.18.4.181]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IAY00FC7MHF85@szxml02-in.huawei.com> for mip4@ietf.org; Thu, 27 Jan 2005 13:12:52 +0800 (CST) Date: Thu, 27 Jan 2005 10:41:13 +0530 From: keshav To: mip4@ietf.org Message-id: <000301c5042e$9fa89740$b504120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-Mailman-Approved-At: Thu, 27 Jan 2005 12:12:37 -0500 Cc: Keshav Subject: [Mip4] MIP4 : Accept De-Reg with out MB entry X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavak@huawei.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1288976381==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 This is a multi-part message in MIME format. --===============1288976381== Content-type: multipart/alternative; boundary="Boundary_(ID_gXtexWaTftZbFWrLO9sfPw)" This is a multi-part message in MIME format. --Boundary_(ID_gXtexWaTftZbFWrLO9sfPw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, HA should be allowed to accept the De-Registration request and send the De-Reg Reply with out having the Binding Entry for that Mobile node? Scenario: When MN returns to home network, by that time MB entry was expired and deleted in HA. Thanks & regards, Keshava --Boundary_(ID_gXtexWaTftZbFWrLO9sfPw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi,

        HA should   be allowed to accept the De-Registration request and send the De-Reg Reply  

        with out having the Binding Entry for that     Mobile node?

 

        Scenario:

 When MN returns to home network, by that time MB entry was expired and deleted in HA.

 

           

 

Thanks & regards,

Keshava

 

--Boundary_(ID_gXtexWaTftZbFWrLO9sfPw)-- --===============1288976381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1288976381==-- From mip4-bounces@ietf.org Thu Jan 27 13:47:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11566 for ; Thu, 27 Jan 2005 13:47:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuExB-0003LL-Jo for mip4-web-archive@ietf.org; Thu, 27 Jan 2005 14:05:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEeJ-0001Pg-Ot; Thu, 27 Jan 2005 13:45:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEVx-0007QB-RI for mip4@megatron.ietf.org; Thu, 27 Jan 2005 13:37:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09992 for ; Thu, 27 Jan 2005 13:37:06 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEn7-0002xj-Hz for mip4@ietf.org; Thu, 27 Jan 2005 13:54:54 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2005 10:44:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0RIaVM8011381; Thu, 27 Jan 2005 10:36:32 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-177-3.cisco.com [128.107.177.3]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BBA75695; Thu, 27 Jan 2005 10:36:30 -0800 (PST) Message-Id: <4.3.2.7.2.20050127103037.02cb3878@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jan 2005 10:36:30 -0800 To: keshavak@huawei.com From: Kent Leung Subject: Re: [Mip4] MIP4 : Accept De-Reg with out MB entry In-Reply-To: <000301c5042e$9fa89740$b504120a@in.huawei.com> Mime-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Keshav , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1348973786==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 --===============1348973786== Content-Type: multipart/alternative; boundary="=====================_2538810==_.ALT" --=====================_2538810==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Keshava. There's nowhere in RFC 3344 that prohibits HA from sending Deregistration Reply. As you pointed out, there are scenarions where MN should be acknowledged that it is no longer registered (by the absence of the mobility binding state) . Kent At 10:41 AM 1/27/2005 +0530, keshav wrote: >Hi, > > HA should be allowed to accept the De-Registration request and > send the De-Reg Reply > > with out having the Binding Entry for that Mobile node? > > > > Scenario: > > When MN returns to home network, by that time MB entry was expired and > deleted in HA. > > > > > > > >Thanks & regards, > >Keshava > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com --=====================_2538810==_.ALT Content-Type: text/html; charset="us-ascii" Hi Keshava.

There's nowhere in RFC 3344 that prohibits HA from sending Deregistration Reply.
As you pointed out, there are scenarions where MN should be acknowledged that
it is no longer registered (by the absence of the mobility binding state) .

Kent

At 10:41 AM 1/27/2005 +0530, keshav wrote:

Hi,

        HA should   be allowed to accept the De-Registration request and send the De-Reg Reply 

        with out having the Binding Entry for that     Mobile node?

 

        Scenario:

 When MN returns to home network, by that time MB entry was expired and deleted in HA.

 

           

 

Thanks & regards,

Keshava

 
--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

--
     |           |                   Kent Leung
    :|:         :|:                  IP Mobility Development
   :|||:       :|||:                 IOS Technologies Division
  :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
 c i s c o S y s t e m s             Email: kleung@cisco.com --=====================_2538810==_.ALT-- --===============1348973786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1348973786==-- From mip4-bounces@ietf.org Fri Jan 28 09:25:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03918 for ; Fri, 28 Jan 2005 09:25:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuXKu-0006CY-2e for mip4-web-archive@ietf.org; Fri, 28 Jan 2005 09:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuWrV-0002AW-5m; Fri, 28 Jan 2005 09:12:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuNad-0004bx-3j for mip4@megatron.ietf.org; Thu, 27 Jan 2005 23:18:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02575 for ; Thu, 27 Jan 2005 23:18:30 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuNrn-0000vM-LW for mip4@ietf.org; Thu, 27 Jan 2005 23:36:24 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB000MYCEK6RJ@szxga01-in.huawei.com> for mip4@ietf.org; Fri, 28 Jan 2005 12:16:54 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB000HMIEK69K@szxga01-in.huawei.com> for mip4@ietf.org; Fri, 28 Jan 2005 12:16:54 +0800 (CST) Received: from keshavaak ([10.18.4.181]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB0001J4EL0UG@szxml02-in.huawei.com> for mip4@ietf.org; Fri, 28 Jan 2005 12:17:25 +0800 (CST) Date: Fri, 28 Jan 2005 09:45:44 +0530 From: keshav To: mip4@ietf.org Message-id: <000001c504f0$0ab6a010$b504120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 2.0 (++) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 X-Mailman-Approved-At: Fri, 28 Jan 2005 09:12:35 -0500 Cc: vikasg@huawei.com, "'Keshav'" , "'Archana'" , HS_Arun@huawei.com Subject: [Mip4] new draft available for review X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavak@huawei.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0336277533==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 This is a multi-part message in MIME format. --===============0336277533== Content-type: multipart/alternative; boundary="Boundary_(ID_wd7HeCO6uPUunBdc2w5K2A)" This is a multi-part message in MIME format. --Boundary_(ID_wd7HeCO6uPUunBdc2w5K2A) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, A new Internet Draft is available at the following URL http://www.ietf.org/internet-drafts/draft-goel-mip4-encapext-00.txt This drafts talks about a new extension for use by Mobility Agents Operating Mobile IP for IPv4 .The new extension allows home Agent to specify the kind of encapsulation type it supports currently. Please give your comments about the draft. Regards, Keshava --Boundary_(ID_wd7HeCO6uPUunBdc2w5K2A) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi,

A new Internet Draft is available at the following URL

 

       http://www.ietf.org/internet-drafts/draft-goel-mip4-encapext-00.txt

 

       This drafts talks about a new extension for use by Mobility Agents  

Operating Mobile IP for IPv4 .The new extension allows home

Agent to specify the kind of encapsulation type it supports currently.

 

 

       Please give your comments about the draft.

 

Regards,

Keshava

 

--Boundary_(ID_wd7HeCO6uPUunBdc2w5K2A)-- --===============0336277533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0336277533==-- From mip4-bounces@ietf.org Mon Jan 31 01:38:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09308 for ; Mon, 31 Jan 2005 01:38:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvVU7-0002vS-Pu for mip4-web-archive@ietf.org; Mon, 31 Jan 2005 01:56:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvVBA-0000o8-Ge; Mon, 31 Jan 2005 01:36:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvV8s-0000QZ-2h; Mon, 31 Jan 2005 01:34:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09097; Mon, 31 Jan 2005 01:34:33 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvVQk-0002r2-KB; Mon, 31 Jan 2005 01:53:04 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Jan 2005 22:40:50 -0800 Received: from alpeshw2k03 (sjc-vpn5-36.cisco.com [10.21.88.36]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0V6XuNt025327; Sun, 30 Jan 2005 22:33:57 -0800 (PST) Message-Id: <200501310633.j0V6XuNt025327@sj-core-5.cisco.com> From: "Alpesh" To: , Subject: RE: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' toProposed Standard Date: Sun, 30 Jan 2005 22:33:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUCFS1yAWB8DC3DTkWk4ddCNvcb0gFST5oA X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <20050124125621.GB5599@yin.bjorns.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Bjorn - Thanks for the comments. Please see inline: > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of bjorn@iki.fi > Sent: Monday, January 24, 2005 4:56 AM > To: iesg@ietf.org > Cc: mip4@ietf.org > Subject: Re: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home=20 > Agent Assignment' toProposed Standard >=20 > Figures 2 and 3 and bullet 5 for the figures give the impression that > the second registraiton request bypasses the foreign agent. Surly > all requests must traverse the FA (if one is present), mustn't they? Agree on the above two points - it was an oversight. Definitely the RRQ traverses the FA. We will update the diagrams and the associated text to clarify this. Thanks for pointing it out. >=20 > Just as a note, a simpler and perhaps more backward=20 > compatible way to address=20 > one of the issues addressed in the draft is to use subnet directed > broadcast method described in RFC3344 but with a unicast address: > 1. The MN sends a RRQ to a unicast HA address > 2. If the HA that receives the RRQ wants to redirect the MN=20 > to another HA > it replies with the "unknown HA" failure code and sets the=20 > redirected HA > in the HA field of the RRP as specified in RFC3344. > 3. The MN registrers with the new HA. I understand your suggestion here. Unfortunately, we will like to use = the all zero/one address as an explicit indication for dynamic HA assignment. This is the explicit mechanism defined in the base spec and we are enhancing on it. Per RFC3344, I believe that the HA can reject the RRQ as you mention = even today with code 139 (not sure with the code value). Regards Alpesh >=20 > The unicast address used in step 1 may either be an address owned > by a single specific HA, or it may be a virtual HA cluster address > which is directed to an appropriate HA address in the home network > (with whatever means, e.g. ARP or routing tables). This way > one can achieve lightweight load balancing and high-availability while > providing backward compatiblity. We have a couple of years of good > real-world experiences using this method in our product. >=20 > This method is of course not as flexible as the one described in the > draft and does not address all issues. But it may perhaps be=20 > worthwhile > to consider the method I described in scenarios where it is sufficient > as it is (nearly) backwards compatible from the MN point-of-view > (provided it does not differient between broadcast addresses=20 > and unicast > addresses) and does not introduce new registration message extensions. >=20 > Bjorn Andersson >=20 >=20 > On Wed, Jan 12 2005, at 10:53:26 -0500, The IESG wrote: > > The IESG has received a request from the Mobility for IPv4=20 > WG to consider the=20 > > following document: > >=20 > > - 'Mobile IPv4 Dynamic Home Agent Assignment ' > > as a=20 > Proposed Standard > >=20 > > The IESG plans to make a decision in the next few weeks,=20 > and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-26. > >=20 > > The file can be obtained via > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-as > signment-03.txt > >=20 > >=20 > > --=20 > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ >=20 > --=20 > Bj=F6rn Andersson > PGP id 5AFC144B > Mobile +358 40 7723074 >=20 > --=20 > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 31 02:29:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27330 for ; Mon, 31 Jan 2005 02:29:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvWIM-0003rN-Ty for mip4-web-archive@ietf.org; Mon, 31 Jan 2005 02:48:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvVuZ-000240-OA; Mon, 31 Jan 2005 02:23:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvVtI-0001Ts-Fr; Mon, 31 Jan 2005 02:22:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26253; Mon, 31 Jan 2005 02:22:30 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvWB9-0003fw-Qr; Mon, 31 Jan 2005 02:41:02 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB6006XU73DD2@szxga02-in.huawei.com>; Mon, 31 Jan 2005 15:21:13 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB600BEJ73DS2@szxga02-in.huawei.com>; Mon, 31 Jan 2005 15:21:13 +0800 (CST) Received: from keshavaak ([10.18.4.181]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB600DD277PEW@szxml01-in.huawei.com>; Mon, 31 Jan 2005 15:23:51 +0800 (CST) Date: Mon, 31 Jan 2005 12:49:25 +0530 From: keshav Subject: RE: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard In-reply-to: To: "'IETF-Announce'" , iesg@ietf.org Message-id: <000001c50765$328a4160$b504120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7BIT Cc: vikasg@huawei.com, Keshav , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavak@huawei.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7BIT Hi, This drafts has mentioned that "The mechanism by which the network selects an HA for assignment to the MN is outside the scope of this document". Unless a standard mechanism is proposed, can this be implemented across different vendors? Regards, keshava -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, January 12, 2005 9:23 PM To: IETF-Announce Cc: mip4@ietf.org Subject: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard The IESG has received a request from the Mobility for IPv4 WG to consider the following document: - 'Mobile IPv4 Dynamic Home Agent Assignment ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-26. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-03.tx t -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 31 02:51:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28738 for ; Mon, 31 Jan 2005 02:51:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvWco-0004Gy-SH for mip4-web-archive@ietf.org; Mon, 31 Jan 2005 03:09:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvWIk-0008TI-Sh; Mon, 31 Jan 2005 02:48:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvWGT-00085H-Fg; Mon, 31 Jan 2005 02:46:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28509; Mon, 31 Jan 2005 02:46:28 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvWYL-0004BU-AI; Mon, 31 Jan 2005 03:04:59 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Jan 2005 23:52:47 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0V7jpNt020123; Sun, 30 Jan 2005 23:45:52 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn5-596.cisco.com [10.21.90.84]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BBD25348; Sun, 30 Jan 2005 23:45:33 -0800 (PST) Message-Id: <4.3.2.7.2.20050130233445.02ae6470@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 30 Jan 2005 23:45:31 -0800 To: keshavak@huawei.com From: Kent Leung Subject: RE: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard In-Reply-To: <000001c50765$328a4160$b504120a@in.huawei.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: vikasg@huawei.com, Keshav , mip4@ietf.org, iesg@ietf.org, "'IETF-Announce'" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Hi Keshava. The MN, FA, and HA that operates in accordance to the draft will be interoperable regardless of how the HA is assigned. The signaling between the mobility entities is specified in the draft, thus allowing HA to be dynamically assigned. Kent At 12:49 PM 1/31/2005 +0530, keshav wrote: >Hi, > This drafts has mentioned that >"The mechanism by which the network selects an HA for assignment to the MN >is outside the scope of this document". > >Unless a standard mechanism is proposed, can this be implemented across >different vendors? > > >Regards, >keshava > >-----Original Message----- >From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of The >IESG >Sent: Wednesday, January 12, 2005 9:23 PM >To: IETF-Announce >Cc: mip4@ietf.org >Subject: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to >Proposed Standard > >The IESG has received a request from the Mobility for IPv4 WG to consider >the >following document: > >- 'Mobile IPv4 Dynamic Home Agent Assignment ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-26. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-03.tx >t > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 31 06:02:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14304 for ; Mon, 31 Jan 2005 06:02:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvZcL-0008N1-2I for mip4-web-archive@ietf.org; Mon, 31 Jan 2005 06:21:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvZBx-00012X-GY; Mon, 31 Jan 2005 05:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvZ4O-000832-WA; Mon, 31 Jan 2005 05:46:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12584; Mon, 31 Jan 2005 05:46:08 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvZMG-0007rp-S7; Mon, 31 Jan 2005 06:04:43 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB6003LHFQVOU@szxga02-in.huawei.com>; Mon, 31 Jan 2005 18:28:07 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB600BBHFQV0A@szxga02-in.huawei.com>; Mon, 31 Jan 2005 18:28:07 +0800 (CST) Received: from keshavaak ([10.18.4.181]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB600GV0FQRCM@szxml02-in.huawei.com>; Mon, 31 Jan 2005 18:28:05 +0800 (CST) Date: Mon, 31 Jan 2005 15:56:18 +0530 From: keshav Subject: RE: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard In-reply-to: <4.3.2.7.2.20050130233445.02ae6470@mira-sjcm-2.cisco.com> To: "'Kent Leung'" Message-id: <000001c5077f$4e67e580$b504120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7BIT Cc: vikasg@huawei.com, "'Keshav'" , mip4@ietf.org, iesg@ietf.org, "'IETF-Announce'" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavak@huawei.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7BIT Hi Kent, If we want to achieve the Load balancing across different HA How to achieve this? Is there any dynamic mechanism where HA can learn other HA's capability before redirecting. Unless such capability negotiation across HA is standardized achieving True load balancing may not be practicable? (Of course administrator can configure this based on policy which is very cumbersome) Keshava -----Original Message----- From: Kent Leung [mailto:kleung@cisco.com] Sent: Monday, January 31, 2005 1:16 PM To: keshavak@huawei.com Cc: 'IETF-Announce'; iesg@ietf.org; vikasg@huawei.com; Keshav; mip4@ietf.org Subject: RE: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard Hi Keshava. The MN, FA, and HA that operates in accordance to the draft will be interoperable regardless of how the HA is assigned. The signaling between the mobility entities is specified in the draft, thus allowing HA to be dynamically assigned. Kent At 12:49 PM 1/31/2005 +0530, keshav wrote: >Hi, > This drafts has mentioned that >"The mechanism by which the network selects an HA for assignment to the MN >is outside the scope of this document". > >Unless a standard mechanism is proposed, can this be implemented across >different vendors? > > >Regards, >keshava > >-----Original Message----- >From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of The >IESG >Sent: Wednesday, January 12, 2005 9:23 PM >To: IETF-Announce >Cc: mip4@ietf.org >Subject: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to >Proposed Standard > >The IESG has received a request from the Mobility for IPv4 WG to consider >the >following document: > >- 'Mobile IPv4 Dynamic Home Agent Assignment ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-26. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-03.t x >t > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 31 12:06:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23890 for ; Mon, 31 Jan 2005 12:06:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvfI7-0000H8-6O for mip4-web-archive@ietf.org; Mon, 31 Jan 2005 12:24:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CveqJ-0000FA-8Z; Mon, 31 Jan 2005 11:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CveoI-00081S-F6; Mon, 31 Jan 2005 11:53:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22524; Mon, 31 Jan 2005 11:53:56 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvf6H-0008Nq-Ie; Mon, 31 Jan 2005 12:12:33 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 31 Jan 2005 08:53:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0VGrL1O023608; Mon, 31 Jan 2005 08:53:23 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-40.cisco.com [128.107.163.40]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BBD48966; Mon, 31 Jan 2005 08:53:20 -0800 (PST) Message-Id: <4.3.2.7.2.20050131073856.02706090@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 31 Jan 2005 07:51:24 -0800 To: keshavak@huawei.com From: Kent Leung Subject: RE: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard In-Reply-To: <000001c5077f$4e67e580$b504120a@in.huawei.com> References: <4.3.2.7.2.20050130233445.02ae6470@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: vikasg@huawei.com, "'Keshav'" , mip4@ietf.org, iesg@ietf.org, "'IETF-Announce'" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede There are numerous methods to support load balancing. Some of them are transparent to the assigned HA. That's why it's up to the implementers to come up with what works best for them. The draft ensures that dynamic HA assignment can be achieved, regardless what is used specifically for load balancing. Kent At 03:56 PM 1/31/2005 +0530, keshav wrote: >Hi Kent, > If we want to achieve the Load balancing across different HA > How to achieve this? Is there any dynamic mechanism where HA > > can learn other HA's capability before redirecting. > > Unless such capability negotiation across HA is standardized >achieving > True load balancing may not be practicable? > > (Of course administrator can configure this based on policy which is >very cumbersome) > > >Keshava > >-----Original Message----- >From: Kent Leung [mailto:kleung@cisco.com] >Sent: Monday, January 31, 2005 1:16 PM >To: keshavak@huawei.com >Cc: 'IETF-Announce'; iesg@ietf.org; vikasg@huawei.com; Keshav; mip4@ietf.org >Subject: RE: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' >to Proposed Standard > >Hi Keshava. The MN, FA, and HA that operates in accordance >to the draft will be interoperable regardless of how the HA is >assigned. The signaling between the mobility entities is >specified in the draft, thus allowing HA to be dynamically >assigned. > >Kent > >At 12:49 PM 1/31/2005 +0530, keshav wrote: > >Hi, > > This drafts has mentioned that > >"The mechanism by which the network selects an HA for assignment to the MN > >is outside the scope of this document". > > > >Unless a standard mechanism is proposed, can this be implemented across > >different vendors? > > > > > >Regards, > >keshava > > > >-----Original Message----- > >From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of The > >IESG > >Sent: Wednesday, January 12, 2005 9:23 PM > >To: IETF-Announce > >Cc: mip4@ietf.org > >Subject: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to > >Proposed Standard > > > >The IESG has received a request from the Mobility for IPv4 WG to consider > >the > >following document: > > > >- 'Mobile IPv4 Dynamic Home Agent Assignment ' > > as a Proposed Standard > > > >The IESG plans to make a decision in the next few weeks, and solicits > >final comments on this action. Please send any comments to the > >iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-26. > > > >The file can be obtained via > >http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-03.t >x > >t > > > > > >-- > >Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >Supplemental site: http://www.mip4.org/ > > > > > >-- > >Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >Supplemental site: http://www.mip4.org/ > >-- > | | Kent Leung > :|: :|: IP Mobility Development > :|||: :|||: IOS Technologies Division > :|||||||: :|||||||: Voice: 408.526.5030 >.:|||||||||:.:|||||||||:. Fax: 408.525.1653 > c i s c o S y s t e m s Email: kleung@cisco.com > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 31 12:48:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28904 for ; Mon, 31 Jan 2005 12:48:37 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvfxC-0001Xu-UY for mip4-web-archive@ietf.org; Mon, 31 Jan 2005 13:07:16 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CvffC-0006Vr-1Z for mip4-web-archive@ietf.org; Mon, 31 Jan 2005 12:48:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfVR-00022G-5k; Mon, 31 Jan 2005 12:38:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfOV-0000zZ-AM for mip4@megatron.ietf.org; Mon, 31 Jan 2005 12:31:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26679 for ; Mon, 31 Jan 2005 12:31:20 -0500 (EST) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvfgU-0000zP-KE for mip4@ietf.org; Mon, 31 Jan 2005 12:49:59 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j0VHUovE010673; Mon, 31 Jan 2005 11:30:50 -0600 (CST) Message-ID: <41FE6B4A.92A18684@alcatel.com> Date: Mon, 31 Jan 2005 11:30:50 -0600 From: Tim Ozugur X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds952.usa.alcatel.com id j0VHUovE010673 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Subject: [Mip4] CFP: Broadband Wireless Access Network on fixed network (BWAN 2005) - Extended Deadline X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable (Apologies if you are receiving this message more than once) ****** Submission Deadline is EXTENDED to March 15, 2005 ****** ------------------------------------------------------------------ CALL FOR PAPERS International Workshop on=20 Broadband Wireless Access Network on fixed network (BWAN 2005) (http://www.bwan.org/) ORLANDO, FL - JUNE 12, 2005 co-located with International Conference on Multimedia Services=20 Access Networks (MSAN '05: http://www.msan.org) CO_SPONSORED BY IEEE ****** EXTENDED SUBMISSION DEADLINE: March 15, 2005 ****** ------------------------------------------------------------------- Scope: Workshop: Broadband Wireless Access based on fixed Network=20 (xDSL, FTTx, etc ).=20 This Workshop will deal about complementary wireless broadband access network based on wired network (xDSL, FTTx, etc), 3G/4G and also about different techniques that can solved the tremendous challenges making the sharing of each phone line accessible through wireless access with a minimum guarantee of service for any connected user. In this workshop, the challenges to develop a new low cost mobile or semi-mobile access network with low powering unit will be explored and that may complement UMTS.=20 The workshop is intended to present new architectures of fixed network supporting mobility and/or nomadic features for wireless access (802.11, WiMax,=85802.20=85.), the sharing of the network access, bandwidth sharin= g on radio access. (Single Hop, mesh,=85) and discuss about the perspective= s of shared access network enhanced with wireless extension based on technologies such as WiFi,.. 802.16,.. 802.20, etc to maximize the performance of the overall link and reduce the costs. Within the framework of BWAN 2005, a new research field to prepare the next generation of network access.=20 Topics of interest to this workshop include (but are not limited to) performance studies and solutions (algorithms, protocols, architectures) that tend to improve experience of users of services and applications based on Internet.=20 Workshop Topics: - New Architectures and technologies for broadband wireless=20 access on fixed network(xDSL/FTTx,etc) with mobility features=20 - AAA (Authentification, Authorization, Accounting)=20 - Micro and macro mobility=20 - Medium access control (QoS, bandwidth sharing, fairness)=20 - End to end security and privacy issues on Mobile and/or nomadic=20 Access Network=20 - Low cost and low power integrated xDSL/FTTx+WiFi modem with=20 mobility enhancement=20 - Network cost performance and Business Models SLA-based services=20 - Radio extension such as 802.xy (WiFi, WiMax, etc) Relating Topics:=20 - Modulation, coding and antennas (MIMO)=20 - Interference mitigation for multiple access=20 - Complementary solutions to UMTS=20 - Location-Based Services Applications=20 - Scalability issues to large number of sites=20 - Standard and regulations=20 - IPv6 impact=20 - Mesh extensions =20 Publication:=20 The submissions to be presented at the workshop will be selected,=20 based on their originality, technical merit and topical relevance=20 of their contents. All accepted papers will be published in the=20 conference proceedings that will be available at the workshop.=20 Important Dates: - Submission Deadline: March 15, 2005=20 - Notification of acceptance: April 15, 2005=20 - Camera ready due: April 30, 2005=20 - Workshop date: June 12, 2005=20 Submission Guidelines: We encourage full papers that present well-developed research results (up to 4 pages double column, including figures and references), but also short papers that are more speculative in nature, works in progress and position papers are solicited.=20 Submitted papers must be unpublished and must not be currently under review for any other publication. If you are unsure whether your work falls within the scope of the conference, please contact the Program Co-Chairs.=20 All paper submissions will be carefully reviewed by experts. The authors of accepted papers must guarantee that their paper will be presented at the workshop. At least one author of each accepted paper must be registered for the workshop in order for that paper to appear in the proceedings and to be scheduled for presentation.=20 All submissions should be sent electronically in Postscript or Adobe PDF format. Detailed instructions about submissions are available at the submission page. The electronic submission is available at EDAS.=20 _____________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 31 13:05:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01179 for ; Mon, 31 Jan 2005 13:05:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvgDw-00028G-JS for mip4-web-archive@ietf.org; Mon, 31 Jan 2005 13:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvfqt-0006XT-HE; Mon, 31 Jan 2005 13:00:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvfjd-00044w-1M; Mon, 31 Jan 2005 12:53:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29532; Mon, 31 Jan 2005 12:53:10 -0500 (EST) From: sgoswami@umich.edu Received: from arapaho.web.itd.umich.edu ([141.211.144.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvg1c-0001h0-AQ; Mon, 31 Jan 2005 13:11:48 -0500 Received: (from www@localhost) by arapaho.web.itd.umich.edu (8.12.9/8.12.9) id j0VHrAeM003568; Mon, 31 Jan 2005 12:53:10 -0500 Received: from c-67-182-52-27.client.comcast.net (c-67-182-52-27.client.comcast.net [67.182.52.27]) by web.mail.umich.edu (IMP) with HTTP for ; Mon, 31 Jan 2005 12:53:10 -0500 Message-ID: <1107193990.41fe7086bd080@web.mail.umich.edu> Date: Mon, 31 Jan 2005 12:53:10 -0500 To: mip4@ietf.org, iesg@ietf.org Subject: RE: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard References: <4.3.2.7.2.20050130233445.02ae6470@mira-sjcm-2.cisco.com> <4.3.2.7.2.20050131073856.02706090@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20050131073856.02706090@mira-sjcm-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-IMP-Server: 141.211.144.104 X-Originating-IP: 67.182.52.27 X-Originating-User: sgoswami X-Spam-Score: 0.4 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 8bit X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 8bit Just as an aside, it is possible to collapse the HA and FA (i.e. in Fig 2, potentially the FA and HA can be the same entity). That would imply a certain amount of load balancing and also avoid the triangular routing for the first subnet. When the MN moves to another subnet then ofcourse the FA(HA)-old becomes the HA. Subrata Goswami, Ph.D. Quoting Kent Leung : > There are numerous methods to support load balancing. Some of > them are transparent to the assigned HA. That's why it's up to > the implementers to come up with what works best for them. The > draft ensures that dynamic HA assignment can be achieved, > regardless what is used specifically for load balancing. > > Kent > > At 03:56 PM 1/31/2005 +0530, keshav wrote: > >Hi Kent, > > If we want to achieve the Load balancing across different HA > > How to achieve this? Is there any dynamic mechanism where HA > > > > can learn other HA's capability before redirecting. > > > > Unless such capability negotiation across HA is standardized > >achieving > > True load balancing may not be practicable? > > > > (Of course administrator can configure this based on policy which > is > >very cumbersome) > > > > > >Keshava > > > >-----Original Message----- > >From: Kent Leung [mailto:kleung@cisco.com] > >Sent: Monday, January 31, 2005 1:16 PM > >To: keshavak@huawei.com > >Cc: 'IETF-Announce'; iesg@ietf.org; vikasg@huawei.com; Keshav; mip4@ietf.org > >Subject: RE: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' > >to Proposed Standard > > > >Hi Keshava. The MN, FA, and HA that operates in accordance > >to the draft will be interoperable regardless of how the HA is > >assigned. The signaling between the mobility entities is > >specified in the draft, thus allowing HA to be dynamically > >assigned. > > > >Kent > > > >At 12:49 PM 1/31/2005 +0530, keshav wrote: > > >Hi, > > > This drafts has mentioned that > > >"The mechanism by which the network selects an HA for assignment to the MN > > >is outside the scope of this document". > > > > > >Unless a standard mechanism is proposed, can this be implemented across > > >different vendors? > > > > > > > > >Regards, > > >keshava > > > > > >-----Original Message----- > > >From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of > The > > >IESG > > >Sent: Wednesday, January 12, 2005 9:23 PM > > >To: IETF-Announce > > >Cc: mip4@ietf.org > > >Subject: [Mip4] Last Call: 'Mobile IPv4 Dynamic Home Agent Assignment' to > > >Proposed Standard > > > > > >The IESG has received a request from the Mobility for IPv4 WG to consider > > >the > > >following document: > > > > > >- 'Mobile IPv4 Dynamic Home Agent Assignment ' > > > as a Proposed Standard > > > > > >The IESG plans to make a decision in the next few weeks, and solicits > > >final comments on this action. Please send any comments to the > > >iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-26. > > > > > >The file can be obtained via > > > >http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-03.t > >x > > >t > > > > > > > > >-- > > >Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > >Supplemental site: http://www.mip4.org/ > > > > > > > > >-- > > >Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > >Supplemental site: http://www.mip4.org/ > > > >-- > > | | Kent Leung > > :|: :|: IP Mobility Development > > :|||: :|||: IOS Technologies Division > > :|||||||: :|||||||: Voice: 408.526.5030 > >.:|||||||||:.:|||||||||:. Fax: 408.525.1653 > > c i s c o S y s t e m s Email: kleung@cisco.com > > > > > >-- > >Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >Supplemental site: http://www.mip4.org/ > > -- > | | Kent Leung > :|: :|: IP Mobility Development > :|||: :|||: IOS Technologies Division > :|||||||: :|||||||: Voice: 408.526.5030 > .:|||||||||:.:|||||||||:. Fax: 408.525.1653 > c i s c o S y s t e m s Email: kleung@cisco.com > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > > > Subrata Goswami, Ph.D. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/