From exim@www1.ietf.org Wed May 5 18:43:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16841 for ; Wed, 5 May 2004 18:43:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLV0S-0006id-N5 for mip4-archive@odin.ietf.org; Wed, 05 May 2004 18:36:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45MamG4025827 for mip4-archive@odin.ietf.org; Wed, 5 May 2004 18:36:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUvq-0005Ez-Q3 for mip4-web-archive@optimus.ietf.org; Wed, 05 May 2004 18:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16463 for ; Wed, 5 May 2004 18:31:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLUvn-0003yJ-Qr for mip4-web-archive@ietf.org; Wed, 05 May 2004 18:31:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLUur-0003fG-00 for mip4-web-archive@ietf.org; Wed, 05 May 2004 18:31:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLUtz-0003M5-00 for mip4-web-archive@ietf.org; Wed, 05 May 2004 18:30:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUn7-0001gI-Bw; Wed, 05 May 2004 18:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLSU7-0000Js-4W for mip4@optimus.ietf.org; Wed, 05 May 2004 15:55:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08371 for ; Wed, 5 May 2004 15:55:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLSU5-0004v0-By for mip4@ietf.org; Wed, 05 May 2004 15:55:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLST3-0004b5-00 for mip4@ietf.org; Wed, 05 May 2004 15:54:09 -0400 Received: from cs-lists.cs.colorado.edu ([128.138.243.152]) by ietf-mx with esmtp (Exim 4.12) id 1BLSSI-0004HG-00; Wed, 05 May 2004 15:53:23 -0400 Received: from cs-lists.cs.colorado.edu (localhost.cs.colorado.edu [127.0.0.1]) by cs-lists.cs.colorado.edu (8.12.10/8.12.6) with ESMTP id i45Jk1bc049068; Wed, 5 May 2004 13:48:19 -0600 (MDT) Received: from mroe.cs.colorado.edu (mroe.cs.colorado.edu [128.138.243.151]) by cs-lists.cs.colorado.edu (8.12.10/8.12.6) with ESMTP id i45Jhuba049055 for ; Wed, 5 May 2004 13:43:56 -0600 (MDT) Received: from research.cs.colorado.edu (research.cs.colorado.edu [128.138.242.225]) by mroe.cs.colorado.edu (8.12.10/8.12.6) with ESMTP id i45JhumU052404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 May 2004 13:43:56 -0600 (MDT) Received: from earthrise2 (admin-net-dhcp8.cs.colorado.edu [128.138.236.58]) by research.cs.colorado.edu (8.12.10/8.12.6) with ESMTP id i45JhlBP014506 for ; Wed, 5 May 2004 13:43:56 -0600 (MDT) To: Date: Wed, 5 May 2004 13:43:43 -0600 Organization: University of Colorado Message-ID: <001c01c432d9$4c0514f0$b46dfea9@cs.colorado.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by cs-lists.cs.colorado.edu id i45Jhuba049055 X-Mailman-Approved-At: Wed, 05 May 2004 13:45:58 -0600 From: basenets04-cfp@cs-lists.cs.colorado.edu X-BeenThere: basenets04-cfp@cs-lists.cs.colorado.edu X-Mailman-Version: 2.1.4 Precedence: list Content-Transfer-Encoding: 8bit Subject: [Mip4] BASENETS 2004, Call For Papers, New June 21 Submission Deadline Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=FROM_AND_TO_SAME,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- CALL FOR PAPERS ******************************************************** * * * 1st Workshop on Broadband Advanced Sensor Networks * * (co-located with BroadNets 04) * * San Jose, CA, October 25, 2004 * * * * BASENETS 04 * * * ******************************************************** * * * http://www.basenets.org * * * ******************************************************** SCOPE The emergence and adoption of broadband wireless access standards, such as 802.16, 802.16a and 802.11a/g, offers exciting new possibilities for high-bandwidth data communication over the "last mile". A significant use of such high bandwidth may lie in the use of a variety of multimodal sensors for monitoring and control of diverse geographic areas. Such sensors may be used for remote video/audio surveillance and active monitoring of telemetry data in city blocks, highways, airports, hotels, campuses and a variety of other indoor and outdoor environments. This workshop is intended for the presentation and discussion of novel architectures, algorithms and applications of sensor networks based on the use of wireless broadband channels. Areas of interest include problems related to energy efficiency, dynamic control and reliability of such sensor network deployments, especially under the expected resource constraints on the sensor devices. Of particular interest are visions, practical case studies, demonstrations or pilots of innovative techniques for building sensor networks using either broadband local or metropolitan wireless networks. Topics of interest include, but are not limited to: * Multimedia Interfaces for Wireless Sensors * Broadband vs. Narrowband Wireless Sensing * Video and Audio Sensing Applications over Broadband Networks * Distributed Multimedia Compression/Aggregation for Broadband Sensor Networks * Scalability and Performance Bottlenecks for Wide-Area Broadband Sensing * Adaptive Configuration of Broadband Sensor Networks * Power and Spectrum Management Issues for Broadband Sensing * Architectures for Broadband Sensor Networks * Applications of Wireless Broadband Sensor Networks * Security and Privacy for Broadband Sensor Networks * Broadband Sensor Networks with Mobile Nodes * Heterogeneous Wired-Wireless Broadband Sensor Networks SUBMISSION Papers should be written in English, should not exceed 20 double-spaced, single-column pages, including figures and references, and should include an abstract, not to exceed 250 words. Papers should be submitted in PDF format via the EDAS system (http://edas.info). All papers will be peer reviewed. The best papers of this workshop will be considered for possible publication in the ACM Transactions on Sensor Networks (http://www.acm.org/tosn/). IMPORTANT DATES Full paper due: June 21, 2004 *EXTENDED* Notification of acceptance: July 18, 2004 Camera-ready copy: Aug. 9, 2004 Workshop Chairs: W. Heinzelman (U. of Rochester) B. Krishnamachari (U. of Southern California) Program Committee: N. Abu-Ghazaleh (Binghamton U.) J. Apostolopoulos (HP Labs) A. Bestavros (Boston U.) A. Campbell (Columbia U.) M. El Zarki (U. of California at Irvine) W.-C. Feng (OGI) S. Gupta (Arizona State U.) R. Han (U. of Colorado at Boulder) A. Helmy (U. of Southern California) S. Jha (U. of New South Wales) H. Karl (TU Berlin) M. Liu (U. of Michigan) B. Nath (Rutgers U.) M. Papadopouli (U. of North Carolina) A. Safwat (Queens U.) I. Stojmenovic (U. of Ottawa) U. Tureli (Stevens U.) M. van der Schaar (U. of California at Davis) P. Varshney (Syracuse U.) Publicity Co-Chairs: R. Han (U. of Colorado at Boulder) H. Karl (Technical University Berlin) For more details, please visit http://www.basenets.org or contact basenets04-chairs@ece.rochester.edu _______________________________________________ basenets04-cfp mailing list basenets04-cfp@cs-lists.cs.colorado.edu http://cs-lists.cs.colorado.edu/mailman/listinfo/basenets04-cfp -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 7 20:06:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29557 for ; Fri, 7 May 2004 20:06:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMFGc-0005kF-Be for mip4-archive@odin.ietf.org; Fri, 07 May 2004 20:00:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4800Yf4022067 for mip4-archive@odin.ietf.org; Fri, 7 May 2004 20:00:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMFEN-0004yG-Lw for mip4-web-archive@optimus.ietf.org; Fri, 07 May 2004 19:58:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29301 for ; Fri, 7 May 2004 19:58:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMFEL-0006VT-Q3 for mip4-web-archive@ietf.org; Fri, 07 May 2004 19:58:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMFDO-00065V-00 for mip4-web-archive@ietf.org; Fri, 07 May 2004 19:57:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMFCk-0005fs-00 for mip4-web-archive@ietf.org; Fri, 07 May 2004 19:56:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMF8L-0003Qz-8O; Fri, 07 May 2004 19:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMF4p-0002Oh-6T for mip4@optimus.ietf.org; Fri, 07 May 2004 19:48:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28996 for ; Fri, 7 May 2004 19:48:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMF4n-0002HV-Bb for mip4@ietf.org; Fri, 07 May 2004 19:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMF3f-0001qr-00 for mip4@ietf.org; Fri, 07 May 2004 19:47:12 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1BMF2f-00011W-00 for mip4@ietf.org; Fri, 07 May 2004 19:46:09 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i47NjdFq015620 for ; Fri, 7 May 2004 18:45:39 -0500 (CDT) Message-ID: <409C20CF.AD33D421@alcatel.com> Date: Fri, 07 May 2004 18:50:39 -0500 From: Tim Ozugur X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mip4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] BroadNets 2004: Call for "Work-in-Progress" Poster Papers Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Apologies if you are receiving this message more than once) ------------------------------------------------------------ Call for "Work-in-Progress" Poster Papers BroadNets 2004 - Wireless Networking Symposium October 25 - 29, 2004, San Jose, California, USA http://www.broadnets.org BroadNets 2004, the first international conference on broadband networks will be held during October 25-29 in the heart of Silicon Valley -- San Jose, CA. Technical paper submission is now closed. To allow the presentation of recent results and/or research work in progress, BroadNets 2004 Wireless Networking Symposium solicits poster papers demonstrating state-of-the-art research in broadly defined wireless networking area. Poster papers, not previously published, should be a maximum of 3 pages in length (in double column, 10 point font) and will be published in thenbconference proceedings by IEEE Computer Society. Poster submissions will be reviewed. Important dates: - Deadline for submitting a work-in-progress poster paper: June 1, 2004. - Notification of acceptance: June 15, 2004. - Final manuscript due: July 7, 2004. Authors are invited to submit poster papers directly to TPC co-chairs, Dr.Parmesh Ramanathan (parmesh@ece.wisc.edu) and Dr. Thomas Hou (thou@vt.edu). All submissions should be in Postscript or Adobe PDF format. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 10 14:34:39 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22693 for ; Mon, 10 May 2004 14:34:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFTk-0005MB-Vq for mip4-archive@odin.ietf.org; Mon, 10 May 2004 14:26:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AIQGXW020592 for mip4-archive@odin.ietf.org; Mon, 10 May 2004 14:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFOg-0004G5-Hl for mip4-web-archive@optimus.ietf.org; Mon, 10 May 2004 14:21:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21739 for ; Mon, 10 May 2004 14:20:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNFOe-0001Tf-6i for mip4-web-archive@ietf.org; Mon, 10 May 2004 14:21:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFNs-00019E-00 for mip4-web-archive@ietf.org; Mon, 10 May 2004 14:20:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNFMv-0000nH-00 for mip4-web-archive@ietf.org; Mon, 10 May 2004 14:19:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFLn-0003ob-Nj; Mon, 10 May 2004 14:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFG2-0002Kj-23 for mip4@optimus.ietf.org; Mon, 10 May 2004 14:12:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20924 for ; Mon, 10 May 2004 14:12:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNFFz-0005kM-LF for mip4@ietf.org; Mon, 10 May 2004 14:12:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFE2-0005Ga-00 for mip4@ietf.org; Mon, 10 May 2004 14:10:02 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BNFD0-0004aN-00 for mip4@ietf.org; Mon, 10 May 2004 14:08:58 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4AI8Rw32118 for ; Mon, 10 May 2004 11:08:27 -0700 X-mProtect: <200405101808> 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 smtpdeyxbX9; Mon, 10 May 2004 11:08:24 PDT Message-ID: <409FC50E.301F4CEE@iprg.nokia.com> Date: Mon, 10 May 2004 11:08:14 -0700 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: Mobile IPv4 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] New revision for rfc3344bis document Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, I have created a new revision of the rfc3344bis document, and I would like to submit it soon to the Internet Drafts directories unless there is a good reason for holding it. The outstanding issues have been resolved except for possibly issue #45, but even so it is useful to have a new revision submitted for consideration. In this e-mail, I will describe the current changes which have been made to the specification in a proposed attempt to resolve issue #45. If more text is needed, another document revision will be created, hopefully before the meeting in San Diego. In order to prevent a rogue foreign-agent from denying a mobile node's deregistration by simply attaching a bad Foreign-Home authentication extension, the home agent is now mandated to ignore such extensions when applied to a deregistration message (i.e., zero lifetime). For this a new paragraph has been added to section 3.8.2.2: A deregistration which is passed through a foreign agent which is different from the the one whose care-of address is being deregistered MAY add a Foreign-Home Authentication Extension to such a deregistration. However, as this deregistration concerns a different foreign agent than the one whose authentication extension, the home agent MUST disregard the Foreign-Home Authentication Extension of such a deregistration. The remaining validity checks, as described in Section 3.8.2.1, are required in full. This requires a change to section 3.8.2.1, bullet item (c), first sentence to now read: c) If the home agent shares a mobility security association with the foreign agent, and this is a registration request (has non-zero lifetime), the home agent MUST check for the presence of a valid Foreign-Home Authentication Extension. In section 3.7.2.1, first sentence, clarification about when code 77 is valid: Requests with the 'D' bit set to 0, nonzero lifetime, and specifying a care-of address not offered by the foreign agent, MUST be rejected with code 77 (invalid care-of address). Thanks to Henrik for fashioning the above text replacements and additions. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 10 18:43:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13533 for ; Mon, 10 May 2004 18:43:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJPU-0006LT-Py for mip4-archive@odin.ietf.org; Mon, 10 May 2004 18:38:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AMc8ks024384 for mip4-archive@odin.ietf.org; Mon, 10 May 2004 18:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJB9-0002wH-IH for mip4-web-archive@optimus.ietf.org; Mon, 10 May 2004 18:23:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12107 for ; Mon, 10 May 2004 18:23:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNJB6-0001yF-OW for mip4-web-archive@ietf.org; Mon, 10 May 2004 18:23:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNJA7-0001ck-00 for mip4-web-archive@ietf.org; Mon, 10 May 2004 18:22:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNJ97-0001IM-00 for mip4-web-archive@ietf.org; Mon, 10 May 2004 18:21:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIwO-0003Jg-1F; Mon, 10 May 2004 18:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIk0-0005ro-Aw for mip4@optimus.ietf.org; Mon, 10 May 2004 17:55:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09010 for ; Mon, 10 May 2004 17:55:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNIjx-0007ai-O7 for mip4@ietf.org; Mon, 10 May 2004 17:55:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIj8-0007GU-00 for mip4@ietf.org; Mon, 10 May 2004 17:54:23 -0400 Received: from av1-1-sn3.vrr.skanova.net ([81.228.9.105]) by ietf-mx with esmtp (Exim 4.12) id 1BNIig-0006uv-00 for mip4@ietf.org; Mon, 10 May 2004 17:53:54 -0400 Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id DB7EA37EFC; Mon, 10 May 2004 23:53:23 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id CCB2A37E52; Mon, 10 May 2004 23:53:23 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 05B6B3800B; Mon, 10 May 2004 23:53:23 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BNIi9-0000vD-00; Mon, 10 May 2004 23:53:21 +0200 Date: Mon, 10 May 2004 23:53:21 +0200 From: Henrik Levkowetz To: "Charles E.Perkins" Cc: Mobile IPv4 Mailing List Subject: Re: [Mip4] New revision for rfc3344bis document Message-Id: <20040510235321.11c8f1ee.henrik@levkowetz.com> In-Reply-To: <409FC50E.301F4CEE@iprg.nokia.com> References: <409FC50E.301F4CEE@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Charlie, Thanks for creating a new revision of rfc3344bis. One correction: Monday 10 May 2004, Charles E.Perkins wrote: > > For this a new paragraph has been added to section 3.8.2.2: > > A deregistration which is passed through a foreign agent which is > different from the the one whose care-of address is being > deregistered MAY add a Foreign-Home Authentication Extension to such > a deregistration. However, as this deregistration concerns a > different foreign agent than the one whose authentication extension, > the home agent MUST disregard the Foreign-Home Authentication > Extension of such a deregistration. The remaining validity checks, > as described in Section 3.8.2.1, are required in full. I think that had better be: s/whose authentication extension,/whose authentication extension is added,/ This blunder was in the text I sent you, and not due to any editing miss on your part. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Wed May 12 12:06:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21791 for ; Wed, 12 May 2004 12:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvYc-0007uf-MH for mip4-archive@odin.ietf.org; Wed, 12 May 2004 11:22:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CFM68Q030415 for mip4-archive@odin.ietf.org; Wed, 12 May 2004 11:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvLS-0000rl-08 for mip4-web-archive@optimus.ietf.org; Wed, 12 May 2004 11:08:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14702 for ; Wed, 12 May 2004 11:08:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNvLN-0005or-67 for mip4-web-archive@ietf.org; Wed, 12 May 2004 11:08:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNvI2-0004kd-00 for mip4-web-archive@ietf.org; Wed, 12 May 2004 11:04:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNvDp-0003IL-00 for mip4-web-archive@ietf.org; Wed, 12 May 2004 11:00:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNuFG-0002N7-3d; Wed, 12 May 2004 09:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtzB-0004Xl-SR for mip4@optimus.ietf.org; Wed, 12 May 2004 09:41:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02619; Wed, 12 May 2004 09:41:23 -0400 (EDT) Message-Id: <200405121341.JAA02619@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mip4@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 12 May 2004 09:41:23 -0400 Subject: [Mip4] I-D ACTION:draft-ietf-mip4-aaa-key-05.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : AAA Registration Keys for Mobile IPv4 Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mip4-aaa-key-05.txt Pages : 30 Date : 2004-5-11 AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-aaa-key-05.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-aaa-key-05.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-aaa-key-05.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: <2004-5-12094214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-aaa-key-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-aaa-key-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-12094214.I-D@ietf.org> --OtherAccess-- --NextPart-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Wed May 12 13:05:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26878 for ; Wed, 12 May 2004 13:05:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNx1q-0008Bn-Bz for mip4-archive@odin.ietf.org; Wed, 12 May 2004 12:56:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CGuMaB031480 for mip4-archive@odin.ietf.org; Wed, 12 May 2004 12:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwp3-0004Td-RI for mip4-web-archive@optimus.ietf.org; Wed, 12 May 2004 12:43:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25432 for ; Wed, 12 May 2004 12:43:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNwp2-00031b-9M for mip4-web-archive@ietf.org; Wed, 12 May 2004 12:43:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwo9-0002TP-00 for mip4-web-archive@ietf.org; Wed, 12 May 2004 12:42:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNwn3-0001uH-00 for mip4-web-archive@ietf.org; Wed, 12 May 2004 12:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwbq-0007HT-2N; Wed, 12 May 2004 12:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwFr-0003QW-AK for mip4@optimus.ietf.org; Wed, 12 May 2004 12:06:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21840 for ; Wed, 12 May 2004 12:06:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNwFq-0001Uv-1h for mip4@ietf.org; Wed, 12 May 2004 12:06:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwEy-0000wn-00 for mip4@ietf.org; Wed, 12 May 2004 12:05:53 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BNwDk-0007bt-00 for mip4@ietf.org; Wed, 12 May 2004 12:04:36 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CG41B10111 for ; Wed, 12 May 2004 11:04:01 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i4CG3xr07240; Wed, 12 May 2004 11:03:59 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HXLZAI-00010G-00 for mip4@ietf.org; Wed, 12 May 2004 12:03:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16546.19178.447241.874644@gargle.gargle.HOWL> Date: Wed, 12 May 2004 11:03:54 -0500 From: Pete McCann To: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-aaa-key-05.txt In-Reply-To: <200405121341.JAA02619@ietf.org> References: <200405121341.JAA02619@ietf.org> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just to keep everyone up to date: this is a new rev of aaa-key, which addresses some recent IESG DISCUSS comments. It cleans up the description of how the AAAH identifies the mobile node to remove ambiguity in the key generation algorithm. -Pete Internet-Drafts@ietf.org writes: > 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 : AAA Registration Keys for Mobile IPv4 > Author(s) : C. Perkins, P. Calhoun > Filename : draft-ietf-mip4-aaa-key-05.txt > Pages : 30 > Date : 2004-5-11 > > AAA servers, such as RADIUS and DIAMETER, are in use within > the Internet today to provide authentication and authorization > services for dial-up computers. Mobile IP for IPv4 requires strong > authentication between the mobile node and its home agent. When the > mobile node shares an AAA Security Association with its home AAA > server, however, it is possible to use that AAA Security Association > to create derived Mobility Security Associations between the mobile > node and its home agent, and again between the mobile node and the > foreign agent currently offering connectivity to the mobile node. > This document specifies extensions to Mobile IP registration messages > that can be used to create Mobility Security Associations between the > mobile node and its home agent, and/or between the mobile node and a > foreign agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-aaa-key-05.txt -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Wed May 12 18:41:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16554 for ; Wed, 12 May 2004 18:41:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO2Nk-0005sk-M5 for mip4-archive@odin.ietf.org; Wed, 12 May 2004 18:39:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CMdKkQ022610 for mip4-archive@odin.ietf.org; Wed, 12 May 2004 18:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO29i-0002tK-7T for mip4-web-archive@optimus.ietf.org; Wed, 12 May 2004 18:24:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15946 for ; Wed, 12 May 2004 18:24:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO29f-0006Pd-BH for mip4-web-archive@ietf.org; Wed, 12 May 2004 18:24:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO28g-0005tV-00 for mip4-web-archive@ietf.org; Wed, 12 May 2004 18:23:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO27e-0005KB-00 for mip4-web-archive@ietf.org; Wed, 12 May 2004 18:22:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO21C-0008Kr-9Q; Wed, 12 May 2004 18:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO201-0007f4-Ag for mip4@optimus.ietf.org; Wed, 12 May 2004 18:14:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15240 for ; Wed, 12 May 2004 18:14:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO1zy-0001JA-AM for mip4@ietf.org; Wed, 12 May 2004 18:14:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO1z0-0000oo-00 for mip4@ietf.org; Wed, 12 May 2004 18:13:46 -0400 Received: from av3-1-sn1.fre.skanova.net ([81.228.11.109]) by ietf-mx with esmtp (Exim 4.12) id 1BO1yH-0007hI-00 for mip4@ietf.org; Wed, 12 May 2004 18:13:01 -0400 Received: by av3-1-sn1.fre.skanova.net (Postfix, from userid 502) id 8701737FE0; Thu, 13 May 2004 00:12:30 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av3-1-sn1.fre.skanova.net (Postfix) with ESMTP id 79F4537E52; Thu, 13 May 2004 00:12:30 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id E40B337E45; Thu, 13 May 2004 00:12:29 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BO1xj-0002P6-00; Thu, 13 May 2004 00:12:27 +0200 Date: Thu, 13 May 2004 00:12:27 +0200 From: Henrik Levkowetz To: mip4@ietf.org Cc: Pete McCann Message-Id: <20040513001227.018482df.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Call for Agenda Items for IETF 60 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, To get a timeslot for IETF 60, we will need to submit an agenda. So consider this a call for agend items. Please send mail to myself and/or Pete, letting us know: a. The draft name you'd like to present. b. Whether it's a charter item (charter items get priority) c. How much time you need. Thanks in advance, Henrik & Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 14 03:49:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04323 for ; Fri, 14 May 2004 03:49:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXQg-0003Lt-IS for mip4-archive@odin.ietf.org; Fri, 14 May 2004 03:48:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E7mQv5012886 for mip4-archive@odin.ietf.org; Fri, 14 May 2004 03:48:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXLO-0002Ss-Vp for mip4-web-archive@optimus.ietf.org; Fri, 14 May 2004 03:42:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04044 for ; Fri, 14 May 2004 03:42:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXLM-0000Y7-IQ for mip4-web-archive@ietf.org; Fri, 14 May 2004 03:42:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXKZ-00000D-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 03:42:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOXJX-0007GL-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 03:41:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXFf-0000vc-0u; Fri, 14 May 2004 03:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXAX-0008Fz-BN for mip4@optimus.ietf.org; Fri, 14 May 2004 03:31:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03348 for ; Fri, 14 May 2004 03:31:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXAU-000255-Rv for mip4@ietf.org; Fri, 14 May 2004 03:31:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOX9Y-0001ZT-00 for mip4@ietf.org; Fri, 14 May 2004 03:30:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BOX8n-0000bU-00 for mip4@ietf.org; Fri, 14 May 2004 03:29:57 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 14 May 2004 00:28:21 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4E7TQW9015200; Fri, 14 May 2004 00:29:26 -0700 (PDT) Received: from cisco.com (stealth-10-32-246-212.cisco.com [10.32.246.212]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with SMTP id AOY19030; Fri, 14 May 2004 00:29:25 -0700 (PDT) Message-ID: <40A47571.CBF7A716@cisco.com> Date: Fri, 14 May 2004 00:29:53 -0700 From: Sri Gundavelli X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] New revision for rfc3344bis document References: <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Charlie, Since we all agreed to use explicit FA Identity extension in the Registration Requests from the foreign agent to the home agent for notifying the the care-of address, we should probably remove the MUST clause from the following text and allow provision for using the Identity extension as a means to validate the FHAE. Thanks ! Sri. > home agent MUST disregard the Foreign-Home Authentication > > Thanks for creating a new revision of rfc3344bis. > > One correction: > > Monday 10 May 2004, Charles E.Perkins wrote: > > > > For this a new paragraph has been added to section 3.8.2.2: > > > > A deregistration which is passed through a foreign agent which is > > different from the the one whose care-of address is being > > deregistered MAY add a Foreign-Home Authentication Extension to such > > a deregistration. However, as this deregistration concerns a > > different foreign agent than the one whose authentication extension, > > the home agent MUST disregard the Foreign-Home Authentication > > Extension of such a deregistration. The remaining validity checks, > > as described in Section 3.8.2.1, are required in full. > > I think that had better be: > s/whose authentication extension,/whose authentication extension is added,/ > > This blunder was in the text I sent you, and not due to any editing miss > on your part. > > Henrik > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.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://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 14 04:21:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06218 for ; Fri, 14 May 2004 04:21:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXoR-0000jB-Cp for mip4-archive@odin.ietf.org; Fri, 14 May 2004 04:12:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E8Cx5p002798 for mip4-archive@odin.ietf.org; Fri, 14 May 2004 04:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXmR-00008f-JJ for mip4-web-archive@optimus.ietf.org; Fri, 14 May 2004 04:10:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05804 for ; Fri, 14 May 2004 04:10:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXmP-000015-22 for mip4-web-archive@ietf.org; Fri, 14 May 2004 04:10:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXlN-0007Iz-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 04:09:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOXkT-0006mB-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 04:08:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXg2-0006oQ-M3; Fri, 14 May 2004 04:04:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXaw-0005XZ-8K for mip4@optimus.ietf.org; Fri, 14 May 2004 03:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05245 for ; Fri, 14 May 2004 03:58:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXat-0001Ua-LV for mip4@ietf.org; Fri, 14 May 2004 03:58:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXZt-0000yf-00 for mip4@ietf.org; Fri, 14 May 2004 03:57:57 -0400 Received: from av1-2-sn4.m-sp.skanova.net ([81.228.10.115]) by ietf-mx with esmtp (Exim 4.12) id 1BOXZB-0000QX-00 for mip4@ietf.org; Fri, 14 May 2004 03:57:13 -0400 Received: by av1-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 4775337E58; Fri, 14 May 2004 09:56:44 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av1-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 3661937E45; Fri, 14 May 2004 09:56:44 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 3502837E5E; Fri, 14 May 2004 09:56:43 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BOXYg-0000Yn-00; Fri, 14 May 2004 09:56:42 +0200 Date: Fri, 14 May 2004 09:56:41 +0200 From: Henrik Levkowetz To: Sri Gundavelli Cc: "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040514095641.2e2d5194.henrik@levkowetz.com> In-Reply-To: <40A47571.CBF7A716@cisco.com> References: <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Sri, I'm adding [Issue 45] to the subject line to have this picked up by the Issue tracker and archived for this issue. More inline: Friday 14 May 2004, Sri Gundavelli wrote: > Hi Charlie, > Since we all agreed to use explicit FA Identity extension in the > Registration Requests from the foreign agent to the home agent for notifying the the > care-of address, we should probably remove the MUST clause from the following text and > allow provision for using the Identity extension as a means to validate the FHAE. I believe that if you go over the entries in the issue tracker for issue 45, you'll find that it's far from clearcut that we have consensus on a resolution; so you'r statement "we all agreed to use explicit FA Identity extension" above doesn't quite hold up. More below. .... > > Thanks for creating a new revision of rfc3344bis. > > > > One correction: > > > > Monday 10 May 2004, Charles E.Perkins wrote: > > > > > > For this a new paragraph has been added to section 3.8.2.2: > > > > > > A deregistration which is passed through a foreign agent which is > > > different from the the one whose care-of address is being > > > deregistered MAY add a Foreign-Home Authentication Extension to such > > > a deregistration. However, as this deregistration concerns a > > > different foreign agent than the one whose authentication extension, > > > the home agent MUST disregard the Foreign-Home Authentication > > > Extension of such a deregistration. The remaining validity checks, > > > as described in Section 3.8.2.1, are required in full. > > > > I think that had better be: > > s/whose authentication extension,/whose authentication extension is added,/ ... If you find the above proposal unsatisfactory, it would be good if you could propose some alternative text. But I think it would be good to keep in mind that: 1. The proposal above works also in the case of an old unmodified FA. 2. Adding dependency on a new draft may in the best case delay 3344bis half a year, in the worst case prevent it from advancing from Draft to Proposed standard at all. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 14 04:38:50 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07311 for ; Fri, 14 May 2004 04:38:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOY9E-0005bF-Ts for mip4-archive@odin.ietf.org; Fri, 14 May 2004 04:34:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E8YS6n021526 for mip4-archive@odin.ietf.org; Fri, 14 May 2004 04:34:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOY2q-0004Fy-Ao for mip4-web-archive@optimus.ietf.org; Fri, 14 May 2004 04:27:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06863 for ; Fri, 14 May 2004 04:27:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOY2n-0001C4-FZ for mip4-web-archive@ietf.org; Fri, 14 May 2004 04:27:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOY1z-0000hL-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 04:27:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOY15-0000CF-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 04:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXz7-0003Kv-9e; Fri, 14 May 2004 04:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXws-0002qU-UO for mip4@optimus.ietf.org; Fri, 14 May 2004 04:21:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06244 for ; Fri, 14 May 2004 04:21:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXwq-0005QZ-10 for mip4@ietf.org; Fri, 14 May 2004 04:21:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXv9-0004k8-00 for mip4@ietf.org; Fri, 14 May 2004 04:19:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BOXu8-0003j0-00 for mip4@ietf.org; Fri, 14 May 2004 04:18:52 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 14 May 2004 01:17:14 -0700 Received: from ajamwal-u60.cisco.com (ajamwal-u60.cisco.com [128.107.132.155]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i4E8IL0R018148; Fri, 14 May 2004 01:18:21 -0700 (PDT) Date: Fri, 14 May 2004 01:18:21 -0700 (PDT) From: Sri Gundavelli To: Henrik Levkowetz cc: "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document In-Reply-To: <20040514095641.2e2d5194.henrik@levkowetz.com> Message-ID: References: <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Henrik, Comments inline .. On Fri, 14 May 2004, Henrik Levkowetz wrote: > Hi Sri, > > I'm adding [Issue 45] to the subject line to have this picked up by > the Issue tracker and archived for this issue. More inline: > > Friday 14 May 2004, Sri Gundavelli wrote: > > Hi Charlie, > > Since we all agreed to use explicit FA Identity extension in the > > Registration Requests from the foreign agent to the home agent for notifying the the > > care-of address, we should probably remove the MUST clause from the following text and > > allow provision for using the Identity extension as a means to validate the FHAE. > > I believe that if you go over the entries in the issue tracker for issue > 45, you'll find that it's far from clearcut that we have consensus on a > resolution; so you'r statement "we all agreed to use explicit FA Identity > extension" above doesn't quite hold up. > > More below. > > .... > > > Thanks for creating a new revision of rfc3344bis. > > > > > > One correction: > > > > > > Monday 10 May 2004, Charles E.Perkins wrote: > > > > > > > > For this a new paragraph has been added to section 3.8.2.2: > > > > > > > > A deregistration which is passed through a foreign agent which is > > > > different from the the one whose care-of address is being > > > > deregistered MAY add a Foreign-Home Authentication Extension to such > > > > a deregistration. However, as this deregistration concerns a > > > > different foreign agent than the one whose authentication extension, > > > > the home agent MUST disregard the Foreign-Home Authentication > > > > Extension of such a deregistration. The remaining validity checks, > > > > as described in Section 3.8.2.1, are required in full. > > > > > > I think that had better be: > > > s/whose authentication extension,/whose authentication extension is added,/ > ... > > If you find the above proposal unsatisfactory, it would be good if > you could propose some alternative text. > > But I think it would be good to keep in mind that: > > 1. The proposal above works also in the case of an old unmodified FA. > > 2. Adding dependency on a new draft may in the best case delay > 3344bis half a year, in the worst case prevent it from advancing > from Draft to Proposed standard at all. > Sure. We agreed not to hold the current draft and I'm not asking for the extension to be added to this draft. Sorry, if I was not clear on that. My only point is to change the "MUST" clause on HA behaviour with respect to the FHAE validation. The "Mobility Identity Extension" draft we published today can potentially address the FHAE issue ONLY if HA is not forced to ignore the FHAE validation in the above scenario. May be all I'm asking is to leave the above text with the "MAY" clause and that would not have any impact on the old FA scenarios. Regards ! Sri/ > > Henrik > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 14 04:51:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07858 for ; Fri, 14 May 2004 04:51:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYMm-0003CP-SN for mip4-archive@odin.ietf.org; Fri, 14 May 2004 04:48:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E8mSbi012298 for mip4-archive@odin.ietf.org; Fri, 14 May 2004 04:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYLD-0002pK-QY for mip4-web-archive@optimus.ietf.org; Fri, 14 May 2004 04:46:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07627 for ; Fri, 14 May 2004 04:46:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOYLA-0002zM-Px for mip4-web-archive@ietf.org; Fri, 14 May 2004 04:46:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOYK7-0002T5-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 04:45:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOYJ0-0001gG-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 04:44:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYFZ-0001SW-Qk; Fri, 14 May 2004 04:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYDf-0008WG-Ja for mip4@optimus.ietf.org; Fri, 14 May 2004 04:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07367 for ; Fri, 14 May 2004 04:39:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOYDc-0006mt-LA for mip4@ietf.org; Fri, 14 May 2004 04:39:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOYCp-0006Hi-00 for mip4@ietf.org; Fri, 14 May 2004 04:38:12 -0400 Received: from av3-2-sn3.vrr.skanova.net ([81.228.9.110]) by ietf-mx with esmtp (Exim 4.12) id 1BOYBz-0005iF-00 for mip4@ietf.org; Fri, 14 May 2004 04:37:19 -0400 Received: by av3-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 40A2837EAC; Fri, 14 May 2004 10:36:50 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3299C37E43; Fri, 14 May 2004 10:36:50 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 70CB338010; Fri, 14 May 2004 10:36:49 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BOYBU-0000cz-00; Fri, 14 May 2004 10:36:48 +0200 Date: Fri, 14 May 2004 10:36:48 +0200 From: Henrik Levkowetz To: Sri Gundavelli Cc: "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040514103648.473e180f.henrik@levkowetz.com> In-Reply-To: References: <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Sri, Friday 14 May 2004, Sri Gundavelli wrote: > Sure. We agreed not to hold the current draft and I'm not asking for the > extension to be added to this draft. Sorry, if I was not clear on that. My > only point is to change the "MUST" clause on HA behaviour with respect to > the FHAE validation. The "Mobility Identity Extension" draft we published > today can potentially address the FHAE issue ONLY if HA is not forced to > ignore the FHAE validation in the above scenario. May be all I'm asking is > to leave the above text with the "MAY" clause and that would not have any > impact on the old FA scenarios. Ok, I see. My thoughts were that you could let the new draft amend 3344bis on this point, saying in effect something like this in the new draft: ...if the FA uses a FA identity extension to identify itself and its authentication extension, as described in this draft, and the HA understands the FA identity extension, the HA no longer must disregard the authentication extension from the FA as described in [3344bis], but on the contrary SHOULD verify the FA authentication extension using the FA identidy from the FA identity extension... Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 14 12:02:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29276 for ; Fri, 14 May 2004 12:02:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOf4V-0006QB-Oz for mip4-archive@odin.ietf.org; Fri, 14 May 2004 11:58:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EFw3Dw024683 for mip4-archive@odin.ietf.org; Fri, 14 May 2004 11:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOezj-0004nP-3g for mip4-web-archive@optimus.ietf.org; Fri, 14 May 2004 11:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28998 for ; Fri, 14 May 2004 11:53:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOezh-0007eH-Tk for mip4-web-archive@ietf.org; Fri, 14 May 2004 11:53:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOeym-0007AR-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 11:52:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOexr-0006gU-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 11:51:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOetp-0003ar-2G; Fri, 14 May 2004 11:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOes8-0003G5-H8 for mip4@optimus.ietf.org; Fri, 14 May 2004 11:45:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28542 for ; Fri, 14 May 2004 11:45:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOes7-0003Xo-9z for mip4@ietf.org; Fri, 14 May 2004 11:45:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOer9-00031u-00 for mip4@ietf.org; Fri, 14 May 2004 11:44:16 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BOeq8-00022B-00 for mip4@ietf.org; Fri, 14 May 2004 11:43:12 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4EFdZj22189; Fri, 14 May 2004 10:40:04 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i4EFdX015887; Fri, 14 May 2004 10:39:33 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HXPNHU-00008S-00; Fri, 14 May 2004 11:39:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16548.59440.888121.724523@gargle.gargle.HOWL> Date: Fri, 14 May 2004 10:39:28 -0500 From: Pete McCann To: Henrik Levkowetz Cc: Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document In-Reply-To: <20040514103648.473e180f.henrik@levkowetz.com> References: <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm ok with relaxing the MUST disregard to a MAY disregard; however, I am not sure that adding FA NAI extension would turn this into a MUST verify before processing de-registration. It seems like the HA would always honor a valid de-registration request that passed end-to-end replay protection, no matter what extensions or authenticators were added by the FA. Maybe we need to take a more nuanced approach than all-or-nothing success/failure. Maybe we should view the FHAE as protecting only the extensions added by the FA, and possibly the care-of address owned by that FA if the request has lifetime > 0. One thing we might be missing in all of the discussion on identifying the FA: an important part of indexing a security association is not just so that you can find it when you are checking an existing authentication extension, but also so that you can detect when it is missing in a message received from another entity. The FA NAI, by itself, cannot be the only index key to the SA table, because we also need to be able to discard messages (or ignore certain parts of messages) that are not protected by an authentication extension when they really should be, according to the IP source address / care-of address. -Pete Henrik Levkowetz writes: > Hi Sri, > > Friday 14 May 2004, Sri Gundavelli wrote: > > Sure. We agreed not to hold the current draft and I'm not asking for the > > extension to be added to this draft. Sorry, if I was not clear on that. My > > only point is to change the "MUST" clause on HA behaviour with respect to > > the FHAE validation. The "Mobility Identity Extension" draft we published > > today can potentially address the FHAE issue ONLY if HA is not forced to > > ignore the FHAE validation in the above scenario. May be all I'm asking is > > to leave the above text with the "MAY" clause and that would not have any > > impact on the old FA scenarios. > > Ok, I see. My thoughts were that you could let the new draft amend > 3344bis on this point, saying in effect something like this in the new > draft: > > ...if the FA uses a FA identity extension to identify itself and its > authentication extension, as described in this draft, and the HA understands > the FA identity extension, the HA no longer must disregard the authentication > extension from the FA as described in [3344bis], but on the contrary SHOULD > verify the FA authentication extension using the FA identidy from the FA > identity extension... > > Henrik > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.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://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 14 13:22:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06577 for ; Fri, 14 May 2004 13:22:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgKq-0006jm-Ou for mip4-archive@odin.ietf.org; Fri, 14 May 2004 13:19:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EHJ0tm025894 for mip4-archive@odin.ietf.org; Fri, 14 May 2004 13:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOg9Z-0004HR-HJ for mip4-web-archive@optimus.ietf.org; Fri, 14 May 2004 13:07:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05722 for ; Fri, 14 May 2004 13:07:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOg9X-0002S8-O5 for mip4-web-archive@ietf.org; Fri, 14 May 2004 13:07:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOg8o-0001xb-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 13:06:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOg7x-0001S4-00 for mip4-web-archive@ietf.org; Fri, 14 May 2004 13:05:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOg3V-0002yD-AB; Fri, 14 May 2004 13:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOfwr-0001bn-Ad for mip4@optimus.ietf.org; Fri, 14 May 2004 12:54:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04755 for ; Fri, 14 May 2004 12:54:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOfwp-0003QK-IQ for mip4@ietf.org; Fri, 14 May 2004 12:54:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOfvp-0002tv-00 for mip4@ietf.org; Fri, 14 May 2004 12:53:11 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BOful-0001qv-00 for mip4@ietf.org; Fri, 14 May 2004 12:52:03 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4EGpOt19887; Fri, 14 May 2004 12:51:25 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 May 2004 12:51:24 -0400 Message-ID: From: "Jayshree Bharatia" To: "'Charles E.Perkins'" Cc: "'Mobile IPv4 Mailing List'" Subject: RE: [Mip4] New revision for rfc3344bis document Date: Fri, 14 May 2004 12:51:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C439D3.AA1F88E2" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C439D3.AA1F88E2 Content-Type: text/plain Hello Charlie, We had some mailing list discussion earlier regarding issue 17 which is related to the support of a nonzero unicast HA address (section 3.8.3.2). I don't see those agreed changes in 3344bis draft. It will be good if those changes are added to the draft. Regards, Jayshree -----Original Message----- From: Charles E.Perkins [mailto:charliep@iprg.nokia.com] Sent: Monday, May 10, 2004 1:08 PM To: Mobile IPv4 Mailing List Subject: [Mip4] New revision for rfc3344bis document Hello folks, I have created a new revision of the rfc3344bis document, and I would like to submit it soon to the Internet Drafts directories unless there is a good reason for holding it. The outstanding issues have been resolved except for possibly issue #45, but even so it is useful to have a new revision submitted for consideration. In this e-mail, I will describe the current changes which have been made to the specification in a proposed attempt to resolve issue #45. If more text is needed, another document revision will be created, hopefully before the meeting in San Diego. In order to prevent a rogue foreign-agent from denying a mobile node's deregistration by simply attaching a bad Foreign-Home authentication extension, the home agent is now mandated to ignore such extensions when applied to a deregistration message (i.e., zero lifetime). For this a new paragraph has been added to section 3.8.2.2: A deregistration which is passed through a foreign agent which is different from the the one whose care-of address is being deregistered MAY add a Foreign-Home Authentication Extension to such a deregistration. However, as this deregistration concerns a different foreign agent than the one whose authentication extension, the home agent MUST disregard the Foreign-Home Authentication Extension of such a deregistration. The remaining validity checks, as described in Section 3.8.2.1, are required in full. This requires a change to section 3.8.2.1, bullet item (c), first sentence to now read: c) If the home agent shares a mobility security association with the foreign agent, and this is a registration request (has non-zero lifetime), the home agent MUST check for the presence of a valid Foreign-Home Authentication Extension. In section 3.7.2.1, first sentence, clarification about when code 77 is valid: Requests with the 'D' bit set to 0, nonzero lifetime, and specifying a care-of address not offered by the foreign agent, MUST be rejected with code 77 (invalid care-of address). Thanks to Henrik for fashioning the above text replacements and additions. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ------_=_NextPart_001_01C439D3.AA1F88E2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] New revision for rfc3344bis document

Hello Charlie,
 
We had some mailing list discussion earlier = regarding issue 17 which is related to the support of a nonzero unicast = HA address (section 3.8.3.2). I don't see those agreed changes in = 3344bis draft. It will be good if those changes are added to the = draft.

Regards,
Jayshree

-----Original Message-----
From: Charles E.Perkins [mailto:charliep@iprg.nokia.com]
Sent: Monday, May 10, 2004 1:08 PM
To: Mobile IPv4 Mailing List
Subject: [Mip4] New revision for rfc3344bis = document



Hello folks,

I have created a new revision of the rfc3344bis = document,
and I would like to submit it soon to the Internet = Drafts directories unless there is a good reason for holding it.

The outstanding issues have been resolved except = for
possibly issue #45, but even so it is useful to = have
a new revision submitted for consideration.  In = this
e-mail, I will describe the current changes = which
have been made to the specification in a = proposed
attempt to resolve issue #45.  If more text is = needed,
another document revision will be created, = hopefully
before the meeting in San Diego.

In order to prevent a rogue foreign-agent from
denying a mobile node's deregistration by = simply
attaching a bad Foreign-Home authentication = extension,
the home agent is now mandated to ignore such
extensions when applied to a deregistration = message
(i.e., zero lifetime).

For this a new paragraph has been added to section = 3.8.2.2:

   A deregistration which is passed through = a foreign agent which is
   different from the the one whose = care-of address is being
   deregistered MAY add a Foreign-Home = Authentication Extension to such
   a deregistration.  However, as = this deregistration concerns a
   different foreign agent than the one = whose authentication extension,
   the home agent MUST disregard the = Foreign-Home Authentication
   Extension of such a = deregistration.  The remaining validity checks,
   as described in Section 3.8.2.1, are = required in full.

This requires a change to section 3.8.2.1, bullet = item (c), first sentence to now read:

      c) If the home agent = shares a mobility security association with
         the = foreign agent, and this is a registration request (has
         = non-zero lifetime), the home agent MUST check for the presence
         of = a valid Foreign-Home Authentication Extension.

In section 3.7.2.1, first sentence, clarification = about when code 77 is valid:

      Requests with the 'D' = bit set to 0, nonzero lifetime, and
      specifying a care-of = address not offered by the foreign agent,
      MUST be rejected with = code 77 (invalid care-of address).

Thanks to Henrik for fashioning the above text = replacements
and additions.

Regards,
Charlie P.

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

------_=_NextPart_001_01C439D3.AA1F88E2-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 01:34:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20701 for ; Sat, 15 May 2004 01:34:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOrei-0003nm-6f for mip4-archive@odin.ietf.org; Sat, 15 May 2004 01:24:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F5OGIJ014610 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 01:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOrdA-0003Qk-C6 for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 01:22:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20370 for ; Sat, 15 May 2004 01:22:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOrd7-0000Fh-Dt for mip4-web-archive@ietf.org; Sat, 15 May 2004 01:22:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOrcF-0007au-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 01:21:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOrbN-00078p-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 01:20:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOrXh-0002UQ-1c; Sat, 15 May 2004 01:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOrWS-0002FO-Nw for mip4@optimus.ietf.org; Sat, 15 May 2004 01:15:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20166 for ; Sat, 15 May 2004 01:15:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOrWP-0004nK-HJ for mip4@ietf.org; Sat, 15 May 2004 01:15:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOrVS-0004Kd-00 for mip4@ietf.org; Sat, 15 May 2004 01:14:43 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BOrUp-0003mo-00 for mip4@ietf.org; Sat, 15 May 2004 01:14:03 -0400 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 i4F5DUC1025649; Fri, 14 May 2004 22:13:31 -0700 (PDT) Received: from kleung-w2k01.cisco.com (sjc-vpn2-948.cisco.com [10.21.115.180]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF12600; Fri, 14 May 2004 22:12:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 May 2004 22:13:30 -0700 To: Pete McCann From: Kent Leung Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Cc: Henrik Levkowetz , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List In-Reply-To: <16548.59440.888121.724523@gargle.gargle.HOWL> References: <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 I believe that no security association between peers should be compromised. Maybe I missed it, but don't remember any consensus to put such text to disregard Authentication Extension. Actually, I think there was some agreement that FHAE (or any AEs for that matter) should not be simply ignored. (I know I've been vocal in my disagreement about ignoring FHAE - sorry AEs should not have special cases for handling; either one is trying to secure or not. :) See Issue #44 Comment #149: >I think your response last week convinced me that ignoring the R >bit is not a good idea, and I agree that the HA should check the FHAE, >if it is present, and discard the message if it doesn't check. RFC 3344bis should probably not mandate changes to current implementations. Thought there was already agreement that Mobility Entity Identify extension is needed for accurate identification, which is the root cause of issues #44 and #45. So that would solve the problem cleanly and not bypass any security associations which are set up by administrators. And there was agreement that another draft will handle this. See Issue #44 Comment #149: >If someone wants to put together a new document on Mobility Agent >Identifier extensions I think that would be a good idea. See Issue #44, Comment #142: >Your argument below is persuasive. It seems to me this would be a >fairly clean solution which leaves 3344 as flexible as today, improves >NAT traversal and solves the deregistration FHAE problem. In addition, I would expect that any messages received without proper AEs would be discarded. For example, the source IP address or CoA that matches an FA SA in a message that does not contain FHAE would be discarded by the HA for failing authentication. With the new draft, the Mobility Entitiy Identifer would be used to index an FA SA. In summary, I propose removing any text related to the issue in RFC3344bis because current implementation is right in terms of identifying the FA by source IP address or CoA. Future implementation should follow the upcoming draft that identifies FA accurately and solve both problems cleanly. Having any text that specifies to not add AE or ignore AE is more damaging than leaving issues as status quo to be dealt with later, IMHO. Kent At 10:39 AM 5/14/2004 -0500, Pete McCann wrote: >I'm ok with relaxing the MUST disregard to a MAY disregard; however, I >am not sure that adding FA NAI extension would turn this into a MUST >verify before processing de-registration. It seems like the HA would >always honor a valid de-registration request that passed end-to-end >replay protection, no matter what extensions or authenticators were >added by the FA. > >Maybe we need to take a more nuanced approach than all-or-nothing >success/failure. Maybe we should view the FHAE as protecting only the >extensions added by the FA, and possibly the care-of address owned by >that FA if the request has lifetime > 0. > >One thing we might be missing in all of the discussion on identifying >the FA: an important part of indexing a security association is not >just so that you can find it when you are checking an existing >authentication extension, but also so that you can detect when it is >missing in a message received from another entity. The FA NAI, by >itself, cannot be the only index key to the SA table, because we also >need to be able to discard messages (or ignore certain parts of >messages) that are not protected by an authentication extension when >they really should be, according to the IP source address / care-of >address. > >-Pete > >Henrik Levkowetz writes: > > Hi Sri, > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > Sure. We agreed not to hold the current draft and I'm not asking for the > > > extension to be added to this draft. Sorry, if I was not clear on > that. My > > > only point is to change the "MUST" clause on HA behaviour with > respect to > > > the FHAE validation. The "Mobility Identity Extension" draft we > published > > > today can potentially address the FHAE issue ONLY if HA is not forced to > > > ignore the FHAE validation in the above scenario. May be all I'm > asking is > > > to leave the above text with the "MAY" clause and that would not > have any > > > impact on the old FA scenarios. > > > > Ok, I see. My thoughts were that you could let the new draft amend > > 3344bis on this point, saying in effect something like this in the new > > draft: > > > > ...if the FA uses a FA identity extension to identify itself and its > > authentication extension, as described in this draft, and the HA > understands > > the FA identity extension, the HA no longer must disregard the > authentication > > extension from the FA as described in [3344bis], but on the contrary > SHOULD > > verify the FA authentication extension using the FA identidy from the FA > > identity extension... > > > > Henrik > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www.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://www.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://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 03:19:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08314 for ; Sat, 15 May 2004 03:19:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtQ3-00022H-HS for mip4-archive@odin.ietf.org; Sat, 15 May 2004 03:17:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F7HFtu007826 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 03:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtPZ-0001uz-At for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 03:16:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08190 for ; Sat, 15 May 2004 03:16:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOtPX-0000P4-7F for mip4-web-archive@ietf.org; Sat, 15 May 2004 03:16:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOtOa-0007iL-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 03:15:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOtNb-00070T-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 03:14:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtK1-00014k-BH; Sat, 15 May 2004 03:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtC5-0008OC-8V for mip4@optimus.ietf.org; Sat, 15 May 2004 03:02:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07720 for ; Sat, 15 May 2004 03:02:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOtC1-0001aa-5H for mip4@ietf.org; Sat, 15 May 2004 03:02:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOtAz-00017S-00 for mip4@ietf.org; Sat, 15 May 2004 03:01:42 -0400 Received: from av1-1-sn4.m-sp.skanova.net ([81.228.10.116]) by ietf-mx with esmtp (Exim 4.12) id 1BOtA2-0000CV-00 for mip4@ietf.org; Sat, 15 May 2004 03:00:42 -0400 Received: by av1-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 031A637E6C; Sat, 15 May 2004 09:00:13 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av1-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id EA8D437E43 for ; Sat, 15 May 2004 09:00:12 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 95D7A37E4F for ; Sat, 15 May 2004 09:00:12 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 3.35 #1 (Debian)) id 1BOt9Y-0007a5-00 for ; Sat, 15 May 2004 09:00:12 +0200 Content-Type: text/plain; charset=utf-8 To: mip4@ietf.org From: Henrik Levkowetz Reply-To: Mip4 issue tracker Date: Sat, 15 May 2004 07:00:10 +0000 MIME-Version: 1.0 Message-Id: <1084604410.02.0.237777342859.issue46@mip4.org> X-Roundup-Name: Mip4 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Mip4] [issue46] Applicability of Experimental Extensions to Agent Advertisements Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable New submission from Henrik Levkowetz : This issue is taken from the review of the experimental messages draft, at http://mip4.org/tools/rfcmarkup/rfcmarkup.cgi?url=3D../../reviews/review-ie= tf-mip4-experimental-messages-00.txt&comments=3DHENRIK Page 6, Section 7. IANA Considerations: Also, values for EXP-NONSKIP-EXT-TYPE and EXP-SKIP-EXT-TYPE must be assigned for experimental extensions. HENRIK: I suggest adding new paragraphs as follows: "The value for EXP-NONSKIP-EXT-TYPE should be assigned from the numbering space for non-skippable extensions which may appear in control messages, and also (with the same number) from the numbering space for non-skippable extensions which may appear in ICMP router discovery messages. The value 127 is suggested in both cases." "The value for EXP-SKIP-EXT-TYPE should be assigned from the numbering space for skippable extensions which may appear in control messages, and also (with the same number) from the numbering space for skippable extensions which may appear in ICMP router discovery messages. The value 255 is suggested in both cases." ---------- category: Technical draft: draft-ietf-mip4-experimental-messages messages: 157 nosy: henrik priority: Must fix status: No discussion title: Applicability of Experimental Extensions to Agent Advertisements _________________________________________________ Mip4 issue tracker _________________________________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 04:03:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09690 for ; Sat, 15 May 2004 04:03:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOu6t-0007c8-He for mip4-archive@odin.ietf.org; Sat, 15 May 2004 04:01:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F81VNe029264 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 04:01:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtzX-0006ir-GB for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 03:53:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09396 for ; Sat, 15 May 2004 03:53:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOtzV-0001sX-2M for mip4-web-archive@ietf.org; Sat, 15 May 2004 03:53:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOtyV-0001RI-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 03:52:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOtxu-000102-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 03:52:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtun-00068t-FV; Sat, 15 May 2004 03:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtsd-0005ug-7T for mip4@optimus.ietf.org; Sat, 15 May 2004 03:46:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09257 for ; Sat, 15 May 2004 03:46:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOtsa-0006ZD-MW for mip4@ietf.org; Sat, 15 May 2004 03:46:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOtrf-00067b-00 for mip4@ietf.org; Sat, 15 May 2004 03:45:48 -0400 Received: from av4-2-sn3.vrr.skanova.net ([81.228.9.112]) by ietf-mx with esmtp (Exim 4.12) id 1BOtqa-0005Fx-00 for mip4@ietf.org; Sat, 15 May 2004 03:44:40 -0400 Received: by av4-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 80F4C37E5D; Sat, 15 May 2004 09:44:10 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av4-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 6F4D137E5A; Sat, 15 May 2004 09:44:10 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 0642B38004; Sat, 15 May 2004 09:44:10 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BOtq5-0000zE-00; Sat, 15 May 2004 09:44:09 +0200 Date: Sat, 15 May 2004 09:44:08 +0200 From: Henrik Levkowetz To: Kent Leung Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040515094408.5844e41c.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> References: <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kent, I'm not adverse to your reasoning here. However, two points: 1. If we say nothing about this in 3344bis, then we still have the basic issue unsolved, and no indication that it even exist, in 3344bis. 2. The end result of leaving things as they are for now is that an FA is able to block the deregistration of a CoA belonging to another FA - i.e. a CoA for which it has no authority. Considering these points, could you suggest some alternative text, please? Or do you feel really strongly about not even mentioning the issue in 3344bis? Henrik Friday 14 May 2004, Kent Leung wrote: > I believe that no security association between peers should be compromised. > Maybe I missed it, but don't remember any consensus to put such text > to disregard Authentication Extension. Actually, I think there was some > agreement that FHAE (or any AEs for that matter) should not be > simply ignored. (I know I've been vocal in my disagreement about > ignoring FHAE - sorry AEs should not have special cases for handling; > either one is trying to secure or not. :) > > See Issue #44 Comment #149: > >I think your response last week convinced me that ignoring the R > >bit is not a good idea, and I agree that the HA should check the FHAE, > >if it is present, and discard the message if it doesn't check. > > RFC 3344bis should probably not mandate changes to current > implementations. Thought there was already agreement that Mobility > Entity Identify extension is needed for accurate identification, which is > the root cause of issues #44 and #45. So that would > solve the problem cleanly and not bypass any security associations > which are set up by administrators. And there was agreement that > another draft will handle this. > > See Issue #44 Comment #149: > >If someone wants to put together a new document on Mobility Agent > >Identifier extensions I think that would be a good idea. > > See Issue #44, Comment #142: > >Your argument below is persuasive. It seems to me this would be a > >fairly clean solution which leaves 3344 as flexible as today, improves > >NAT traversal and solves the deregistration FHAE problem. > > In addition, I would expect that any messages received without proper > AEs would be discarded. For example, the source IP address or CoA > that matches an FA SA in a message that does not contain FHAE > would be discarded by the HA for failing authentication. With the new > draft, the Mobility Entitiy Identifer would be used to index an FA SA. > > In summary, I propose removing any text related to the issue in > RFC3344bis because current implementation is right in terms of > identifying the FA by source IP address or CoA. Future implementation > should follow the upcoming draft that identifies FA accurately and solve both > problems cleanly. Having any text that specifies to not add AE or ignore > AE is more damaging than leaving issues as status quo to be dealt with > later, IMHO. > > Kent > > At 10:39 AM 5/14/2004 -0500, Pete McCann wrote: > > >I'm ok with relaxing the MUST disregard to a MAY disregard; however, I > >am not sure that adding FA NAI extension would turn this into a MUST > >verify before processing de-registration. It seems like the HA would > >always honor a valid de-registration request that passed end-to-end > >replay protection, no matter what extensions or authenticators were > >added by the FA. > > > >Maybe we need to take a more nuanced approach than all-or-nothing > >success/failure. Maybe we should view the FHAE as protecting only the > >extensions added by the FA, and possibly the care-of address owned by > >that FA if the request has lifetime > 0. > > > >One thing we might be missing in all of the discussion on identifying > >the FA: an important part of indexing a security association is not > >just so that you can find it when you are checking an existing > >authentication extension, but also so that you can detect when it is > >missing in a message received from another entity. The FA NAI, by > >itself, cannot be the only index key to the SA table, because we also > >need to be able to discard messages (or ignore certain parts of > >messages) that are not protected by an authentication extension when > >they really should be, according to the IP source address / care-of > >address. > > > >-Pete > > > >Henrik Levkowetz writes: > > > Hi Sri, > > > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > > Sure. We agreed not to hold the current draft and I'm not asking for the > > > > extension to be added to this draft. Sorry, if I was not clear on > > that. My > > > > only point is to change the "MUST" clause on HA behaviour with > > respect to > > > > the FHAE validation. The "Mobility Identity Extension" draft we > > published > > > > today can potentially address the FHAE issue ONLY if HA is not forced to > > > > ignore the FHAE validation in the above scenario. May be all I'm > > asking is > > > > to leave the above text with the "MAY" clause and that would not > > have any > > > > impact on the old FA scenarios. > > > > > > Ok, I see. My thoughts were that you could let the new draft amend > > > 3344bis on this point, saying in effect something like this in the new > > > draft: > > > > > > ...if the FA uses a FA identity extension to identify itself and its > > > authentication extension, as described in this draft, and the HA > > understands > > > the FA identity extension, the HA no longer must disregard the > > authentication > > > extension from the FA as described in [3344bis], but on the contrary > > SHOULD > > > verify the FA authentication extension using the FA identidy from the FA > > > identity extension... > > > > > > Henrik > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www.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://www.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://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 04:04:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09775 for ; Sat, 15 May 2004 04:04:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOu8I-0007qW-4b for mip4-archive@odin.ietf.org; Sat, 15 May 2004 04:02:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F82wD8030156 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 04:02:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOu4F-00077Z-JA for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 03:58:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09507 for ; Sat, 15 May 2004 03:58:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOu4D-000452-2k for mip4-web-archive@ietf.org; Sat, 15 May 2004 03:58:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOu3D-0003eG-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 03:57:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOu2K-0003DX-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 03:56:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtwk-0006Mq-4g; Sat, 15 May 2004 03:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtun-00068o-5V for mip4@optimus.ietf.org; Sat, 15 May 2004 03:49:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09286 for ; Sat, 15 May 2004 03:48:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOtuk-0007SS-K3 for mip4@ietf.org; Sat, 15 May 2004 03:48:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOttc-000718-00 for mip4@ietf.org; Sat, 15 May 2004 03:47:49 -0400 Received: from av5-1-sn1.fre.skanova.net ([81.228.11.111]) by ietf-mx with esmtp (Exim 4.12) id 1BOtt9-0006Zr-00 for mip4@ietf.org; Sat, 15 May 2004 03:47:19 -0400 Received: by av5-1-sn1.fre.skanova.net (Postfix, from userid 502) id 20A0837E5F; Sat, 15 May 2004 09:46:50 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av5-1-sn1.fre.skanova.net (Postfix) with ESMTP id 11CA737E42; Sat, 15 May 2004 09:46:50 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 3E08237E4E; Sat, 15 May 2004 09:46:49 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BOtse-0000zN-00; Sat, 15 May 2004 09:46:48 +0200 Date: Sat, 15 May 2004 09:46:48 +0200 From: Henrik Levkowetz To: "Jayshree Bharatia" Cc: "'Charles E.Perkins'" , "'Mobile IPv4 Mailing List'" Subject: Re: [Mip4] New revision for rfc3344bis document Message-Id: <20040515094648.0826319a.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jayshree, Friday 14 May 2004, Jayshree Bharatia wrote: > Hello Charlie, > > We had some mailing list discussion earlier regarding issue 17 which is > related to the support of a nonzero unicast HA address (section 3.8.3.2). I > don't see those agreed changes in 3344bis draft. It will be good if those > changes are added to the draft. Would it be OK with you to continue this discussion without holding up the submission of this revision of 3344bis? We still don't have a -00 out there, so I'd really like to get this one posted so we have an updated baseline to work from. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 04:15:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10251 for ; Sat, 15 May 2004 04:15:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOuIa-000171-W9 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 04:13:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F8DaW7004274 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 04:13:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOuDu-0000aX-91 for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 04:08:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09927 for ; Sat, 15 May 2004 04:08:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOuDr-0000lh-HO for mip4-web-archive@ietf.org; Sat, 15 May 2004 04:08:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOuCs-0000KD-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 04:07:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOuBv-0007fx-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 04:06:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOu9I-00081L-SS; Sat, 15 May 2004 04:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOu7D-0007ci-MK for mip4@optimus.ietf.org; Sat, 15 May 2004 04:01:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09603 for ; Sat, 15 May 2004 04:01:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOu7B-0005QI-6A for mip4@ietf.org; Sat, 15 May 2004 04:01:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOu65-0004xb-00 for mip4@ietf.org; Sat, 15 May 2004 04:00:42 -0400 Received: from av1-2-sn3.vrr.skanova.net ([81.228.9.106]) by ietf-mx with esmtp (Exim 4.12) id 1BOu54-00045s-00 for mip4@ietf.org; Sat, 15 May 2004 03:59:38 -0400 Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id DEDE737E47; Sat, 15 May 2004 09:59:09 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id D086137E43; Sat, 15 May 2004 09:59:09 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id B29D038021; Sat, 15 May 2004 09:59:09 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BOu4b-000102-00; Sat, 15 May 2004 09:59:09 +0200 Date: Sat, 15 May 2004 09:59:09 +0200 From: Henrik Levkowetz To: Pete McCann Cc: Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040515095909.2fe68293.henrik@levkowetz.com> In-Reply-To: <16548.59440.888121.724523@gargle.gargle.HOWL> References: <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <16548.59440.888121.724523@gargle.gargle.HOWL> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pete, Friday 14 May 2004, Pete McCann wrote: > > I'm ok with relaxing the MUST disregard to a MAY disregard; however, I > am not sure that adding FA NAI extension would turn this into a MUST > verify before processing de-registration. It seems like the HA would > always honor a valid de-registration request that passed end-to-end > replay protection, no matter what extensions or authenticators were > added by the FA. How about SHOULD disregard? As for the MUST verify, I don't feel particularly strongly about that. However, see Kent response - there are other opinions. > Maybe we need to take a more nuanced approach than all-or-nothing > success/failure. Maybe we should view the FHAE as protecting only the > extensions added by the FA, and possibly the care-of address owned by > that FA if the request has lifetime > 0. Makes strong sense to me. > One thing we might be missing in all of the discussion on identifying > the FA: an important part of indexing a security association is not > just so that you can find it when you are checking an existing > authentication extension, but also so that you can detect when it is > missing in a message received from another entity. The FA NAI, by > itself, cannot be the only index key to the SA table, because we also > need to be able to discard messages (or ignore certain parts of > messages) that are not protected by an authentication extension when > they really should be, according to the IP source address / care-of > address. Good point. Starting to think about this, I get the feeling we need a combinatorial state table here, to cover all the cases of source/care-of address and how they should be handled, to make sure we're not missing something. Maybe we could suggest including such a table in the draft-sgundave-mip4-identity-ext-00.txt? :-) Henrik > Henrik Levkowetz writes: > > Hi Sri, > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > Sure. We agreed not to hold the current draft and I'm not asking for the > > > extension to be added to this draft. Sorry, if I was not clear on that. My > > > only point is to change the "MUST" clause on HA behaviour with respect to > > > the FHAE validation. The "Mobility Identity Extension" draft we published > > > today can potentially address the FHAE issue ONLY if HA is not forced to > > > ignore the FHAE validation in the above scenario. May be all I'm asking is > > > to leave the above text with the "MAY" clause and that would not have any > > > impact on the old FA scenarios. > > > > Ok, I see. My thoughts were that you could let the new draft amend > > 3344bis on this point, saying in effect something like this in the new > > draft: > > > > ...if the FA uses a FA identity extension to identify itself and its > > authentication extension, as described in this draft, and the HA understands > > the FA identity extension, the HA no longer must disregard the authentication > > extension from the FA as described in [3344bis], but on the contrary SHOULD > > verify the FA authentication extension using the FA identidy from the FA > > identity extension... > > > > Henrik > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www.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://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 11:34:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27055 for ; Sat, 15 May 2004 11:34:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP1A6-000395-GF for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:33:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FFXI6H012092 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:33:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0zG-0001pf-8M for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 11:22:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26412 for ; Sat, 15 May 2004 11:22:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP0zF-0006nu-CM for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:22:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP0wF-0005wi-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:19:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BP0tu-0005IF-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:16:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0nd-0000F7-Py; Sat, 15 May 2004 11:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0hx-0007dh-2P for mip4@optimus.ietf.org; Sat, 15 May 2004 11:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25995 for ; Sat, 15 May 2004 11:04:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP0hu-0000ZS-Fh for mip4@ietf.org; Sat, 15 May 2004 11:04:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP0gy-0000BX-00 for mip4@ietf.org; Sat, 15 May 2004 11:03:13 -0400 Received: from av5-1-sn1.fre.skanova.net ([81.228.11.111]) by ietf-mx with esmtp (Exim 4.12) id 1BP0gE-0007Qd-00 for mip4@ietf.org; Sat, 15 May 2004 11:02:26 -0400 Received: by av5-1-sn1.fre.skanova.net (Postfix, from userid 502) id 5DA9537E7B; Sat, 15 May 2004 17:01:55 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av5-1-sn1.fre.skanova.net (Postfix) with ESMTP id 4C92037E4B for ; Sat, 15 May 2004 17:01:55 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 3710537E5A for ; Sat, 15 May 2004 17:01:55 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BP0fh-0001UE-00 for ; Sat, 15 May 2004 17:01:53 +0200 Message-ID: <40A41121.8030200@cisco.com> Date: Thu, 13 May 2004 17:21:53 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Cc: mccap@lucent.com, kleung@cisco.com, alpesh@cisco.com References: <20040428154724.2df810f9.henrik@levkowetz.com> <40A1AC1A.1070702@cisco.com> <20040512092143.3c4a35a7.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Resent-Date: Sat, 15 May 2004 17:01:53 +0200 Resent-From: Henrik Levkowetz Subject: Re: [Mip4] [Issue 46] Results of WG last call on draft-ietf-mip4-experimental-messages-00.txt Resent-Message-Id: <20040515170153.67339715.henrik@levkowetz.com> Resent-To: mip4@ietf.org Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henrik - HENRIK: I suggest adding new paragraphs as follows: "The value for EXP-NONSKIP-EXT-TYPE should be assigned from the numbering space for non-skippable extensions which may appear in control messages, and also (with the same number) from the numbering space for non-skippable extensions which may appear in ICMP router discovery messages. The value 127 is suggested in both cases." "The value for EXP-SKIP-EXT-TYPE should be assigned from the numbering space for skippable extensions which may appear in control messages, and also (with the same number) from the numbering space for skippable extensions which may appear in ICMP router discovery messages. The value 255 is suggested in both cases." I don't have a problem in adding these two paragraphs - atleast the first half of both. The only problem is that we are extending the scope of this draft beyond mobile ip and defining experimental numbers for ICMP in this draft. I would like to leave it out of scope of this document, since we are not defining the structure/usage for experimental ICMPmessage. Comments? Alpesh Henrik Levkowetz wrote: >Hi Alpesh, > >Tuesday 11 May 2004, Alpesh wrote: > > >>attached is the draft with relevant corrections. The multiple spaces >>were because the draft original is in word format and I had set on >>alignment. I turned that off. >> >> > >Yes, that's the usual reason ;-) > > > >>(Actually have discovered that xml is the >>best tool and will use it for other drafts). >> >> > >Applause! > > > >>I am attaching the draft for your reference. I actually cannot go to the >>2nd link you have below. >> >> >> > >Oops! I had to change some of those links because of a security issue. >Here is the relevant one. There are some stuff in the review which I >would really like you to fix, so if you could take a look at it... > >http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=../../reviews/review-ietf-mip4-experimental-messages-00.txt&comments=HENRIK > > > > >>I tried to run the idnits tool from your webpage, but that is giving me >>error. >> >> > >You seem to be running on windows; in order to run it there you need to >have cygwin installed. I'll make a note of that on the webpage. > > > >>Please let me know if I need to do anything else or if I should just >>post it to the WG alias and ietf-drafts@ietf.org. >> >> > >It would be great if you could fix the stuff in the review, and if you >like I can run it through idnits again after that to see that everything >is fine. If you *do* have cygwin installed on your windows box, I'd be >very happy to get feedback on any problems with running idnits, so I >can fix them. > > Henrik > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 11:35:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27097 for ; Sat, 15 May 2004 11:35:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP1AB-0003Ch-Pu for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:33:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FFXN60012310 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:33:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP10t-00024j-EV for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 11:23:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26629 for ; Sat, 15 May 2004 11:23:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP10s-0007Vn-LZ for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:23:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP0zm-00071u-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:22:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BP0xb-0006AS-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:20:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0vJ-000191-Vs; Sat, 15 May 2004 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0og-0000KX-5X for mip4@optimus.ietf.org; Sat, 15 May 2004 11:11:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26161 for ; Sat, 15 May 2004 11:11:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP0od-0003J6-Hy for mip4@ietf.org; Sat, 15 May 2004 11:11:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP0o3-0002uM-00 for mip4@ietf.org; Sat, 15 May 2004 11:10:31 -0400 Received: from av5-2-sn3.vrr.skanova.net ([81.228.9.114]) by ietf-mx with esmtp (Exim 4.12) id 1BP0mh-00027l-00 for mip4@ietf.org; Sat, 15 May 2004 11:09:07 -0400 Received: by av5-2-sn3.vrr.skanova.net (Postfix, from userid 502) id D4FA137E60; Sat, 15 May 2004 17:08:36 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av5-2-sn3.vrr.skanova.net (Postfix) with ESMTP id C60C737E42 for ; Sat, 15 May 2004 17:08:36 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 9281938019 for ; Sat, 15 May 2004 17:08:36 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BP0mA-0001Y4-00 for ; Sat, 15 May 2004 17:08:34 +0200 Date: Fri, 14 May 2004 02:48:00 +0200 From: Henrik Levkowetz To: Alpesh Cc: mccap@lucent.com, kleung@cisco.com, alpesh@cisco.com Message-Id: <20040514024800.147cd4f5.henrik@levkowetz.com> In-Reply-To: <40A41121.8030200@cisco.com> References: <20040428154724.2df810f9.henrik@levkowetz.com> <40A1AC1A.1070702@cisco.com> <20040512092143.3c4a35a7.henrik@levkowetz.com> <40A41121.8030200@cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Date: Sat, 15 May 2004 17:08:34 +0200 Resent-From: Henrik Levkowetz Subject: Re: [Mip4] [Issue 46] Results of WG last call on draft-ietf-mip4-experimental-messages-00.txt Resent-Message-Id: <20040515170834.319c68e6.henrik@levkowetz.com> Resent-To: mip4@ietf.org Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alpesh, Thursday 13 May 2004, Alpesh wrote: > HENRIK: I suggest adding new paragraphs as follows: > "The value for EXP-NONSKIP-EXT-TYPE should be assigned from the > numbering space for non-skippable extensions which may appear in > control messages, and also (with the same number) from the > numbering space for non-skippable extensions which may appear in > ICMP router discovery messages. The value 127 is suggested in > both cases." > "The value for EXP-SKIP-EXT-TYPE should be assigned from the > numbering space for skippable extensions which may appear in > control messages, and also (with the same number) from the > numbering space for skippable extensions which may appear in > ICMP router discovery messages. The value 255 is suggested in > both cases." > > I don't have a problem in adding these two paragraphs - atleast the > first half of both. The only problem is that we are extending the scope > of this draft beyond mobile ip and defining experimental numbers for ICMP > in this draft. I would like to leave it out of scope of this document, since > we are not defining the structure/usage for experimental ICMPmessage. No, that's not right, as I see it. The MIP extensions to the Router Advertisments are defined by 3344, and the numbering space defined for these are fully within the purview of MIP. These are managed on IANAs MIP4 numbers page, nowhere else. This is not a question of new ICMP messages. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 11:35:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27125 for ; Sat, 15 May 2004 11:35:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP1AD-0003DW-06 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:33:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FFXOVp012361 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP11P-00028v-IQ for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 11:24:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26695 for ; Sat, 15 May 2004 11:24:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP11O-00007n-Mp for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:24:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP10R-0007T1-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:23:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BP0zK-0006s3-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:22:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0vK-000199-Aa; Sat, 15 May 2004 11:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0pa-0000P4-EX for mip4@optimus.ietf.org; Sat, 15 May 2004 11:12:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26209 for ; Sat, 15 May 2004 11:12:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP0pZ-0003hh-IA for mip4@ietf.org; Sat, 15 May 2004 11:12:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP0oW-0003IC-00 for mip4@ietf.org; Sat, 15 May 2004 11:11:01 -0400 Received: from av9-2-sn1.fre.skanova.net ([81.228.11.116]) by ietf-mx with esmtp (Exim 4.12) id 1BP0nM-0002W3-00 for mip4@ietf.org; Sat, 15 May 2004 11:09:49 -0400 Received: by av9-2-sn1.fre.skanova.net (Postfix, from userid 502) id 89FDB37EA2; Sat, 15 May 2004 17:09:18 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av9-2-sn1.fre.skanova.net (Postfix) with ESMTP id 785AA37E46 for ; Sat, 15 May 2004 17:09:18 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 60EF437E4E for ; Sat, 15 May 2004 17:09:18 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BP0mq-0001YB-00 for ; Sat, 15 May 2004 17:09:16 +0200 Message-ID: <40A4FE04.2050800@cisco.com> Date: Fri, 14 May 2004 10:12:36 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Cc: mccap@lucent.com, kleung@cisco.com, alpesh@cisco.com References: <20040428154724.2df810f9.henrik@levkowetz.com> <40A1AC1A.1070702@cisco.com> <20040512092143.3c4a35a7.henrik@levkowetz.com> <40A41121.8030200@cisco.com> <20040514024800.147cd4f5.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Resent-Date: Sat, 15 May 2004 17:09:16 +0200 Resent-From: Henrik Levkowetz Subject: Re: [Mip4] [Issue 46] Results of WG last call on draft-ietf-mip4-experimental-messages-00.txt Resent-Message-Id: <20040515170916.5bd05f00.henrik@levkowetz.com> Resent-To: mip4@ietf.org Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henrik - Okay I went through that and in principle agree that it is open ended statement and leaves open the scope that ICMP router discovery (advertisement, typically) can also be included here. While I agree that it is meaningful to define a ICMP Router advertisement skippable extension, I have doubts about the non-skippable extension. The reason being, if as a host you receive a non-skippable extension in ICMP RA (router advertisement) are you supposed to drop/ignore the whole RA? This is probably not desired as the FA as an access router will always add the non-skippable extension - making it impossible for other (non-mobile hosts) to interpret the RA. (While the counter argument is that experimental extensions will be used for experimentation only this should not be a problem). But if we move forth from experimentation to standardizing that extension, the above problem still persists. Comments? -a Henrik Levkowetz wrote: >Hi Alpesh, > >Thursday 13 May 2004, Alpesh wrote: > > >>HENRIK: I suggest adding new paragraphs as follows: >> "The value for EXP-NONSKIP-EXT-TYPE should be assigned from the >> numbering space for non-skippable extensions which may appear in >> control messages, and also (with the same number) from the >> numbering space for non-skippable extensions which may appear in >> ICMP router discovery messages. The value 127 is suggested in >> both cases." >> "The value for EXP-SKIP-EXT-TYPE should be assigned from the >> numbering space for skippable extensions which may appear in >> control messages, and also (with the same number) from the >> numbering space for skippable extensions which may appear in >> ICMP router discovery messages. The value 255 is suggested in >> both cases." >> >>I don't have a problem in adding these two paragraphs - atleast the >>first half of both. The only problem is that we are extending the scope >>of this draft beyond mobile ip and defining experimental numbers for ICMP >>in this draft. I would like to leave it out of scope of this document, since >>we are not defining the structure/usage for experimental ICMPmessage. >> >> > >No, that's not right, as I see it. The MIP extensions to the Router >Advertisments are defined by 3344, and the numbering space defined for >these are fully within the purview of MIP. These are managed on IANAs >MIP4 numbers page, nowhere else. This is not a question of new ICMP >messages. > > Henrik > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 11:36:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27200 for ; Sat, 15 May 2004 11:36:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP1Au-0003M4-Tu for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:34:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FFY8GB012891 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP143-0002Go-TR for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 11:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26788 for ; Sat, 15 May 2004 11:27:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP142-0001Lb-Tn for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:27:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP132-0000wT-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:26:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BP11w-0000FV-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:24:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0wI-0001N7-08; Sat, 15 May 2004 11:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0re-0000hv-3d for mip4@optimus.ietf.org; Sat, 15 May 2004 11:14:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26280 for ; Sat, 15 May 2004 11:14:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP0rd-0004Wd-Aq for mip4@ietf.org; Sat, 15 May 2004 11:14:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP0qf-00047e-00 for mip4@ietf.org; Sat, 15 May 2004 11:13:14 -0400 Received: from av5-1-sn4.m-sp.skanova.net ([81.228.10.112]) by ietf-mx with esmtp (Exim 4.12) id 1BP0pt-0003XM-00 for mip4@ietf.org; Sat, 15 May 2004 11:12:26 -0400 Received: by av5-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 3DD4B37E49; Sat, 15 May 2004 17:11:55 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av5-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 2E63137E49 for ; Sat, 15 May 2004 17:11:55 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 14F6E37E4A for ; Sat, 15 May 2004 17:11:55 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BP0pN-0001YL-00 for ; Sat, 15 May 2004 17:11:53 +0200 Message-ID: <40A4204C.5090706@cisco.com> Date: Thu, 13 May 2004 18:26:36 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Cc: mccap@lucent.com, kleung@cisco.com, Alpesh References: <20040428154724.2df810f9.henrik@levkowetz.com> <40A1AC1A.1070702@cisco.com> <20040512092143.3c4a35a7.henrik@levkowetz.com> <40A41121.8030200@cisco.com> <20040514024800.147cd4f5.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Resent-Date: Sat, 15 May 2004 17:11:53 +0200 Resent-From: Henrik Levkowetz Subject: Re: [Mip4] [Issue 46] Results of WG last call on draft-ietf-mip4-experimental-messages-00.txt Resent-Message-Id: <20040515171153.41c53efb.henrik@levkowetz.com> Resent-To: mip4@ietf.org Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Okay, I see your point .. The second set consists of those extensions which may appear only in ICMP Router Discovery messages [4]. Currently, Mobile IP defines the following Types for Extensions appearing in ICMP Router Discovery messages: Value Name Reference ----- ------------------------------------------ --------- 0 One-byte Padding (encoded with no Length nor Data field)[RFC3344] 16 Mobility Agent Advertisement [RFC3344] 19 Prefix-Lengths [RFC3344] 24 Challenge Extension [RFC3012] The question I have then is within the ICMP types, the values are not partitioned to be skippable/non-skippable (as we have in MIPv4 number space). Also, their interpretation is not defined - what if I cannot skip - just ignore the whole RA? Do we want to define that behavior here? I think not. On the other hand, I am okay with defining an experimental type to be included in RA. To that end, I would need to add an additional section in the draft - do you agree? That would define the abstract structure of this type. Only resistance I have is doing a WG last call again. We can still post it to the WG for comments before sending it to IESG. Comments? -a Henrik Levkowetz wrote: >Hi Alpesh, > >Thursday 13 May 2004, Alpesh wrote: > > >>HENRIK: I suggest adding new paragraphs as follows: >> "The value for EXP-NONSKIP-EXT-TYPE should be assigned from the >> numbering space for non-skippable extensions which may appear in >> control messages, and also (with the same number) from the >> numbering space for non-skippable extensions which may appear in >> ICMP router discovery messages. The value 127 is suggested in >> both cases." >> "The value for EXP-SKIP-EXT-TYPE should be assigned from the >> numbering space for skippable extensions which may appear in >> control messages, and also (with the same number) from the >> numbering space for skippable extensions which may appear in >> ICMP router discovery messages. The value 255 is suggested in >> both cases." >> >>I don't have a problem in adding these two paragraphs - atleast the >>first half of both. The only problem is that we are extending the scope >>of this draft beyond mobile ip and defining experimental numbers for ICMP >>in this draft. I would like to leave it out of scope of this document, since >>we are not defining the structure/usage for experimental ICMPmessage. >> >> > >No, that's not right, as I see it. The MIP extensions to the Router >Advertisments are defined by 3344, and the numbering space defined for >these are fully within the purview of MIP. These are managed on IANAs >MIP4 numbers page, nowhere else. This is not a question of new ICMP >messages. > > Henrik > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat May 15 11:37:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27235 for ; Sat, 15 May 2004 11:37:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP1Aw-0003Mw-L0 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:34:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FFYAM3012945 for mip4-archive@odin.ietf.org; Sat, 15 May 2004 11:34:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP165-0002UB-HS for mip4-web-archive@optimus.ietf.org; Sat, 15 May 2004 11:29:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26876 for ; Sat, 15 May 2004 11:29:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP164-00029Z-KX for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:29:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP158-0001kw-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:28:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BP14c-0001Mn-00 for mip4-web-archive@ietf.org; Sat, 15 May 2004 11:27:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0wI-0001NF-E1; Sat, 15 May 2004 11:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP0uZ-00016l-K5 for mip4@optimus.ietf.org; Sat, 15 May 2004 11:17:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26313 for ; Sat, 15 May 2004 11:17:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP0uT-0005Io-Nf for mip4@ietf.org; Sat, 15 May 2004 11:17:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP0rf-0004Wv-00 for mip4@ietf.org; Sat, 15 May 2004 11:14:16 -0400 Received: from av1-1-sn3.vrr.skanova.net ([81.228.9.105]) by ietf-mx with esmtp (Exim 4.12) id 1BP0qi-0003iv-00 for mip4@ietf.org; Sat, 15 May 2004 11:13:16 -0400 Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 5CF3137EAE; Sat, 15 May 2004 17:12:46 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4DE2137E42 for ; Sat, 15 May 2004 17:12:46 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3466738003 for ; Sat, 15 May 2004 17:12:46 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BP0qC-0001YT-00 for ; Sat, 15 May 2004 17:12:44 +0200 Date: Fri, 14 May 2004 04:17:46 +0200 From: Henrik Levkowetz To: Alpesh Cc: mccap@lucent.com, kleung@cisco.com, Alpesh Message-Id: <20040514041746.55266af8.henrik@levkowetz.com> In-Reply-To: <40A4204C.5090706@cisco.com> References: <20040428154724.2df810f9.henrik@levkowetz.com> <40A1AC1A.1070702@cisco.com> <20040512092143.3c4a35a7.henrik@levkowetz.com> <40A41121.8030200@cisco.com> <20040514024800.147cd4f5.henrik@levkowetz.com> <40A4204C.5090706@cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Date: Sat, 15 May 2004 17:12:44 +0200 Resent-From: Henrik Levkowetz Subject: Re: [Mip4] [Issue 46] Results of WG last call on draft-ietf-mip4-experimental-messages-00.txt Resent-Message-Id: <20040515171244.00e4d103.henrik@levkowetz.com> Resent-To: mip4@ietf.org Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alpesh, Thursday 13 May 2004, Alpesh wrote: > Okay, I see your point .. > > The second set consists of those extensions which may appear only > in ICMP Router Discovery messages [4]. Currently, Mobile IP > defines the following Types for Extensions appearing in ICMP > Router Discovery messages: > > Value Name Reference > ----- ------------------------------------------ --------- > 0 One-byte Padding (encoded with no Length nor Data field)[RFC3344] > 16 Mobility Agent Advertisement [RFC3344] > 19 Prefix-Lengths [RFC3344] > 24 Challenge Extension [RFC3012] > > > The question I have then is within the ICMP types, the values are not partitioned > to be skippable/non-skippable (as we have in MIPv4 number space). Also, their > interpretation is not defined - what if I cannot skip - just ignore the whole RA? First, I'm not aware of anything which says that the skippable/non-skippable division doesn't apply to MIP extensions in ICMP messages - on the contrary, the wording in 3344 (second last para. of page 14) seems to be carefully chosen so as to apply to both registration and ICMP messages. Second, this (as I see it) does give us a defined interpretation in the ICMP case, too. > Do we want to define that behavior here? I think not. On the other hand, I am > okay with defining an experimental type to be included in RA. I don't think that we're doing any definition of new behaviour, this is already covered in 3344. > To that end, I would need to add an additional section in the draft - do > you agree? That would define the abstract structure of this type. I was thinking that we would be already covered - these extensions would be defined identically for the Registration and ICMP case. If you want to put in a sentence somewhere to clarify this, in addition to the IANA considerations, that's fine by me. > Only resistance I have is doing a WG last call again. We can still post > it to the WG for comments before sending it to IESG. Comments? Sounds fine to me. I wasn't thinking in terms of a new last call. Henrik > > -a > > Henrik Levkowetz wrote: > > >Hi Alpesh, > > > >Thursday 13 May 2004, Alpesh wrote: > > > > > >>HENRIK: I suggest adding new paragraphs as follows: > >> "The value for EXP-NONSKIP-EXT-TYPE should be assigned from the > >> numbering space for non-skippable extensions which may appear in > >> control messages, and also (with the same number) from the > >> numbering space for non-skippable extensions which may appear in > >> ICMP router discovery messages. The value 127 is suggested in > >> both cases." > >> "The value for EXP-SKIP-EXT-TYPE should be assigned from the > >> numbering space for skippable extensions which may appear in > >> control messages, and also (with the same number) from the > >> numbering space for skippable extensions which may appear in > >> ICMP router discovery messages. The value 255 is suggested in > >> both cases." > >> > >>I don't have a problem in adding these two paragraphs - atleast the > >>first half of both. The only problem is that we are extending the scope > >>of this draft beyond mobile ip and defining experimental numbers for ICMP > >>in this draft. I would like to leave it out of scope of this document, since > >>we are not defining the structure/usage for experimental ICMPmessage. > >> > >> > > > >No, that's not right, as I see it. The MIP extensions to the Router > >Advertisments are defined by 3344, and the numbering space defined for > >these are fully within the purview of MIP. These are managed on IANAs > >MIP4 numbers page, nowhere else. This is not a question of new ICMP > >messages. > > > > Henrik > > > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 17 01:22:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15348 for ; Mon, 17 May 2004 01:22:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPaYa-0008LE-MK for mip4-archive@odin.ietf.org; Mon, 17 May 2004 01:20:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H5Ku0j032064 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 01:20:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPaYK-0008E5-Lb for mip4-web-archive@optimus.ietf.org; Mon, 17 May 2004 01:20:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15219 for ; Mon, 17 May 2004 01:20:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPaYH-00030Z-NV for mip4-web-archive@ietf.org; Mon, 17 May 2004 01:20:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPaXP-0002iZ-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 01:19:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPaWc-0002RH-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 01:18:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPaQy-0007DY-Gs; Mon, 17 May 2004 01:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPaKr-0005iA-GQ for mip4@optimus.ietf.org; Mon, 17 May 2004 01:06:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14938 for ; Mon, 17 May 2004 01:06:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPaKo-0006qV-Mt for mip4@ietf.org; Mon, 17 May 2004 01:06:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPaJs-0006Z2-00 for mip4@ietf.org; Mon, 17 May 2004 01:05:46 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BPaJS-0006HB-00 for mip4@ietf.org; Mon, 17 May 2004 01:05:18 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4H54Rc08928; Mon, 17 May 2004 00:04:27 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i4H54PO26965; Mon, 17 May 2004 00:04:26 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HXUE2X-0000KG-00; Mon, 17 May 2004 01:04:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16552.18385.75121.9522@gargle.gargle.HOWL> Date: Mon, 17 May 2004 00:04:17 -0500 From: Pete McCann To: Henrik Levkowetz Cc: Kent Leung , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document In-Reply-To: <20040515094408.5844e41c.henrik@levkowetz.com> References: <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040515094408.5844e41c.henrik@levkowetz.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Kent, Yes, I can see how special-casing the FHAE would be difficult in most implementations. However, I agree with Henrik & others that there is a subtle problem here, and now I don't think it can be fixed with an FA NAI, due to the missing auth extension detection problem. If attackers would just cooperate and set the "evil" bit in the packet headers our job would be a lot easier. Reading your mail, I think you are suggesting to index the SA by *both* FA source IP address and FA COA. Is that explicit in the current draft? If not, it should be. We may have slightly differing views on the current problem we are trying to solve. Let me try to state it a couple of different ways and see if you agree: * An MN is trying to de-register an old care-of address through an FA that is behind a NAT. The FA thinks it has an SA with an HA, so appends FHAE. Unfortunately, the HA can't find it due to the NAT and so drops the message. Now, it seems that FA NAI would fix this problem. However, let me state another problem: * An MN is trying to de-register an old care-of address through an FA that is behind a NAT. The FA doesn't have an SA with an HA, so does not append FHAE. Unfortunately, the HA looks at the COA in the message, realizes that it has an SA with the old FA, and so drops the message. Note that source IP address is not useful for identifying the FA because of the NAT. Now, it seems like FA NAI would not fix this problem, because there is no way to tell whether or not an un-authenticated NAI was inserted by an attacker after stripping out the real NAI/authenticator extensions. So, it seems like we at least will end up needing special rules for how to index the SA in the case of de-registration. That is, we might look for SAs based on source IP address, COA, and/or FA NAI in the case of registrations, but with de-registrations, we can't use the COA. We might still be able to use the other two items. Is that accurate? -Pete Henrik Levkowetz writes: > Hi Kent, > > I'm not adverse to your reasoning here. However, two points: > > 1. If we say nothing about this in 3344bis, then we still have the basic > issue unsolved, and no indication that it even exist, in 3344bis. > > 2. The end result of leaving things as they are for now is that an FA is > able to block the deregistration of a CoA belonging to another FA - i.e. > a CoA for which it has no authority. > > Considering these points, could you suggest some alternative text, please? > > Or do you feel really strongly about not even mentioning the issue in > 3344bis? > > Henrik > > Friday 14 May 2004, Kent Leung wrote: > > I believe that no security association between peers should be compromised. > > Maybe I missed it, but don't remember any consensus to put such text > > to disregard Authentication Extension. Actually, I think there was some > > agreement that FHAE (or any AEs for that matter) should not be > > simply ignored. (I know I've been vocal in my disagreement about > > ignoring FHAE - sorry AEs should not have special cases for handling; > > either one is trying to secure or not. :) > > > > See Issue #44 Comment #149: > > >I think your response last week convinced me that ignoring the R > > >bit is not a good idea, and I agree that the HA should check the FHAE, > > >if it is present, and discard the message if it doesn't check. > > > > RFC 3344bis should probably not mandate changes to current > > implementations. Thought there was already agreement that Mobility > > Entity Identify extension is needed for accurate identification, which is > > the root cause of issues #44 and #45. So that would > > solve the problem cleanly and not bypass any security associations > > which are set up by administrators. And there was agreement that > > another draft will handle this. > > > > See Issue #44 Comment #149: > > >If someone wants to put together a new document on Mobility Agent > > >Identifier extensions I think that would be a good idea. > > > > See Issue #44, Comment #142: > > >Your argument below is persuasive. It seems to me this would be a > > >fairly clean solution which leaves 3344 as flexible as today, improves > > >NAT traversal and solves the deregistration FHAE problem. > > > > In addition, I would expect that any messages received without proper > > AEs would be discarded. For example, the source IP address or CoA > > that matches an FA SA in a message that does not contain FHAE > > would be discarded by the HA for failing authentication. With the new > > draft, the Mobility Entitiy Identifer would be used to index an FA SA. > > > > In summary, I propose removing any text related to the issue in > > RFC3344bis because current implementation is right in terms of > > identifying the FA by source IP address or CoA. Future implementation > > should follow the upcoming draft that identifies FA accurately and solve both > > problems cleanly. Having any text that specifies to not add AE or ignore > > AE is more damaging than leaving issues as status quo to be dealt with > > later, IMHO. > > > > Kent > > > > At 10:39 AM 5/14/2004 -0500, Pete McCann wrote: > > > > >I'm ok with relaxing the MUST disregard to a MAY disregard; however, I > > >am not sure that adding FA NAI extension would turn this into a MUST > > >verify before processing de-registration. It seems like the HA would > > >always honor a valid de-registration request that passed end-to-end > > >replay protection, no matter what extensions or authenticators were > > >added by the FA. > > > > > >Maybe we need to take a more nuanced approach than all-or-nothing > > >success/failure. Maybe we should view the FHAE as protecting only the > > >extensions added by the FA, and possibly the care-of address owned by > > >that FA if the request has lifetime > 0. > > > > > >One thing we might be missing in all of the discussion on identifying > > >the FA: an important part of indexing a security association is not > > >just so that you can find it when you are checking an existing > > >authentication extension, but also so that you can detect when it is > > >missing in a message received from another entity. The FA NAI, by > > >itself, cannot be the only index key to the SA table, because we also > > >need to be able to discard messages (or ignore certain parts of > > >messages) that are not protected by an authentication extension when > > >they really should be, according to the IP source address / care-of > > >address. > > > > > >-Pete > > > > > >Henrik Levkowetz writes: > > > > Hi Sri, > > > > > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > > > Sure. We agreed not to hold the current draft and I'm not asking for the > > > > > extension to be added to this draft. Sorry, if I was not clear on > > > that. My > > > > > only point is to change the "MUST" clause on HA behaviour with > > > respect to > > > > > the FHAE validation. The "Mobility Identity Extension" draft we > > > published > > > > > today can potentially address the FHAE issue ONLY if HA is not forced to > > > > > ignore the FHAE validation in the above scenario. May be all I'm > > > asking is > > > > > to leave the above text with the "MAY" clause and that would not > > > have any > > > > > impact on the old FA scenarios. > > > > > > > > Ok, I see. My thoughts were that you could let the new draft amend > > > > 3344bis on this point, saying in effect something like this in the new > > > > draft: > > > > > > > > ...if the FA uses a FA identity extension to identify itself and its > > > > authentication extension, as described in this draft, and the HA > > > understands > > > > the FA identity extension, the HA no longer must disregard the > > > authentication > > > > extension from the FA as described in [3344bis], but on the contrary > > > SHOULD > > > > verify the FA authentication extension using the FA identidy from the FA > > > > identity extension... > > > > > > > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 17 02:51:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02513 for ; Mon, 17 May 2004 02:51:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbxQ-0001bD-93 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 02:50:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H6oe5r006143 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 02:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbve-0001Ky-7o for mip4-web-archive@optimus.ietf.org; Mon, 17 May 2004 02:48:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02439 for ; Mon, 17 May 2004 02:48:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPbva-0006Oj-Fb for mip4-web-archive@ietf.org; Mon, 17 May 2004 02:48:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPbud-000663-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 02:47:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPbtn-0005nt-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 02:46:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbqz-0000lX-BE; Mon, 17 May 2004 02:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPbno-0000JO-Mz for mip4@optimus.ietf.org; Mon, 17 May 2004 02:40:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02106 for ; Mon, 17 May 2004 02:40:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPbnk-0003xe-T5 for mip4@ietf.org; Mon, 17 May 2004 02:40:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPbmm-0003dR-00 for mip4@ietf.org; Mon, 17 May 2004 02:39:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BPbls-0002xH-00 for mip4@ietf.org; Mon, 17 May 2004 02:38:44 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 May 2004 22:45:15 +0000 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 i4H6cCW9009812; Sun, 16 May 2004 23:38:13 -0700 (PDT) Received: from kleung-w2k01.cisco.com (sjc-vpn4-1159.cisco.com [10.21.84.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF74034; Sun, 16 May 2004 23:37:24 -0700 (PDT) Message-Id: <4.3.2.7.2.20040516230344.02eebdd8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 16 May 2004 23:38:39 -0700 To: Pete McCann From: Kent Leung Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Cc: Henrik Levkowetz , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List In-Reply-To: <16552.18385.75121.9522@gargle.gargle.HOWL> References: <20040515094408.5844e41c.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040515094408.5844e41c.henrik@levkowetz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Hi Pete. Comments below. At 12:04 AM 5/17/2004 -0500, Pete McCann wrote: >Hi, Kent, > >Yes, I can see how special-casing the FHAE would be difficult in most >implementations. > >However, I agree with Henrik & others that there is a subtle problem >here, and now I don't think it can be fixed with an FA NAI, due to the >missing auth extension detection problem. If attackers would just >cooperate and set the "evil" bit in the packet headers our job would >be a lot easier. > >Reading your mail, I think you are suggesting to index the SA by >*both* FA source IP address and FA COA. Is that explicit in the >current draft? If not, it should be. It is not explicit as far as I'm aware of. Exactly how the FA is identified is not clearly defined. I've always assumed both fields are used since CoA was not always the right identity for FA. >We may have slightly differing views on the current problem we are >trying to solve. Let me try to state it a couple of different ways >and see if you agree: > >* An MN is trying to de-register an old care-of address through an FA > that is behind a NAT. The FA thinks it has an SA with an HA, so > appends FHAE. Unfortunately, the HA can't find it due to the NAT > and so drops the message. > >Now, it seems that FA NAI would fix this problem. Yes. >However, let me state another problem: > >* An MN is trying to de-register an old care-of address through an > FA that is behind a NAT. The FA doesn't have an SA with an HA, so > does not append FHAE. Unfortunately, the HA looks at the COA in > the message, realizes that it has an SA with the old FA, and so > drops the message. Note that source IP address is not useful > for identifying the FA because of the NAT. But, FA should be appending the FA NAI ext to identify itself since the CoA nor the source IP address is insufficient. This new extension is providing identity for source endpoint of the message and allow the receiver side to detect if NAT occurred, SA checked, and any future operations needed. >Now, it seems like FA NAI would not fix this problem, because there is >no way to tell whether or not an un-authenticated NAI was inserted by >an attacker after stripping out the real NAI/authenticator extensions. Hmm, not totally clear about this scenario. Are you saying that the attacker can modify fields in the message in transit to cause failed authentication? But it would be easier just to change one bit anywhere before the MHAE? As for how to avoid un-authenticated FA NAI, one method is to advertise this identity to the MN so it gets protected by the MHAE? This can be dealt with in the new draft. >So, it seems like we at least will end up needing special rules for >how to index the SA in the case of de-registration. That is, we might >look for SAs based on source IP address, COA, and/or FA NAI in the >case of registrations, but with de-registrations, we can't use the >COA. We might still be able to use the other two items. I think we can have consistency for registration and de-registration by having the FA to always insert the FA NAI in the message when the source IP address or CoA is insufficient. The FHAE is appended only if FA has an SA with the HA. The HA will know which FA is the sender and act in a clear manner to process the message. As for logic for determining when CoA is insufficient, either when FA is behind NAT (source IP address will be translated), or CoA in message is not advertised by FA or match FA's identity, comes to mind... Kent >Is that accurate? > >-Pete > > >Henrik Levkowetz writes: > > Hi Kent, > > > > I'm not adverse to your reasoning here. However, two points: > > > > 1. If we say nothing about this in 3344bis, then we still have the basic > > issue unsolved, and no indication that it even exist, in 3344bis. > > > > 2. The end result of leaving things as they are for now is that an FA is > > able to block the deregistration of a CoA belonging to another FA - i.e. > > a CoA for which it has no authority. > > > > Considering these points, could you suggest some alternative text, please? > > > > Or do you feel really strongly about not even mentioning the issue in > > 3344bis? > > > > Henrik > > > > Friday 14 May 2004, Kent Leung wrote: > > > I believe that no security association between peers should be > compromised. > > > Maybe I missed it, but don't remember any consensus to put such text > > > to disregard Authentication Extension. Actually, I think there was some > > > agreement that FHAE (or any AEs for that matter) should not be > > > simply ignored. (I know I've been vocal in my disagreement about > > > ignoring FHAE - sorry AEs should not have special cases for handling; > > > either one is trying to secure or not. :) > > > > > > See Issue #44 Comment #149: > > > >I think your response last week convinced me that ignoring the R > > > >bit is not a good idea, and I agree that the HA should check the FHAE, > > > >if it is present, and discard the message if it doesn't check. > > > > > > RFC 3344bis should probably not mandate changes to current > > > implementations. Thought there was already agreement that Mobility > > > Entity Identify extension is needed for accurate identification, > which is > > > the root cause of issues #44 and #45. So that would > > > solve the problem cleanly and not bypass any security associations > > > which are set up by administrators. And there was agreement that > > > another draft will handle this. > > > > > > See Issue #44 Comment #149: > > > >If someone wants to put together a new document on Mobility Agent > > > >Identifier extensions I think that would be a good idea. > > > > > > See Issue #44, Comment #142: > > > >Your argument below is persuasive. It seems to me this would be a > > > >fairly clean solution which leaves 3344 as flexible as today, improves > > > >NAT traversal and solves the deregistration FHAE problem. > > > > > > In addition, I would expect that any messages received without proper > > > AEs would be discarded. For example, the source IP address or CoA > > > that matches an FA SA in a message that does not contain FHAE > > > would be discarded by the HA for failing authentication. With the new > > > draft, the Mobility Entitiy Identifer would be used to index an FA SA. > > > > > > In summary, I propose removing any text related to the issue in > > > RFC3344bis because current implementation is right in terms of > > > identifying the FA by source IP address or CoA. Future implementation > > > should follow the upcoming draft that identifies FA accurately and > solve both > > > problems cleanly. Having any text that specifies to not add AE or > ignore > > > AE is more damaging than leaving issues as status quo to be dealt with > > > later, IMHO. > > > > > > Kent > > > > > > At 10:39 AM 5/14/2004 -0500, Pete McCann wrote: > > > > > > >I'm ok with relaxing the MUST disregard to a MAY disregard; however, I > > > >am not sure that adding FA NAI extension would turn this into a MUST > > > >verify before processing de-registration. It seems like the HA would > > > >always honor a valid de-registration request that passed end-to-end > > > >replay protection, no matter what extensions or authenticators were > > > >added by the FA. > > > > > > > >Maybe we need to take a more nuanced approach than all-or-nothing > > > >success/failure. Maybe we should view the FHAE as protecting only the > > > >extensions added by the FA, and possibly the care-of address owned by > > > >that FA if the request has lifetime > 0. > > > > > > > >One thing we might be missing in all of the discussion on identifying > > > >the FA: an important part of indexing a security association is not > > > >just so that you can find it when you are checking an existing > > > >authentication extension, but also so that you can detect when it is > > > >missing in a message received from another entity. The FA NAI, by > > > >itself, cannot be the only index key to the SA table, because we also > > > >need to be able to discard messages (or ignore certain parts of > > > >messages) that are not protected by an authentication extension when > > > >they really should be, according to the IP source address / care-of > > > >address. > > > > > > > >-Pete > > > > > > > >Henrik Levkowetz writes: > > > > > Hi Sri, > > > > > > > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > > > > Sure. We agreed not to hold the current draft and I'm not > asking for the > > > > > > extension to be added to this draft. Sorry, if I was not > clear on > > > > that. My > > > > > > only point is to change the "MUST" clause on HA behaviour with > > > > respect to > > > > > > the FHAE validation. The "Mobility Identity Extension" draft we > > > > published > > > > > > today can potentially address the FHAE issue ONLY if HA is > not forced to > > > > > > ignore the FHAE validation in the above scenario. May be all I'm > > > > asking is > > > > > > to leave the above text with the "MAY" clause and that would not > > > > have any > > > > > > impact on the old FA scenarios. > > > > > > > > > > Ok, I see. My thoughts were that you could let the new draft amend > > > > > 3344bis on this point, saying in effect something like this in > the new > > > > > draft: > > > > > > > > > > ...if the FA uses a FA identity extension to identify itself > and its > > > > > authentication extension, as described in this draft, and the HA > > > > understands > > > > > the FA identity extension, the HA no longer must disregard the > > > > authentication > > > > > extension from the FA as described in [3344bis], but on the > contrary > > > > SHOULD > > > > > verify the FA authentication extension using the FA identidy > from the FA > > > > > identity extension... > > > > > > > > > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 17 03:33:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04351 for ; Mon, 17 May 2004 03:33:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcYq-0006Ap-H8 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 03:29:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H7TKEp023731 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 03:29:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcSf-0005TY-TA for mip4-web-archive@optimus.ietf.org; Mon, 17 May 2004 03:22:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03814 for ; Mon, 17 May 2004 03:22:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcSd-0001En-M3 for mip4-web-archive@ietf.org; Mon, 17 May 2004 03:22:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcRZ-0000up-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 03:21:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPcQo-0000cD-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 03:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcI4-0004Mh-Tw; Mon, 17 May 2004 03:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcEw-0003ri-Es for mip4@optimus.ietf.org; Mon, 17 May 2004 03:08:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03308 for ; Mon, 17 May 2004 03:08:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcEs-0004j4-9k for mip4@ietf.org; Mon, 17 May 2004 03:08:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcDz-0004Rg-00 for mip4@ietf.org; Mon, 17 May 2004 03:07:48 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BPcDY-00049d-00 for mip4@ietf.org; Mon, 17 May 2004 03:07:21 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 May 2004 23:13:51 +0000 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 i4H76nW9007669; Mon, 17 May 2004 00:06:49 -0700 (PDT) Received: from kleung-w2k01.cisco.com (sjc-vpn4-1159.cisco.com [10.21.84.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF75240; Mon, 17 May 2004 00:06:01 -0700 (PDT) Message-Id: <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 May 2004 00:07:16 -0700 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List In-Reply-To: <20040515094408.5844e41c.henrik@levkowetz.com> References: <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 At 09:44 AM 5/15/2004 +0200, Henrik Levkowetz wrote: >Hi Kent, > >I'm not adverse to your reasoning here. However, two points: > >1. If we say nothing about this in 3344bis, then we still have the basic >issue unsolved, and no indication that it even exist, in 3344bis. Yes, the problem exists. Saying nothing or describing the problem in 3344bis will still result in having issue unsolved, right? The dilemma is if we describe the problem, can we just leave it as unresolved until another draft? >2. The end result of leaving things as they are for now is that an FA is >able to block the deregistration of a CoA belonging to another FA - i.e. >a CoA for which it has no authority. Sorry, I just don't see that "FA is able to block ..". I see communications between FA and HA that should be secured by FHAE, and the lack of identifier of the source of message. FA is not deliberately trying to sabotage the deregistration, just that we have not provided the capability to secure the exchange. >Considering these points, could you suggest some alternative text, please? > >Or do you feel really strongly about not even mentioning the issue in >3344bis? There is a problem, but there's been agreement not to provide solution in 3344bis. I don't have problem with text describing issue. But if you feel that it's sufficient just to provide description and no solution, then I can propose some text. Kent > Henrik > >Friday 14 May 2004, Kent Leung wrote: > > I believe that no security association between peers should be compromised. > > Maybe I missed it, but don't remember any consensus to put such text > > to disregard Authentication Extension. Actually, I think there was some > > agreement that FHAE (or any AEs for that matter) should not be > > simply ignored. (I know I've been vocal in my disagreement about > > ignoring FHAE - sorry AEs should not have special cases for handling; > > either one is trying to secure or not. :) > > > > See Issue #44 Comment #149: > > >I think your response last week convinced me that ignoring the R > > >bit is not a good idea, and I agree that the HA should check the FHAE, > > >if it is present, and discard the message if it doesn't check. > > > > RFC 3344bis should probably not mandate changes to current > > implementations. Thought there was already agreement that Mobility > > Entity Identify extension is needed for accurate identification, which is > > the root cause of issues #44 and #45. So that would > > solve the problem cleanly and not bypass any security associations > > which are set up by administrators. And there was agreement that > > another draft will handle this. > > > > See Issue #44 Comment #149: > > >If someone wants to put together a new document on Mobility Agent > > >Identifier extensions I think that would be a good idea. > > > > See Issue #44, Comment #142: > > >Your argument below is persuasive. It seems to me this would be a > > >fairly clean solution which leaves 3344 as flexible as today, improves > > >NAT traversal and solves the deregistration FHAE problem. > > > > In addition, I would expect that any messages received without proper > > AEs would be discarded. For example, the source IP address or CoA > > that matches an FA SA in a message that does not contain FHAE > > would be discarded by the HA for failing authentication. With the new > > draft, the Mobility Entitiy Identifer would be used to index an FA SA. > > > > In summary, I propose removing any text related to the issue in > > RFC3344bis because current implementation is right in terms of > > identifying the FA by source IP address or CoA. Future implementation > > should follow the upcoming draft that identifies FA accurately and > solve both > > problems cleanly. Having any text that specifies to not add AE or ignore > > AE is more damaging than leaving issues as status quo to be dealt with > > later, IMHO. > > > > Kent > > > > At 10:39 AM 5/14/2004 -0500, Pete McCann wrote: > > > > >I'm ok with relaxing the MUST disregard to a MAY disregard; however, I > > >am not sure that adding FA NAI extension would turn this into a MUST > > >verify before processing de-registration. It seems like the HA would > > >always honor a valid de-registration request that passed end-to-end > > >replay protection, no matter what extensions or authenticators were > > >added by the FA. > > > > > >Maybe we need to take a more nuanced approach than all-or-nothing > > >success/failure. Maybe we should view the FHAE as protecting only the > > >extensions added by the FA, and possibly the care-of address owned by > > >that FA if the request has lifetime > 0. > > > > > >One thing we might be missing in all of the discussion on identifying > > >the FA: an important part of indexing a security association is not > > >just so that you can find it when you are checking an existing > > >authentication extension, but also so that you can detect when it is > > >missing in a message received from another entity. The FA NAI, by > > >itself, cannot be the only index key to the SA table, because we also > > >need to be able to discard messages (or ignore certain parts of > > >messages) that are not protected by an authentication extension when > > >they really should be, according to the IP source address / care-of > > >address. > > > > > >-Pete > > > > > >Henrik Levkowetz writes: > > > > Hi Sri, > > > > > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > > > Sure. We agreed not to hold the current draft and I'm not asking > for the > > > > > extension to be added to this draft. Sorry, if I was not clear on > > > that. My > > > > > only point is to change the "MUST" clause on HA behaviour with > > > respect to > > > > > the FHAE validation. The "Mobility Identity Extension" draft we > > > published > > > > > today can potentially address the FHAE issue ONLY if HA is not > forced to > > > > > ignore the FHAE validation in the above scenario. May be all I'm > > > asking is > > > > > to leave the above text with the "MAY" clause and that would not > > > have any > > > > > impact on the old FA scenarios. > > > > > > > > Ok, I see. My thoughts were that you could let the new draft amend > > > > 3344bis on this point, saying in effect something like this in the new > > > > draft: > > > > > > > > ...if the FA uses a FA identity extension to identify itself and its > > > > authentication extension, as described in this draft, and the HA > > > understands > > > > the FA identity extension, the HA no longer must disregard the > > > authentication > > > > extension from the FA as described in [3344bis], but on the contrary > > > SHOULD > > > > verify the FA authentication extension using the FA identidy from > the FA > > > > identity extension... > > > > > > > > Henrik > > > > > > > > -- > > > > Mip4 mailing list: Mip4@ietf.org > > > > Web interface: https://www.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://www.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://www.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://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 17 05:44:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10350 for ; Mon, 17 May 2004 05:44:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPea4-0007ki-C7 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 05:38:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H9cieB029800 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 05:38:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeYW-0007IV-9y for mip4-web-archive@optimus.ietf.org; Mon, 17 May 2004 05:37:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10109 for ; Mon, 17 May 2004 05:37:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPeYQ-00045R-5M for mip4-web-archive@ietf.org; Mon, 17 May 2004 05:37:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPeXQ-0003lo-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 05:36:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPeWv-0003Si-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 05:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeOn-00069Q-HR; Mon, 17 May 2004 05:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPeLh-0005jB-QD for mip4@optimus.ietf.org; Mon, 17 May 2004 05:23:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09434 for ; Mon, 17 May 2004 05:23:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPeLe-0007l2-FK for mip4@ietf.org; Mon, 17 May 2004 05:23:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPeKf-0007SM-00 for mip4@ietf.org; Mon, 17 May 2004 05:22:49 -0400 Received: from av5-2-sn3.vrr.skanova.net ([81.228.9.114]) by ietf-mx with esmtp (Exim 4.12) id 1BPeK5-00078C-00 for mip4@ietf.org; Mon, 17 May 2004 05:22:13 -0400 Received: by av5-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 6CD2637E79; Mon, 17 May 2004 11:21:43 +0200 (CEST) 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 5FD4637E43; Mon, 17 May 2004 11:21:43 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 9479C38003; Mon, 17 May 2004 11:21:42 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BPeJZ-0003Pw-00; Mon, 17 May 2004 11:21:41 +0200 Date: Mon, 17 May 2004 11:21:39 +0200 From: Henrik Levkowetz To: Kent Leung Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040517112139.264b22d6.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kent, Monday 17 May 2004, Kent Leung wrote: > >2. The end result of leaving things as they are for now is that an FA is > >able to block the deregistration of a CoA belonging to another FA - i.e. > >a CoA for which it has no authority. > > > Sorry, I just don't see that "FA is able to block ..". I see communications > between FA and HA that should be secured by FHAE, and the lack of > identifier of the source of message. FA is not deliberately trying to sabotage > the deregistration, just that we have not provided the capability to secure > the exchange. I'd like to explore this a bit more - when you say you don't see... above, do yoou mean that you don't agree that the current FA (behind NAT or sending from a different address than the CoA of the MN) under the current rules can make it impossible to de-register an earlier care-of address belonging to another FA - if there is a security association between the current FA and it inserts an FHAE in the message trying to de-register the old CoA? - or do you mean simply that you're not bothered by this ability to block the de-registration? > >Considering these points, could you suggest some alternative text, please? > > > >Or do you feel really strongly about not even mentioning the issue in > >3344bis? > > > There is a problem, but there's been agreement not to provide solution in > 3344bis. No, I don't think we have any clear agreement at all yet ;-) > I don't have problem with text describing issue. But if you feel > that it's sufficient just to provide description and no solution, then I can > propose some text. No, I personally don't think it's sufficient to just provide a description and no solution in 3344bis, but that wasn't so much the point I was getting at here... I think that we need to move forward, so if you object to a proposed text (and I don't claim the text I proposed was necessarily perfect ! :) it would be good if you could propose some alternative text. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 17 13:34:40 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07355 for ; Mon, 17 May 2004 13:34:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlqo-0006cJ-6Z for mip4-archive@odin.ietf.org; Mon, 17 May 2004 13:24:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HHOUO5025435 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 13:24:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlds-0004xX-6z for mip4-web-archive@optimus.ietf.org; Mon, 17 May 2004 13:11:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05911 for ; Mon, 17 May 2004 13:11:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPldq-0005cP-As for mip4-web-archive@ietf.org; Mon, 17 May 2004 13:11:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlcr-0005Gc-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 13:10:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPlbs-0004tS-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 13:09:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlWz-0003Pp-PX; Mon, 17 May 2004 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlHs-0001Te-0b for mip4@optimus.ietf.org; Mon, 17 May 2004 12:48:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04328 for ; Mon, 17 May 2004 12:48:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlHq-0005OG-B2 for mip4@ietf.org; Mon, 17 May 2004 12:48:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlGl-00051u-00 for mip4@ietf.org; Mon, 17 May 2004 12:47:16 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BPlFv-0004N2-00 for mip4@ietf.org; Mon, 17 May 2004 12:46:23 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4HGjig14560; Mon, 17 May 2004 12:45:44 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 May 2004 12:45:44 -0400 Message-ID: From: "Jayshree Bharatia" To: "'Henrik Levkowetz'" Cc: "'Charles E.Perkins'" , "'Mobile IPv4 Mailing List'" Subject: RE: [Mip4] New revision for rfc3344bis document Date: Mon, 17 May 2004 12:45:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43C2E.5BA36DB7" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C43C2E.5BA36DB7 Content-Type: text/plain Hello Henrik, That's fine. This change can go in the later version. Regards, Jayshree -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com] Sent: Saturday, May 15, 2004 2:47 AM To: Bharatia, Jayshree [RICH1:2H13:EXCH] Cc: 'Charles E.Perkins'; 'Mobile IPv4 Mailing List' Subject: Re: [Mip4] New revision for rfc3344bis document Hi Jayshree, Friday 14 May 2004, Jayshree Bharatia wrote: > Hello Charlie, > > We had some mailing list discussion earlier regarding issue 17 which > is related to the support of a nonzero unicast HA address (section > 3.8.3.2). I don't see those agreed changes in 3344bis draft. It will > be good if those changes are added to the draft. Would it be OK with you to continue this discussion without holding up the submission of this revision of 3344bis? We still don't have a -00 out there, so I'd really like to get this one posted so we have an updated baseline to work from. Henrik ------_=_NextPart_001_01C43C2E.5BA36DB7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] New revision for rfc3344bis document

Hello Henrik,

That's fine. This change can go in the later = version.

Regards,
Jayshree

-----Original Message-----
From: Henrik Levkowetz [mailto:henrik@levkowetz.com] =
Sent: Saturday, May 15, 2004 2:47 AM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]
Cc: 'Charles E.Perkins'; 'Mobile IPv4 Mailing = List'
Subject: Re: [Mip4] New revision for rfc3344bis = document


Hi Jayshree,

Friday 14 May 2004, Jayshree Bharatia wrote:
> Hello Charlie,
> 
> We had some mailing list discussion earlier = regarding issue 17 which
> is related to the support of a nonzero unicast = HA address (section
> 3.8.3.2). I don't see those agreed changes in = 3344bis draft. It will
> be good if those changes are added to the = draft.

Would it be OK with you to continue this discussion = without holding up the submission of this revision of 3344bis?  We = still don't have a -00 out there, so I'd really like to get this one = posted so we have an updated baseline to work from.

        Henrik

------_=_NextPart_001_01C43C2E.5BA36DB7-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 17 17:05:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27505 for ; Mon, 17 May 2004 17:05:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoHZ-0003UN-BO for mip4-archive@odin.ietf.org; Mon, 17 May 2004 16:00:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HK0Hca013412 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 16:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPo53-0007DE-Kw for mip4-web-archive@optimus.ietf.org; Mon, 17 May 2004 15:47:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19391 for ; Mon, 17 May 2004 15:47:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPo52-00075E-1j for mip4-web-archive@ietf.org; Mon, 17 May 2004 15:47:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPo3G-0006RL-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 15:45:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPo1d-0005oP-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 15:43:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnaz-0005ql-6C; Mon, 17 May 2004 15:16:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnFO-0005dz-HD for mip4@optimus.ietf.org; Mon, 17 May 2004 14:53:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14443 for ; Mon, 17 May 2004 14:53:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPnFL-0003Yl-NE for mip4@ietf.org; Mon, 17 May 2004 14:53:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnEG-00037d-00 for mip4@ietf.org; Mon, 17 May 2004 14:52:48 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BPnCy-0002MV-00 for mip4@ietf.org; Mon, 17 May 2004 14:51:28 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4HInG712067; Mon, 17 May 2004 11:49:16 -0700 X-mProtect: <200405171849> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141214.americas.nokia.com (172.18.141.214, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTmwyET; Mon, 17 May 2004 11:49:10 PDT Message-ID: <40A9046D.7080707@iprg.nokia.com> Date: Mon, 17 May 2004 11:29:01 -0700 From: Charlie P Organization: NOKIA User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz , Kent Leung CC: Pete McCann , Sri Gundavelli , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document References: <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.h In-Reply-To: <20040517112139.264b22d6.henrik@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, I agree that it's inappropriate to specify in rfc3344bis that one should "ignore" the FA-HA security association. And, yet, I think it's clear that the FA shouldn't be able to "invalidate" the mobile node's deregistration. I'd like to suggest a possible (perhaps temporary) resolution. What if we point out the problem in the specification, near the text preventing the invalidation, and specify that the inconsistency MUST be logged and alarmed at the home agent? I think it's clear that in this scenario something has gone wrong which cannot easily be fixed by protocol. Regards, Charlie P. I agree that it's inappropriate to specify in rfc3344bis that one should "ignore" the FA-HA security association. And, yet, I think it's clear that the Henrik Levkowetz wrote: >Hi Kent, > >Monday 17 May 2004, Kent Leung wrote: > > >>>2. The end result of leaving things as they are for now is that an FA is >>>able to block the deregistration of a CoA belonging to another FA - i.e. >>>a CoA for which it has no authority. >>> >>> >>Sorry, I just don't see that "FA is able to block ..". I see communications >>between FA and HA that should be secured by FHAE, and the lack of >>identifier of the source of message. FA is not deliberately trying to sabotage >>the deregistration, just that we have not provided the capability to secure >>the exchange. >> >> > >I'd like to explore this a bit more - when you say you don't see... above, >do yoou mean that you don't agree that the current FA (behind NAT or >sending from a different address than the CoA of the MN) under the >current rules can make it impossible to de-register an earlier care-of >address belonging to another FA - if there is a security association >between the current FA and it inserts an FHAE in the message trying to >de-register the old CoA? > >- or do you mean simply that you're not bothered by this ability to block >the de-registration? > > > > >>>Considering these points, could you suggest some alternative text, please? >>> >>>Or do you feel really strongly about not even mentioning the issue in >>>3344bis? >>> >>> >>There is a problem, but there's been agreement not to provide solution in >>3344bis. >> >> > >No, I don't think we have any clear agreement at all yet ;-) > > > >>I don't have problem with text describing issue. But if you feel >>that it's sufficient just to provide description and no solution, then I can >>propose some text. >> >> > >No, I personally don't think it's sufficient to just provide a description >and no solution in 3344bis, but that wasn't so much the point I was getting >at here... > >I think that we need to move forward, so if you object to a proposed text >(and I don't claim the text I proposed was necessarily perfect ! :) it >would be good if you could propose some alternative text. > > > Henrik > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 17 18:18:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08291 for ; Mon, 17 May 2004 18:18:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPqAV-0002R3-MA for mip4-archive@odin.ietf.org; Mon, 17 May 2004 18:01:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HM15Ft009337 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 18:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPq2T-0004gV-Vv for mip4-web-archive@optimus.ietf.org; Mon, 17 May 2004 17:52:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05019 for ; Mon, 17 May 2004 17:52:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPq2R-00011B-Dg for mip4-web-archive@ietf.org; Mon, 17 May 2004 17:52:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPpzR-0007jA-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 17:49:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPpuT-0006Kl-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 17:44:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpjc-0002NR-C5; Mon, 17 May 2004 17:33:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPp4c-00088i-ST for mip4@optimus.ietf.org; Mon, 17 May 2004 16:50:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25763 for ; Mon, 17 May 2004 16:50:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPp4a-0007ZY-NY for mip4@ietf.org; Mon, 17 May 2004 16:50:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPozK-0006Al-00 for mip4@ietf.org; Mon, 17 May 2004 16:45:33 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BPovk-00053M-00 for mip4@ietf.org; Mon, 17 May 2004 16:41:49 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BPogG-0000wo-MN for mip4@ietf.org; Mon, 17 May 2004 16:25:48 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4HKOYV12350; Mon, 17 May 2004 15:24:35 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i4HKOXC02782; Mon, 17 May 2004 15:24:33 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HXVKOG-0001KC-00; Mon, 17 May 2004 16:24:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16553.8057.88121.752707@gargle.gargle.HOWL> Date: Mon, 17 May 2004 15:24:25 -0500 From: Pete McCann To: Kent Leung Cc: Henrik Levkowetz , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document In-Reply-To: <4.3.2.7.2.20040516230344.02eebdd8@mira-sjcm-2.cisco.com> References: <20040515094408.5844e41c.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516230344.02eebdd8@mira-sjcm-2.cisco.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Kent, Kent Leung writes: > Hi Pete. Comments below. > > At 12:04 AM 5/17/2004 -0500, Pete McCann wrote: > > >Hi, Kent, > > > >Yes, I can see how special-casing the FHAE would be difficult in most > >implementations. > > > >However, I agree with Henrik & others that there is a subtle problem > >here, and now I don't think it can be fixed with an FA NAI, due to the > >missing auth extension detection problem. If attackers would just > >cooperate and set the "evil" bit in the packet headers our job would > >be a lot easier. > > > >Reading your mail, I think you are suggesting to index the SA by > >*both* FA source IP address and FA COA. Is that explicit in the > >current draft? If not, it should be. > > > It is not explicit as far as I'm aware of. Exactly how the FA is identified > is not clearly defined. I've always assumed both fields are used since > CoA was not always the right identity for FA. In fact, I think the source IP address has to be the main identifier. That is how all the other SAs work and it would be consistent with your "flat" definition of a Mobile IP SA. At best, the CoA is just an auxiliary piece of information that we may or may not keep as part of the SA, as something that the FA may be authorized to use from the HA's perspective. > >We may have slightly differing views on the current problem we are > >trying to solve. Let me try to state it a couple of different ways > >and see if you agree: > > > >* An MN is trying to de-register an old care-of address through an FA > > that is behind a NAT. The FA thinks it has an SA with an HA, so > > appends FHAE. Unfortunately, the HA can't find it due to the NAT > > and so drops the message. > > > >Now, it seems that FA NAI would fix this problem. > > > Yes. > > > >However, let me state another problem: > > > >* An MN is trying to de-register an old care-of address through an > > FA that is behind a NAT. The FA doesn't have an SA with an HA, so > > does not append FHAE. Unfortunately, the HA looks at the COA in > > the message, realizes that it has an SA with the old FA, and so > > drops the message. Note that source IP address is not useful > > for identifying the FA because of the NAT. > > > But, FA should be appending the FA NAI ext to identify itself since the > CoA nor the source IP address is insufficient. This new extension is > providing identity for source endpoint of the message and allow the > receiver side to detect if NAT occurred, SA checked, and any future > operations needed. So I think you are saying that 3519 is just broken until we have the FA NAI extension. In fact, we would need a 3519-bis that *required* the NAI extension and *required* HAs to drop registration requests that appear to be NAT-related but which don't contain the extension. > >Now, it seems like FA NAI would not fix this problem, because there is > >no way to tell whether or not an un-authenticated NAI was inserted by > >an attacker after stripping out the real NAI/authenticator extensions. > > Hmm, not totally clear about this scenario. Are you saying that the > attacker can modify fields in the message in transit to cause failed > authentication? But it would be easier just to change one bit anywhere > before the MHAE? I am worried about a situation where FAs that support the FA NAI and nodes that do not co-exist in the network. There is no way in general for the HA to tell whether it is talking to an old FA with which it doesn't have an SA or a new FA with which it does but where an attacker has stripped off the FA NAI + authentication extension. It should process the request in the first case but drop it in the second. How does it know? > As for how to avoid un-authenticated FA NAI, one method is to advertise > this identity to the MN so it gets protected by the MHAE? This can be > dealt with in the new draft. That might help, and avoids the problem of an attacker stripping it off after the RRQ is generated. But, I'm not sure it is a cure-all... > >So, it seems like we at least will end up needing special rules for > >how to index the SA in the case of de-registration. That is, we might > >look for SAs based on source IP address, COA, and/or FA NAI in the > >case of registrations, but with de-registrations, we can't use the > >COA. We might still be able to use the other two items. > > I think we can have consistency for registration and de-registration by having > the FA to always insert the FA NAI in the message when the source IP > address or CoA is insufficient. The FHAE is appended only if FA has an SA > with the HA. The HA will know which FA is the sender and act in a clear > manner to process the message. But do we allow existing 3344-compliant FAs to exist in this universe? If so, we need to keep the old rules for identifying SAs based on FA source IP address. > As for logic for determining when CoA is insufficient, either when FA is behind > NAT (source IP address will be translated), or CoA in message is not advertised > by FA or match FA's identity, comes to mind... Are you speaking about logic on the FA or the HA? I think the logic on the FA is easy: if you support FA NAI, then always include it. Logic on the HA is more difficult, as I believe the mechanisms for detecting NAT in 3519 are themselves not always 100% reliable (but maybe someone more familiar with the draft can comment). -Pete > Kent > > >Is that accurate? > > > >-Pete > > > > > >Henrik Levkowetz writes: > > > Hi Kent, > > > > > > I'm not adverse to your reasoning here. However, two points: > > > > > > 1. If we say nothing about this in 3344bis, then we still have the basic > > > issue unsolved, and no indication that it even exist, in 3344bis. > > > > > > 2. The end result of leaving things as they are for now is that an FA is > > > able to block the deregistration of a CoA belonging to another FA - i.e. > > > a CoA for which it has no authority. > > > > > > Considering these points, could you suggest some alternative text, please? > > > > > > Or do you feel really strongly about not even mentioning the issue in > > > 3344bis? > > > > > > Henrik > > > > > > Friday 14 May 2004, Kent Leung wrote: > > > > I believe that no security association between peers should be > > compromised. > > > > Maybe I missed it, but don't remember any consensus to put such text > > > > to disregard Authentication Extension. Actually, I think there was some > > > > agreement that FHAE (or any AEs for that matter) should not be > > > > simply ignored. (I know I've been vocal in my disagreement about > > > > ignoring FHAE - sorry AEs should not have special cases for handling; > > > > either one is trying to secure or not. :) > > > > > > > > See Issue #44 Comment #149: > > > > >I think your response last week convinced me that ignoring the R > > > > >bit is not a good idea, and I agree that the HA should check the FHAE, > > > > >if it is present, and discard the message if it doesn't check. > > > > > > > > RFC 3344bis should probably not mandate changes to current > > > > implementations. Thought there was already agreement that Mobility > > > > Entity Identify extension is needed for accurate identification, > > which is > > > > the root cause of issues #44 and #45. So that would > > > > solve the problem cleanly and not bypass any security associations > > > > which are set up by administrators. And there was agreement that > > > > another draft will handle this. > > > > > > > > See Issue #44 Comment #149: > > > > >If someone wants to put together a new document on Mobility Agent > > > > >Identifier extensions I think that would be a good idea. > > > > > > > > See Issue #44, Comment #142: > > > > >Your argument below is persuasive. It seems to me this would be a > > > > >fairly clean solution which leaves 3344 as flexible as today, improves > > > > >NAT traversal and solves the deregistration FHAE problem. > > > > > > > > In addition, I would expect that any messages received without proper > > > > AEs would be discarded. For example, the source IP address or CoA > > > > that matches an FA SA in a message that does not contain FHAE > > > > would be discarded by the HA for failing authentication. With the new > > > > draft, the Mobility Entitiy Identifer would be used to index an FA SA. > > > > > > > > In summary, I propose removing any text related to the issue in > > > > RFC3344bis because current implementation is right in terms of > > > > identifying the FA by source IP address or CoA. Future implementation > > > > should follow the upcoming draft that identifies FA accurately and > > solve both > > > > problems cleanly. Having any text that specifies to not add AE or > > ignore > > > > AE is more damaging than leaving issues as status quo to be dealt with > > > > later, IMHO. > > > > > > > > Kent > > > > > > > > At 10:39 AM 5/14/2004 -0500, Pete McCann wrote: > > > > > > > > >I'm ok with relaxing the MUST disregard to a MAY disregard; however, I > > > > >am not sure that adding FA NAI extension would turn this into a MUST > > > > >verify before processing de-registration. It seems like the HA would > > > > >always honor a valid de-registration request that passed end-to-end > > > > >replay protection, no matter what extensions or authenticators were > > > > >added by the FA. > > > > > > > > > >Maybe we need to take a more nuanced approach than all-or-nothing > > > > >success/failure. Maybe we should view the FHAE as protecting only the > > > > >extensions added by the FA, and possibly the care-of address owned by > > > > >that FA if the request has lifetime > 0. > > > > > > > > > >One thing we might be missing in all of the discussion on identifying > > > > >the FA: an important part of indexing a security association is not > > > > >just so that you can find it when you are checking an existing > > > > >authentication extension, but also so that you can detect when it is > > > > >missing in a message received from another entity. The FA NAI, by > > > > >itself, cannot be the only index key to the SA table, because we also > > > > >need to be able to discard messages (or ignore certain parts of > > > > >messages) that are not protected by an authentication extension when > > > > >they really should be, according to the IP source address / care-of > > > > >address. > > > > > > > > > >-Pete > > > > > > > > > >Henrik Levkowetz writes: > > > > > > Hi Sri, > > > > > > > > > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > > > > > Sure. We agreed not to hold the current draft and I'm not > > asking for the > > > > > > > extension to be added to this draft. Sorry, if I was not > > clear on > > > > > that. My > > > > > > > only point is to change the "MUST" clause on HA behaviour with > > > > > respect to > > > > > > > the FHAE validation. The "Mobility Identity Extension" draft we > > > > > published > > > > > > > today can potentially address the FHAE issue ONLY if HA is > > not forced to > > > > > > > ignore the FHAE validation in the above scenario. May be all I'm > > > > > asking is > > > > > > > to leave the above text with the "MAY" clause and that would not > > > > > have any > > > > > > > impact on the old FA scenarios. > > > > > > > > > > > > Ok, I see. My thoughts were that you could let the new draft amend > > > > > > 3344bis on this point, saying in effect something like this in > > the new > > > > > > draft: > > > > > > > > > > > > ...if the FA uses a FA identity extension to identify itself > > and its > > > > > > authentication extension, as described in this draft, and the HA > > > > > understands > > > > > > the FA identity extension, the HA no longer must disregard the > > > > > authentication > > > > > > extension from the FA as described in [3344bis], but on the > > contrary > > > > > SHOULD > > > > > > verify the FA authentication extension using the FA identidy > > from the FA > > > > > > identity extension... > > > > > > > > > > > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 17 19:37:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13283 for ; Mon, 17 May 2004 19:37:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPrWT-0007Il-RK for mip4-archive@odin.ietf.org; Mon, 17 May 2004 19:27:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HNRr7p028067 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 19:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPrQR-00051P-15 for mip4-web-archive@optimus.ietf.org; Mon, 17 May 2004 19:21:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12471 for ; Mon, 17 May 2004 19:21:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPrQP-0001gi-G4 for mip4-web-archive@ietf.org; Mon, 17 May 2004 19:21:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPrPM-0001LC-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 19:20:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPrOt-000107-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 19:20:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPr6V-0006T2-2Q; Mon, 17 May 2004 19:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPqri-0000dy-3M for mip4@optimus.ietf.org; Mon, 17 May 2004 18:45:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10874 for ; Mon, 17 May 2004 18:45:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPqre-00050f-Rn for mip4@ietf.org; Mon, 17 May 2004 18:45:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPqqc-0004eY-00 for mip4@ietf.org; Mon, 17 May 2004 18:44:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BPqq3-0004GS-00 for mip4@ietf.org; Mon, 17 May 2004 18:44:03 -0400 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 i4HMhVW9008869; Mon, 17 May 2004 15:43:31 -0700 (PDT) Received: from kleung-w2k01.cisco.com ([128.107.176.164]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATG43989; Mon, 17 May 2004 15:42:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 May 2004 15:43:55 -0700 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List In-Reply-To: <20040517112139.264b22d6.henrik@levkowetz.com> References: <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi Henrik. At 11:21 AM 5/17/2004 +0200, Henrik Levkowetz wrote: >[snip] > >I'd like to explore this a bit more - when you say you don't see... above, >do yoou mean that you don't agree that the current FA (behind NAT or >sending from a different address than the CoA of the MN) under the >current rules can make it impossible to de-register an earlier care-of >address belonging to another FA - if there is a security association >between the current FA and it inserts an FHAE in the message trying to >de-register the old CoA? > >- or do you mean simply that you're not bothered by this ability to block >the de-registration? I sensed that some folks see that the current FA is blocking the RRQ. So just pointing out that FA is doing its job of securing the message to the HA and we need to define a solution to achieve that properly. > > >Considering these points, could you suggest some alternative text, please? > > > > > >Or do you feel really strongly about not even mentioning the issue in > > >3344bis? > > > > > > There is a problem, but there's been agreement not to provide solution in > > 3344bis. > >No, I don't think we have any clear agreement at all yet ;-) If we can provide a solution in 3344bis, then we can state that Mobility Entity Identifier extension is used to unambiguously determine the peer. > > I don't have problem with text describing issue. But if you feel > > that it's sufficient just to provide description and no solution, then > I can > > propose some text. > >No, I personally don't think it's sufficient to just provide a description >and no solution in 3344bis, but that wasn't so much the point I was getting >at here... > >I think that we need to move forward, so if you object to a proposed text >(and I don't claim the text I proposed was necessarily perfect ! :) it >would be good if you could propose some alternative text. I'm not sure if the following text is something you're looking for? The original text: A deregistration which is passed through a foreign agent which is different from the the one whose care-of address is being deregistered MAY add a Foreign-Home Authentication Extension to such a deregistration. However, as this deregistration concerns a different foreign agent than the one whose authentication extension, the home agent MUST disregard the Foreign-Home Authentication Extension of such a deregistration. The remaining validity checks, as described in Section 3.8.2.1, are required in full. Proposed text: The home agent needs to clearly identify the foreign agent that sent the Registration Request for authentication. This requires the foreign agent to append an extension containing its identity when the Care-of Address and source IP address in the message do not provide accurate foreign agent identification to the home agent. However, this extension may be appended indiscriminantly by the foreign agent to avoid un-ambiguity for any condition. The remaining validity checks, as described in Section 3.8.2.1, are required in full. (I've not named the extension as Mobility Entity Identifer type for now) Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 17 19:53:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14472 for ; Mon, 17 May 2004 19:53:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPrtV-0007Mi-Cu for mip4-archive@odin.ietf.org; Mon, 17 May 2004 19:51:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HNpfWG028313 for mip4-archive@odin.ietf.org; Mon, 17 May 2004 19:51:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BProo-0005gz-7u for mip4-web-archive@optimus.ietf.org; Mon, 17 May 2004 19:46:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13931 for ; Mon, 17 May 2004 19:46:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BProm-0002vY-FB for mip4-web-archive@ietf.org; Mon, 17 May 2004 19:46:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPrnm-0002YO-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 19:45:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPrnD-0002Bj-00 for mip4-web-archive@ietf.org; Mon, 17 May 2004 19:45:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPriE-0003H9-CU; Mon, 17 May 2004 19:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPrb0-0008QM-Ti for mip4@optimus.ietf.org; Mon, 17 May 2004 19:32:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13088 for ; Mon, 17 May 2004 19:32:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPraz-0005f0-B0 for mip4@ietf.org; Mon, 17 May 2004 19:32:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPra0-0005Hz-00 for mip4@ietf.org; Mon, 17 May 2004 19:31:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BPrZ9-0004YB-00 for mip4@ietf.org; Mon, 17 May 2004 19:30:39 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 May 2004 15:37:17 +0000 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 i4HNU7Su012235; Mon, 17 May 2004 16:30:08 -0700 (PDT) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-120.cisco.com [128.107.163.120]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATG48779; Mon, 17 May 2004 16:29:20 -0700 (PDT) Message-Id: <4.3.2.7.2.20040517161102.030d4e78@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 May 2004 16:30:37 -0700 To: Pete McCann From: Kent Leung Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Cc: Henrik Levkowetz , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List In-Reply-To: <16553.8057.88121.752707@gargle.gargle.HOWL> References: <4.3.2.7.2.20040516230344.02eebdd8@mira-sjcm-2.cisco.com> <20040515094408.5844e41c.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516230344.02eebdd8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Hi Pete. My take is that HA and FA need to identify the source of the message for authentication. The identification may be the Mobility Entity Identifer, source IP address, or Care-of Address. Once authenticated, the message is processed in accordance to RFC 3344 and 3519. I think we should move fast in the WG to come to consensus on having a Mobility Entity Identifier extension to fix the problem. We may not run into this problem since FHAE is not common unless within CDMA2000 network. But in that case, the NAT box is not usually between the FA and HA. I agree to move forward to closure on this issue. Kent At 03:24 PM 5/17/2004 -0500, Pete McCann wrote: >Hi, Kent, > >Kent Leung writes: > > Hi Pete. Comments below. > > > > At 12:04 AM 5/17/2004 -0500, Pete McCann wrote: > > > > >Hi, Kent, > > > > > >Yes, I can see how special-casing the FHAE would be difficult in most > > >implementations. > > > > > >However, I agree with Henrik & others that there is a subtle problem > > >here, and now I don't think it can be fixed with an FA NAI, due to the > > >missing auth extension detection problem. If attackers would just > > >cooperate and set the "evil" bit in the packet headers our job would > > >be a lot easier. > > > > > >Reading your mail, I think you are suggesting to index the SA by > > >*both* FA source IP address and FA COA. Is that explicit in the > > >current draft? If not, it should be. > > > > > > It is not explicit as far as I'm aware of. Exactly how the FA is > identified > > is not clearly defined. I've always assumed both fields are used since > > CoA was not always the right identity for FA. > >In fact, I think the source IP address has to be the main identifier. >That is how all the other SAs work and it would be consistent with >your "flat" definition of a Mobile IP SA. At best, the CoA is just an >auxiliary piece of information that we may or may not keep as part of >the SA, as something that the FA may be authorized to use from the >HA's perspective. > > > >We may have slightly differing views on the current problem we are > > >trying to solve. Let me try to state it a couple of different ways > > >and see if you agree: > > > > > >* An MN is trying to de-register an old care-of address through an FA > > > that is behind a NAT. The FA thinks it has an SA with an HA, so > > > appends FHAE. Unfortunately, the HA can't find it due to the NAT > > > and so drops the message. > > > > > >Now, it seems that FA NAI would fix this problem. > > > > > > Yes. > > > > > > >However, let me state another problem: > > > > > >* An MN is trying to de-register an old care-of address through an > > > FA that is behind a NAT. The FA doesn't have an SA with an HA, so > > > does not append FHAE. Unfortunately, the HA looks at the COA in > > > the message, realizes that it has an SA with the old FA, and so > > > drops the message. Note that source IP address is not useful > > > for identifying the FA because of the NAT. > > > > > > But, FA should be appending the FA NAI ext to identify itself since the > > CoA nor the source IP address is insufficient. This new extension is > > providing identity for source endpoint of the message and allow the > > receiver side to detect if NAT occurred, SA checked, and any future > > operations needed. > >So I think you are saying that 3519 is just broken until we have the >FA NAI extension. In fact, we would need a 3519-bis that *required* >the NAI extension and *required* HAs to drop registration requests that >appear to be NAT-related but which don't contain the extension. > > > >Now, it seems like FA NAI would not fix this problem, because there is > > >no way to tell whether or not an un-authenticated NAI was inserted by > > >an attacker after stripping out the real NAI/authenticator extensions. > > > > Hmm, not totally clear about this scenario. Are you saying that the > > attacker can modify fields in the message in transit to cause failed > > authentication? But it would be easier just to change one bit anywhere > > before the MHAE? > >I am worried about a situation where FAs that support the FA NAI and >nodes that do not co-exist in the network. There is no way in general >for the HA to tell whether it is talking to an old FA with which it >doesn't have an SA or a new FA with which it does but where an >attacker has stripped off the FA NAI + authentication extension. >It should process the request in the first case but drop it in the >second. How does it know? > > > As for how to avoid un-authenticated FA NAI, one method is to advertise > > this identity to the MN so it gets protected by the MHAE? This can be > > dealt with in the new draft. > >That might help, and avoids the problem of an attacker stripping it >off after the RRQ is generated. But, I'm not sure it is a cure-all... > > > >So, it seems like we at least will end up needing special rules for > > >how to index the SA in the case of de-registration. That is, we might > > >look for SAs based on source IP address, COA, and/or FA NAI in the > > >case of registrations, but with de-registrations, we can't use the > > >COA. We might still be able to use the other two items. > > > > I think we can have consistency for registration and de-registration > by having > > the FA to always insert the FA NAI in the message when the source IP > > address or CoA is insufficient. The FHAE is appended only if FA has an SA > > with the HA. The HA will know which FA is the sender and act in a clear > > manner to process the message. > >But do we allow existing 3344-compliant FAs to exist in this universe? >If so, we need to keep the old rules for identifying SAs based on FA >source IP address. > > > As for logic for determining when CoA is insufficient, either when FA > is behind > > NAT (source IP address will be translated), or CoA in message is not > advertised > > by FA or match FA's identity, comes to mind... > >Are you speaking about logic on the FA or the HA? I think the logic >on the FA is easy: if you support FA NAI, then always include it. >Logic on the HA is more difficult, as I believe the mechanisms for >detecting NAT in 3519 are themselves not always 100% reliable (but >maybe someone more familiar with the draft can comment). > >-Pete > > > Kent > > > > >Is that accurate? > > > > > >-Pete > > > > > > > > >Henrik Levkowetz writes: > > > > Hi Kent, > > > > > > > > I'm not adverse to your reasoning here. However, two points: > > > > > > > > 1. If we say nothing about this in 3344bis, then we still have > the basic > > > > issue unsolved, and no indication that it even exist, in 3344bis. > > > > > > > > 2. The end result of leaving things as they are for now is that > an FA is > > > > able to block the deregistration of a CoA belonging to another FA > - i.e. > > > > a CoA for which it has no authority. > > > > > > > > Considering these points, could you suggest some alternative > text, please? > > > > > > > > Or do you feel really strongly about not even mentioning the issue in > > > > 3344bis? > > > > > > > > Henrik > > > > > > > > Friday 14 May 2004, Kent Leung wrote: > > > > > I believe that no security association between peers should be > > > compromised. > > > > > Maybe I missed it, but don't remember any consensus to put such > text > > > > > to disregard Authentication Extension. Actually, I think there > was some > > > > > agreement that FHAE (or any AEs for that matter) should not be > > > > > simply ignored. (I know I've been vocal in my disagreement about > > > > > ignoring FHAE - sorry AEs should not have special cases for > handling; > > > > > either one is trying to secure or not. :) > > > > > > > > > > See Issue #44 Comment #149: > > > > > >I think your response last week convinced me that ignoring the R > > > > > >bit is not a good idea, and I agree that the HA should check > the FHAE, > > > > > >if it is present, and discard the message if it doesn't check. > > > > > > > > > > RFC 3344bis should probably not mandate changes to current > > > > > implementations. Thought there was already agreement that Mobility > > > > > Entity Identify extension is needed for accurate identification, > > > which is > > > > > the root cause of issues #44 and #45. So that would > > > > > solve the problem cleanly and not bypass any security associations > > > > > which are set up by administrators. And there was agreement that > > > > > another draft will handle this. > > > > > > > > > > See Issue #44 Comment #149: > > > > > >If someone wants to put together a new document on Mobility Agent > > > > > >Identifier extensions I think that would be a good idea. > > > > > > > > > > See Issue #44, Comment #142: > > > > > >Your argument below is persuasive. It seems to me this would be a > > > > > >fairly clean solution which leaves 3344 as flexible as today, > improves > > > > > >NAT traversal and solves the deregistration FHAE problem. > > > > > > > > > > In addition, I would expect that any messages received without > proper > > > > > AEs would be discarded. For example, the source IP address or CoA > > > > > that matches an FA SA in a message that does not contain FHAE > > > > > would be discarded by the HA for failing authentication. With > the new > > > > > draft, the Mobility Entitiy Identifer would be used to index an > FA SA. > > > > > > > > > > In summary, I propose removing any text related to the issue in > > > > > RFC3344bis because current implementation is right in terms of > > > > > identifying the FA by source IP address or CoA. Future > implementation > > > > > should follow the upcoming draft that identifies FA accurately and > > > solve both > > > > > problems cleanly. Having any text that specifies to not add AE or > > > ignore > > > > > AE is more damaging than leaving issues as status quo to be > dealt with > > > > > later, IMHO. > > > > > > > > > > Kent > > > > > > > > > > At 10:39 AM 5/14/2004 -0500, Pete McCann wrote: > > > > > > > > > > >I'm ok with relaxing the MUST disregard to a MAY disregard; > however, I > > > > > >am not sure that adding FA NAI extension would turn this into > a MUST > > > > > >verify before processing de-registration. It seems like the > HA would > > > > > >always honor a valid de-registration request that passed > end-to-end > > > > > >replay protection, no matter what extensions or authenticators > were > > > > > >added by the FA. > > > > > > > > > > > >Maybe we need to take a more nuanced approach than all-or-nothing > > > > > >success/failure. Maybe we should view the FHAE as protecting > only the > > > > > >extensions added by the FA, and possibly the care-of address > owned by > > > > > >that FA if the request has lifetime > 0. > > > > > > > > > > > >One thing we might be missing in all of the discussion on > identifying > > > > > >the FA: an important part of indexing a security association > is not > > > > > >just so that you can find it when you are checking an existing > > > > > >authentication extension, but also so that you can detect when > it is > > > > > >missing in a message received from another entity. The FA NAI, by > > > > > >itself, cannot be the only index key to the SA table, because > we also > > > > > >need to be able to discard messages (or ignore certain parts of > > > > > >messages) that are not protected by an authentication > extension when > > > > > >they really should be, according to the IP source address / > care-of > > > > > >address. > > > > > > > > > > > >-Pete > > > > > > > > > > > >Henrik Levkowetz writes: > > > > > > > Hi Sri, > > > > > > > > > > > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > > > > > > Sure. We agreed not to hold the current draft and I'm not > > > asking for the > > > > > > > > extension to be added to this draft. Sorry, if I was not > > > clear on > > > > > > that. My > > > > > > > > only point is to change the "MUST" clause on HA > behaviour with > > > > > > respect to > > > > > > > > the FHAE validation. The "Mobility Identity Extension" > draft we > > > > > > published > > > > > > > > today can potentially address the FHAE issue ONLY if HA is > > > not forced to > > > > > > > > ignore the FHAE validation in the above scenario. May be > all I'm > > > > > > asking is > > > > > > > > to leave the above text with the "MAY" clause and that > would not > > > > > > have any > > > > > > > > impact on the old FA scenarios. > > > > > > > > > > > > > > Ok, I see. My thoughts were that you could let the new > draft amend > > > > > > > 3344bis on this point, saying in effect something like > this in > > > the new > > > > > > > draft: > > > > > > > > > > > > > > ...if the FA uses a FA identity extension to identify itself > > > and its > > > > > > > authentication extension, as described in this draft, and > the HA > > > > > > understands > > > > > > > the FA identity extension, the HA no longer must disregard the > > > > > > authentication > > > > > > > extension from the FA as described in [3344bis], but on the > > > contrary > > > > > > SHOULD > > > > > > > verify the FA authentication extension using the FA identidy > > > from the FA > > > > > > > identity extension... > > > > > > > > > > > > > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 15:04:25 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06038 for ; Tue, 18 May 2004 15:04:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9o8-0005Zp-W2 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 14:59:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IIxKlh021438 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 14:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9iC-0004ks-TB for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 14:53:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05396 for ; Tue, 18 May 2004 14:53:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9iA-0006zQ-3p for mip4-web-archive@ietf.org; Tue, 18 May 2004 14:53:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9hJ-0006wu-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 14:52:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9gm-0006tn-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 14:51:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9aH-0003RV-JI; Tue, 18 May 2004 14:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9Rd-0001oE-0g for mip4@optimus.ietf.org; Tue, 18 May 2004 14:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04357 for ; Tue, 18 May 2004 14:36:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9Ra-0005sk-89 for mip4@ietf.org; Tue, 18 May 2004 14:36:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9Qh-0005pq-00 for mip4@ietf.org; Tue, 18 May 2004 14:35:07 -0400 Received: from av5-2-sn3.vrr.skanova.net ([81.228.9.114]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9Pr-0005m2-00 for mip4@ietf.org; Tue, 18 May 2004 14:34:15 -0400 Received: by av5-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 731BB37F25; Tue, 18 May 2004 20:33:44 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av5-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 65BBF37F21; Tue, 18 May 2004 20:33:44 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 6FD8438005; Tue, 18 May 2004 20:33:43 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BQ9PK-00040g-00; Tue, 18 May 2004 20:33:42 +0200 Date: Tue, 18 May 2004 20:33:41 +0200 From: Henrik Levkowetz To: Kent Leung Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040518203341.744606c8.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kent, Monday 17 May 2004, Kent Leung wrote: > Hi Henrik. > > At 11:21 AM 5/17/2004 +0200, Henrik Levkowetz wrote: > >[snip] > > > >I'd like to explore this a bit more - when you say you don't see... above, > >do yoou mean that you don't agree that the current FA (behind NAT or > >sending from a different address than the CoA of the MN) under the > >current rules can make it impossible to de-register an earlier care-of > >address belonging to another FA - if there is a security association > >between the current FA and it inserts an FHAE in the message trying to > >de-register the old CoA? > > > >- or do you mean simply that you're not bothered by this ability to block > >the de-registration? > > > I sensed that some folks see that the current FA is blocking the RRQ. So > just pointing out that FA is doing its job of securing the message to the HA > and we need to define a solution to achieve that properly. Yes. I think we have a small though basic disagreement on one point - I see the purpose of the FA using a FHAE as validating and authenticating the parts of any registration exchange which concerns *that FA*. If there is a question of using its resources, it must authenticate that usage. However, how do we handle messages from the MN which in no way concern this FA? I've been considering various options which haven't been mentioned so far, to my knowledge, like for instance requireing the FA to look at deregistration messages, and if they concern a CoA which is not its own, to not sign them. But this seems still not quite right to me. Let me test yet another one on you: The de-registration message in question could just as well have been sent by the MN from any other address, as long as it's covered by a valid MN-HA Auth. Ext. Is there any reason why the MN couldn't send this package as *data traffic* to the HA, which would de-tunnel it, and route it to itself? Then the FA (quite rightly) wouldn't see it as a registration request concerning itself, to be protected with it's FHAE... Maybe I'm getting to wild here, but I keep returning to this idea that the deregistration we're talking about really concerns nobody but the MN and the HA, and could have been sent from any point really, not necessarily from this particular FA. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 15:18:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07989 for ; Tue, 18 May 2004 15:18:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQA46-0003Sl-9o for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:15:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJFoxe013298 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9v1-0003dr-PG for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:06:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06280 for ; Tue, 18 May 2004 15:06:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9uy-0007gV-Pb for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:06:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9u2-0007cx-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:05:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9ta-0007a7-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:04:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9ov-0005g8-NK; Tue, 18 May 2004 15:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9h8-0004f5-5c for mip4@optimus.ietf.org; Tue, 18 May 2004 14:52:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05301 for ; Tue, 18 May 2004 14:52:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9h5-0006un-9B for mip4@ietf.org; Tue, 18 May 2004 14:52:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9gA-0006pH-00 for mip4@ietf.org; Tue, 18 May 2004 14:51:07 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ9fG-0006hJ-00 for mip4@ietf.org; Tue, 18 May 2004 14:50:10 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4IInZq17260 for ; Tue, 18 May 2004 13:49:36 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i4IInYI09882; Tue, 18 May 2004 13:49:35 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HXXAY5-0001QO-00 for mip4@ietf.org; Tue, 18 May 2004 14:49:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16554.23223.66121.836847@gargle.gargle.HOWL> Date: Tue, 18 May 2004 13:49:27 -0500 From: Pete McCann To: Mobile IPv4 Mailing List X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Subject: [Mip4] AD review comments on advance draft-ietf-mobileip-lowlatency-handoffs-v4-08.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, We received the following AD review comments from Thomas Narten on draft-ietf-mobileip-lowlatency-handoffs-v4-08.txt. We have asked the editor (Karim El Malki) to prepare a new revision in response. If anyone has comments on the comments or suggested text for Karim (I'm sure he'd appreciate it) please send it to the list. -Pet ----------------------- IANA considerations needs work. I suspect that IANA will not understand what needs to be done here. E.g., try the following thought experiment: ask someone outside of the WG to read the section and can they identify the name spaces and possible values that could be used). Be more clear. Say specifically what is being requested, i.e, naming the name space and citing where it is defined, etc. Look at RFC 3543 or 3519 for examples. Security considerations needs work. At a minimum, the text about "use ESP" seems insufficient (see security AD comments in ID tracke for draft-ietf-seamoby-card-protocol for starters - I suspect the same point applies to this document.) THe security analysis as a whole seems pretty weak, and in reading it, I didn't get a sense that the security issues were well-understood. E.g., seems like a lot of the security properties depend on L2 security, of which there is no discussion. I.e., has a detailed analysis in the context of a specific LL type been done? Could it be done? Editorial: > aFA - anchor Foreign Agent, the FA that is currently handling > the network end of the BET in POST-REGISTRATION. Pleas expand acronyms on first use. > The Registration MAY be transmitted more than once to reduce the > probability that it is lost due to errors on the wireless link. seems like MAY need to be a SHOULD/MUST, if this protocol is going to be robust... > since it is unnecessary for a secured unicast message. The ICMP > solicitations and advertisements MUST be authenticated. These > messages MUST be protected using ESP [10] to prevent attacks. An FA > MUST NOT accept ICMP solicitations or advertisements from sources > which are not authenticated. Which transforms specifically? > issues the Registration Request. Therefore the > MIN_SOLICITATION_INTERVAL in oFA MUST be set to a value equal to (0.5 > * nFA's CHALLENGE_WINDOW * nFA's Agent advertisement interval). The > CHALLENGE_WINDOW and Agent advertisement interval are defined in [7] > and [1] respectively. The minimum requirement is that the > MIN_SOLICITATION_INTERVAL MUST be manually configurable, while > possible autoconfiguration mechanisms are outside the scope of this > document. To allow advertisement caching in certain implementations The two MUSTs contradict each other. I think the first MUST should probably not be a MUST, but be a suggested default. > When the MN receives an Agent Advertisement with a Mobility Agent > extension, it performs actions according to the following movement > detection mechanism: the MN MUST be "Eager" to perform new bindings. > This means that the MN MUST perform Registrations with any new FA > from which it receives an advertisement (i.e. MN is Eager), as long > as there are no locally-defined policies in the MN that discourage > the use of the discovered FA. For example, the MN could have a > policy based on the cost of service. The method by which the MN > determines whether the FA is a new FA is described in [1] and MAY use > an FA-NAI extension [11]. First MUST to be "Eager" seems unecessary. Experimentation is needed to figure out how eager one should be. That suggests SHOULD or just pointing out the obvious that if one doesn't do registrations, one doesn't get benefits... > - when L3 cannot rely upon L2 security between the MN and the FA to > make modifications to IP routing and therefore authenticated Mobile > IP messages are required, > Don't understand this bullet > Registration with nFA will not complete before the MN moves on, HTT HTT used prior to expansion/defn. > Code A value indicating the result of the Handoff > Request. Only two codes are currently supported, > 0, indicating success, and a nonzero value, > indicating that the handoff cannot be performed. Seems foolish to all any non-zero to indicate error. Better to just say 0 and 1 defined, rest are for future. > established. The techniques which will solve this problem and allow > the MN to receive traffic independently of the timing of the L2 > handoff event are currently under study by the Mobile IP WG but are > outside the scope of this document. MIP WG has been closed... -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 15:25:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08584 for ; Tue, 18 May 2004 15:25:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQA5g-00058v-MI for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:17:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJHSAI019760 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:17:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9xp-0005so-Ve for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:09:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06772 for ; Tue, 18 May 2004 15:09:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9xm-00005O-VW for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:09:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9wx-00001q-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:08:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9wI-0007lJ-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:07:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9sf-0002C9-CW; Tue, 18 May 2004 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9m3-0005Fp-8W for mip4@optimus.ietf.org; Tue, 18 May 2004 14:57:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05575 for ; Tue, 18 May 2004 14:57:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9m0-0007C7-G0 for mip4@ietf.org; Tue, 18 May 2004 14:57:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9l5-00079j-00 for mip4@ietf.org; Tue, 18 May 2004 14:56:12 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ9kP-00074d-00 for mip4@ietf.org; Tue, 18 May 2004 14:55:29 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 May 2004 11:02:17 +0000 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 i4IIsvW9023508; Tue, 18 May 2004 11:54:57 -0700 (PDT) Received: from kleung-w2k01.cisco.com (sjc-vpn3-491.cisco.com [10.21.65.235]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATH15184; Tue, 18 May 2004 11:54:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20040518114703.02f55598@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 11:55:25 -0700 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List In-Reply-To: <20040518203341.744606c8.henrik@levkowetz.com> References: <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 The problem with MN sending a data packet to the HA is that what type of packet is this? It would have to be an encapsulated registration request. But HA doesn't have a tunnel with the MN. And MN cannot fake the source IP address as the FA's CoA since the FA may prevent invalid source IP address, as well as difficulty to map to reverse tunnel in some cases. You're right that there's a fundamental difference in viewpoints. I believe that SA between peers is used to protect the exchange of messages, regardless of the content. If we provide clear identification of the peers, this solves the problem simply and generically. Kent At 08:33 PM 5/18/2004 +0200, Henrik Levkowetz wrote: >Hi Kent, > >Monday 17 May 2004, Kent Leung wrote: > > Hi Henrik. > > > > At 11:21 AM 5/17/2004 +0200, Henrik Levkowetz wrote: > > >[snip] > > > > > >I'd like to explore this a bit more - when you say you don't see... above, > > >do yoou mean that you don't agree that the current FA (behind NAT or > > >sending from a different address than the CoA of the MN) under the > > >current rules can make it impossible to de-register an earlier care-of > > >address belonging to another FA - if there is a security association > > >between the current FA and it inserts an FHAE in the message trying to > > >de-register the old CoA? > > > > > >- or do you mean simply that you're not bothered by this ability to block > > >the de-registration? > > > > > > I sensed that some folks see that the current FA is blocking the RRQ. So > > just pointing out that FA is doing its job of securing the message to > the HA > > and we need to define a solution to achieve that properly. > >Yes. I think we have a small though basic disagreement on one point - I see >the purpose of the FA using a FHAE as validating and authenticating the >parts of any registration exchange which concerns *that FA*. If there is a >question of using its resources, it must authenticate that usage. However, >how do we handle messages from the MN which in no way concern this FA? > >I've been considering various options which haven't been mentioned so far, >to my knowledge, like for instance requireing the FA to look at deregistration >messages, and if they concern a CoA which is not its own, to not sign them. >But this seems still not quite right to me. > >Let me test yet another one on you: > >The de-registration message in question could just as well have been sent >by the MN from any other address, as long as it's covered by a valid MN-HA >Auth. Ext. Is there any reason why the MN couldn't send this package as >*data traffic* to the HA, which would de-tunnel it, and route it to itself? > >Then the FA (quite rightly) wouldn't see it as a registration request >concerning itself, to be protected with it's FHAE... > >Maybe I'm getting to wild here, but I keep returning to this idea that the >deregistration we're talking about really concerns nobody but the MN and >the HA, and could have been sent from any point really, not necessarily >from this particular FA. > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 15:26:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08658 for ; Tue, 18 May 2004 15:26:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQACB-0000Pa-Rp for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:24:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJOB7O001578 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQA4T-0003et-E2 for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:16:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07712 for ; Tue, 18 May 2004 15:16:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQA4S-0000Qo-7L for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:16:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQA3f-0000OV-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:15:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQA34-0000Lo-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:14:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9ub-0003Ok-0E; Tue, 18 May 2004 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9oy-0005gi-JE for mip4@optimus.ietf.org; Tue, 18 May 2004 15:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05756 for ; Tue, 18 May 2004 15:00:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9ov-0007MW-Od for mip4@ietf.org; Tue, 18 May 2004 15:00:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9o4-0007KJ-00 for mip4@ietf.org; Tue, 18 May 2004 14:59:16 -0400 Received: from av9-2-sn4.m-sp.skanova.net ([81.228.10.107]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9ne-0007Gg-00 for mip4@ietf.org; Tue, 18 May 2004 14:58:50 -0400 Received: by av9-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id EB39A37F3E; Tue, 18 May 2004 20:58:19 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av9-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id D89B237E52; Tue, 18 May 2004 20:58:19 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 47C0837E7A; Tue, 18 May 2004 20:58:19 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BQ9n8-00042b-00; Tue, 18 May 2004 20:58:18 +0200 Date: Tue, 18 May 2004 20:58:18 +0200 From: Henrik Levkowetz To: Kent Leung Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040518205818.68ce790a.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kent, Returning to the second part of your message. Monday 17 May 2004, Kent Leung wrote: ... > I'm not sure if the following text is something you're looking for? > > The original text: > > A deregistration which is passed through a foreign agent which is > different from the the one whose care-of address is being > deregistered MAY add a Foreign-Home Authentication Extension to > such a deregistration. However, as this deregistration concerns > a different foreign agent than the one whose authentication > extension, the home agent MUST disregard the Foreign-Home > Authentication Extension of such a deregistration. The remaining > validity checks, as described in Section 3.8.2.1, are required in > full. > > Proposed text: > > The home agent needs to clearly identify the foreign agent that > sent the Registration Request for authentication. This requires > the foreign agent to append an extension containing its identity > when the Care-of Address and source IP address in the message do > not provide accurate foreign agent identification to the home > agent. However, this extension may be appended indiscriminantly > by the foreign agent to avoid un-ambiguity for any condition. The > remaining validity checks, as described in Section 3.8.2.1, are > required in full. Maybe. As discussed by you and Pete yesterday, maybe this should be separated as much as possible from 3344bis, and handled as a 3519bis or completely separate issue, e.g. by the recently submitted draft. In that case, I'm thinking that maybe we could describe the problem, but not solve it: There exists a situation where a home agent will have trouble correctly identifying the security association to apply to a registration request coming from a foreign agent. This occurs when the mobile node attempts to de-register a care-of address it had with a previous foreign agent, when the current foreign agent is behind a NAT or is forwarding the registration request from a different source address than the mobile nodes currnt care-of address. In this case, if the foreign address has a security association with the home agent, the home agent will not be able to identify the security association, as neither source address nor care-of address of the registration request will match the security association used by the foregn agent in creating the Foregn-Home Authentication Extension. This may be solved by adding a separate foreign agent identification extension to the registration request, but this is outside the scope of the current specification. In the absence of some means of correctly identifying the security association, the home agent has no choice but to reject the registration request, in accordance with the requirements in Section 3.8.2.1. Is this a way forward? Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 15:33:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09296 for ; Tue, 18 May 2004 15:33:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAE4-0000nU-B6 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:26:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJQ8oa003059 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:26:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQABM-0000Kr-QU for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:23:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08381 for ; Tue, 18 May 2004 15:23:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQABL-0000pt-H3 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:23:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAAI-0000m7-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:22:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQA9q-0000j6-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:21:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQA4G-0003Xx-Lm; Tue, 18 May 2004 15:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9uz-0003bs-4u for mip4@optimus.ietf.org; Tue, 18 May 2004 15:06:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06268 for ; Tue, 18 May 2004 15:06:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9uw-0007gB-6L for mip4@ietf.org; Tue, 18 May 2004 15:06:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9ty-0007cR-00 for mip4@ietf.org; Tue, 18 May 2004 15:05:23 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ9t6-0007Wx-00 for mip4@ietf.org; Tue, 18 May 2004 15:04:28 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4IJ2Zq23415; Tue, 18 May 2004 14:02:36 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i4IJ2ZI09226; Tue, 18 May 2004 14:02:35 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HXXBJT-0001QS-00; Tue, 18 May 2004 15:02:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16554.24002.804121.537389@gargle.gargle.HOWL> Date: Tue, 18 May 2004 14:02:26 -0500 From: Pete McCann To: Kent Leung Cc: Henrik Levkowetz , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document In-Reply-To: <4.3.2.7.2.20040517161102.030d4e78@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20040516230344.02eebdd8@mira-sjcm-2.cisco.com> <20040515094408.5844e41c.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517161102.030d4e78@mira-sjcm-2.cisco.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Kent, After thinking about this more, I think it's important that we have 3344bis that works as a standalone document without waiting for any Mobility Entity Identifier. So, we need to clarify at least what are the identifiers for the existing SAs (source IP addresses, CoAs) and specify exactly what the HA does when it gets a message with a missing/wrong/broken authentication extension. Right now, I think SAs between FA and HA are identified by source IP address, and the action is to drop any message that has a missing/wrong/broken authentication extension. For now, we should consider 3519 to update this behavior to allow the HA to use a different algorithm for identifying SAs. In this respect, 3519 opens up many security considerations and most of these are at least listed in 3519. It may not be possible to fix them, even with the FA NAI, but at this point I think we need to keep that discussion separate from 3344bis. 2794 is an example of a document that updates the indexing of SAs between MN and HA to use NAI instead of Home Address. However, in that document, the Home Address cannot take on any value as it can with 3519. So, the security considerations may be different. Maybe we just have to live with the fact that an MN might be unable to de-register an old CoA without cooperation of the current FA and a valid SA between the FA and its HA (having no SA is an example of a valid SA). Without such cooperation and valid SA, it is impossible to fix this problem even with an FA NAI. -Pete Kent Leung writes: > Hi Pete. > > My take is that HA and FA need to identify the source of the message for > authentication. The identification may be the Mobility Entity Identifer, > source IP address, or Care-of Address. Once authenticated, the message > is processed in accordance to RFC 3344 and 3519. > > I think we should move fast in the WG to come to consensus on having > a Mobility Entity Identifier extension to fix the problem. We may not run > into this > problem since FHAE is not common unless within CDMA2000 network. > But in that case, the NAT box is not usually between the FA and HA. > > I agree to move forward to closure on this issue. > > Kent > > At 03:24 PM 5/17/2004 -0500, Pete McCann wrote: > > >Hi, Kent, > > > >Kent Leung writes: > > > Hi Pete. Comments below. > > > > > > At 12:04 AM 5/17/2004 -0500, Pete McCann wrote: > > > > > > >Hi, Kent, > > > > > > > >Yes, I can see how special-casing the FHAE would be difficult in most > > > >implementations. > > > > > > > >However, I agree with Henrik & others that there is a subtle problem > > > >here, and now I don't think it can be fixed with an FA NAI, due to the > > > >missing auth extension detection problem. If attackers would just > > > >cooperate and set the "evil" bit in the packet headers our job would > > > >be a lot easier. > > > > > > > >Reading your mail, I think you are suggesting to index the SA by > > > >*both* FA source IP address and FA COA. Is that explicit in the > > > >current draft? If not, it should be. > > > > > > > > > It is not explicit as far as I'm aware of. Exactly how the FA is > > identified > > > is not clearly defined. I've always assumed both fields are used since > > > CoA was not always the right identity for FA. > > > >In fact, I think the source IP address has to be the main identifier. > >That is how all the other SAs work and it would be consistent with > >your "flat" definition of a Mobile IP SA. At best, the CoA is just an > >auxiliary piece of information that we may or may not keep as part of > >the SA, as something that the FA may be authorized to use from the > >HA's perspective. > > > > > >We may have slightly differing views on the current problem we are > > > >trying to solve. Let me try to state it a couple of different ways > > > >and see if you agree: > > > > > > > >* An MN is trying to de-register an old care-of address through an FA > > > > that is behind a NAT. The FA thinks it has an SA with an HA, so > > > > appends FHAE. Unfortunately, the HA can't find it due to the NAT > > > > and so drops the message. > > > > > > > >Now, it seems that FA NAI would fix this problem. > > > > > > > > > Yes. > > > > > > > > > >However, let me state another problem: > > > > > > > >* An MN is trying to de-register an old care-of address through an > > > > FA that is behind a NAT. The FA doesn't have an SA with an HA, so > > > > does not append FHAE. Unfortunately, the HA looks at the COA in > > > > the message, realizes that it has an SA with the old FA, and so > > > > drops the message. Note that source IP address is not useful > > > > for identifying the FA because of the NAT. > > > > > > > > > But, FA should be appending the FA NAI ext to identify itself since the > > > CoA nor the source IP address is insufficient. This new extension is > > > providing identity for source endpoint of the message and allow the > > > receiver side to detect if NAT occurred, SA checked, and any future > > > operations needed. > > > >So I think you are saying that 3519 is just broken until we have the > >FA NAI extension. In fact, we would need a 3519-bis that *required* > >the NAI extension and *required* HAs to drop registration requests that > >appear to be NAT-related but which don't contain the extension. > > > > > >Now, it seems like FA NAI would not fix this problem, because there is > > > >no way to tell whether or not an un-authenticated NAI was inserted by > > > >an attacker after stripping out the real NAI/authenticator extensions. > > > > > > Hmm, not totally clear about this scenario. Are you saying that the > > > attacker can modify fields in the message in transit to cause failed > > > authentication? But it would be easier just to change one bit anywhere > > > before the MHAE? > > > >I am worried about a situation where FAs that support the FA NAI and > >nodes that do not co-exist in the network. There is no way in general > >for the HA to tell whether it is talking to an old FA with which it > >doesn't have an SA or a new FA with which it does but where an > >attacker has stripped off the FA NAI + authentication extension. > >It should process the request in the first case but drop it in the > >second. How does it know? > > > > > As for how to avoid un-authenticated FA NAI, one method is to advertise > > > this identity to the MN so it gets protected by the MHAE? This can be > > > dealt with in the new draft. > > > >That might help, and avoids the problem of an attacker stripping it > >off after the RRQ is generated. But, I'm not sure it is a cure-all... > > > > > >So, it seems like we at least will end up needing special rules for > > > >how to index the SA in the case of de-registration. That is, we might > > > >look for SAs based on source IP address, COA, and/or FA NAI in the > > > >case of registrations, but with de-registrations, we can't use the > > > >COA. We might still be able to use the other two items. > > > > > > I think we can have consistency for registration and de-registration > > by having > > > the FA to always insert the FA NAI in the message when the source IP > > > address or CoA is insufficient. The FHAE is appended only if FA has an SA > > > with the HA. The HA will know which FA is the sender and act in a clear > > > manner to process the message. > > > >But do we allow existing 3344-compliant FAs to exist in this universe? > >If so, we need to keep the old rules for identifying SAs based on FA > >source IP address. > > > > > As for logic for determining when CoA is insufficient, either when FA > > is behind > > > NAT (source IP address will be translated), or CoA in message is not > > advertised > > > by FA or match FA's identity, comes to mind... > > > >Are you speaking about logic on the FA or the HA? I think the logic > >on the FA is easy: if you support FA NAI, then always include it. > >Logic on the HA is more difficult, as I believe the mechanisms for > >detecting NAT in 3519 are themselves not always 100% reliable (but > >maybe someone more familiar with the draft can comment). > > > >-Pete > > > > > Kent > > > > > > >Is that accurate? > > > > > > > >-Pete > > > > > > > > > > > >Henrik Levkowetz writes: > > > > > Hi Kent, > > > > > > > > > > I'm not adverse to your reasoning here. However, two points: > > > > > > > > > > 1. If we say nothing about this in 3344bis, then we still have > > the basic > > > > > issue unsolved, and no indication that it even exist, in 3344bis. > > > > > > > > > > 2. The end result of leaving things as they are for now is that > > an FA is > > > > > able to block the deregistration of a CoA belonging to another FA > > - i.e. > > > > > a CoA for which it has no authority. > > > > > > > > > > Considering these points, could you suggest some alternative > > text, please? > > > > > > > > > > Or do you feel really strongly about not even mentioning the issue in > > > > > 3344bis? > > > > > > > > > > Henrik > > > > > > > > > > Friday 14 May 2004, Kent Leung wrote: > > > > > > I believe that no security association between peers should be > > > > compromised. > > > > > > Maybe I missed it, but don't remember any consensus to put such > > text > > > > > > to disregard Authentication Extension. Actually, I think there > > was some > > > > > > agreement that FHAE (or any AEs for that matter) should not be > > > > > > simply ignored. (I know I've been vocal in my disagreement about > > > > > > ignoring FHAE - sorry AEs should not have special cases for > > handling; > > > > > > either one is trying to secure or not. :) > > > > > > > > > > > > See Issue #44 Comment #149: > > > > > > >I think your response last week convinced me that ignoring the R > > > > > > >bit is not a good idea, and I agree that the HA should check > > the FHAE, > > > > > > >if it is present, and discard the message if it doesn't check. > > > > > > > > > > > > RFC 3344bis should probably not mandate changes to current > > > > > > implementations. Thought there was already agreement that Mobility > > > > > > Entity Identify extension is needed for accurate identification, > > > > which is > > > > > > the root cause of issues #44 and #45. So that would > > > > > > solve the problem cleanly and not bypass any security associations > > > > > > which are set up by administrators. And there was agreement that > > > > > > another draft will handle this. > > > > > > > > > > > > See Issue #44 Comment #149: > > > > > > >If someone wants to put together a new document on Mobility Agent > > > > > > >Identifier extensions I think that would be a good idea. > > > > > > > > > > > > See Issue #44, Comment #142: > > > > > > >Your argument below is persuasive. It seems to me this would be a > > > > > > >fairly clean solution which leaves 3344 as flexible as today, > > improves > > > > > > >NAT traversal and solves the deregistration FHAE problem. > > > > > > > > > > > > In addition, I would expect that any messages received without > > proper > > > > > > AEs would be discarded. For example, the source IP address or CoA > > > > > > that matches an FA SA in a message that does not contain FHAE > > > > > > would be discarded by the HA for failing authentication. With > > the new > > > > > > draft, the Mobility Entitiy Identifer would be used to index an > > FA SA. > > > > > > > > > > > > In summary, I propose removing any text related to the issue in > > > > > > RFC3344bis because current implementation is right in terms of > > > > > > identifying the FA by source IP address or CoA. Future > > implementation > > > > > > should follow the upcoming draft that identifies FA accurately and > > > > solve both > > > > > > problems cleanly. Having any text that specifies to not add AE or > > > > ignore > > > > > > AE is more damaging than leaving issues as status quo to be > > dealt with > > > > > > later, IMHO. > > > > > > > > > > > > Kent > > > > > > > > > > > > At 10:39 AM 5/14/2004 -0500, Pete McCann wrote: > > > > > > > > > > > > >I'm ok with relaxing the MUST disregard to a MAY disregard; > > however, I > > > > > > >am not sure that adding FA NAI extension would turn this into > > a MUST > > > > > > >verify before processing de-registration. It seems like the > > HA would > > > > > > >always honor a valid de-registration request that passed > > end-to-end > > > > > > >replay protection, no matter what extensions or authenticators > > were > > > > > > >added by the FA. > > > > > > > > > > > > > >Maybe we need to take a more nuanced approach than all-or-nothing > > > > > > >success/failure. Maybe we should view the FHAE as protecting > > only the > > > > > > >extensions added by the FA, and possibly the care-of address > > owned by > > > > > > >that FA if the request has lifetime > 0. > > > > > > > > > > > > > >One thing we might be missing in all of the discussion on > > identifying > > > > > > >the FA: an important part of indexing a security association > > is not > > > > > > >just so that you can find it when you are checking an existing > > > > > > >authentication extension, but also so that you can detect when > > it is > > > > > > >missing in a message received from another entity. The FA NAI, by > > > > > > >itself, cannot be the only index key to the SA table, because > > we also > > > > > > >need to be able to discard messages (or ignore certain parts of > > > > > > >messages) that are not protected by an authentication > > extension when > > > > > > >they really should be, according to the IP source address / > > care-of > > > > > > >address. > > > > > > > > > > > > > >-Pete > > > > > > > > > > > > > >Henrik Levkowetz writes: > > > > > > > > Hi Sri, > > > > > > > > > > > > > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > > > > > > > Sure. We agreed not to hold the current draft and I'm not > > > > asking for the > > > > > > > > > extension to be added to this draft. Sorry, if I was not > > > > clear on > > > > > > > that. My > > > > > > > > > only point is to change the "MUST" clause on HA > > behaviour with > > > > > > > respect to > > > > > > > > > the FHAE validation. The "Mobility Identity Extension" > > draft we > > > > > > > published > > > > > > > > > today can potentially address the FHAE issue ONLY if HA is > > > > not forced to > > > > > > > > > ignore the FHAE validation in the above scenario. May be > > all I'm > > > > > > > asking is > > > > > > > > > to leave the above text with the "MAY" clause and that > > would not > > > > > > > have any > > > > > > > > > impact on the old FA scenarios. > > > > > > > > > > > > > > > > Ok, I see. My thoughts were that you could let the new > > draft amend > > > > > > > > 3344bis on this point, saying in effect something like > > this in > > > > the new > > > > > > > > draft: > > > > > > > > > > > > > > > > ...if the FA uses a FA identity extension to identify itself > > > > and its > > > > > > > > authentication extension, as described in this draft, and > > the HA > > > > > > > understands > > > > > > > > the FA identity extension, the HA no longer must disregard the > > > > > > > authentication > > > > > > > > extension from the FA as described in [3344bis], but on the > > > > contrary > > > > > > > SHOULD > > > > > > > > verify the FA authentication extension using the FA identidy > > > > from the FA > > > > > > > > identity extension... > > > > > > > > > > > > > > > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 15:40:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09714 for ; Tue, 18 May 2004 15:40:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAON-0003xS-IS for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:36:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJalY7015214 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:36:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAFI-0000sb-8w for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:27:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08731 for ; Tue, 18 May 2004 15:27:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQAFG-0001Df-UF for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:27:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAEK-00018Q-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:26:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQADZ-00013g-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:25:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQA6D-0005Nr-Sl; Tue, 18 May 2004 15:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9wz-0005JG-5j for mip4@optimus.ietf.org; Tue, 18 May 2004 15:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06579 for ; Tue, 18 May 2004 15:08:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9ww-00001Y-6q for mip4@ietf.org; Tue, 18 May 2004 15:08:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9wD-0007l2-00 for mip4@ietf.org; Tue, 18 May 2004 15:07:42 -0400 Received: from av9-2-sn4.m-sp.skanova.net ([81.228.10.107]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9vW-0007gh-00 for mip4@ietf.org; Tue, 18 May 2004 15:06:58 -0400 Received: by av9-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 6EC6E37F50; Tue, 18 May 2004 21:06:28 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av9-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 5A59F37E48; Tue, 18 May 2004 21:06:28 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 2D88537E62; Tue, 18 May 2004 21:06:28 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BQ9v1-000438-00; Tue, 18 May 2004 21:06:27 +0200 Date: Tue, 18 May 2004 21:06:27 +0200 From: Henrik Levkowetz To: Kent Leung Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040518210627.0cfe9727.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20040518114703.02f55598@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040518114703.02f55598@mira-sjcm-2.cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kent, Tuesday 18 May 2004, Kent Leung wrote: > The problem with MN sending a data packet to the HA is that > what type of packet is this? It would have to be an encapsulated > registration request. But HA doesn't have a tunnel with the MN. > And MN cannot fake the source IP address as the FA's CoA > since the FA may prevent invalid source IP address, as well as > difficulty to map to reverse tunnel in some cases. This would have to be an encapsulated registration request, sent from the MNs home address presumably, and you're right, the problem would be in encapsulating it so that it's seen as data and not a registration request by the FA. I'm wondering right now how our (ipUnplugged) HA would handle IPIP in IP encapsulated traffic coming from an MN... > You're right that there's a fundamental difference in viewpoints. > I believe that SA between peers is used to protect the exchange > of messages, regardless of the content. If we provide clear > identification of the peers, this solves the problem simply and > generically. Yes. But not in 3344bis. And also not for legacy systems, but that may be OK, if we see this as a needed extension for the use of FAs in a 3519 context. Henrik > Kent > > At 08:33 PM 5/18/2004 +0200, Henrik Levkowetz wrote: > >Hi Kent, > > > >Monday 17 May 2004, Kent Leung wrote: > > > Hi Henrik. > > > > > > At 11:21 AM 5/17/2004 +0200, Henrik Levkowetz wrote: > > > >[snip] > > > > > > > >I'd like to explore this a bit more - when you say you don't see... above, > > > >do yoou mean that you don't agree that the current FA (behind NAT or > > > >sending from a different address than the CoA of the MN) under the > > > >current rules can make it impossible to de-register an earlier care-of > > > >address belonging to another FA - if there is a security association > > > >between the current FA and it inserts an FHAE in the message trying to > > > >de-register the old CoA? > > > > > > > >- or do you mean simply that you're not bothered by this ability to block > > > >the de-registration? > > > > > > > > > I sensed that some folks see that the current FA is blocking the RRQ. So > > > just pointing out that FA is doing its job of securing the message to > > the HA > > > and we need to define a solution to achieve that properly. > > > >Yes. I think we have a small though basic disagreement on one point - I see > >the purpose of the FA using a FHAE as validating and authenticating the > >parts of any registration exchange which concerns *that FA*. If there is a > >question of using its resources, it must authenticate that usage. However, > >how do we handle messages from the MN which in no way concern this FA? > > > >I've been considering various options which haven't been mentioned so far, > >to my knowledge, like for instance requireing the FA to look at deregistration > >messages, and if they concern a CoA which is not its own, to not sign them. > >But this seems still not quite right to me. > > > >Let me test yet another one on you: > > > >The de-registration message in question could just as well have been sent > >by the MN from any other address, as long as it's covered by a valid MN-HA > >Auth. Ext. Is there any reason why the MN couldn't send this package as > >*data traffic* to the HA, which would de-tunnel it, and route it to itself? > > > >Then the FA (quite rightly) wouldn't see it as a registration request > >concerning itself, to be protected with it's FHAE... > > > >Maybe I'm getting to wild here, but I keep returning to this idea that the > >deregistration we're talking about really concerns nobody but the MN and > >the HA, and could have been sent from any point really, not necessarily > >from this particular FA. > > > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 15:58:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10721 for ; Tue, 18 May 2004 15:58:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAQi-0005Ud-IV for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:39:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJdClx021116 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:39:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAKr-000220-0h for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:33:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09244 for ; Tue, 18 May 2004 15:33:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQAKp-0001Xi-KG for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:33:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAJr-0001Vk-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:32:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQAJT-0001Ty-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:31:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQACz-0000Vi-J9; Tue, 18 May 2004 15:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQA4M-0003Zj-BC for mip4@optimus.ietf.org; Tue, 18 May 2004 15:16:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07683 for ; Tue, 18 May 2004 15:16:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQA4K-0000Q8-SK for mip4@ietf.org; Tue, 18 May 2004 15:16:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQA3Z-0000No-00 for mip4@ietf.org; Tue, 18 May 2004 15:15:19 -0400 Received: from av4-1-sn3.vrr.skanova.net ([81.228.9.111]) by ietf-mx with esmtp (Exim 4.12) id 1BQA2c-0000Iq-00 for mip4@ietf.org; Tue, 18 May 2004 15:14:18 -0400 Received: by av4-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 2B77437F4A; Tue, 18 May 2004 21:13:48 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 1C58C37EC7; Tue, 18 May 2004 21:13:48 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id C517938015; Tue, 18 May 2004 21:13:47 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BQA27-000443-00; Tue, 18 May 2004 21:13:47 +0200 Date: Tue, 18 May 2004 21:13:47 +0200 From: Henrik Levkowetz To: Pete McCann Cc: Kent Leung , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040518211347.162912b0.henrik@levkowetz.com> In-Reply-To: <16554.24002.804121.537389@gargle.gargle.HOWL> References: <4.3.2.7.2.20040516230344.02eebdd8@mira-sjcm-2.cisco.com> <20040515094408.5844e41c.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517161102.030d4e78@mira-sjcm-2.cisco.com> <16554.24002.804121.537389@gargle.gargle.HOWL> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pete, Tuesday 18 May 2004, Pete McCann wrote: > Hi, Kent, > > After thinking about this more, I think it's important that we have > 3344bis that works as a standalone document without waiting for any > Mobility Entity Identifier. So, we need to clarify at least what are > the identifiers for the existing SAs (source IP addresses, CoAs) and > specify exactly what the HA does when it gets a message with a > missing/wrong/broken authentication extension. Agree. > Right now, I think SAs between FA and HA are identified by source IP > address, and the action is to drop any message that has a > missing/wrong/broken authentication extension. Yes. > For now, we should consider 3519 to update this behavior to allow the > HA to use a different algorithm for identifying SAs. In this respect, > 3519 opens up many security considerations and most of these are > at least listed in 3519. It may not be possible to fix them, even > with the FA NAI, but at this point I think we need to keep that > discussion separate from 3344bis. Yes. > 2794 is an example of a document that updates the indexing of SAs > between MN and HA to use NAI instead of Home Address. However, in > that document, the Home Address cannot take on any value as it can > with 3519. So, the security considerations may be different. > > Maybe we just have to live with the fact that an MN might be unable to > de-register an old CoA without cooperation of the current FA and a > valid SA between the FA and its HA (having no SA is an example of a > valid SA). Without such cooperation and valid SA, it is impossible to > fix this problem even with an FA NAI. I agree. See my most recently proposed text, which I intended to say bacically this :-) Henrik > -Pete > > > Kent Leung writes: > > Hi Pete. > > > > My take is that HA and FA need to identify the source of the message for > > authentication. The identification may be the Mobility Entity Identifer, > > source IP address, or Care-of Address. Once authenticated, the message > > is processed in accordance to RFC 3344 and 3519. > > > > I think we should move fast in the WG to come to consensus on having > > a Mobility Entity Identifier extension to fix the problem. We may not run > > into this > > problem since FHAE is not common unless within CDMA2000 network. > > But in that case, the NAT box is not usually between the FA and HA. > > > > I agree to move forward to closure on this issue. > > > > Kent > > > > At 03:24 PM 5/17/2004 -0500, Pete McCann wrote: > > > > >Hi, Kent, > > > > > >Kent Leung writes: > > > > Hi Pete. Comments below. > > > > > > > > At 12:04 AM 5/17/2004 -0500, Pete McCann wrote: > > > > > > > > >Hi, Kent, > > > > > > > > > >Yes, I can see how special-casing the FHAE would be difficult in most > > > > >implementations. > > > > > > > > > >However, I agree with Henrik & others that there is a subtle problem > > > > >here, and now I don't think it can be fixed with an FA NAI, due to the > > > > >missing auth extension detection problem. If attackers would just > > > > >cooperate and set the "evil" bit in the packet headers our job would > > > > >be a lot easier. > > > > > > > > > >Reading your mail, I think you are suggesting to index the SA by > > > > >*both* FA source IP address and FA COA. Is that explicit in the > > > > >current draft? If not, it should be. > > > > > > > > > > > > It is not explicit as far as I'm aware of. Exactly how the FA is > > > identified > > > > is not clearly defined. I've always assumed both fields are used since > > > > CoA was not always the right identity for FA. > > > > > >In fact, I think the source IP address has to be the main identifier. > > >That is how all the other SAs work and it would be consistent with > > >your "flat" definition of a Mobile IP SA. At best, the CoA is just an > > >auxiliary piece of information that we may or may not keep as part of > > >the SA, as something that the FA may be authorized to use from the > > >HA's perspective. > > > > > > > >We may have slightly differing views on the current problem we are > > > > >trying to solve. Let me try to state it a couple of different ways > > > > >and see if you agree: > > > > > > > > > >* An MN is trying to de-register an old care-of address through an FA > > > > > that is behind a NAT. The FA thinks it has an SA with an HA, so > > > > > appends FHAE. Unfortunately, the HA can't find it due to the NAT > > > > > and so drops the message. > > > > > > > > > >Now, it seems that FA NAI would fix this problem. > > > > > > > > > > > > Yes. > > > > > > > > > > > > >However, let me state another problem: > > > > > > > > > >* An MN is trying to de-register an old care-of address through an > > > > > FA that is behind a NAT. The FA doesn't have an SA with an HA, so > > > > > does not append FHAE. Unfortunately, the HA looks at the COA in > > > > > the message, realizes that it has an SA with the old FA, and so > > > > > drops the message. Note that source IP address is not useful > > > > > for identifying the FA because of the NAT. > > > > > > > > > > > > But, FA should be appending the FA NAI ext to identify itself since the > > > > CoA nor the source IP address is insufficient. This new extension is > > > > providing identity for source endpoint of the message and allow the > > > > receiver side to detect if NAT occurred, SA checked, and any future > > > > operations needed. > > > > > >So I think you are saying that 3519 is just broken until we have the > > >FA NAI extension. In fact, we would need a 3519-bis that *required* > > >the NAI extension and *required* HAs to drop registration requests that > > >appear to be NAT-related but which don't contain the extension. > > > > > > > >Now, it seems like FA NAI would not fix this problem, because there is > > > > >no way to tell whether or not an un-authenticated NAI was inserted by > > > > >an attacker after stripping out the real NAI/authenticator extensions. > > > > > > > > Hmm, not totally clear about this scenario. Are you saying that the > > > > attacker can modify fields in the message in transit to cause failed > > > > authentication? But it would be easier just to change one bit anywhere > > > > before the MHAE? > > > > > >I am worried about a situation where FAs that support the FA NAI and > > >nodes that do not co-exist in the network. There is no way in general > > >for the HA to tell whether it is talking to an old FA with which it > > >doesn't have an SA or a new FA with which it does but where an > > >attacker has stripped off the FA NAI + authentication extension. > > >It should process the request in the first case but drop it in the > > >second. How does it know? > > > > > > > As for how to avoid un-authenticated FA NAI, one method is to advertise > > > > this identity to the MN so it gets protected by the MHAE? This can be > > > > dealt with in the new draft. > > > > > >That might help, and avoids the problem of an attacker stripping it > > >off after the RRQ is generated. But, I'm not sure it is a cure-all... > > > > > > > >So, it seems like we at least will end up needing special rules for > > > > >how to index the SA in the case of de-registration. That is, we might > > > > >look for SAs based on source IP address, COA, and/or FA NAI in the > > > > >case of registrations, but with de-registrations, we can't use the > > > > >COA. We might still be able to use the other two items. > > > > > > > > I think we can have consistency for registration and de-registration > > > by having > > > > the FA to always insert the FA NAI in the message when the source IP > > > > address or CoA is insufficient. The FHAE is appended only if FA has an SA > > > > with the HA. The HA will know which FA is the sender and act in a clear > > > > manner to process the message. > > > > > >But do we allow existing 3344-compliant FAs to exist in this universe? > > >If so, we need to keep the old rules for identifying SAs based on FA > > >source IP address. > > > > > > > As for logic for determining when CoA is insufficient, either when FA > > > is behind > > > > NAT (source IP address will be translated), or CoA in message is not > > > advertised > > > > by FA or match FA's identity, comes to mind... > > > > > >Are you speaking about logic on the FA or the HA? I think the logic > > >on the FA is easy: if you support FA NAI, then always include it. > > >Logic on the HA is more difficult, as I believe the mechanisms for > > >detecting NAT in 3519 are themselves not always 100% reliable (but > > >maybe someone more familiar with the draft can comment). > > > > > >-Pete > > > > > > > Kent > > > > > > > > >Is that accurate? > > > > > > > > > >-Pete > > > > > > > > > > > > > > >Henrik Levkowetz writes: > > > > > > Hi Kent, > > > > > > > > > > > > I'm not adverse to your reasoning here. However, two points: > > > > > > > > > > > > 1. If we say nothing about this in 3344bis, then we still have > > > the basic > > > > > > issue unsolved, and no indication that it even exist, in 3344bis. > > > > > > > > > > > > 2. The end result of leaving things as they are for now is that > > > an FA is > > > > > > able to block the deregistration of a CoA belonging to another FA > > > - i.e. > > > > > > a CoA for which it has no authority. > > > > > > > > > > > > Considering these points, could you suggest some alternative > > > text, please? > > > > > > > > > > > > Or do you feel really strongly about not even mentioning the issue in > > > > > > 3344bis? > > > > > > > > > > > > Henrik > > > > > > > > > > > > Friday 14 May 2004, Kent Leung wrote: > > > > > > > I believe that no security association between peers should be > > > > > compromised. > > > > > > > Maybe I missed it, but don't remember any consensus to put such > > > text > > > > > > > to disregard Authentication Extension. Actually, I think there > > > was some > > > > > > > agreement that FHAE (or any AEs for that matter) should not be > > > > > > > simply ignored. (I know I've been vocal in my disagreement about > > > > > > > ignoring FHAE - sorry AEs should not have special cases for > > > handling; > > > > > > > either one is trying to secure or not. :) > > > > > > > > > > > > > > See Issue #44 Comment #149: > > > > > > > >I think your response last week convinced me that ignoring the R > > > > > > > >bit is not a good idea, and I agree that the HA should check > > > the FHAE, > > > > > > > >if it is present, and discard the message if it doesn't check. > > > > > > > > > > > > > > RFC 3344bis should probably not mandate changes to current > > > > > > > implementations. Thought there was already agreement that Mobility > > > > > > > Entity Identify extension is needed for accurate identification, > > > > > which is > > > > > > > the root cause of issues #44 and #45. So that would > > > > > > > solve the problem cleanly and not bypass any security associations > > > > > > > which are set up by administrators. And there was agreement that > > > > > > > another draft will handle this. > > > > > > > > > > > > > > See Issue #44 Comment #149: > > > > > > > >If someone wants to put together a new document on Mobility Agent > > > > > > > >Identifier extensions I think that would be a good idea. > > > > > > > > > > > > > > See Issue #44, Comment #142: > > > > > > > >Your argument below is persuasive. It seems to me this would be a > > > > > > > >fairly clean solution which leaves 3344 as flexible as today, > > > improves > > > > > > > >NAT traversal and solves the deregistration FHAE problem. > > > > > > > > > > > > > > In addition, I would expect that any messages received without > > > proper > > > > > > > AEs would be discarded. For example, the source IP address or CoA > > > > > > > that matches an FA SA in a message that does not contain FHAE > > > > > > > would be discarded by the HA for failing authentication. With > > > the new > > > > > > > draft, the Mobility Entitiy Identifer would be used to index an > > > FA SA. > > > > > > > > > > > > > > In summary, I propose removing any text related to the issue in > > > > > > > RFC3344bis because current implementation is right in terms of > > > > > > > identifying the FA by source IP address or CoA. Future > > > implementation > > > > > > > should follow the upcoming draft that identifies FA accurately and > > > > > solve both > > > > > > > problems cleanly. Having any text that specifies to not add AE or > > > > > ignore > > > > > > > AE is more damaging than leaving issues as status quo to be > > > dealt with > > > > > > > later, IMHO. > > > > > > > > > > > > > > Kent > > > > > > > > > > > > > > At 10:39 AM 5/14/2004 -0500, Pete McCann wrote: > > > > > > > > > > > > > > >I'm ok with relaxing the MUST disregard to a MAY disregard; > > > however, I > > > > > > > >am not sure that adding FA NAI extension would turn this into > > > a MUST > > > > > > > >verify before processing de-registration. It seems like the > > > HA would > > > > > > > >always honor a valid de-registration request that passed > > > end-to-end > > > > > > > >replay protection, no matter what extensions or authenticators > > > were > > > > > > > >added by the FA. > > > > > > > > > > > > > > > >Maybe we need to take a more nuanced approach than all-or-nothing > > > > > > > >success/failure. Maybe we should view the FHAE as protecting > > > only the > > > > > > > >extensions added by the FA, and possibly the care-of address > > > owned by > > > > > > > >that FA if the request has lifetime > 0. > > > > > > > > > > > > > > > >One thing we might be missing in all of the discussion on > > > identifying > > > > > > > >the FA: an important part of indexing a security association > > > is not > > > > > > > >just so that you can find it when you are checking an existing > > > > > > > >authentication extension, but also so that you can detect when > > > it is > > > > > > > >missing in a message received from another entity. The FA NAI, by > > > > > > > >itself, cannot be the only index key to the SA table, because > > > we also > > > > > > > >need to be able to discard messages (or ignore certain parts of > > > > > > > >messages) that are not protected by an authentication > > > extension when > > > > > > > >they really should be, according to the IP source address / > > > care-of > > > > > > > >address. > > > > > > > > > > > > > > > >-Pete > > > > > > > > > > > > > > > >Henrik Levkowetz writes: > > > > > > > > > Hi Sri, > > > > > > > > > > > > > > > > > > Friday 14 May 2004, Sri Gundavelli wrote: > > > > > > > > > > Sure. We agreed not to hold the current draft and I'm not > > > > > asking for the > > > > > > > > > > extension to be added to this draft. Sorry, if I was not > > > > > clear on > > > > > > > > that. My > > > > > > > > > > only point is to change the "MUST" clause on HA > > > behaviour with > > > > > > > > respect to > > > > > > > > > > the FHAE validation. The "Mobility Identity Extension" > > > draft we > > > > > > > > published > > > > > > > > > > today can potentially address the FHAE issue ONLY if HA is > > > > > not forced to > > > > > > > > > > ignore the FHAE validation in the above scenario. May be > > > all I'm > > > > > > > > asking is > > > > > > > > > > to leave the above text with the "MAY" clause and that > > > would not > > > > > > > > have any > > > > > > > > > > impact on the old FA scenarios. > > > > > > > > > > > > > > > > > > Ok, I see. My thoughts were that you could let the new > > > draft amend > > > > > > > > > 3344bis on this point, saying in effect something like > > > this in > > > > > the new > > > > > > > > > draft: > > > > > > > > > > > > > > > > > > ...if the FA uses a FA identity extension to identify itself > > > > > and its > > > > > > > > > authentication extension, as described in this draft, and > > > the HA > > > > > > > > understands > > > > > > > > > the FA identity extension, the HA no longer must disregard the > > > > > > > > authentication > > > > > > > > > extension from the FA as described in [3344bis], but on the > > > > > contrary > > > > > > > > SHOULD > > > > > > > > > verify the FA authentication extension using the FA identidy > > > > > from the FA > > > > > > > > > identity extension... > > > > > > > > > > > > > > > > > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 15:58:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10785 for ; Tue, 18 May 2004 15:58:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAR9-0005as-Qg for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:39:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJddM6021497 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 15:39:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQALv-0002pi-8v for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09354 for ; Tue, 18 May 2004 15:34:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQALu-0001bp-1D for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:34:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAL2-0001ZI-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:33:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQAKR-0001WN-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:32:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQADy-0000l3-JK; Tue, 18 May 2004 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQA6O-0005Qt-Qo for mip4@optimus.ietf.org; Tue, 18 May 2004 15:18:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07959 for ; Tue, 18 May 2004 15:18:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQA6N-0000XW-HE for mip4@ietf.org; Tue, 18 May 2004 15:18:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQA5X-0000V7-00 for mip4@ietf.org; Tue, 18 May 2004 15:17:20 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQA4h-0000PF-00 for mip4@ietf.org; Tue, 18 May 2004 15:16:27 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 May 2004 11:23:15 +0000 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 i4IJFtSu008412; Tue, 18 May 2004 12:15:55 -0700 (PDT) Received: from kleung-w2k01.cisco.com (sjc-vpn3-491.cisco.com [10.21.65.235]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATH17337; Tue, 18 May 2004 12:15:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20040518120514.01cfe8d0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 12:16:19 -0700 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List In-Reply-To: <20040518205818.68ce790a.henrik@levkowetz.com> References: <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2556145==_.ALT" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --=====================_2556145==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Henrik. That was what I asked last time - about describing problem only in 3344bis vs. having some solution. :) I've made some minor edits. Though underlined the part that I'm not fully clear about. > There exists a situation where a home agent will not be able to > correctly identify the security association to apply to a > registration request coming from a foreign agent. This occurs when > the mobile node attempts to de-register a previous care-of address > using the current foreign agent which is > behind a NAT device or is forwarding the registration request from a > different source address than the mobile nodes current care-of > address. In this case, if the foreign address has a security > association with the home agent, the home agent will not be able to > identify the security association, as neither source address nor > care-of address of the registration request will match the security > association used by the foreign agent in creating the Foreign-Home > Authentication Extension. This may be solved by adding a separate > foreign agent identification extension to the registration request, > but this is outside the scope of the current specification. In the > absence of some means of correctly identifying the security > association, the home agent has no choice but to reject the > registration request, in accordance with the requirements in Section > 3.8.2.1. Kent At 08:58 PM 5/18/2004 +0200, Henrik Levkowetz wrote: >Hi Kent, > >Returning to the second part of your message. > >Monday 17 May 2004, Kent Leung wrote: >... > > I'm not sure if the following text is something you're looking for? > > > > The original text: > > > > A deregistration which is passed through a foreign agent which is > > different from the the one whose care-of address is being > > deregistered MAY add a Foreign-Home Authentication Extension to > > such a deregistration. However, as this deregistration concerns > > a different foreign agent than the one whose authentication > > extension, the home agent MUST disregard the Foreign-Home > > Authentication Extension of such a deregistration. The remaining > > validity checks, as described in Section 3.8.2.1, are required in > > full. > > > > Proposed text: > > > > The home agent needs to clearly identify the foreign agent that > > sent the Registration Request for authentication. This requires > > the foreign agent to append an extension containing its identity > > when the Care-of Address and source IP address in the message do > > not provide accurate foreign agent identification to the home > > agent. However, this extension may be appended indiscriminantly > > by the foreign agent to avoid un-ambiguity for any condition. The > > remaining validity checks, as described in Section 3.8.2.1, are > > required in full. > >Maybe. As discussed by you and Pete yesterday, maybe this should be >separated as much as possible from 3344bis, and handled as a 3519bis or >completely separate issue, e.g. by the recently submitted draft. In >that case, I'm thinking that maybe we could describe the problem, but >not solve it: > > There exists a situation where a home agent will have trouble > correctly identifying the security association to apply to a > registration request coming from a foreign agent. This occurs when > the mobile node attempts to de-register a care-of address it had > with a previous foreign agent, when the current foreign agent is > behind a NAT or is forwarding the registration request from a > different source address than the mobile nodes currnt care-of > address. In this case, if the foreign address has a security > association with the home agent, the home agent will not be able to > identify the security association, as neither source address nor > care-of address of the registration request will match the security > association used by the foregn agent in creating the Foregn-Home > Authentication Extension. This may be solved by adding a separate > foreign agent identification extension to the registration request, > but this is outside the scope of the current specification. In the > absence of some means of correctly identifying the security > association, the home agent has no choice but to reject the > registration request, in accordance with the requirements in Section > 3.8.2.1. > >Is this a way forward? > > Henrik --=====================_2556145==_.ALT Content-Type: text/html; charset="us-ascii" Hi Henrik.  That was what I asked last time - about describing problem
only in 3344bis vs. having some solution.  :)

I've made some minor edits.  Though underlined the part that I'm not
fully clear about.

    There exists a situation where a home agent will not be able to
    correctly identify the security association to apply to a
    registration request coming from a foreign agent.  This occurs when
    the mobile node attempts to de-register a  previous care-of address
    using the current foreign agent which is
    behind a NAT device or is forwarding the registration request from a
    different source address than the mobile nodes current care-of
    address.  In this case, if the foreign address has a security
    association with the home agent, the home agent will not be able to
    identify the security association, as neither source address nor
    care-of address of the registration request will match the security
    association used by the foreign agent in creating the Foreign-Home
    Authentication Extension.  This may be solved by adding a separate
    foreign agent identification extension to the registration request,
    but this is outside the scope of the current specification.  In the
    absence of some means of correctly identifying the security
    association, the home agent has no choice but to reject the
    registration request, in accordance with the requirements in Section
    3.8.2.1.


Kent

At 08:58 PM 5/18/2004 +0200, Henrik Levkowetz wrote:
Hi Kent,

Returning to the second part of your message.

Monday 17 May 2004, Kent Leung wrote:
...
> I'm not sure if the following text is something you're looking for?
>
> The original text:
>
>      A deregistration which is passed through a foreign agent which is
>      different from the the one whose care-of address is being
>      deregistered MAY add a Foreign-Home Authentication Extension to
>      such a deregistration.  However, as this deregistration concerns
>      a different foreign agent than the one whose authentication
>      extension, the home agent MUST disregard the Foreign-Home
>      Authentication Extension of such a deregistration.  The remaining
>      validity checks, as described in Section 3.8.2.1, are required in
>      full.
>
> Proposed text:
>
>      The home agent needs to clearly identify the foreign agent that
>      sent the Registration Request for authentication.  This requires
>      the foreign agent to append an extension containing its identity
>      when the Care-of Address and source IP address in the message do
>      not provide accurate foreign agent identification to the home
>      agent.  However, this extension may be appended indiscriminantly
>      by the foreign agent to avoid un-ambiguity for any condition. The
>      remaining validity checks, as described in Section 3.8.2.1, are
>      required in full.

Maybe.  As discussed by you and Pete yesterday, maybe this should be
separated as much as possible from 3344bis, and handled as a 3519bis or
completely separate issue, e.g. by the recently submitted draft.  In
that case, I'm thinking that maybe we could describe the problem, but
not solve it:

    There exists a situation where a home agent will have trouble
    correctly identifying the security association to apply to a
    registration request coming from a foreign agent.  This occurs when
    the mobile node attempts to de-register a care-of address it had
    with a previous foreign agent, when the current foreign agent is
    behind a NAT or is forwarding the registration request from a
    different source address than the mobile nodes currnt care-of
    address.  In this case, if the foreign address has a security
    association with the home agent, the home agent will not be able to
    identify the security association, as neither source address nor
    care-of address of the registration request will match the security
    association used by the foregn agent in creating the Foregn-Home
    Authentication Extension.  This may be solved by adding a separate
    foreign agent identification extension to the registration request,
    but this is outside the scope of the current specification.  In the
    absence of some means of correctly identifying the security
    association, the home agent has no choice but to reject the
    registration request, in accordance with the requirements in Section
    3.8.2.1.

Is this a way forward?

        Henrik
--=====================_2556145==_.ALT-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 16:49:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17067 for ; Tue, 18 May 2004 16:49:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBAO-000359-1J for mip4-archive@odin.ietf.org; Tue, 18 May 2004 16:26:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IKQNWm011837 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 16:26:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQASV-0006Zg-Fh for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09740 for ; Tue, 18 May 2004 15:41:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQASU-0001uB-3w for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:41:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQARW-0001rK-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:40:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQAQY-0001ok-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAKi-0001yv-RJ; Tue, 18 May 2004 15:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQADJ-0000XY-CU for mip4@optimus.ietf.org; Tue, 18 May 2004 15:25:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08536 for ; Tue, 18 May 2004 15:25:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQADH-000120-U9 for mip4@ietf.org; Tue, 18 May 2004 15:25:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQACT-0000we-00 for mip4@ietf.org; Tue, 18 May 2004 15:24:29 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQABc-0000oo-00 for mip4@ietf.org; Tue, 18 May 2004 15:23:36 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 May 2004 11:28:45 +0000 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 i4IJN4C1011451; Tue, 18 May 2004 12:23:04 -0700 (PDT) Received: from kleung-w2k01.cisco.com (sjc-vpn3-491.cisco.com [10.21.65.235]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATH18028; Tue, 18 May 2004 12:22:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20040518121936.023de398@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 May 2004 12:23:34 -0700 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List In-Reply-To: <20040518210627.0cfe9727.henrik@levkowetz.com> References: <4.3.2.7.2.20040518114703.02f55598@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040518114703.02f55598@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Hi Henrik. I think we're in agreement about not having a fix in 3344bis. It's just how to move forward on 3344bis with this problem. I think the latest approach is to describe the problem and say that's the way it is, and will be solved later. It's not the end of the world that this is not fixed right now as I've been pointing out as well. This scenario is a not common one. Though some good brain exercise went into providing some good answers later. :) Kent At 09:06 PM 5/18/2004 +0200, Henrik Levkowetz wrote: >Hi Kent, > >Tuesday 18 May 2004, Kent Leung wrote: > > The problem with MN sending a data packet to the HA is that > > what type of packet is this? It would have to be an encapsulated > > registration request. But HA doesn't have a tunnel with the MN. > > And MN cannot fake the source IP address as the FA's CoA > > since the FA may prevent invalid source IP address, as well as > > difficulty to map to reverse tunnel in some cases. > >This would have to be an encapsulated registration request, sent from >the MNs home address presumably, and you're right, the problem would be >in encapsulating it so that it's seen as data and not a registration >request by the FA. I'm wondering right now how our (ipUnplugged) HA >would handle IPIP in IP encapsulated traffic coming from an MN... > > > You're right that there's a fundamental difference in viewpoints. > > I believe that SA between peers is used to protect the exchange > > of messages, regardless of the content. If we provide clear > > identification of the peers, this solves the problem simply and > > generically. > >Yes. But not in 3344bis. And also not for legacy systems, but that >may be OK, if we see this as a needed extension for the use of FAs >in a 3519 context. > > Henrik > > > Kent > > > > At 08:33 PM 5/18/2004 +0200, Henrik Levkowetz wrote: > > >Hi Kent, > > > > > >Monday 17 May 2004, Kent Leung wrote: > > > > Hi Henrik. > > > > > > > > At 11:21 AM 5/17/2004 +0200, Henrik Levkowetz wrote: > > > > >[snip] > > > > > > > > > >I'd like to explore this a bit more - when you say you don't > see... above, > > > > >do yoou mean that you don't agree that the current FA (behind NAT or > > > > >sending from a different address than the CoA of the MN) under the > > > > >current rules can make it impossible to de-register an earlier care-of > > > > >address belonging to another FA - if there is a security association > > > > >between the current FA and it inserts an FHAE in the message trying to > > > > >de-register the old CoA? > > > > > > > > > >- or do you mean simply that you're not bothered by this ability > to block > > > > >the de-registration? > > > > > > > > > > > > I sensed that some folks see that the current FA is blocking the > RRQ. So > > > > just pointing out that FA is doing its job of securing the message to > > > the HA > > > > and we need to define a solution to achieve that properly. > > > > > >Yes. I think we have a small though basic disagreement on one point - > I see > > >the purpose of the FA using a FHAE as validating and authenticating the > > >parts of any registration exchange which concerns *that FA*. If there > is a > > >question of using its resources, it must authenticate that > usage. However, > > >how do we handle messages from the MN which in no way concern this FA? > > > > > >I've been considering various options which haven't been mentioned so far, > > >to my knowledge, like for instance requireing the FA to look at > deregistration > > >messages, and if they concern a CoA which is not its own, to not sign > them. > > >But this seems still not quite right to me. > > > > > >Let me test yet another one on you: > > > > > >The de-registration message in question could just as well have been sent > > >by the MN from any other address, as long as it's covered by a valid MN-HA > > >Auth. Ext. Is there any reason why the MN couldn't send this package as > > >*data traffic* to the HA, which would de-tunnel it, and route it to > itself? > > > > > >Then the FA (quite rightly) wouldn't see it as a registration request > > >concerning itself, to be protected with it's FHAE... > > > > > >Maybe I'm getting to wild here, but I keep returning to this idea that the > > >deregistration we're talking about really concerns nobody but the MN and > > >the HA, and could have been sent from any point really, not necessarily > > >from this particular FA. > > > > > > Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 16:49:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17095 for ; Tue, 18 May 2004 16:49:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBCQ-0003FW-9S for mip4-archive@odin.ietf.org; Tue, 18 May 2004 16:28:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IKSURq012485 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 16:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQATb-0006j7-8T for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:42:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09783 for ; Tue, 18 May 2004 15:42:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQATZ-0001yH-Q6 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:42:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQASd-0001vR-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:41:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQAS3-0001tP-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 15:40:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAOc-00040N-Ct; Tue, 18 May 2004 15:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAF9-0000sC-0I for mip4@optimus.ietf.org; Tue, 18 May 2004 15:27:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08707 for ; Tue, 18 May 2004 15:27:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQAF7-0001CE-Jg for mip4@ietf.org; Tue, 18 May 2004 15:27:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAE7-00017B-00 for mip4@ietf.org; Tue, 18 May 2004 15:26:12 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BQADB-0000zO-00 for mip4@ietf.org; Tue, 18 May 2004 15:25:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4IJO5832308; Tue, 18 May 2004 12:24:05 -0700 X-mProtect: <200405181924> 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 smtpdqm4Q5h; Tue, 18 May 2004 12:24:03 PDT Message-ID: <40AA62C9.63851725@iprg.nokia.com> Date: Tue, 18 May 2004 12:23:53 -0700 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: Henrik Levkowetz CC: Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document References: <4.3.2.7.2.20040516230344.02eebdd8@mira-sjcm-2.cisco.com> <20040515094408.5844e41c.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517161102.030d4e78@mira-sjcm-2.cisco.com> <16554.24002.804121.537389@gargle.gargle.HOWL> <20040518211347.162912b0.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Henrik, > > Maybe we just have to live with the fact that an MN might be unable to > > de-register an old CoA without cooperation of the current FA and a > > valid SA between the FA and its HA (having no SA is an example of a > > valid SA). Without such cooperation and valid SA, it is impossible to > > fix this problem even with an FA NAI. > > I agree. See my most recently proposed text, which I intended to say > bacically this :-) If the home agent gets a deregistration, and there is a Mbbile-Home Authentication extension which proves that the mobile node wants to deregister, then I think the home agent has to deregister the mobile node. If, in addition to the Mobile-Home authentication there is a Foreign-Home authentication that fails, then some action could conceivably be taken. I do not see that the home agent should ever disregard the authenticated instructions of a mobile node, regardless of the error condition between the foreign agent and the home agent. Regards, Charlie P. PS. Haven't we all been getting two copies of these messages? I deleted a few CC:'s. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 17:02:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18182 for ; Tue, 18 May 2004 17:02:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBWG-0002Nz-JE for mip4-archive@odin.ietf.org; Tue, 18 May 2004 16:49:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IKn0ti009167 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 16:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQB5b-0001Jd-3K for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 16:21:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13165 for ; Tue, 18 May 2004 16:21:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQB5U-0006J5-FB for mip4-web-archive@ietf.org; Tue, 18 May 2004 16:21:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQB3c-00061q-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 16:19:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQB1L-0005c5-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 16:17:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQARv-0006Fy-EJ; Tue, 18 May 2004 15:40:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQANj-0003rz-TY for mip4@optimus.ietf.org; Tue, 18 May 2004 15:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09506 for ; Tue, 18 May 2004 15:36:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQANi-0001gU-Df for mip4@ietf.org; Tue, 18 May 2004 15:36:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAMw-0001eu-00 for mip4@ietf.org; Tue, 18 May 2004 15:35:19 -0400 Received: from av3-1-sn3.vrr.skanova.net ([81.228.9.109]) by ietf-mx with esmtp (Exim 4.12) id 1BQAMB-0001Zs-00 for mip4@ietf.org; Tue, 18 May 2004 15:34:32 -0400 Received: by av3-1-sn3.vrr.skanova.net (Postfix, from userid 502) id E0A5A37ECA; Tue, 18 May 2004 21:34:00 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D1B8B37E49; Tue, 18 May 2004 21:34:00 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id A7A9738027; Tue, 18 May 2004 21:34:00 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BQALg-00045g-00; Tue, 18 May 2004 21:34:00 +0200 Date: Tue, 18 May 2004 21:34:00 +0200 From: Henrik Levkowetz To: Kent Leung Cc: Pete McCann , Sri Gundavelli , "Charles E.Perkins" , Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040518213400.58f392d8.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20040518120514.01cfe8d0@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517104646.02ef50e0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040518120514.01cfe8d0@mira-sjcm-2.cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kent, Continuing to refine this, There exists a situation where a home agent will not be able to correctly identify the security association to apply to a registration request coming from a foreign agent. This occurs when the mobile node attempts to de-register a care-of address it had with a previous foreign agent using the current foreign agent when the current foreign agent is behind a NAT device. In this case, if the foreign address has a security association with the home agent, the home agent will not be able to identify the security association, as neither source address nor care-of address of the registration request will match the security association used by the foreign agent in creating the Foreign-Home Authentication Extension. This may be solved by adding a separate foreign agent identification extension to the registration request, but this is outside the scope of the current specification. In the absence of some means of correctly identifying the security association, the home agent has no choice but to reject the registration request, in accordance with the requirements in Section 3.8.2.1. I reverted some of the changes - in the case of simultaneous bindings, I don't think it's quite correct to say that it's a previous care-of address, while it is a previous foreign agent. I took out the part you questioned - I think the FA may actually send from a different address than the care-of address, and this will also trigger the same problem - but maybe that's making the discussion too comples. Hm, wonder where that consistent misspelling of foreign came from - good catch. Henrik Tuesday 18 May 2004, Kent Leung wrote: > Hi Henrik. That was what I asked last time - about describing problem > only in 3344bis vs. having some solution. :) > > I've made some minor edits. Though underlined the part that I'm not > fully clear about. > > > There exists a situation where a home agent will not be able to > > correctly identify the security association to apply to a > > registration request coming from a foreign agent. This occurs when > > the mobile node attempts to de-register a previous care-of address > > using the current foreign agent which is > > behind a NAT device or is forwarding the registration request from a > > different source address than the mobile nodes current care-of > > address. In this case, if the foreign address has a security > > association with the home agent, the home agent will not be able to > > identify the security association, as neither source address nor > > care-of address of the registration request will match the security > > association used by the foreign agent in creating the Foreign-Home > > Authentication Extension. This may be solved by adding a separate > > foreign agent identification extension to the registration request, > > but this is outside the scope of the current specification. In the > > absence of some means of correctly identifying the security > > association, the home agent has no choice but to reject the > > registration request, in accordance with the requirements in Section > > 3.8.2.1. > > > Kent > > At 08:58 PM 5/18/2004 +0200, Henrik Levkowetz wrote: > >Hi Kent, > > > >Returning to the second part of your message. > > > >Monday 17 May 2004, Kent Leung wrote: > >... > > > I'm not sure if the following text is something you're looking for? > > > > > > The original text: > > > > > > A deregistration which is passed through a foreign agent which is > > > different from the the one whose care-of address is being > > > deregistered MAY add a Foreign-Home Authentication Extension to > > > such a deregistration. However, as this deregistration concerns > > > a different foreign agent than the one whose authentication > > > extension, the home agent MUST disregard the Foreign-Home > > > Authentication Extension of such a deregistration. The remaining > > > validity checks, as described in Section 3.8.2.1, are required in > > > full. > > > > > > Proposed text: > > > > > > The home agent needs to clearly identify the foreign agent that > > > sent the Registration Request for authentication. This requires > > > the foreign agent to append an extension containing its identity > > > when the Care-of Address and source IP address in the message do > > > not provide accurate foreign agent identification to the home > > > agent. However, this extension may be appended indiscriminantly > > > by the foreign agent to avoid un-ambiguity for any condition. The > > > remaining validity checks, as described in Section 3.8.2.1, are > > > required in full. > > > >Maybe. As discussed by you and Pete yesterday, maybe this should be > >separated as much as possible from 3344bis, and handled as a 3519bis or > >completely separate issue, e.g. by the recently submitted draft. In > >that case, I'm thinking that maybe we could describe the problem, but > >not solve it: > > > > There exists a situation where a home agent will have trouble > > correctly identifying the security association to apply to a > > registration request coming from a foreign agent. This occurs when > > the mobile node attempts to de-register a care-of address it had > > with a previous foreign agent, when the current foreign agent is > > behind a NAT or is forwarding the registration request from a > > different source address than the mobile nodes currnt care-of > > address. In this case, if the foreign address has a security > > association with the home agent, the home agent will not be able to > > identify the security association, as neither source address nor > > care-of address of the registration request will match the security > > association used by the foregn agent in creating the Foregn-Home > > Authentication Extension. This may be solved by adding a separate > > foreign agent identification extension to the registration request, > > but this is outside the scope of the current specification. In the > > absence of some means of correctly identifying the security > > association, the home agent has no choice but to reject the > > registration request, in accordance with the requirements in Section > > 3.8.2.1. > > > >Is this a way forward? > > > > Henrik > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 17:18:00 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19617 for ; Tue, 18 May 2004 17:18:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBqh-0001Ws-Dh for mip4-archive@odin.ietf.org; Tue, 18 May 2004 17:10:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ILA7P9005862 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 17:10:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBdA-0005FU-Q2 for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 16:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17813 for ; Tue, 18 May 2004 16:56:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQBd8-0003NE-Sn for mip4-web-archive@ietf.org; Tue, 18 May 2004 16:56:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQBcD-0003HU-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 16:55:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQBbO-0003C0-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 16:54:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBOh-0007iX-TX; Tue, 18 May 2004 16:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAbQ-0007Rh-7Y for mip4@optimus.ietf.org; Tue, 18 May 2004 15:50:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10277 for ; Tue, 18 May 2004 15:50:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQAbO-0002V1-KP for mip4@ietf.org; Tue, 18 May 2004 15:50:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAaV-0002Ry-00 for mip4@ietf.org; Tue, 18 May 2004 15:49:19 -0400 Received: from av9-2-sn1.fre.skanova.net ([81.228.11.116]) by ietf-mx with esmtp (Exim 4.12) id 1BQAZu-0002Nh-00 for mip4@ietf.org; Tue, 18 May 2004 15:48:42 -0400 Received: by av9-2-sn1.fre.skanova.net (Postfix, from userid 502) id 5D31037EFA; Tue, 18 May 2004 21:48:11 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av9-2-sn1.fre.skanova.net (Postfix) with ESMTP id 4BDB637EA2; Tue, 18 May 2004 21:48:11 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 338CA37E5F; Tue, 18 May 2004 21:48:11 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BQAZO-00046N-00; Tue, 18 May 2004 21:48:10 +0200 Date: Tue, 18 May 2004 21:48:10 +0200 From: Henrik Levkowetz To: "Charles E.Perkins" Cc: Mobile IPv4 Mailing List Subject: Re: [Mip4] [Issue 45] New revision for rfc3344bis document Message-Id: <20040518214810.00d3f9ed.henrik@levkowetz.com> In-Reply-To: <40AA62C9.63851725@iprg.nokia.com> References: <4.3.2.7.2.20040516230344.02eebdd8@mira-sjcm-2.cisco.com> <20040515094408.5844e41c.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517161102.030d4e78@mira-sjcm-2.cisco.com> <16554.24002.804121.537389@gargle.gargle.HOWL> <20040518211347.162912b0.henrik@levkowetz.com> <40AA62C9.63851725@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Charlie, So, the way I understand you is that you believe the original text I proposed was OK, while you think the most recent proposal is un-desireable? As I've tried to say earlier, I think the MNs deregistration of a CoA with a previous FA is none of the current FA's business, but it seems to be difficult to find a way of actually accomplishing this without breaking too much of the security between a FA and HA which have a common security association. At least that's the way I understand Kent here. I can accept my original text proposal, I can also accept that this problem is outside of 3344 and thus is mentioned but not solved - but I *do* wish us to get somewhere with this :-) Henrik Tuesday 18 May 2004, Charles E.Perkins wrote: > > Hello Henrik, > > > > Maybe we just have to live with the fact that an MN might be unable to > > > de-register an old CoA without cooperation of the current FA and a > > > valid SA between the FA and its HA (having no SA is an example of a > > > valid SA). Without such cooperation and valid SA, it is impossible to > > > fix this problem even with an FA NAI. > > > > I agree. See my most recently proposed text, which I intended to say > > bacically this :-) > > If the home agent gets a deregistration, and there > is a Mbbile-Home Authentication extension which > proves that the mobile node wants to deregister, > then I think the home agent has to deregister the > mobile node. If, in addition to the Mobile-Home > authentication there is a Foreign-Home authentication > that fails, then some action could conceivably be > taken. I do not see that the home agent should > ever disregard the authenticated instructions of > a mobile node, regardless of the error condition > between the foreign agent and the home agent. > > Regards, > Charlie P. > > PS. Haven't we all been getting two copies of these > messages? I deleted a few CC:'s. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 17:52:10 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21200 for ; Tue, 18 May 2004 17:52:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCU0-0002Ei-MJ for mip4-archive@odin.ietf.org; Tue, 18 May 2004 17:50:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ILoiZW008596 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 17:50:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCJr-0000z5-HM for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 17:40:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20844 for ; Tue, 18 May 2004 17:40:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQCJp-00071n-3U for mip4-web-archive@ietf.org; Tue, 18 May 2004 17:40:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQCJ2-0006yx-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 17:39:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQCIU-0006vC-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 17:38:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQCDq-00071p-Sp; Tue, 18 May 2004 17:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQC99-0005y1-Rd for mip4@optimus.ietf.org; Tue, 18 May 2004 17:29:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20321 for ; Tue, 18 May 2004 17:29:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQC97-0006K3-Fu for mip4@ietf.org; Tue, 18 May 2004 17:29:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQC8F-0006GG-00 for mip4@ietf.org; Tue, 18 May 2004 17:28:16 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1BQC7K-0006D2-00 for mip4@ietf.org; Tue, 18 May 2004 17:27:18 -0400 Message-ID: <04da01c43d1e$fd71e6b0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pete McCann" , "Mobile IPv4 Mailing List" References: <16554.23223.66121.836847@gargle.gargle.HOWL> Subject: Re: [Mip4] AD review comments on advance draft-ietf-mobileip-lowlatency-handoffs-v4-08.txt Date: Tue, 18 May 2004 14:27:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete, > Security considerations needs work. At a minimum, the text about "use > ESP" seems insufficient (see security AD comments in ID tracke for > draft-ietf-seamoby-card-protocol for starters - I suspect the same > point applies to this document.) THe security analysis as a whole > seems pretty weak, and in reading it, I didn't get a sense that the > security issues were well-understood. E.g., seems like a lot of the > security properties depend on L2 security, of which there is no > discussion. I.e., has a detailed analysis in the context of a specific > LL type been done? Could it be done? > The CARD draft was recently rewritten to use SEND signatures based on the SEND router certificates, as suggested by Steve Bellovin in the comments Thomas refers to here. The Seamoby WG is still in the process of discussing a few final comments about the document, but since CARD applies to IPv4 as well as IPv6, a similar solution might apply here (of course, the rewritten draft has not yet been through the IESG so there may yet be suprises in store for the Seamoby WG). The new CARD security protocol drops IPsec for the MN-AR interface and instead uses the SEND security association (IPsec remains for the AR-AR interface, however). One major issue is certificate exchange. In IPv6, the SEND DCS/DCA messages can be used for certificate exchange on the same router, but there's nothing like that for IPv4, even if the same signature format and certificate profile as SEND is used. The solution for CARD is to define a certificate exchange extension that works similarly to SEND, with the MN sending a list of trusted roots and the AR sending back the chain for one of them. An additional benefit that CARD provides is that the MN can solicit for certificates to handover candidate access routers connected to APs that the MN can see, thereby allowing the MN to have the certificate chain preconfigured for the new AR prior to movement. This can result in additional latency reduction for handover. Provided the MIP4 WG was willing to go with CARD certificate exchange, the SEND signature option could be reused for low latency handover PrxyRtXXX messages as was done for CARD. The alternative option would be to try defining something like DCS/DCA for IPv4, but there is little realistic chance that it would be deployed, since AFAICT, hosts in IPv4 rarely use router advertisments to discover their default routers, they use DHCP. The exception is Mobile IPv4 FAAdverts, of course. An alternative would be to reuse the MIPv4 MN-FA authentication extension for low latency. If the WG decides that it likes that alternative better, it might be a good idea to talk to Steve Bellovin and Russ Hously about it first, to make sure they are OK with it, to avoid another IESG return. While the SEND solution looks like a pretty good one from a technical standpoint for this problem, the assumption is that Steve preferred that solution since he explicitly mentioned it in his comments, which is secondarily why it was used in CARD. jak -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue May 18 22:52:11 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07518 for ; Tue, 18 May 2004 22:52:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQH2V-0007KD-Pf for mip4-archive@odin.ietf.org; Tue, 18 May 2004 22:42:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J2gd0b028152 for mip4-archive@odin.ietf.org; Tue, 18 May 2004 22:42:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQGxX-0006PW-Id for mip4-web-archive@optimus.ietf.org; Tue, 18 May 2004 22:37:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07052 for ; Tue, 18 May 2004 22:37:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQGxU-00070b-93 for mip4-web-archive@ietf.org; Tue, 18 May 2004 22:37:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQGwU-0006vu-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 22:36:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQGw1-0006rA-00 for mip4-web-archive@ietf.org; Tue, 18 May 2004 22:35:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQGiZ-0004J4-Bn; Tue, 18 May 2004 22:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQGdL-0003IJ-Qz for mip4@optimus.ietf.org; Tue, 18 May 2004 22:16:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06511 for ; Tue, 18 May 2004 22:16:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQGdI-0005NU-MO for mip4@ietf.org; Tue, 18 May 2004 22:16:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQGca-0005HH-00 for mip4@ietf.org; Tue, 18 May 2004 22:15:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BQGbt-00053p-00 for mip4@ietf.org; Tue, 18 May 2004 22:15:09 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 18 May 2004 19:14:15 -0700 Received: from ajamwal-u60.cisco.com (ajamwal-u60.cisco.com [128.107.132.155]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i4J2EcjP024974; Tue, 18 May 2004 19:14:38 -0700 (PDT) Date: Tue, 18 May 2004 19:14:38 -0700 (PDT) From: Sri Gundavelli To: mip4@ietf.org cc: Henrik Levkowetz , Pete McCann In-Reply-To: <4.3.2.7.2.20040518125631.027d8068@mira-sjcm-2.cisco.com> Message-ID: References: <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <20040514103648.473e180f.henrik@levkowetz.com> <409FC50E.301F4CEE@iprg.nokia.com> <20040510235321.11c8f1ee.henrik@levkowetz.com> <40A47571.CBF7A716@cisco.com> <20040514095641.2e2d5194.henrik@levkowetz.com> <20040514103648.473e180f.henrik@levkowetz.com> <4.3.2.7.2.20040514203731.024d3228@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040516225801.024c9708@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040517163452.0259e548@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040518120054.02f54218@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040518125631.027d8068@mira-sjcm-2.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Mip4] Fwd: I-D ACTION:draft-sgundave-mip4-identity-ext-00.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 I've posted this ID couple of days back ..., never made it to the WG. Please post your comments. Thanks ! Sri >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>. To: i-d-announce at ietf.org Subject: I-D ACTION:draft-sgundave-mip4-identity-ext-00.txt From: Internet-Drafts at ietf.org Date: Fri, 14 May 2004 15:39:43 -0400 List-help: List-id: List-post: List-subscribe: , List-unsubscribe: , Reply-to: internet-drafts at ietf.org Sender: i-d-announce-admin at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility Agent Identity Extension for Mobile IPv4 Author(s) : S. Gundavelli, K. Leung Filename : draft-sgundave-mip4-identity-ext-00.txt Pages : 5 Date : 2004-5-14 This document specifies a new extension that can be used by any mobility agent operating Mobile IPv4 protocol in the Mobile IP Registration messages for offering its identity to the other mobility agent receiving the message. This is a generic extension that can be used in the Registration Request or Reply message and can be used by the Home Agent, Foreign Agent and the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sgundave-mip4-identity-ext-00.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-sgundave-mip4-identity-ext-00.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-sgundave-mip4-identity-ext-00.txt". -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 21 03:25:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12114 for ; Fri, 21 May 2004 03:25:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR4Ix-0007az-LE for mip4-archive@odin.ietf.org; Fri, 21 May 2004 03:18:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L7ItOG029197 for mip4-archive@odin.ietf.org; Fri, 21 May 2004 03:18:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR4Ek-00068W-GA for mip4-web-archive@optimus.ietf.org; Fri, 21 May 2004 03:14:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11255 for ; Fri, 21 May 2004 03:14:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR4Ei-00032k-CU for mip4-web-archive@ietf.org; Fri, 21 May 2004 03:14:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR4Dc-0002sm-00 for mip4-web-archive@ietf.org; Fri, 21 May 2004 03:13:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR4D1-0002lX-00 for mip4-web-archive@ietf.org; Fri, 21 May 2004 03:12:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR42i-0003Me-4z; Fri, 21 May 2004 03:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR3xa-0002CR-Ul for mip4@optimus.ietf.org; Fri, 21 May 2004 02:56:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10209 for ; Fri, 21 May 2004 02:56:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR3xW-0000c5-TN for mip4@ietf.org; Fri, 21 May 2004 02:56:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR3wT-0000OQ-00 for mip4@ietf.org; Fri, 21 May 2004 02:55:42 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BR3vE-00003q-00 for mip4@ietf.org; Fri, 21 May 2004 02:54:25 -0400 Received: from archana70282 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HY100KGLXBNHE@mta0.huawei.com> for mip4@ietf.org; Fri, 21 May 2004 14:43:01 +0800 (CST) Date: Fri, 21 May 2004 12:14:00 +0530 From: Archana To: mip4@ietf.org Message-id: <000001c43eff$057bf990$4504120a@archana70282> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:59.31180 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) Content-Transfer-Encoding: 7BIT Subject: [Mip4] Minor corrcetion to draft-ietf-mip4-rfc3012bis-01.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi There is a minor correction that needs to be made on the following section in the draft draft-ietf-mip4-rfc3012bis-01.txt The existing text is as follows. Appendix C. 5. The foreign agent relays the Registration Reply to the mobile node, possibly along with a new Challenge Value to be used by the mobile node in its next Registration Reply message The Registration Reply should be changed to Registration Request message. 5. The foreign agent relays the Registration Reply to the mobile node, possibly along with a new Challenge Value to be used by the mobile node in its next Registration Request message Kindly ignore if this correction is already been reported. Regards Archana -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 21 06:39:02 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22596 for ; Fri, 21 May 2004 06:39:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7Fy-0005i0-Bq for mip4-archive@odin.ietf.org; Fri, 21 May 2004 06:28:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LAS2WF021921 for mip4-archive@odin.ietf.org; Fri, 21 May 2004 06:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR73f-0002sv-SA for mip4-web-archive@optimus.ietf.org; Fri, 21 May 2004 06:15:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21068 for ; Fri, 21 May 2004 06:15:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR73c-0006SN-3g for mip4-web-archive@ietf.org; Fri, 21 May 2004 06:15:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR714-00060b-00 for mip4-web-archive@ietf.org; Fri, 21 May 2004 06:12:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR6yr-0005d0-00 for mip4-web-archive@ietf.org; Fri, 21 May 2004 06:10:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6ox-000685-Cc; Fri, 21 May 2004 06:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6kU-0004y6-BZ for mip4@optimus.ietf.org; Fri, 21 May 2004 05:55:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19867 for ; Fri, 21 May 2004 05:55:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR6kQ-00033t-Nd for mip4@ietf.org; Fri, 21 May 2004 05:55:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR6jf-0002va-00 for mip4@ietf.org; Fri, 21 May 2004 05:54:39 -0400 Received: from [140.119.80.147] (helo=hliu.com) by ietf-mx with smtp (Exim 4.12) id 1BR6j7-0002lb-00 for mip4@ietf.org; Fri, 21 May 2004 05:54:05 -0400 Date: Fri, 21 May 2004 17:54:05 +0800 To: "Mip" From: "Henrik" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------dxqtdiiuhybmxijqraiw" Subject: [Mip4] Encrypted document Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.60 ----------dxqtdiiuhybmxijqraiw Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------dxqtdiiuhybmxijqraiw Content-Type: application/octet-stream; name="the_message.cpl" Content-Disposition: attachment; filename="the_message.cpl" Content-Transfer-Encoding: base64 ----------dxqtdiiuhybmxijqraiw-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 21 12:05:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10992 for ; Fri, 21 May 2004 12:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRCFG-0007XT-2S for mip4-archive@odin.ietf.org; Fri, 21 May 2004 11:47:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LFlcsf028980 for mip4-archive@odin.ietf.org; Fri, 21 May 2004 11:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRCDO-0006rZ-4A for mip4-web-archive@optimus.ietf.org; Fri, 21 May 2004 11:45:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09918 for ; Fri, 21 May 2004 11:45:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRCDM-00071P-Uj for mip4-web-archive@ietf.org; Fri, 21 May 2004 11:45:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRCCV-0006ye-00 for mip4-web-archive@ietf.org; Fri, 21 May 2004 11:44:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRCC5-0006vv-00 for mip4-web-archive@ietf.org; Fri, 21 May 2004 11:44:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRBvJ-0001cx-4Y; Fri, 21 May 2004 11:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRBoO-0008Gy-Q8 for mip4@optimus.ietf.org; Fri, 21 May 2004 11:19:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08408 for ; Fri, 21 May 2004 11:19:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRBoN-0005J9-Sn for mip4@ietf.org; Fri, 21 May 2004 11:19:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRBnV-00054m-00 for mip4@ietf.org; Fri, 21 May 2004 11:18:58 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BRBmt-0004oC-00 for mip4@ietf.org; Fri, 21 May 2004 11:18:19 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4LFHgn22951; Fri, 21 May 2004 11:17:42 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 May 2004 11:17:43 -0400 Message-ID: From: "Jayshree Bharatia" To: "'Archana'" , "'mip4@ietf.org'" Subject: RE: [Mip4] Minor corrcetion to draft-ietf-mip4-rfc3012bis-01.txt Date: Fri, 21 May 2004 11:17:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Hello Archana, Similar typo also exists in appendix D. I will correct both these errors. Thanks for your comments. Regards, Jayshree -----Original Message----- From: Archana [mailto:archana_p@huawei.com] Sent: Friday, May 21, 2004 1:44 AM To: mip4@ietf.org Subject: [Mip4] Minor corrcetion to draft-ietf-mip4-rfc3012bis-01.txt Hi There is a minor correction that needs to be made on the following section in the draft draft-ietf-mip4-rfc3012bis-01.txt The existing text is as follows. Appendix C. 5. The foreign agent relays the Registration Reply to the mobile node, possibly along with a new Challenge Value to be used by the mobile node in its next Registration Reply message The Registration Reply should be changed to Registration Request message. 5. The foreign agent relays the Registration Reply to the mobile node, possibly along with a new Challenge Value to be used by the mobile node in its next Registration Request message Kindly ignore if this correction is already been reported. Regards Archana -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.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://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri May 21 19:02:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11382 for ; Fri, 21 May 2004 19:02:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRIuB-0005to-8d for mip4-archive@odin.ietf.org; Fri, 21 May 2004 18:54:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LMsJrb022652 for mip4-archive@odin.ietf.org; Fri, 21 May 2004 18:54:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRIot-0004ZE-Kt for mip4-web-archive@optimus.ietf.org; Fri, 21 May 2004 18:48:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10650 for ; Fri, 21 May 2004 18:48:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRIoq-0006Iu-Db for mip4-web-archive@ietf.org; Fri, 21 May 2004 18:48:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRInw-0006EW-00 for mip4-web-archive@ietf.org; Fri, 21 May 2004 18:47:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRIn4-00069o-00 for mip4-web-archive@ietf.org; Fri, 21 May 2004 18:46:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRIdQ-0002Fh-Mz; Fri, 21 May 2004 18:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQs5H-0005vB-Lt for mip4@optimus.ietf.org; Thu, 20 May 2004 14:15:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08479 for ; Thu, 20 May 2004 14:15:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQs5F-0006af-0L for mip4@ietf.org; Thu, 20 May 2004 14:15:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQs4U-0006Vh-00 for mip4@ietf.org; Thu, 20 May 2004 14:15:12 -0400 Received: from lennier.cc.vt.edu ([198.82.162.213]) by ietf-mx with esmtp (Exim 4.12) id 1BQs3J-0006Qx-00; Thu, 20 May 2004 14:13:57 -0400 Received: from zidane.cc.vt.edu (IDENT:mirapoint@evil-zidane [10.1.1.13]) by lennier.cc.vt.edu (8.12.8/8.12.8) with ESMTP id i4KI9deh352804; Thu, 20 May 2004 14:09:39 -0400 (EDT) Received: from TomXP.vt.edu (thoupc2.ece.vt.edu [128.173.52.68]) by zidane.cc.vt.edu (MOS 3.4.6-GR) with ESMTP id AUW53827; Thu, 20 May 2004 14:09:19 -0400 (EDT) Message-Id: <6.0.1.1.2.20040520140546.02f4b6a8@pop.vt.edu> X-Sender: hou@pop.vt.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 20 May 2004 14:09:19 -0400 To: Thomas Hou From: Thomas Hou Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_97908203==.ALT" X-Junkmail-Status: score=11/50, host=zidane.cc.vt.edu Subject: [Mip4] CALL FOR PAPERS: QShine 2004 - The First International Conference on Quality of Service in Heterogeneous Wired/Wireless Networks Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --=====================_97908203==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed CALL FOR PAPERS QShine 2004 - First International Conference on Quality of Service in Heterogeneous Wired/Wireless Networks October 18-20, 2004, Dallas, TX, USA http://www.qshine.org/ Scope: ------------------------------- Recent technological developments in broadband high-speed networks, peer-to-peer networks, wireless and mobile networks, and grid computing have led to newer challenging problems, such as providing QoS support to the emerging high-speed Internet and multimedia applications across both wired and wireless networks. This conference will focus on all aspects of QoS support for heterogeneous wired and wireless networks. Papers addressing cross-layer design on QoS support for both wired and wireless networks are strongly encouraged. It will serve as a forum for researchers from both academia and industry for presenting recent research results in QoS issues for both wired and wireless networks. The conference features prominent invited speakers as well as papers by top researchers in the field. The scope of the conference includes, but is not limited to: - QoS in wireless local area networks - QoS in sensor networks and wireless ad-hoc networks - QoS support and mobility management in wireless Internet - QoS in wireless and mobile multimedia - QoS provisioning in mobile IP and IPv6 - Scheduling policies for wireless networks - QoS in current and emerging cellular and satellite networks - Differentiated service in wireless multimedia networks - QoS in broadband high-speed networks - QoS in optical networks - QoS support for Internet applications - QoS across heterogeneous link technologies - Middleware support for QoS provision - Policy-based QoS differentiation - Interactive broadband television, gaming, and video distribution - Variable and adaptive QoS - QoS modeling and measurement - QoS routing, resource management, and admission control - QoS pricing and billing - QoS architectures, protocols, and systems - QoS in web systems and storage systems - QoS specification, metrics, and analysis - QoS in peer-to-peer networks, grid and application-layer overlay networks - Security aspects of QoS systems Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in ACM / Kluwer Wireless Networks (WINET). Submission Guidelines: ------------------------------- Papers should not exceed 20 pages, must be unpublished and must not be submitted for publication elsewhere. All submissions should be sent electronically in Postscript or Adobe PDF format. Electronic submission instructions will be available at http://www.qshine.org/. Important Dates: -------------------------------- Submission Deadline: May 28, 2004 Notification of Acceptance: July 26, 2004 Camera-ready Manuscripts Due: August 20, 2004 Conference Dates: October 18-20, 2004 Organizing Committee --------------------------------- General Chair: Azzedine Boukerche, University of Ottawa, Canada, Vice Chair: Michael Fang, University of Florida Technical Program Co-Chairs Jorge Cobb, University of Texas at Dallas Shigang Chen, University of Florida Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas Publicity Co-Chairs: Mirela Sechi M. Annoni Notare, Barddal University, Brazil Thomas Hou, Virginia Tech Local Chair & Finance Chair: Hua Zhu, University of Texas at Dallas --=====================_97908203==.ALT Content-Type: text/html; charset="us-ascii"

CALL FOR PAPERS
QShine 2004 - First International Conference on
Quality of Service in Heterogeneous Wired/Wireless Networks
October 18-20, 2004, Dallas, TX, USA
http://www.qshine.org/
 
Scope:
-------------------------------
Recent technological developments in broadband high-speed networks, peer-to-peer networks, wireless and mobile networks, and grid computing have led to newer challenging problems, such as providing QoS support to the emerging high-speed Internet and multimedia applications across both wired and wireless networks.
This conference will focus on all aspects of QoS support for heterogeneous wired and wireless networks. Papers addressing cross-layer design on QoS support for both wired and wireless networks are strongly encouraged. It will serve as a forum for researchers from both academia and industry for presenting recent research results in QoS issues for both wired and wireless networks. The conference features prominent invited speakers as well as papers by top researchers in the field.

The scope of the conference includes, but is not limited to:

- QoS in wireless local area networks
- QoS in sensor networks and wireless ad-hoc networks
- QoS support and mobility management in wireless Internet
- QoS in wireless and mobile multimedia
- QoS provisioning in mobile IP and IPv6
- Scheduling policies for wireless networks
- QoS in current and emerging cellular and satellite networks
- Differentiated service in wireless multimedia networks
- QoS in broadband high-speed networks
- QoS in optical networks
- QoS support for Internet applications
- QoS across heterogeneous link technologies
- Middleware support for QoS provision
- Policy-based QoS differentiation
- Interactive broadband television, gaming, and video distribution
- Variable and adaptive QoS
- QoS modeling and measurement
- QoS routing, resource management, and admission control
- QoS pricing and billing
- QoS architectures, protocols, and systems
- QoS in web systems and storage systems
- QoS specification, metrics, and analysis
- QoS in peer-to-peer networks, grid and application-layer overlay networks
- Security aspects of QoS systems

Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in ACM / Kluwer Wireless Networks (WINET).

Submission Guidelines:
-------------------------------
Papers should not exceed 20 pages, must be unpublished and must not be submitted for publication elsewhere. All submissions should be sent electronically in Postscript or Adobe PDF format. Electronic submission instructions will be available at http://www.qshine.org/.

Important Dates:
--------------------------------
Submission Deadline:    May 28, 2004
Notification of Acceptance:     July 26, 2004
Camera-ready Manuscripts Due:   August 20, 2004
Conference Dates:       October 18-20, 2004

Organizing Committee
---------------------------------
General Chair:
        Azzedine Boukerche, University of Ottawa, Canada,

Vice Chair:
        Michael Fang, University of Florida

Technical Program Co-Chairs
        Jorge Cobb, University of Texas at Dallas       
        Shigang Chen, University of Florida

Steering Committee Chair:
        Imrich Chlamtac, University of Texas at Dallas

Publicity Co-Chairs:
        Mirela Sechi M. Annoni Notare, Barddal University, Brazil
        Thomas Hou, Virginia Tech

Local Chair & Finance Chair:
        Hua Zhu, University of Texas at Dallas  


        
--=====================_97908203==.ALT-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon May 24 10:33:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10311 for ; Mon, 24 May 2004 10:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGMh-00087a-53 for mip4-archive@odin.ietf.org; Mon, 24 May 2004 10:23:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OENhpB031218 for mip4-archive@odin.ietf.org; Mon, 24 May 2004 10:23:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGCo-0006b3-Mu for mip4-web-archive@optimus.ietf.org; Mon, 24 May 2004 10:13:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08433 for ; Mon, 24 May 2004 10:13:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGCm-0007aY-Eb for mip4-web-archive@ietf.org; Mon, 24 May 2004 10:13:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGBs-0007X2-00 for mip4-web-archive@ietf.org; Mon, 24 May 2004 10:12:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSGBY-0007Ss-00 for mip4-web-archive@ietf.org; Mon, 24 May 2004 10:12:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFvy-0003fM-OW; Mon, 24 May 2004 09:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFkx-000235-6z for mip4@optimus.ietf.org; Mon, 24 May 2004 09:44:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05899 for ; Mon, 24 May 2004 09:44:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFkv-0005Fg-9J for mip4@ietf.org; Mon, 24 May 2004 09:44:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFja-00055N-00 for mip4@ietf.org; Mon, 24 May 2004 09:43:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BSFiG-0004tG-00; Mon, 24 May 2004 09:41:56 -0400 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 i4ODfNf9023792; Mon, 24 May 2004 06:41:23 -0700 (PDT) Received: from cisco.com (sjc-vpn1-412.cisco.com [10.21.97.156]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATL21938; Mon, 24 May 2004 06:40:33 -0700 (PDT) Message-ID: <40B1FBA1.3050602@cisco.com> Date: Mon, 24 May 2004 06:41:53 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org, alpesh@cisco.com, kleung@cisco.com, internet-drafts@ietf.org, mccap@lucent.com, henrik@levkowetz.com Content-Type: multipart/mixed; boundary="------------060202080106040005040303" Subject: [Mip4] draft-mip4-experimental-messages-03.txt - New version before posting to IESG Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060202080106040005040303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi - A new of the draft "Experimental Message, Extension and Error Codes for Mobile IPv4" is attached herewith for your reference. We have added two new subsections regarding experimental extensions in ICMP router advertisement messages used by MIPv4. Thanks alpesh --------------060202080106040005040303 Content-Type: text/plain; name="draft-ietf-mip4-experimental-messages-03.txt" Content-Disposition: inline; filename="draft-ietf-mip4-experimental-messages-03.txt" Content-Transfer-Encoding: 7bit Mobile IP Working Group Alpesh Patel INTERNET DRAFT Kent Leung 11 May 2004 Cisco Systems Experimental Message, Extension and Error Codes for Mobile IPv4 draft-ietf-mip4-experimental-messages-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) The Internet Society (2004). All Rights Reserved. Abstract Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purpose, to evaluate enhancements to Mobile IPv4 messages before formal standards proposal. Patel, Leung Expires November 10, 2004 [Page 1] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 Table of Contents 1. Introduction.............................................2 2. Terminology..............................................3 3. Experimental Message.....................................3 4. Experimental Extensions..................................4 4.1 Non-skippable Mobile IPv4 Experimental Extension........5 4.2 Non-skippable Router Discovery Experimental Extension...5 4.3 Skippable Mobile IPv4 Experimental Extension............6 4.4 Skippable ICMP Router Discovery Experimental Extension..7 5. Experimental Error Codes.................................7 6. Mobility Entity Considerations...........................7 7. IANA Considerations......................................8 8. Security Considerations..................................8 9. Backward Compatibility Considerations....................9 10. Intellectual Property Rights............................9 11. Acknowledgements........................................9 12. References.............................................10 12.1 Normative References..................................10 12.2 Informative References................................10 13. Authors' Addresses.....................................10 Intellectual Property Statement............................11 Full Copyright Statement...................................11 1. Introduction Mobile IPv4 message types range from 0 to 255. This document reserves a message type for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before formal standards proposal. Without experimental message capability, one would have to select a type value from the range defined for IANA assignment, which may result in collisions. Also, Mobile IP defines a general extension mechanism to allow optional information to be carried by Mobile IP control messages. Extensions are not skippable if defined in range [0-127] and skippable if defined in range [128-255]. This document reserves extension types in both the skippable and non-skippable range for experimental use. Mobile IPv4 defines error codes for use by the FA [64-127] and HA [128-192]. This document reserves an error code in both these ranges for experimental use. This document defines and reserves experimental numbers as per the recommendation of BCP 82 (section 2.2), RFC 3692. Patel, Leung Expires November 10, 2004 [Page 2] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. In addition, this document frequently uses the following terms: EXP-MSG-TYPE: A Mobile-IPv4 message number in the range [0-255] to be assigned by IANA for experimental use. EXP-SKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery (advertisement) extension number in the range [128-255] to be assigned by IANA for experimental use. EXP-NONSKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery (advertisement) extension number in the range [0-127] to be assigned by IANA for experimental use. EXP-HA-ERROR-CODE: A Mobile-IPv4 error code in the range [128- 192] for use by HA in reply messages to indicate error condition. EXP-FA-ERROR-CODE: A Mobile-IPv4 error code in the range [64- 127] for use by FA in reply messages to indicate error condition. Mobility Entity: Entities as defined in [2] (home agent, foreign agent and mobile node). 3. Experimental Message Since the nature and purpose of an experimental message cannot be known in advance, the structure is defined as an opaque payload. Entities implementing the message can interpret the message as per their implementation. One suggestion is to interpret based on extensions present in the message. These messages may be used between the mobility entities (Home Agent, Foreign Agent, and Mobile Node). Experimental messages SHOULD be authenticated using any of the authentication mechanism defined for Mobile IP ([2], [5]). Patel, Leung Expires November 10, 2004 [Page 3] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 This message MAY contain extensions defined in Mobile IP, including vendor specific extensions [4]. IP fields: Source Address Typically the interface address from which the message is sent. Destination Address The address of the agent or the Mobile Node. UDP fields: Source Port Set according to RFC 768 (variable) Destination Port Set to the value 434 Mobile IP fields shown below follow the UDP header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Opaque. . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type EXP-MSG-TYPE (To be assigned by IANA) Opaque Zero or more octets of data, with structure defined only by the particular experiment it is used for. Once an experimental message has been tested and shown to be useful, a permanent number should be obtained through the normal assignment procedures. A single experimental message type is recommended since this message can contain extensions based on which the message can be interpreted. 4. Experimental Extensions This document reserves Mobile IPv4 extensions in both the skippable and non-skippable range for experimental purposes. The long extension format (for non-skippable extensions) and short extension format (for skippable extensions), as defined by [2] are used for Mobile IPv4 experimental extensions. Patel, Leung Expires November 10, 2004 [Page 4] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 Also, ICMP router discovery extension numbers in both the skippable and non-skippable range are reserved for experimental use. 4.1 Non-skippable Mobile IPv4 Experimental Extension This format is applicable for non-skippable extensions and may carry information more than 256 bytes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque. . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type EXP-NONSKIP-EXT-TYPE (to be assigned by IANA) is the type, which describes an experimental extension. Sub-Type is a unique number given to each member in the aggregated type. Length Indicates the length (in bytes) of the data field within this extension. It does NOT include the Type, Sub-Type and Length bytes. Opaque Zero or more octets of data, with structure defined only by the particular experiment it is used for. Since the length field is 16 bits wide, the extension data can exceed 256 bytes in length. 4.2 Non-skippable Router Discovery Experimental Extension This format is applicable for non-skippable extensions. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Opaque . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Patel, Leung Expires November 10, 2004 [Page 5] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 Type EXP-NONSKIP-EXT-TYPE (to be assigned by IANA) is the type, which describes an ICMP router discovery experimental extension. Length Indicates the length (in bytes) of the data field within this extension. It does NOT include the Type, Sub-Type and Length bytes. Opaque Zero or more octets of data, with structure defined only by the particular experiment it is used for. A node, which receives a router advertisement with this extension should ignore the extension if it does not recognize it. A mobility entity, which understands this extension, but does not recognize it should drop (ignore) the router advertisement. 4.3 Skippable Mobile IPv4 Experimental Extension This format is applicable for skippable extensions, which carry information less than 256 bytes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Opaque. . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type EXP-SKIP-EXT-TYPE (to be assigned by IANA) is the type, which describes an experimental extension. Length Indicates the length (in bytes) of the data field within this extension. It does NOT include the Type and Length bytes. Sub-Type is a unique number given to each member in the aggregated type. Opaque Zero or more octets of data, with structure defined only by the particular experiment it is used for. Since the length field is 8 bits wide, the extension data cannot exceed 256 bytes in length. Patel, Leung Expires November 10, 2004 [Page 6] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 4.4 Skippable ICMP Router Discovery Experimental Extension This format is applicable for skippable ICMP router discovery extensions. This extension should be ignored if an implementation does not understand it. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Opaque. . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type EXP-SKIP-EXT-TYPE (to be assigned by IANA) is the type, which describes an experimental extension. Length Indicates the length (in bytes) of the data field within this extension. It does NOT include the Type and Length bytes. Opaque Zero or more octets of data, with structure defined only by the particular experiment it is used for. A node, which receives a router advertisement with this extension should ignore the extension. 5. Experimental Error Codes This document reserves reply error code EXP-FA-ERROR-CODE, in the range [64-127], for use by the FA. This document also reserves reply error code EXP-HA-ERROR-CODE, in the range [128- 192], for use by the HA. These experimental error codes may be used in registration reply messages. It is recommended that experimental error codes are used with experimental messages and extensions whenever none of the standardized error codes are applicable. 6. Mobility Entity Considerations Patel, Leung Expires November 10, 2004 [Page 7] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 Mobility entities can send and receive experimental messages. Implementations that don't understand the message type SHOULD silently discard the message. Experimental extensions can be carried in experimental messages and standards defined messages. In the later case, it is suggested that experimental extensions MUST not be used in deployed products and usage be restricted to experimentations only. 7. IANA Considerations IANA services are required for this draft. Since a new message type is needed to be reserved as experimental, a value must be assigned for EXP-MSG-TYPE from the Mobile IP control message space. Also, values for EXP-NONSKIP-EXT-TYPE and EXP-SKIP-EXT-TYPE must be assigned for experimental extensions. The value for EXP-NONSKIP-EXT-TYPE should be assigned from the numbering space for non-skippable extensions which may appear in control messages, and also (with the same number) from the numbering space for non-skippable extensions which may appear in ICMP router discovery messages. The value 127 is suggested in both cases. The value for EXP-SKIP-EXT-TYPE should be assigned from the numbering space for skippable extensions which may appear in control messages, and also (with the same number) from the numbering space for skippable extensions which may appear in ICMP router discovery messages. The value 255 is suggested in both cases. Also, values for EXP-HA-ERROR-CODE and EXP-FA-ERROR-CODE must be assigned for experimental error code. The suggested values are 192 for the EXP-HA-ERROR-CODE and 127 for the EXP-FA-ERROR- CODE. 8. Security Considerations Like all Mobile IP control messages, the experimental messages MUST be authenticated as per the requirements specified in [2] or [5]. Experimental messages without a valid authenticator MUST be discarded. Patel, Leung Expires November 10, 2004 [Page 8] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 9. Backward Compatibility Considerations Mobility entities that don't understand the experimental message MUST silently discard it. Mobility entities that don't understand the experimental skippable extensions MUST ignore them. Mobility entities that don't understand the non-skippable experimental extensions MUST silently discard the message containing them. FA and HA SHOULD include experimental error code in reply message only if they have a general indication that the receiving entity would be able to parse it. An indication of this is if the request message was of type EXP-MSG-TYPE or contained at-least one experimental extension. 10. Intellectual Property Rights The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 11. Acknowledgements Patel, Leung Expires November 10, 2004 [Page 9] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 The authors would like to acknowledge Henrik Levkowetz for his detailed review of the draft and suggestion to incorporate experimental extensions in this draft. The authors would also like to acknowledge Thomas Narten for his initial review of the draft and reference to [6] for general guidelines. 12. References 12.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Perkins, C., "IP Mobility Support", RFC 3344, August 2002. [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. 12.2 Informative References [4] G. Dommety, K. Leung, "Mobile IP Vendor/Organization-Specific Extensions" RFC 3115, April 2001 [5] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000 [6] T. Narten, "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January, 2004 13. Authors' Addresses Questions and comments about this draft should be directed at the Mobile IPv4 working group: mip4@ietf.org Questions and comments about this draft may also be directed to the authors: Alpesh Patel Patel, Leung Expires November 10, 2004 [Page 10] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134 USA Email: alpesh@cisco.com Phone: +1 408-853-9580 Kent Leung Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134 USA Email: kleung@cisco.com Phone: +1 408-526-5030 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in Patel, Leung Expires November 10, 2004 [Page 11] Internet Draft Experimental Mesg., Ext. & Error Codes May 2004 part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Patel, Leung Expires November 10, 2004 [Page 12] --------------060202080106040005040303-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/