From exim@www1.ietf.org Mon Feb 2 16:04:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09362 for ; Mon, 2 Feb 2004 16:04:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlET-0007Dv-T5 for mip6-archive@odin.ietf.org; Mon, 02 Feb 2004 16:03:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12L3nTb027767 for mip6-archive@odin.ietf.org; Mon, 2 Feb 2004 16:03:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlET-0007Dk-Nl for mip6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 16:03:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09294 for ; Mon, 2 Feb 2004 16:03:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnlES-0000qU-00 for mip6-web-archive@ietf.org; Mon, 02 Feb 2004 16:03:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnlDV-0000lL-00 for mip6-web-archive@ietf.org; Mon, 02 Feb 2004 16:02:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnlCn-0000gi-00 for mip6-web-archive@ietf.org; Mon, 02 Feb 2004 16:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlCj-00076a-CW; Mon, 02 Feb 2004 16:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlC9-00075e-34 for mip6@optimus.ietf.org; Mon, 02 Feb 2004 16:01:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09115; Mon, 2 Feb 2004 16:01:22 -0500 (EST) Message-Id: <200402022101.QAA09115@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 02 Feb 2004 16:01:21 -0500 Subject: [Mip6] I-D ACTION:draft-daniel-mip6-optimized-vertical-handover-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,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. Title : L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Exampl Author(s) : S. Park Filename : draft-daniel-mip6-optimized-vertical-handover-00.txt Pages : 19 Date : 2004-2-2 This document describes a mechanism that extends Mobile IPv6 protocol to smoothly manage handovers for Mobile Nodes equipped with multiple interfaces and moving across different and heterogeneous links. For this purpose, the document provides indications on how to use the link events information to optimize L3 movement detection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daniel-mip6-optimized-vertical-handover-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-daniel-mip6-optimized-vertical-handover-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-daniel-mip6-optimized-vertical-handover-00.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-2-2150443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daniel-mip6-optimized-vertical-handover-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-daniel-mip6-optimized-vertical-handover-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150443.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 2 17:15:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17690 for ; Mon, 2 Feb 2004 17:15:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmKw-0005Xp-Ly for mip6-archive@odin.ietf.org; Mon, 02 Feb 2004 17:14:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12MEYeb021308 for mip6-archive@odin.ietf.org; Mon, 2 Feb 2004 17:14:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmKv-0005Xb-6m for mip6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 17:14:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17595 for ; Mon, 2 Feb 2004 17:14:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmKt-0004JW-00 for mip6-web-archive@ietf.org; Mon, 02 Feb 2004 17:14:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmJU-0004Aq-00 for mip6-web-archive@ietf.org; Mon, 02 Feb 2004 17:13:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnmIY-00041A-00 for mip6-web-archive@ietf.org; Mon, 02 Feb 2004 17:12:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmIS-0005KB-Q6; Mon, 02 Feb 2004 17:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjKA-00056w-O5 for mip6@optimus.ietf.org; Mon, 02 Feb 2004 14:01:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02572 for ; Mon, 2 Feb 2004 14:01:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjK8-0004wS-00 for mip6@ietf.org; Mon, 02 Feb 2004 14:01:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjIr-0004fM-00 for mip6@ietf.org; Mon, 02 Feb 2004 14:00:14 -0500 Received: from gaia.cs.uoi.gr ([195.130.121.201]) by ietf-mx with esmtp (Exim 4.12) id 1AnjGu-0003zu-00; Mon, 02 Feb 2004 13:58:13 -0500 Received: from zeus.cs.uoi.gr (zeus.cs.uoi.gr [195.130.121.11]) by gaia.cs.uoi.gr (8.12.10/8.12.10) with ESMTP id i12IvdqF096584; Mon, 2 Feb 2004 20:57:39 +0200 (EET) (envelope-from faturu@zeus.cs.uoi.gr) Received: from athena.cs.uoi.gr (athena [195.130.121.36]) by zeus.cs.uoi.gr (8.12.9+Sun/8.12.5) with ESMTP id i12IvcZm028396; Mon, 2 Feb 2004 20:57:38 +0200 (EET) Received: from localhost (faturu@localhost) by athena.cs.uoi.gr (8.9.3+Sun/8.9.3) with SMTP id UAA16622; Mon, 2 Feb 2004 20:43:47 +0200 (EET) Date: Mon, 2 Feb 2004 20:43:47 +0200 (EET) From: Panagiota Fatourou To: mip6@ietf.org, mip4@ietf.org, mipshop@ietf.org cc: kutten@ie.technion.ac.il, Victor.Luchangco@sun.com, Fatourou Panagiota Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.66d' Subject: [Mip6] Edsger W. Dijkstra Prize in Distributed Computing: Early call for paper nominations Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Please accept our apologies if you receive multiple copies. ============================================================================== Early call for paper nominations for the ACM SIGACT/SIGOPS Annual Edsger W. Dijkstra Prize in Distributed Computing ----------------------------------------------------------------------------- The Edsger W. Dijkstra Prize in Distributed Computing is named for Edsger W. Dijsktra, a pioneer in the area of distributed computing. The prize is presented at the PODC conference (http://www.podc.org/podc2004/). However, papers appearing in any conference proceedings or journals are eligible, as long as they have had a significant impact on research areas of interest within the PODC community, and as long as the year of publication is at least ten years prior to the year in which the award is given. The winning authors will share a cash award of $1,000, and each will be presented with a plaque at PODC'2004. An announcement of the award recipient will be included in the PODC 2003 proceedings. The announcement will include a paragraph describing the paper's lasting contributions. Additional details about the award and the nomination instructions can be found in http://www.acm.org/podc/dijkstra/ Please send your nominations to Shay Kutten, program chair of PODC'04 dijkstra_prize@ie.technion.ac.il The deadline is May 1st. Thanks, Shay Kutten PODC 2004 PC Chair P.S. The deadline for submitting papers at PODC'04 is approaching. We expect a strong program for our expanded area of interest, and a beautiful location for the conference. Please consider also submitting a paper to PODC'04! _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 5 03:56:21 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 DAA07749 for ; Thu, 5 Feb 2004 03:56:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AofIe-0003mR-HR for mip6-archive@odin.ietf.org; Thu, 05 Feb 2004 03:55:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i158tqap014528 for mip6-archive@odin.ietf.org; Thu, 5 Feb 2004 03:55:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AofIe-0003mF-2A for mip6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 03:55:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07737 for ; Thu, 5 Feb 2004 03:55:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AofIb-00056N-00 for mip6-web-archive@ietf.org; Thu, 05 Feb 2004 03:55:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AofHa-00051C-00 for mip6-web-archive@ietf.org; Thu, 05 Feb 2004 03:54:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AofGs-0004wj-00 for mip6-web-archive@ietf.org; Thu, 05 Feb 2004 03:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AofGs-0003Wz-8L; Thu, 05 Feb 2004 03:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7SU-0008Pt-S8 for mip6@optimus.ietf.org; Tue, 03 Feb 2004 15:47:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00269 for ; Tue, 3 Feb 2004 15:47:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7ST-0001ca-00 for mip6@ietf.org; Tue, 03 Feb 2004 15:47:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7RW-0001Wk-00 for mip6@ietf.org; Tue, 03 Feb 2004 15:46:47 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7R6-0001QY-00 for mip6@ietf.org; Tue, 03 Feb 2004 15:46:20 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i13MOpw3031402 for ; Tue, 3 Feb 2004 14:24:55 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Tue, 3 Feb 2004 12:45:43 -0800 Message-Id: <5.1.0.14.2.20040203154308.01ce3fa0@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Feb 2004 15:44:03 -0500 To: mip6@ietf.org From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Mip6] Fwd: Last Call: 'Nemo Basic Support Protocol' to Proposed Standard Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 FYI -- Review and feedback by MIP6 knowledgeable folks would be very helpful. Margaret >To: IETF-Announce :; >From: The IESG >Subject: Last Call: 'Nemo Basic Support Protocol' to Proposed Standard >Date: Mon, 02 Feb 2004 13:31:04 -0500 > >The IESG has received a request from the Network Mobility WG to consider >the following document: > >- 'Nemo Basic Support Protocol' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-16. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-02.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 5 03:56:24 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 DAA07766 for ; Thu, 5 Feb 2004 03:56:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AofIf-0003mo-PW for mip6-archive@odin.ietf.org; Thu, 05 Feb 2004 03:55:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i158trsA014548 for mip6-archive@odin.ietf.org; Thu, 5 Feb 2004 03:55:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AofIe-0003mX-Pv for mip6-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 03:55:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07740 for ; Thu, 5 Feb 2004 03:55:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AofIc-00056S-00 for mip6-web-archive@ietf.org; Thu, 05 Feb 2004 03:55:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AofHa-00051K-00 for mip6-web-archive@ietf.org; Thu, 05 Feb 2004 03:54:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AofGs-0004wk-00 for mip6-web-archive@ietf.org; Thu, 05 Feb 2004 03:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AofGr-0003Wr-H2; Thu, 05 Feb 2004 03:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5rb-0004fV-8A for mip6@optimus.ietf.org; Tue, 03 Feb 2004 14:05:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24891 for ; Tue, 3 Feb 2004 14:05:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5rY-0007Hq-00 for mip6@ietf.org; Tue, 03 Feb 2004 14:05:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5qe-0007Ce-00 for mip6@ietf.org; Tue, 03 Feb 2004 14:04:37 -0500 Received: from myra.general.services.metu.edu.tr ([144.122.144.147]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5po-00077c-00; Tue, 03 Feb 2004 14:03:44 -0500 Received: from metu.edu.tr (pri1-41.metu.edu.tr [144.122.204.41]) by myra.general.services.metu.edu.tr (8.11.7/8.11.7) with ESMTP id i13J38q17855; Tue, 3 Feb 2004 21:03:09 +0200 (EET) Message-ID: <401FEFDA.8030309@metu.edu.tr> Date: Tue, 03 Feb 2004 21:00:42 +0200 From: Buyurman Baykal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] MedHocNet'04 Call for Papers Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We apologize if you receive multiple copies of this message ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Med-Hoc-Net 2004 ================ The Third Annual Mediterranean Ad Hoc Networking Workshop June 27-30, 2004, Bodrum, Turkey http://www.medhoc04.diit.unict.it/ Call for Papers --------------- Ad hoc network applications are emerging continuously imposing their own stringent constraints which cannot be fulfilled by generic approaches and thus spur new research efforts. The aim of Med-Hoc-Net 2004 is to serve as a platform for researchers and visionaries from academia, research labs, and industry from all over the globe to share their ideas, views, results, and experiences in the field of ad-hoc networking and communications. Med-Hoc-Net 2004 will include presentations of theoretical and experimental achievements, innovative ad-hoc systems, prototyping efforts, case studies, and advancements in technology directly affecting ad-hoc networking and communications infrastructures. After Sardinia (Italy) and Mahdia (Tunisia), this year the workshop will take place in another beautiful spot on the Mediterranean Sea: Bodrum (Turkey) where you will find wonderful nature and amazing historical sites close to hand. Bodrum is easy to reach via frequent flight connections from Istanbul. Topics of Interest: ------------------- The papers solicited in Med-Hoc-Net 2004 cover a variety of topics including but not limited to: - Novel ad-hoc network architectures and applications, - Sensor network applications and protocols, - Implementations, testbeds, and prototypes, - Interfacing ad-hoc systems with different networks, - Resource discovery and management, - Power management and control, - Call admission and traffic shaping policies for ad-hoc networks, - Multimedia location services, - Self organization and network reconfiguration, - Protocols for QoS support in ad-hoc networks, - QoS support in Bluetooth, HomeRF, HIPERLAN, IEEE 802.11 etc., - MAC protocols, scheduling, and radio resource sharing in ad hoc networks, - Unicast and multicast routing algorithms and protocols, - Transport layer protocols for multi-hop networks, - Congestion control, - Performance evaluation of ad-hoc network protocols through simulations, analysis, and measurements, - Security in ad-hoc networks, - Fault tolerance and error recovery - Signal processing algorithms (coding, compression) for ad-hoc networks The program committee will referee all papers, and accepted papers will be published in the conference proceedings. PAPERS OF PARTICULAR MERIT WILL BE PUBLISHED IN AD HOC NETWORKS (ELSEVIER) JOURNAL. Submission and Important Dates: ------------------------------- Manuscripts must be formatted according to the IEEE double-column standard format, except the font size, which must be 11pt. Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or their equivalent. The maximum length of the manuscript is 12 pages. Papers should be submitted in pdf or ps format via email to medhoc04@diit.unict.it according to the following timetable: Full Paper Electronic Submission: March 2, 2004 Tutorial proposal deadline: April 15, 2004 Notification of Acceptance/Rejection: May 3, 2004 Camera ready submission of full papers: May 17, 2004 Tutorial date: June 27, 2004 Conference dates: June 28-30, 2004 Tutorials: ---------- Proposals for tutorials are solicited. Tutorials should address key topics on Wireless Ad-Hoc Networks and Mobile Communications, dealing with both experimental and theoretical research advances in these fields. Evaluation of proposals will be based on the expertise and experience of the instructors, and on the relevance of the subject matter for the workshop. Potential instructors are requested to submit a tutorial proposal of at most 3 pages, including a biographical sketch, to the Tutorial Chairs, Francesca Cuomo (cuomo@infocom.uniroma1.it) and Christos Douligeris (cdoulig@unipi.gr) by the tutorial proposal deadline above (April 15, 2004). Keynote Speakers: ----------------- Leonard Kleinrock (UCLA, USA), Imrich Chlamtac (UTDallas, USA). Steering Committee: ------------------- Khaldoun Al Agha (LRI, France), Mario Gerla (UCLA, USA), Farouk Kamoun (ENSI, Tunisia), Giovanni Pau (UCLA, USA), and Guy Pujolle (LIP6, France). Organization Committee: ----------------------- General Chair: Ian F. Akyildiz, Georgia Institute of Technology, USA General Vice Chair: Erdal Cayirci, Istanbul Technical University, TURKEY Technical Program Chairs: Giacomo Morabito, University of Catania, ITALY Eylem Ekici, Ohio State University, USA Tutorial Chairs: Francesca Cuomo, University of Rome - La Sapienza, ITALY Christos Douligeris, University of Piraeus, GREECE Publicity Chairs: Buyurman Baykal, Middle East Technical University, TURKEY Jaudelice Cavalcante de Oliveira, Drexel University, USA Registration Chair: Sebnem Baydere, Yeditepe University, TURKEY Technical Program Committee: ---------------------------- Khaldoun Al Agha, Laboratoire de Recherche en Informatique, FRANCE Hamid Aghvami, King's College London, UK Eitan Altman, INRIA, FRANCE Roberto Battiti, University of Trento, ITALY Raouf Boutaba, University of Waterloo, CANADA Walid Dabbous, INRIA, FRANCE Magda El Zarki, University of California at Irvine, USA Luigi Fratta, Politecnico di Milano, ITALY Mario Gerla, UCLA, USA Paul J. M. Havinga, University of Twente, NETHERLANDS Ahmed Helmy, University of Southern California, USA Farouk Kamoun, ENSI, TUNISIA Holger Karl, Technical University of Berlin, GERMANY Ulf Korner, Lund Institute of Technology, SWEDEN Bhaskar Krishnamachari, University of Southern California, USA Marwan Krunz, University of Arizona, USA Albert Levi, Sabanci University, TURKEY Janise McNair, University of Florida, USA Lazaros Merakos, University of Athens, GREECE Ioanis Nikolaidis, University of Alberta, CANADA Ariel Orda, Technion, ISRAEL Sergio Palazzo, University of Catania, ITALY Giovanni Pau, UCLA, USA Chiara Petrioli, University of Rome "La Sapienza", ITALY Andreas Pitsillides, University of Cyprus, CYPRUS Guy Pujolle, LIP6, FRANCE Paolo Santi, CNR, ITALY Adrian Segall, Technion, ISRAEL Ness Shroff, Purdue University, USA Moshe Sidi, Technion, ISRAEL Raghupathy Sivakumar, Georgia Institute of Technology, USA Ioannis Stavrakakis, University of Athens, GREECE Ivan Stojmenovic, University of Ottawa, CANADA Violet R. Syrotiuk, Arizona State University, USA Leandros Tassiulas, University of Thessaly, GREECE Damla Turgut, University of Central Florida, USA Bernhard H. Walke, Aachen University of Technology, GERMANY Wenye Wang, North Carolina State University, USA Michele Zorzi, University of Ferrara, ITALY -------------------------------------------------- For more information on the workshop, please check http://www.medhoc04.diit.unict.it/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 8 13:50:06 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 NAA28089 for ; Sun, 8 Feb 2004 13:50:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aptzu-0002BE-2G for mip6-archive@odin.ietf.org; Sun, 08 Feb 2004 13:49:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18IncK9008374 for mip6-archive@odin.ietf.org; Sun, 8 Feb 2004 13:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aptzt-0002Az-U5 for mip6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 13:49:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28084 for ; Sun, 8 Feb 2004 13:49:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aptzr-0007V0-00 for mip6-web-archive@ietf.org; Sun, 08 Feb 2004 13:49:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aptyv-0007Q6-00 for mip6-web-archive@ietf.org; Sun, 08 Feb 2004 13:48:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AptyW-0007Kv-00 for mip6-web-archive@ietf.org; Sun, 08 Feb 2004 13:48:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AptyL-00020n-ND; Sun, 08 Feb 2004 13:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aptxp-0001zp-Bd for mip6@optimus.ietf.org; Sun, 08 Feb 2004 13:47:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28019 for ; Sun, 8 Feb 2004 13:47:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aptxn-0007Jy-00 for mip6@ietf.org; Sun, 08 Feb 2004 13:47:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aptww-0007GN-00 for mip6@ietf.org; Sun, 08 Feb 2004 13:46:34 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AptwA-0007C2-00 for mip6@ietf.org; Sun, 08 Feb 2004 13:45:46 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1Aptw8-0004Pv-00 for ; Sun, 08 Feb 2004 19:45:44 +0100 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83] helo=i72ChVogt) by irams1.ira.uka.de with smtp (Exim 3.30 #7 ) id 1Aptw7-0002oj-00; Sun, 08 Feb 2004 19:45:43 +0100 Message-ID: <001b01c3ee73$aa4f9da0$5347038d@tm.unikarlsruhe.de> From: "Christian Vogt" To: Date: Sun, 8 Feb 2004 19:45:03 +0100 Organization: University of Karlsruhe (TH), Institute of Telematics MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Subject: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGksDQoNCndlIHN1Ym1pdHRlZCBhIG5ldyBJbnRlcm5ldC1EcmFmdCwgZHJhZnQtdm9ndC1taXA2 LWVhcmx5LWJpbmRpbmctdXBkYXRlcy0wMC50eHQsDQp0aGF0IHByb3Bvc2VzIEVhcmx5IEJpbmRp bmcgVXBkYXRlcyBmb3IgTW9iaWxlIElQdjYgKHBsZWFzZSBzZWUgdGhlIGFic3RyYWN0IGJlbG93 KS4NClRoZSBwcm9wb3NhbCBpcyBhbiBvcHRpb25hbCBleHRlbnNpb24gdG8gTW9iaWxlIElQdjYn cyBSb3V0ZSBPcHRpbWl6YXRpb24gbW9kZS4NCg0KV2UgcmVjb2duaXplIHRoYXQgRWFybHkgQmlu ZGluZyBVcGRhdGVzIGZvciBNb2JpbGUgSVB2NiBtYXkgZml0IGludG8gZWl0aGVyIHRoZQ0KbWlw NiBXRydzIG9yIHRoZSBtaXBzaG9wIFdHJ3MgY2hhcnRlci4gV2Ugd291bGQgdGhlcmVmb3JlIGFw cHJlY2lhdGUgZmVlZGJhY2sgZnJvbQ0KdGhpcyBXRyBvbiB3aGV0aGVyIHRoZSBwcm9wb3NhbCBp cyBhcHByb3ByaWF0ZSB0byBiZSBhZG9wdGVkIGFzIGEgV0cgaXRlbSBsYXRlci4NCg0KVGl0bGUu Li4uOiBFYXJseSBCaW5kaW5nIFVwZGF0ZXMgZm9yIE1vYmlsZSBJUHY2DQpBdXRob3Iocyk6IEMu IFZvZ3QsIFIuIEJsZXNzLCBNLiBEb2xsLCBULiBLdWVmbmVyDQpGaWxlbmFtZS46IGRyYWZ0LXZv Z3QtbWlwNi1lYXJseS1iaW5kaW5nLXVwZGF0ZXMtMDAudHh0DQpQYWdlcy4uLi46IDI4DQpEYXRl Li4uLi46IDIwMDQtMDItMDQNCg0KQWJzdHJhY3Q6DQogICBUaGUgbG9uZyBsYXRlbmN5IGFzc29j aWF0ZWQgd2l0aCBNb2JpbGUgSVB2NidzIGhvbWUtYWRkcmVzcyBhbmQNCiAgIGNhcmUtb2YtYWRk cmVzcyB0ZXN0cyBjYW4gc2lnbmlmaWNhbnRseSBpbXBhY3QgZGVsYXktc2Vuc2l0aXZlDQogICBh cHBsaWNhdGlvbnMuIFdlIHByb3Bvc2UgYSBtb2RpZmllZCBiaW5kaW5nLXVwZGF0ZSBwcm9jZWR1 cmUgdGhhdA0KICAgZXZhZGVzIHRoZSBsYXRlbmN5IG9mIGJvdGggYWRkcmVzcyB0ZXN0cy4gVGhl IG1vZGlmaWVkIGJpbmRpbmcgdXBkYXRlDQogICBydW5zIGluIGhhbGYsIG9yIGxlc3MsIG9mIHRo ZSB0aW1lIHRoYXQgYSBzdGFuZGFyZCBiaW5kaW5nIHVwZGF0ZQ0KICAgdGFrZXMuIE1vcmVvdmVy LCB0aGUgbW9kaWZpZWQgYmluZGluZyB1cGRhdGUgaXMgbmVhcmx5IGVxdWl2YWxlbnQgdG8NCiAg IHRoZSBzdGFuZGFyZCBwcm9jZWR1cmUgd2l0aCByZXNwZWN0IHRvIHNlY3VyaXR5LCBhbmQgaXQg aW5jcmVhc2VzIHRoZQ0KICAgcmVzb3VyY2VzIHJlcXVpcmVkIGF0IHRoZSBjb3JyZXNwb25kZW50 IG5vZGUgb25seSBtYXJnaW5hbGx5LiBUaGUNCiAgIG1vZGlmaWNhdGlvbiBpcyByZWFsaXplZCBh cyBhbiBvcHRpb25hbCwgYW5kIGZ1bGx5DQogICBiYWNrd2FyZC1jb21wYXRpYmxlLCBleHRlbnNp b24gdG8gTW9iaWxlIElQdjYuDQoNClRoZSBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuIFRoZSBVUkwgaXM6DQpo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2d0LW1pcDYtZWFybHkt YmluZGluZy11cGRhdGVzLTAwLnR4dA0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KLSBDaHJpc3RpYW4g Vm9ndA0KDQoNClBTOiBBIGZlYXNpYmxlLCB5ZXQgbm9uLXRyaXZpYWwgdmFyaWF0aW9uIG9mICJF YXJseSBCaW5kaW5nIFVwZGF0ZXMgZm9yIE1vYmlsZSBJUHY2IiBpcw0KdG8gaGF2ZSB0aGUgbW9i aWxlIG5vZGUgdGVudGF0aXZlbHkgcmVnaXN0ZXIgYSBuZXcgY2FyZS1vZiBhZGRyZXNzICpiZWZv cmUqIGl0IGNoYW5nZXMNCml0cyBwb2ludCBvZiBuZXR3b3JrIGF0dGFjaG1lbnQuIFdlIGFyZSBj dXJyZW50bHkgd29ya2luZyBvbiBhIHNvbHV0aW9uIGZvciB0aGlzDQp2YXJpYXRpb24uIFdlIGlu dGVuZCB0byBwdWJsaXNoIG91ciB3b3JrIGluIGEgc2VwYXJhdGUgSW50ZXJuZXQtRHJhZnQgaW4g dGhlIG5lYXIgZnV0dXJlLg0KDQoNCnwNCnwgQ2hyaXN0aWFuIFZvZ3QNCnwgSW5zdGl0dXRlIG9m IFRlbGVtYXRpY3MsIFVuaXZlcnNpdHkgb2YgS2FybHNydWhlIChUSCkNCnwgd3d3LnRtLnVrYS5k ZS9+Y2h2b2d0Lw0KfA0KDQo= _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 8 17:25: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 RAA04729 for ; Sun, 8 Feb 2004 17:25:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxM4-0007Ud-Hi for mip6-archive@odin.ietf.org; Sun, 08 Feb 2004 17:24:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18MOipN028797 for mip6-archive@odin.ietf.org; Sun, 8 Feb 2004 17:24:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxM4-0007UO-AD for mip6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 17:24:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04724 for ; Sun, 8 Feb 2004 17:24:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApxM2-00079g-00 for mip6-web-archive@ietf.org; Sun, 08 Feb 2004 17:24:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApxKz-00074V-00 for mip6-web-archive@ietf.org; Sun, 08 Feb 2004 17:23:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApxKP-000704-00 for mip6-web-archive@ietf.org; Sun, 08 Feb 2004 17:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxKP-0007KU-P3; Sun, 08 Feb 2004 17:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApAKZ-0007Uy-5T for mip6@optimus.ietf.org; Fri, 06 Feb 2004 13:03:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07482 for ; Fri, 6 Feb 2004 13:03:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApAKX-0007Io-00 for mip6@ietf.org; Fri, 06 Feb 2004 13:03:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApAJg-0007Fr-00 for mip6@ietf.org; Fri, 06 Feb 2004 13:03:02 -0500 Received: from dcs-server2.cs.uiuc.edu ([128.174.252.3]) by ietf-mx with esmtp (Exim 4.12) id 1ApAJ0-0007CD-00 for mip6@ietf.org; Fri, 06 Feb 2004 13:02:19 -0500 Received: from brooklyn (brooklyn.cs.uiuc.edu [128.174.244.80]) (authenticated bits=0) by dcs-server2.cs.uiuc.edu (8.12.10/8.12.10) with ESMTP id i16I2IZP001395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 6 Feb 2004 12:02:18 -0600 (CST) From: "Robin Kravets" To: Date: Fri, 6 Feb 2004 12:04:17 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [Mip6] ACM MobiCom 2004 CFP Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- =20 CALL FOR PAPERS =20 MobiCom 2004 The Tenth Annual International Conference on Mobile Computing and Networking =20 September 26 - October 1, 2004 Philadelphia, PA, USA (dates and location are subject to final approval) http://www.sigmobile.org/mobicom/2004/ Sponsored by ACM SIGMOBILE IMPORTANT DATES: Paper registrations due: March 8, 2004 Paper submissions due: March 15, 2004 Notification of acceptance: June 21, 2004 Camera-ready versions due: July 25, 2004 =20 ACM MobiCom 2004, the Tenth Annual International Conference on Mobile Computing and Networking, is the tenth in the series of annual = conferences sponsored by ACM SIGMOBILE and dedicated to addressing the challenges in = the areas of mobile computing and wireless and mobile networking. The = MobiCom conference series serves as the premier international forum addressing networks, systems, algorithms, and applications that support the = symbiosis of mobile computers and wireless networks. MobiCom is a highly = selective, single-track conference focusing on all issues in mobile computing and wireless and mobile networking at the link layer and above. =20 PAPERS: Authors are invited to submit full papers presenting new = research related to the theory or practice of mobile computing and networking. = All submissions must describe original research that is not published or currently under review by another conference or journal. Areas of = interest include, but are not limited to: - Applications and computing services supporting mobile users - Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity - Database and data management issues in mobile computing - Operating system and middleware support for mobile computing and=20 networking - Distributed systems aspects of mobile computing - New mobile and wireless applications - Integration and interworking of wired and wireless networks=09 - Performance of mobile and wireless networks and systems=20 - Location-dependent applications and protocols - Security and privacy of mobile/wireless systems - Mobile ad hoc and sensor networks - Wireless multimedia systems - Algorithms and protocols for power management and control - Service creation and management environments for mobile/wireless systems =20 The program committee will referee all papers, and accepted papers will = be published in the conference proceedings. Selected papers will appear in = a special issue of the ACM/Kluwer Wireless Networks (WINET) journal. =20 CHALLENGES PAPERS: The conference also solicits short papers (maximum of = 8 pages) that challenge the mobile computing community with revolutionary = new approaches, new technologies, or visionary applications. Such papers = should provide stimulating ideas or grand visions that may open up exciting = avenues of far-reaching future research. Descriptions of new products or simple evolution of existing work are not appropriate as Challenges Papers. Challenges Papers will be reviewed and should be submitted using the = normal submission procedure. The title of such papers must start with the word "Challenges," i.e., "Challenges: ... `rest of the title'." =20 SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PDF or a PostScript version of their full paper. Papers must be no longer than 15 pages (8 pages for Challenges submissions), font size not smaller than 10 points, and must = fit properly on U.S. "letter"-sized paper (8.5x11 inches) with reasonable margins. Detailed instructions for the paper submission procedure and = format will be available on the conference web pages. The deadline for = registering the title and the abstract of the paper with our electronic submission system is March 8, 2004 and the deadline for submitting the actual paper = is March 15, 2004. All deadlines are 11:59PM EST. All submitted papers will be judged based on their quality through double-blind review process, where the identities of the authors are withheld from the reviewers. Authors should not be identifiable by any = means from the paper or from the PDF or the Postscript file. Guidelines for preparing the paper for blind reviewing, as well as electronic paper submission instructions, will be available on the conference web pages. Submitted or substantially similar papers must not be currently under = review for any other publication. Please direct any questions regarding paper submission to the Program Co-Chairs, Samir Das and Ravi Jain at mobicom_pcchairs@acm.org. =20 TUTORIALS: Proposals for tutorials are solicited. Evaluation of tutorial proposals will be based on the expertise and experience of the = instructors and on the relevance of the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Co-Chairs, Andrew Campbell (campbell@ee.columbia.edu) and Taieb Znati (tznati@nsf.gov). The = deadline for tutorial proposals is April 05, 2004. =20 PANELS: Panel proposals are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel = proposals should not exceed 3 pages, including biographical sketches of the = panelists. Potential panel organizers should contact the Panel Co-Chairs, Prathima Agrawal (pagrawal@eng.auburn.edu) and Tao Zhang (tao@research.telcordia.com). The deadline for panel proposals is April = 26, 2004. =20 RESEARCH DEMOS AND EXHIBITS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of = the demo and equipment to be used. Send proposals to the Research Demo = Chair, Elizabeth Belding-Royer (ebelding@cs.ucsb.edu). The deadline for demo proposals is July 12, 2004. We are also planning an Expo featuring = exhibits of the latest mobile computing products and services. STUDENT POSTER SESSION: Student posters are solicited that present = recent and on-going research by students on mobile computing and mobile and wireless networking topics. Student posters should not exceed 2 pages = and should include a description of the student's research. See above for = paper formatting requirements. Accepted posters will be put on the conference = web page; however, they will not be printed in the conference proceedings. = Send poster submissions to the Student Poster Co-Chairs, Chiara Petrioli (petrioli@di.uniroma1.it) and Stefano Basagni (basagni@ece.neu.edu). The deadline for student posters is July 12, 2004. BEST STUDENT PAPER AWARD: Papers with a student as a primary author will = be considered for the Best Student Paper Award, with a cash award of 1000 = USD. Students must indicate with their submission that they would like to be considered for this award. The student author of the awarded paper is expected to present the paper at the conference. =20 GENERAL CHAIR Zygmunt Haas Cornell University =20 PROGRAM CO-CHAIRS Samir R. Das Stony Brook University, SUNY =20 Ravi Jain DoCoMo USA Labs STEERING COMMITTEE CHAIR Imrich Chlamtac University of Texas at Dallas ACM PROGRAM DIRECTOR Ginger Ignatoff Additional committee members will be announced on the conference web = page. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 9 12:49:52 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 MAA00606 for ; Mon, 9 Feb 2004 12:49:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFXB-00028J-72 for mip6-archive@odin.ietf.org; Mon, 09 Feb 2004 12:49:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19HnPCH008193 for mip6-archive@odin.ietf.org; Mon, 9 Feb 2004 12:49:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFXB-000284-2P for mip6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 12:49:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00594 for ; Mon, 9 Feb 2004 12:49:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFX9-0006HU-00 for mip6-web-archive@ietf.org; Mon, 09 Feb 2004 12:49:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFWC-0006BF-00 for mip6-web-archive@ietf.org; Mon, 09 Feb 2004 12:48:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqFVp-00065D-00 for mip6-web-archive@ietf.org; Mon, 09 Feb 2004 12:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFVo-00021W-UR; Mon, 09 Feb 2004 12:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFUz-00020Y-N1 for mip6@optimus.ietf.org; Mon, 09 Feb 2004 12:47:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00435 for ; Mon, 9 Feb 2004 12:47:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFUx-000623-00 for mip6@ietf.org; Mon, 09 Feb 2004 12:47:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFTz-0005w6-00 for mip6@ietf.org; Mon, 09 Feb 2004 12:46:08 -0500 Received: from zcamail03.zca.compaq.com ([161.114.32.103]) by ietf-mx with esmtp (Exim 4.12) id 1AqFT4-0005mR-00 for mip6@ietf.org; Mon, 09 Feb 2004 12:45:11 -0500 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 63C2ED8ED; Mon, 9 Feb 2004 09:44:40 -0800 (PST) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 256524DC; Mon, 9 Feb 2004 11:44:39 -0600 (CST) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id MAA0002431093; Mon, 9 Feb 2004 12:44:38 -0500 (EST) Message-ID: <4027C703.2080209@hp.com> Date: Mon, 09 Feb 2004 12:44:35 -0500 From: Brian Haley Organization: Linux Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt Cc: mip6@ietf.org Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 References: <001b01c3ee73$aa4f9da0$5347038d@tm.unikarlsruhe.de> In-Reply-To: <001b01c3ee73$aa4f9da0$5347038d@tm.unikarlsruhe.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA00436 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hi Christian, I believe there is a need for faster handovers in Mipv6 (Fmip and Hmip=20 are addressing some of this), but I'm not sure I agree with Section 6.2=20 in the security considerations part of this draft. > Concerning security against flooding attacks, Early Binding Updates > are at a minor disadvantage with standard binding updates, because a > malicious node may exploit the time window during which a > correspondent node sends data to a yet-unverified care-of address. > We propose two ways to mitigate this threat. > > One way is to properly configure the lifetime of a tentative > binding-cache entry. We propose the value, > TENTATIVE_BINDING_LIFETIME, given in Section 8. In scenarios where > flooding attacks cannot be ruled out, one should appropriately reduce > TENTATIVE_BINDING_LIFETIME. We're talking about this attack: 1. I take control of, or have, a system with Mipv6 MN functionality 2. I have it do HoTI/HoT with 10,000 random systems that have CN functionality with this new "early" support 3. I send an Early Binding Update to them all 4. Immediately followed by a TCP SYN, ping, etc. 5. Someone just got flooded Even having just 1 second (the draft gives 3) gives someone a lot of=20 time since they can just keep choosing new systems to flood from, until=20 their MN is caught. Then they move to another MN or network... This=20 particular attack is not possible with regular Binding Updates. -Brian Christian Vogt wrote: > Hi, >=20 > we submitted a new Internet-Draft, draft-vogt-mip6-early-binding-update= s-00.txt, > that proposes Early Binding Updates for Mobile IPv6 (please see the abs= tract below). > The proposal is an optional extension to Mobile IPv6's Route Optimizati= on mode. >=20 > We recognize that Early Binding Updates for Mobile IPv6 may fit into ei= ther the > mip6 WG's or the mipshop WG's charter. We would therefore appreciate fe= edback from > this WG on whether the proposal is appropriate to be adopted as a WG it= em later. >=20 > Title....: Early Binding Updates for Mobile IPv6 > Author(s): C. Vogt, R. Bless, M. Doll, T. Kuefner > Filename.: draft-vogt-mip6-early-binding-updates-00.txt > Pages....: 28 > Date.....: 2004-02-04 >=20 > Abstract: > The long latency associated with Mobile IPv6's home-address and > care-of-address tests can significantly impact delay-sensitive > applications. We propose a modified binding-update procedure that > evades the latency of both address tests. The modified binding updat= e > runs in half, or less, of the time that a standard binding update > takes. Moreover, the modified binding update is nearly equivalent to > the standard procedure with respect to security, and it increases th= e > resources required at the correspondent node only marginally. The > modification is realized as an optional, and fully > backward-compatible, extension to Mobile IPv6. >=20 > The Internet-Draft is available from the on-line Internet-Drafts direct= ories. The URL is: > http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updat= es-00.txt >=20 > Best regards, >=20 >=20 > - Christian Vogt >=20 >=20 > PS: A feasible, yet non-trivial variation of "Early Binding Updates for= Mobile IPv6" is > to have the mobile node tentatively register a new care-of address *bef= ore* it changes > its point of network attachment. We are currently working on a solution= for this > variation. We intend to publish our work in a separate Internet-Draft i= n the near future. >=20 >=20 > | > | Christian Vogt > | Institute of Telematics, University of Karlsruhe (TH) > | www.tm.uka.de/~chvogt/ > | >=20 > 2*z=99=A8=A5=8Ax%=8A=CBL=8A=9E=A2z=D7=E8=AE=08m=B6=9B?=FF=0C0=89=EB_=A2= =B8?=99=A8=A5=99=A9=FF=96+-=8Aw=E8=FEh=A96=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 9 13:40:09 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 NAA03332 for ; Mon, 9 Feb 2004 13:40:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGJp-0006M1-Ik for mip6-archive@odin.ietf.org; Mon, 09 Feb 2004 13:39:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19IdfTV024419 for mip6-archive@odin.ietf.org; Mon, 9 Feb 2004 13:39:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGJp-0006Lm-Bi for mip6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 13:39:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03328 for ; Mon, 9 Feb 2004 13:39:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGJn-0003jO-00 for mip6-web-archive@ietf.org; Mon, 09 Feb 2004 13:39:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGIe-0003dV-00 for mip6-web-archive@ietf.org; Mon, 09 Feb 2004 13:38:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGID-0003XT-00 for mip6-web-archive@ietf.org; Mon, 09 Feb 2004 13:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGID-00069X-Up; Mon, 09 Feb 2004 13:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGHQ-0005xb-GW for mip6@optimus.ietf.org; Mon, 09 Feb 2004 13:37:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03197 for ; Mon, 9 Feb 2004 13:37:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGHO-0003Uu-00 for mip6@ietf.org; Mon, 09 Feb 2004 13:37:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGGP-0003P4-00 for mip6@ietf.org; Mon, 09 Feb 2004 13:36:10 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AqGFX-0003Fs-00 for mip6@ietf.org; Mon, 09 Feb 2004 13:35:15 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i19IYcp02834; Mon, 9 Feb 2004 19:34:38 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i19IYcSj066036; Mon, 9 Feb 2004 19:34:38 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402091834.i19IYcSj066036@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haley cc: Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 In-reply-to: Your message of Mon, 09 Feb 2004 12:44:35 EST. <4027C703.2080209@hp.com> Date: Mon, 09 Feb 2004 19:34:38 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: I believe there is a need for faster handovers in Mipv6 (Fmip and Hmip are addressing some of this), but I'm not sure I agree with Section 6.2 in the security considerations part of this draft. => as there is currently some FUD about reflection attacks with mobile IPv6 optimizations, IMHO we have to be accurate about this issue. This is why I submitted this afternoon (in Europe) a draft about this. > Concerning security against flooding attacks, Early Binding Updates > are at a minor disadvantage with standard binding updates, because a > malicious node may exploit the time window during which a > correspondent node sends data to a yet-unverified care-of address. => in fact even if to verify new care-of addresses is not bad this does not improve the security because: - the HA does not verify them (i.e., why to close the window when the door remains open?) - using mobile IPv6 does not add goodies to the standard reflection attack - this is true for carefully designed optimized schemes, which of course should not verify new care-of addresses if they'd really like to be optimized (:-). We're talking about this attack: 1. I take control of, or have, a system with Mipv6 MN functionality 2. I have it do HoTI/HoT with 10,000 random systems that have CN functionality with this new "early" support 3. I send an Early Binding Update to them all 4. Immediately followed by a TCP SYN, ping, etc. 5. Someone just got flooded => I propose something easier: 1. I take control of, or have, a system with IPv6 functionality 2. I send an HTTP request or ping or etc. to 10,000 random web servers that have IPv6 support 3. Someone just got flooded Even having just 1 second (the draft gives 3) gives someone a lot of time since they can just keep choosing new systems to flood from, until their MN is caught. Then they move to another MN or network... => so either the reflection attack is accepted or the optimization is not optimizing. This particular attack is not possible with regular Binding Updates. => to be accurate it is hard with return routability check on the care-of address. Regards Francis.Dupont@enst-bretagne.fr PS: in fact there is an important detail which is wrong in the early binding draft: the CN MUST NOT accept an early binding update carrying an alternate care-of address option with a different address than the source address in the IPv6 header (the place where the care-of address is usually found). With this precaution the reflection attack using an "early CN" is not better (from the bad guy's point of view) than the standard one. PPS: please wait the publication of my draft in some days, its name is draft-dupont-mipv6-3bombing-00.txt . _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 10 11:02:42 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 LAA24588 for ; Tue, 10 Feb 2004 11:02:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaKy-0001Qo-L5 for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 11:02:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AG2CGO005501 for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 11:02:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaKy-0001Qe-BK for mip6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 11:02:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24538 for ; Tue, 10 Feb 2004 11:02:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaKv-0006UZ-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 11:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaJo-0006Ib-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 11:01:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaIv-00067a-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 11:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaIt-0001GZ-Lc; Tue, 10 Feb 2004 11:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaHw-0001FK-QM for mip6@optimus.ietf.org; Tue, 10 Feb 2004 10:59:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24235 for ; Tue, 10 Feb 2004 10:59:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaHu-0005wp-00 for mip6@ietf.org; Tue, 10 Feb 2004 10:59:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaGz-0005px-00 for mip6@ietf.org; Tue, 10 Feb 2004 10:58:07 -0500 Received: from email.seas.smu.edu ([129.119.113.35]) by ietf-mx with esmtp (Exim 4.12) id 1AqaGK-0005k7-00 for mip6@ietf.org; Tue, 10 Feb 2004 10:57:24 -0500 Received: from SICLTPC1 (sicltpc1.seas.smu.edu [129.119.101.115]) by email.engr.smu.edu (Postfix) with SMTP id 48FAA26B6C; Tue, 10 Feb 2004 09:57:22 -0600 (CST) Message-ID: <004c01c3efee$73d946a0$73657781@SICLTPC1> From: "Jahanzeb Faizan" To: "Vijay Devarapalli" , "Ryuji Wakikawa" , , , Cc: "Hesham El-Rewini" , "Mohamed Khalil" , "Jahanzeb Faizan" References: <4028430D.7080001@iprg.nokia.com> Subject: [Mip6] Re: Re: Home Agent Reliability and (Home Agent Selection?)] Date: Tue, 10 Feb 2004 09:56:29 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C3EFBC.27884D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C3EFBC.27884D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vijay, I am glad to hear from you about the progress in the WG. Also thanks for your comments and suggestions regarding the modifications in our draft (http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-0= 0.txt ) . Please find my comments below followed by "Jahanzeb->" > hi all, > > I was asked by the MIP6 WG chairs to refine the problem > statement draft for HA reliability and use it as a basis > for the work in the MIP6 WG. > > I read through your draft and have a few comments. > > I would like the problem statement to be expanded to > include the case when the home link fails. if the home > link (or a router upstream) fails, then having multiple > Home Agents on the same link is not going to help HA > reliability. it would be nice if the HAs can be in > phyically separate locations. the problem statement draft > does not have to make this the default case, but should > allow for Home Agents to be placed in the physically > different locations. > Jahanzeb-> Yes you are right in making this point of link failure, but allowing the = HA to spread around different links 1. will cause MN to perform multiple home registrations on different HAs which will increase burden on air bandwidth and MN itself. 2. Also MN has to establish IPsec Security Associations with all its HAs which is again a big overhead. 3. Moreover this will not solve the problem of "Delayed Failure = Detection" as we have discussed in our draft. So I think if we want to take link failure into consideration then we = should come up with some thing else , other than allowing HAs to exists on different links. > section 3 now covers Failure Detection and configuring > security associations with the new HA. I think it should > be expanded to include HA switching. HA switching has > two parts to it. the first, how does the MN switch to > another HA? relying on failed BUs and MPSs will take too Jahanzeb->=20 In our draft we have included the discussion about how MN will switch to another HA on the basis of current specifications of Mobile-IPv6. Please refer to the following para in sec 3.2 of our = draft " Once the failure is detected, MN will try to register its Care of Address with any other Home Agent on the subnet. For this MN must know which other Home Agents are available on the subnet. MN MAY start Dynamic Home Agent Discovery(DHAD)[1] protocol and as the result will get list of available Home Agents on the subnet. MN could then select HA_x (in our scenario) on the list as its potential serving Home Agent. MN will send BU message to HA_x setting Home Registration(H) bit. " > long. the second part, how does one HA take over from a > failed HA? was there some shared state between the HAs > which made it possible for one HA to take over from the > failed HA? > Jahanzeb-> We have included this point in the "Solution Guidelines" section instead of putting it in the "Problem Statement" section. Actually according to current specifications of Mobile-Ipv6 failure of any HA on = the subnet does not drive any other HA to do any kind of recovery work , = except updating their HA Status Lists and deleting the entry for the failed HA. = All the recovery load is on MN itself i.e MN after failure of its working HA = has to register with a new HA on the subnet. So there is no such thing or = even need of having this kind of recovery work (a new HA take overs the = failed HA) on the basis of current Mobile-IPv6 specificatios. That's why we = didn't consider it as a problem rather took it as a "Solution Requirement" > there is also the issue of load balancing. if a HA wants > to reduce its load, it should be able to force a > particular MN to start using another HA. > Jahanzeb-> Yes you are right. We should inlcude it in the problem statement. > I dont agree with 4.3 (Seamless failure) and 4.4 (Mobile > Node functionality). infact section 4.2 conflicts with > both 4.3 and 4.4. I prefer the MN to know about the HA > switch rather than put in hacks (generally dirty) to make > the HA switch transparent to the MN. actuallty, I would > like to see section 4 deleted from the draft. it is > sufficient to define the problem. I see Solution Guidelines > as a fancy term for requirements. :) requirements always > lead to never-ending discussions. Jahanzeb-> Actually I don't see requirement 4.2 conflicting with 4.3 and 4.4. MN could remain ignorant about the HA failure and recovery process and = at the same time could have IPsec SAs with the new HA. I take 4.2 as a = seperate requirement than 4.3 and 4.4. The aim over here is to keep the burden on MN, service interruption and performance degradation as low as possible and at the same time = maintaining the required security as well. Moreover 4.3(seamless failure) = requirement is not MUST. We have kept it "Strongly Recommended" which implies "Should". If people can come up with a solution fulfilling this requirement then = it is plus point otherwise it is ok too. > > we should try to produce version 01 for the draft before > the ID submission deadline next Monday. > > Vijay > > Jahanzeb-> I think that we should also hear from rest of our MIP6 WG community = before we submit any changes in the draft. Thanks for your time. have a nice day. Jahanzeb Faizan Southern Methodist University Dallas,TX,USA > -------- Original Message -------- > Subject: Re: Home Agent Reliability and (Home Agent Selection?) > Date: Tue, 03 Feb 2004 14:12:50 -0800 > From: Gopal Dommety > To: Vijay Devarapalli > CC: Basavaraj.Patil@nokia.com , = Vijay > Devarapalli , ryuji@sfc.wide.ad.jp > References: <40196157.3060009@iprg.nokia.com> > <4.3.2.7.2.20040129105418.037624e0@mira-sjcm-3.cisco.com> > <40196157.3060009@iprg.nokia.com> > > > Vijay, > > could you coodrinate with the SMU folks and get the ball rolling.. > > -Gopal > > At 02:16 PM 2/3/2004 -0800, Vijay Devarapalli wrote: > >Gopal, Raj, > > > >What do you want us to do about this? > > > >Vijay > > > >Vijay Devarapalli wrote: > >>hi Gopal, > >>Gopal Dommety wrote: > >> > >>> > >>>Hello Vijay and Ryuji, > >>> > >>> Hope you are doing well. HA reliability is in the MIP6 = roadmap. > >>> Short term goals is to have a problem statement and and define = the current > >>> scope. Wanted to find out if you are interested in defining this > >>> (based on your draft). Let me know... > >> > >>definitely. I would be interested in that. we tried to narrow > >>the scope and describe the problem at the last IETF meeting > >>itself, but I dont think we succeeded. > >>after the last IETF meeting, there was draft put out by some > >>folks from Southern Methodist University. it talks about > >>problem statement for HA reliability. > >>http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-= 00. txt > >> > >>I havent yet read this draft. we could use this draft as a > >>base. if needed, I could work with these folks refining the > >>problem statement draft. > >>let me know what you think about this. > >>Vijay > > > > > ------=_NextPart_000_0047_01C3EFBC.27884D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Vijay,

I am glad to hear from = you about=20 the progress in the WG. Also thanks for
your comments and suggestions = regarding the modifications in our draft
(http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-= reliability-00.txt ) = .
Please find my comments below followed = by=20 "Jahanzeb->"


> hi all,
>
> I was asked by = the MIP6=20 WG chairs to refine the problem
> statement draft for HA = reliability and=20 use it as a basis
> for the work in the MIP6 WG.
>
> I = read=20 through your draft and have a few comments.
>
> I would like = the=20 problem statement to be expanded to
> include the case when the = home link=20 fails. if the home
> link (or a router upstream) fails, then = having=20 multiple
> Home Agents on the same link is not going to help = HA
>=20 reliability. it would be nice if the HAs can be in
> phyically = separate=20 locations. the problem statement draft
> does not have to make = this the=20 default case, but should
> allow for Home Agents to be placed in = the=20 physically
> different = locations.
>

Jahanzeb->

Yes=20 you are right in making this point of link failure, but allowing the = HA
to=20 spread around different links

1. will cause MN to perform = multiple home=20 registrations on different HAs
which will increase burden on air = bandwidth=20 and MN itself.
2. Also MN has to establish IPsec Security = Associations with=20 all its HAs
which is again a big overhead.
3. Moreover this will = not solve=20 the problem of "Delayed Failure Detection"
as we have discussed in = our=20 draft.

So I think if we want to take link failure into = consideration then=20 we should
come up with some thing else , other than allowing HAs to = exists=20 on
different links.

> section 3 now covers Failure = Detection and=20 configuring
> security associations with the new HA. I think it=20 should
> be expanded to include HA switching. HA switching = has
> two=20 parts to it. the first, how does the MN switch to
> another HA? = relying on=20 failed BUs and MPSs will take too

Jahanzeb->
 
In our draft we have included the = discussion about=20 how MN will
switch to another HA on the basis of current = specifications
of=20 Mobile-IPv6. Please refer to the following para in sec 3.2 of our = draft

"=20 Once the failure is detected, MN will try to register its Care=20 of
   Address with any other Home Agent on the subnet. For = this MN=20 must
   know which other Home Agents are available on the = subnet.=20 MN MAY
   start Dynamic Home Agent Discovery(DHAD)[1] = protocol and=20 as the
   result will get list of available Home Agents on = the=20 subnet. MN could
   then select HA_x (in our scenario) on = the list=20 as its potential
   serving Home Agent. MN will send BU = message to=20 HA_x setting Home
   Registration(H) bit. "

> = long. the=20 second part, how does one HA take over from a
> failed HA? was = there some=20 shared state between the HAs
> which made it possible for one HA = to take=20 over from the
> failed = HA?
>

Jahanzeb->
 
 We have included this point in = the "Solution=20 Guidelines" section
instead of putting it in the "Problem = Statement" =20 section. Actually
according to current specifications of Mobile-Ipv6 = failure=20 of any HA on the
subnet does not drive any other HA to do any kind of = recovery work , except
updating their HA Status Lists and deleting = the entry=20 for the failed HA. All
the recovery load is on MN itself i.e MN after = failure=20 of its working HA has
to register with a new HA on the subnet. So = there is no=20 such thing or even
need of having this kind of recovery work (a new = HA take=20 overs the failed
HA) on the basis of current Mobile-IPv6 = specificatios.=20 That's why we didn't
consider it as a problem rather took it as a = "Solution=20 Requirement"


> there is also the issue of load balancing. = if a HA=20 wants
> to reduce its load, it should be able to force a
>=20 particular MN to start using another=20 HA.
>

Jahanzeb->
Yes you are right. We should inlcude it = in the=20 problem statement.


> I dont agree with 4.3 (Seamless = failure) and=20 4.4 (Mobile
> Node functionality). infact section 4.2 conflicts=20 with
> both 4.3 and 4.4. I prefer the MN to know about the = HA
>=20 switch rather than put in hacks (generally dirty) to make
> the HA = switch=20 transparent to the MN. actuallty, I would
> like to see section 4 = deleted=20 from the draft. it is
> sufficient to define the problem. I see = Solution=20 Guidelines
> as a fancy term for requirements. :) requirements=20 always
> lead to never-ending=20 discussions.

Jahanzeb->
 
 Actually I don't see requirement = 4.2=20 conflicting with 4.3 and 4.4.
MN could remain ignorant about the HA = failure=20 and recovery process and at
the same time could have IPsec SAs with = the new=20 HA. I take 4.2 as a seperate requirement
than 4.3 and 4.4.
The aim = over=20 here is to keep the burden on MN, service interruption = and
performance=20 degradation as low as possible and at the same time maintaining
the = required=20 security as well. Moreover 4.3(seamless failure) requirement is
not = MUST. We=20 have kept it "Strongly Recommended" which implies "Should".
If people = can=20 come up with  a solution fulfilling this requirement then it
is = plus=20 point otherwise it is ok too.

>
> we should try to = produce=20 version 01 for the draft before
> the ID submission deadline next=20 Monday.
>
> Vijay
>
>
Jahanzeb->

I think that we should also hear from rest of our MIP6 WG = community=20 before
we submit any changes in the draft.
Thanks for your = time.
have a nice day.
Jahanzeb Faizan
Southern Methodist University
Dallas,TX,USA


> -------- Original Message = --------
>=20 Subject: Re: Home Agent Reliability and (Home Agent Selection?)
> = Date:=20 Tue, 03 Feb 2004 14:12:50 -0800
> From: Gopal Dommety = <gdommety@cisco.com>
> To:=20 Vijay Devarapalli <vijayd@iprg.nokia.com>
> CC: Basavaraj.Patil@nokia.com=20 <Basavaraj.Patil@nokia.com>,        Vijay
> = Devarapalli=20 <vijayd@iprg.nokia.com>, ryuji@sfc.wide.ad.jp
>=20 References: <40196157.3060009@iprg.nokia.com>
> <<= FONT=20 face=3DArial=20 size=3D2>4.3.2.7.2.20040129105418.037624e0@mira-sjcm-3.cisco.com>
> <40196157.3060009@iprg.nokia.com>
>
>
> Vijay,
>
> could you = coodrinate=20 with the SMU folks and get the ball rolling..
>
>=20 -Gopal
>
> At 02:16 PM 2/3/2004 -0800, Vijay Devarapalli=20 wrote:
> >Gopal, Raj,
> >
> >What do you want = us to=20 do about this?
> >
> >Vijay
> >
> = >Vijay=20 Devarapalli wrote:
> >>hi Gopal,
> >>Gopal = Dommety=20 wrote:
> >>
> >>>
> >>>Hello = Vijay and=20 Ryuji,
> >>>
> >>>     = Hope=20 you are doing well. HA reliability is in the MIP6 roadmap.
>=20 >>>  Short term goals is to have a problem statement and = and=20 define the
current
> >>>  scope. Wanted to find = out if=20 you are interested in defining this
> >>> (based on your = draft).=20 Let me know...
> >>
> >>definitely. I would be=20 interested in that. we tried to narrow
> >>the scope and = describe=20 the problem at the last IETF meeting
> >>itself, but I dont = think we=20 succeeded.
> >>after the last IETF meeting, there was draft = put out=20 by some
> >>folks from Southern Methodist University. it = talks=20 about
> >>problem statement for HA=20 reliability.
>
>>http://www.ietf.org/internet-drafts/draft= -jfaizan-mipv6-ha-reliability-00.
txt
>=20 >>
> >>I havent yet read this draft. we could use this = draft=20 as a
> >>base. if needed, I could work with these folks = refining=20 the
> >>problem statement draft.
> >>let me know = what=20 you think about this.
> >>Vijay
>=20 >
>
>
>
------=_NextPart_000_0047_01C3EFBC.27884D00-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 10 11:15:26 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 LAA25668 for ; Tue, 10 Feb 2004 11:15:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaXI-0003Xe-1C for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 11:14:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AGEtWI013608 for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 11:14:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaXH-0003XP-Rd for mip6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 11:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25639 for ; Tue, 10 Feb 2004 11:14:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaXH-0000aX-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 11:14:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaWK-0000TG-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 11:13:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaVP-0000Mi-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 11:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaVP-0003AA-Aj; Tue, 10 Feb 2004 11:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaVM-00039o-51 for mip6@optimus.ietf.org; Tue, 10 Feb 2004 11:12:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25576 for ; Tue, 10 Feb 2004 11:12:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaVL-0000Lq-00 for mip6@ietf.org; Tue, 10 Feb 2004 11:12:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaUQ-0000Fy-00 for mip6@ietf.org; Tue, 10 Feb 2004 11:11:59 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AqaTY-0000Ah-00 for mip6@ietf.org; Tue, 10 Feb 2004 11:11:04 -0500 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83] helo=i72ChVogt) by iramx2.ira.uni-karlsruhe.de with smtp (Exim 3.30 #10 (Debian)) id 1AqaTQ-0001R4-00; Tue, 10 Feb 2004 17:10:56 +0100 Message-ID: <021d01c3efe8$15f14390$5347038d@tm.unikarlsruhe.de> From: "Christian Vogt" To: "Brian Haley" Cc: , References: <001b01c3ee73$aa4f9da0$5347038d@tm.unikarlsruhe.de> <4027C703.2080209@hp.com> Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 Date: Tue, 10 Feb 2004 16:10:55 +0100 Organization: University of Karlsruhe (TH), Institute of Telematics MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCnlvdSBzYXkgdGhhdCBFYXJseSBCaW5kaW5nIFVwZGF0ZXMgbWFrZSBwb3Nz aWJsZSB0aGUgZm9sbG93aW5nIHN0eWxlIG9mIGF0dGFjazoNCg0KPiAxLiBJIHRha2UgY29udHJv bCBvZiwgb3IgaGF2ZSwgYSBzeXN0ZW0gd2l0aCBNaXB2NiBNTiBmdW5jdGlvbmFsaXR5DQo+IDIu IEkgaGF2ZSBpdCBkbyBIb1RJL0hvVCB3aXRoIDEwLDAwMCByYW5kb20gc3lzdGVtcyB0aGF0IGhh dmUgQ04NCj4gICAgZnVuY3Rpb25hbGl0eSB3aXRoIHRoaXMgbmV3ICJlYXJseSIgc3VwcG9ydA0K PiAzLiBJIHNlbmQgYW4gRWFybHkgQmluZGluZyBVcGRhdGUgdG8gdGhlbSBhbGwNCj4gNC4gSW1t ZWRpYXRlbHkgZm9sbG93ZWQgYnkgYSBUQ1AgU1lOLCBwaW5nLCBldGMuDQo+IDUuIFNvbWVvbmUg anVzdCBnb3QgZmxvb2RlZA0KDQpGaXJzdCBvZiBhbGw6IFllcywgeW91IGFyZSByaWdodC4gQXMg c3RhdGVkIGluIHRoZSBJbnRlcm5ldC1EcmFmdCwgdGhlIGF0dGFjayB3b3VsZCBwZXJzaXN0IGZv ciBhIHRpbWUgbGltaXRlZCBieSB0aGUgQ04ncyBURU5UQVRJVkVfQklORElOR19MSUZFVElNRSBw cm90b2NvbC1jb25maWd1cmF0aW9uIHZhcmlhYmxlLiBUaGUgSW50ZXJuZXQtRHJhZnQgY2xhaW1z IHRoYXQgdGhpcyB0aW1lIGlzIHRvbyBzbWFsbCBmb3IgYSB3b3J0aHdoaWxlIGF0dGFjay4gWW91 IGFyZ3VlIHRoYXQgdGhlIHRpbWUgaXMgbG9uZyBlbm91Z2gsIGJlY2F1c2UgdGhlIGF0dGFja2Vy IGNvdWxkIHN1Y2Nlc3NpdmVseSBleHBsb2l0IG11bHRpcGxlIENOcyBpbiBvcmRlciB0byBrZWVw IHRoZSBhdHRhY2sgZ29pbmcuIExldCdzIGxvb2sgY2xvc2VyIGF0IGhvdyBhbiBhdHRhY2tlciB3 b3VsZCBoYXZlIHRvIG9wZXJhdGUuLi4NCg0KUmlnaHQgbm93LCBJIHNlZSB0d28gc3R5bGVzIG9m IGZsb29kaW5nIGF0dGFja3Mgd2hpY2ggYXJlIHJlbGF0ZWQgdG8gb3VyIGRpc2N1c3Npb246IHNp bXBsZSByZWRpcmVjdGlvbiBvZiBkYXRhIGFuZCB0aGUgY29tYmluYXRpb24gb2YgZGF0YSByZWRp cmVjdGlvbiBhbmQgYW1wbGlmaWNhdGlvbi4NCg0KKDEpIFNpbXBsZSByZWRpcmVjdGlvbiBhdHRh Y2tzOiBBbiBhdHRhY2tlciBzZW5kcyBhIHBhY2tldCB0byBhIENOLiBUaGUgcGFja2V0J3MgSVAg U291cmNlIEFkZHJlc3MgaXMgc3Bvb2ZlZDogSXQgY29udGFpbnMgdGhlIElQIGFkZHJlc3Mgb2Yg YW4gYXR0YWNrZWQgbm9kZSwgc2F5LCB0aGUgdmljdGltLiBUaGUgcGFja2V0IGlzIHN1Y2ggdGhh dCB0aGUgQ04gcmVzcG9uZHMgdG8gdGhlIHZpY3RpbSB3aXRoIGEgcGFja2V0IG9mIChhcHByb3hp bWF0ZWx5KSB0aGUgc2FtZSBzaXplLiBUaGlzIGtpbmQgb2YgZmxvb2RpbmcgYXR0YWNrIGNvdWxk IGJlIHRoZSB3ZWxsLWtub3duIFRDUC1TWU4tZmxvb2RpbmcgYXR0YWNrLiBJdCBjb3VsZCBhbHNv IGJlIGFuIElDTVAtRWNoby1SZXF1ZXN0IChQaW5nKSBmbG9vZGluZyBhdHRhY2suIEVpdGhlciB3 YXksIHRoaXMga2luZCBvZiBhdHRhY2sgaXMgcG9zc2libGUgd2l0aCBub3JtYWwgSVB2NiwgaS5l LiwgZXZlbiB3aXRob3V0IE1vYmlsZSBJUHY2IQ0KDQooMikgQ29tYmluaW5nIHJlZGlyZWN0aW9u IHdpdGggYW1wbGlmaWNhdGlvbjogVGhlIGF0dGFja2VyIHNldHMgdXAgYSBoaWdoZXItbGV2ZWwg ZGF0YSBzdHJlYW0uIFRoaXMgY291bGQgYmUgYSBUQ1AtIG9yIFVEUC1iYXNlZCBkb3dubG9hZCwg d2hpY2ggdHlwaWNhbGx5IHJlcXVpcmUgYSBtb3JlIG9yIGxlc3MgY29tcGxpY2F0ZWQgYS1wcmlv cmkgaGFuZHNoYWtlLiAoVGhlIG5lZWQgZm9yIGEgaGFuZHNoYWtlIGlzIGNsZWFyIGluIHRoZSBj YXNlIG9mIGEgVENQLWJhc2VkIGRvd25sb2FkLiBIb3dldmVyLCBtb3N0IFVEUC1iYXNlZCBwcm90 b2NvbHMgYWxzbyByZXF1aXJlIHNvbWUga2luZCBvZiBoYW5kc2hha2UgYmVmb3JlIGRhdGEgZ2V0 cyBmbG93aW5nLikgTm90ZSB0aGF0IHRoZSBhdHRhY2tlciBtdXN0IG1haW50YWluIHN0YXRlIGlu IG9yZGVyIHRvIHN1Y2Nlc3NmdWxseSBkbyB0aGUgaGFuZHNoYWtlLiANCg0KTm93LCBFYXJseSBC aW5kaW5nIFVwZGF0ZXMgY29tZSBpbnRvIHBsYXkuIEhhdmluZyBzaGFrZW4gaGFuZHMgd2l0aCB0 aGUgQ04sIHRoZSBhdHRhY2tlciByZWRpcmVjdHMgdGhlIGRhdGEgZmxvdyB0b3dhcmRzIHRoZSB2 aWN0aW0gd2l0aCB0aGUgaGVscCBvZiBhbiBFYXJseSBCaW5kaW5nIFVwZGF0ZSBtZXNzYWdlLiBU aGlzIGRhdGEgc3RyZWFtIHdpbGwgaG9sZCBmb3IgYXQgbW9zdCBURU5UQVRJVkVfQklORElOR19M SUZFVElNRSBzZWNvbmRzLiAoVEVOVEFUSVZFX0JJTkRJTkdfTElGRVRJTUUgZGVmYXVsdHMgdG8g MyBzZWNvbmRzOyBvbmUgbWF5IC0gYW5kIHByb2JhYmx5IHNob3VsZCAtIHJlZHVjZSB0aGlzIHRp bWUuKQ0KDQpIYXZpbmcgZG9uZSB0aGUgRWFybHkgQmluZGluZyBVcGRhdGUsIHRoZSBhdHRhY2tl ciBtYXkgZGVsZXRlIChwYXJ0IG9mKSB0aGUgc3RhdGUgaXQgaGFzIGNyZWF0ZWQgZm9yIHRoZSBp bml0aWFsIGhhbmRzaGFrZS4gSG93ZXZlciwgdGhlIGF0dGFja2VyIG11c3QgY29udGludWUgdG8g YmxpbmRseSBzZW5kIHNwb29mZWQgYWNrbm93bGVkZ2VtZW50cyBpbiBwZXJpb2RpYyBpbnRlcnZh bHMgaW4gb3JkZXIgdG8ga2VlcCB0aGUgZG93bmxvYWQgdXAgYW5kIHJ1bm5pbmcuIChXaXRoICJz cG9vZmVkIGFja25vd2xlZGdlbWVudHMiLCBJIG1lYW4gYWNrbm93bGVkZ2VtZW50cyB3aXRoIHRo ZSBJUCBTb3VyY2UgQWRkcmVzcyBmaWVsZCBwcmV0ZW5kaW5nIHRoYXQgdGhlIHBhY2tldHMgY29t ZSBmcm9tIHRoZSB2aWN0aW0uKSBNb3N0IHByb2JhYmx5LCB0aGUgYXR0YWNrZXIgbmVlZHMgdG8g a2VlcCBhIGJpdCBvZiBzdGF0ZSBpbiBvcmRlciB0byBzeW5jaHJvbml6ZSBpdHMgYWNrbm93bGVk Z2VtZW50cyB3aXRoIHRoZSBDTi4NCg0KQWdhaW4sIHdpdGggRWFybHkgQmluZGluZyBVcGRhdGVz LCB0aGUgYXR0YWNrZXIncyB5aWVsZCBpcyBhIGRhdGEgc3RyZWFtIHRvd2FyZHMgdGhlIHZpY3Rp bSBvZiBURU5UQVRJVkVfQklORElOR19MSUZFVElNRSBzZWNvbmRzJyBsZW5ndGguIElzbid0IHRo aXMgeWllbGQgdG9vIGxpdHRsZSB0byBtYWtlIHRoZSBmbG9vZGluZyBhdHRhY2sgYSAic3VjY2Vz cyIgKGZyb20gdGhlIGF0dGFja2VyJ3MgcG9pbnQgb2Ygdmlldyk/IA0KDQpJIHRoaW5rIHdoYXQg aXMgbW9zdCBpbXBvcnRhbnQgaXMgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIGF0dGFja2VyJ3Mg eWllbGQgYW5kIHRoZSBhdHRhY2tlcidzICJpbnZlc3RtZW50cyIgaW4gdGVybXMgb2Ygc3RhdGUg YW5kIGhhbmRzaGFraW5nIG92ZXJoZWFkLg0KDQpCcmlhbiwgeW91IG1lbnRpb24gdGhhdCB0aGUg YXR0YWNrZXIgY291bGQgZXhwbG9pdCB0aG91c2FuZHMgb2YgQ05zIGZvciBpdHMgYXR0YWNrLiBZ ZXQsIHRoZSBtb3JlIENOcyBhcmUgYmVpbmcgZXhwbG9pdGVkLCB0aGUgbW9yZSBzdGF0ZSB0aGUg YXR0YWNrZXIgd2lsbCBoYXZlIHRvIG1haW50YWluLiANCg0KUGxlYXNlLCB0ZWxsIG1lIGlmIEkg YW0gbWlzc2luZyBzb21ldGhpbmcuDQoNCkJlc3QgcmVnYXJkcywNCg0KDQotIENocmlzdGlhbg0K DQoNCnwNCnwgQ2hyaXN0aWFuIFZvZ3QNCnwgSW5zdGl0dXRlIG9mIFRlbGVtYXRpY3MsIFVuaXZl cnNpdHkgb2YgS2FybHNydWhlIChUSCkNCnwgd3d3LnRtLnVuaS1rYXJsc3J1aGUuZGUvfmNodm9n dC8NCnwNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkJyaWFuIEhh bGV5IiA8QnJpYW4uSGFsZXlAaHAuY29tPg0KVG86ICJDaHJpc3RpYW4gVm9ndCIgPGNodm9ndEB0 bS51a2EuZGU+DQpDYzogPG1pcDZAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA5 LCAyMDA0IDY6NDQgUE0NClN1YmplY3Q6IFJlOiBbTWlwNl0gTmV3IEktRDogRWFybHkgQmluZGlu ZyBVcGRhdGVzIGZvciBNb2JpbGUgSVB2Ng0KDQoNCkhpIENocmlzdGlhbiwNCg0KSSBiZWxpZXZl IHRoZXJlIGlzIGEgbmVlZCBmb3IgZmFzdGVyIGhhbmRvdmVycyBpbiBNaXB2NiAoRm1pcCBhbmQg SG1pcCANCmFyZSBhZGRyZXNzaW5nIHNvbWUgb2YgdGhpcyksIGJ1dCBJJ20gbm90IHN1cmUgSSBh Z3JlZSB3aXRoIFNlY3Rpb24gNi4yIA0KaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHBh cnQgb2YgdGhpcyBkcmFmdC4NCg0KID4gIENvbmNlcm5pbmcgc2VjdXJpdHkgYWdhaW5zdCBmbG9v ZGluZyBhdHRhY2tzLCBFYXJseSBCaW5kaW5nIFVwZGF0ZXMNCiA+ICBhcmUgYXQgYSBtaW5vciBk aXNhZHZhbnRhZ2Ugd2l0aCBzdGFuZGFyZCBiaW5kaW5nIHVwZGF0ZXMsIGJlY2F1c2UgYQ0KID4g IG1hbGljaW91cyBub2RlIG1heSBleHBsb2l0IHRoZSB0aW1lIHdpbmRvdyBkdXJpbmcgd2hpY2gg YQ0KID4gIGNvcnJlc3BvbmRlbnQgbm9kZSBzZW5kcyBkYXRhIHRvIGEgeWV0LXVudmVyaWZpZWQg Y2FyZS1vZiBhZGRyZXNzLg0KID4gIFdlIHByb3Bvc2UgdHdvIHdheXMgdG8gbWl0aWdhdGUgdGhp cyB0aHJlYXQuDQogPg0KID4gIE9uZSB3YXkgaXMgdG8gcHJvcGVybHkgY29uZmlndXJlIHRoZSBs aWZldGltZSBvZiBhIHRlbnRhdGl2ZQ0KID4gIGJpbmRpbmctY2FjaGUgZW50cnkuIFdlIHByb3Bv c2UgdGhlIHZhbHVlLA0KID4gIFRFTlRBVElWRV9CSU5ESU5HX0xJRkVUSU1FLCBnaXZlbiBpbiBT ZWN0aW9uIDguIEluIHNjZW5hcmlvcyB3aGVyZQ0KID4gIGZsb29kaW5nIGF0dGFja3MgY2Fubm90 IGJlIHJ1bGVkIG91dCwgb25lIHNob3VsZCBhcHByb3ByaWF0ZWx5IHJlZHVjZQ0KID4gIFRFTlRB VElWRV9CSU5ESU5HX0xJRkVUSU1FLg0KDQpXZSdyZSB0YWxraW5nIGFib3V0IHRoaXMgYXR0YWNr Og0KDQoxLiBJIHRha2UgY29udHJvbCBvZiwgb3IgaGF2ZSwgYSBzeXN0ZW0gd2l0aCBNaXB2NiBN TiBmdW5jdGlvbmFsaXR5DQoyLiBJIGhhdmUgaXQgZG8gSG9USS9Ib1Qgd2l0aCAxMCwwMDAgcmFu ZG9tIHN5c3RlbXMgdGhhdCBoYXZlIENODQpmdW5jdGlvbmFsaXR5IHdpdGggdGhpcyBuZXcgImVh cmx5IiBzdXBwb3J0DQozLiBJIHNlbmQgYW4gRWFybHkgQmluZGluZyBVcGRhdGUgdG8gdGhlbSBh bGwNCjQuIEltbWVkaWF0ZWx5IGZvbGxvd2VkIGJ5IGEgVENQIFNZTiwgcGluZywgZXRjLg0KNS4g U29tZW9uZSBqdXN0IGdvdCBmbG9vZGVkDQoNCkV2ZW4gaGF2aW5nIGp1c3QgMSBzZWNvbmQgKHRo ZSBkcmFmdCBnaXZlcyAzKSBnaXZlcyBzb21lb25lIGEgbG90IG9mIA0KdGltZSBzaW5jZSB0aGV5 IGNhbiBqdXN0IGtlZXAgY2hvb3NpbmcgbmV3IHN5c3RlbXMgdG8gZmxvb2QgZnJvbSwgdW50aWwg DQp0aGVpciBNTiBpcyBjYXVnaHQuICBUaGVuIHRoZXkgbW92ZSB0byBhbm90aGVyIE1OIG9yIG5l dHdvcmsuLi4gIFRoaXMgDQpwYXJ0aWN1bGFyIGF0dGFjayBpcyBub3QgcG9zc2libGUgd2l0aCBy ZWd1bGFyIEJpbmRpbmcgVXBkYXRlcy4NCg0KLUJyaWFuDQoNCg0KQ2hyaXN0aWFuIFZvZ3Qgd3Jv dGU6DQoNCj4gSGksDQo+IA0KPiB3ZSBzdWJtaXR0ZWQgYSBuZXcgSW50ZXJuZXQtRHJhZnQsIGRy YWZ0LXZvZ3QtbWlwNi1lYXJseS1iaW5kaW5nLXVwZGF0ZXMtMDAudHh0LA0KPiB0aGF0IHByb3Bv c2VzIEVhcmx5IEJpbmRpbmcgVXBkYXRlcyBmb3IgTW9iaWxlIElQdjYgKHBsZWFzZSBzZWUgdGhl IGFic3RyYWN0IGJlbG93KS4NCj4gVGhlIHByb3Bvc2FsIGlzIGFuIG9wdGlvbmFsIGV4dGVuc2lv biB0byBNb2JpbGUgSVB2NidzIFJvdXRlIE9wdGltaXphdGlvbiBtb2RlLg0KPiANCj4gV2UgcmVj b2duaXplIHRoYXQgRWFybHkgQmluZGluZyBVcGRhdGVzIGZvciBNb2JpbGUgSVB2NiBtYXkgZml0 IGludG8gZWl0aGVyIHRoZQ0KPiBtaXA2IFdHJ3Mgb3IgdGhlIG1pcHNob3AgV0cncyBjaGFydGVy LiBXZSB3b3VsZCB0aGVyZWZvcmUgYXBwcmVjaWF0ZSBmZWVkYmFjayBmcm9tDQo+IHRoaXMgV0cg b24gd2hldGhlciB0aGUgcHJvcG9zYWwgaXMgYXBwcm9wcmlhdGUgdG8gYmUgYWRvcHRlZCBhcyBh IFdHIGl0ZW0gbGF0ZXIuDQo+IA0KPiBUaXRsZS4uLi46IEVhcmx5IEJpbmRpbmcgVXBkYXRlcyBm b3IgTW9iaWxlIElQdjYNCj4gQXV0aG9yKHMpOiBDLiBWb2d0LCBSLiBCbGVzcywgTS4gRG9sbCwg VC4gS3VlZm5lcg0KPiBGaWxlbmFtZS46IGRyYWZ0LXZvZ3QtbWlwNi1lYXJseS1iaW5kaW5nLXVw ZGF0ZXMtMDAudHh0DQo+IFBhZ2VzLi4uLjogMjgNCj4gRGF0ZS4uLi4uOiAyMDA0LTAyLTA0DQo+ IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhlIGxvbmcgbGF0ZW5jeSBhc3NvY2lhdGVkIHdpdGggTW9i aWxlIElQdjYncyBob21lLWFkZHJlc3MgYW5kDQo+ICAgIGNhcmUtb2YtYWRkcmVzcyB0ZXN0cyBj YW4gc2lnbmlmaWNhbnRseSBpbXBhY3QgZGVsYXktc2Vuc2l0aXZlDQo+ICAgIGFwcGxpY2F0aW9u cy4gV2UgcHJvcG9zZSBhIG1vZGlmaWVkIGJpbmRpbmctdXBkYXRlIHByb2NlZHVyZSB0aGF0DQo+ ICAgIGV2YWRlcyB0aGUgbGF0ZW5jeSBvZiBib3RoIGFkZHJlc3MgdGVzdHMuIFRoZSBtb2RpZmll ZCBiaW5kaW5nIHVwZGF0ZQ0KPiAgICBydW5zIGluIGhhbGYsIG9yIGxlc3MsIG9mIHRoZSB0aW1l IHRoYXQgYSBzdGFuZGFyZCBiaW5kaW5nIHVwZGF0ZQ0KPiAgICB0YWtlcy4gTW9yZW92ZXIsIHRo ZSBtb2RpZmllZCBiaW5kaW5nIHVwZGF0ZSBpcyBuZWFybHkgZXF1aXZhbGVudCB0bw0KPiAgICB0 aGUgc3RhbmRhcmQgcHJvY2VkdXJlIHdpdGggcmVzcGVjdCB0byBzZWN1cml0eSwgYW5kIGl0IGlu Y3JlYXNlcyB0aGUNCj4gICAgcmVzb3VyY2VzIHJlcXVpcmVkIGF0IHRoZSBjb3JyZXNwb25kZW50 IG5vZGUgb25seSBtYXJnaW5hbGx5LiBUaGUNCj4gICAgbW9kaWZpY2F0aW9uIGlzIHJlYWxpemVk IGFzIGFuIG9wdGlvbmFsLCBhbmQgZnVsbHkNCj4gICAgYmFja3dhcmQtY29tcGF0aWJsZSwgZXh0 ZW5zaW9uIHRvIE1vYmlsZSBJUHY2Lg0KPiANCj4gVGhlIEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhlIFVS TCBpczoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdm9ndC1t aXA2LWVhcmx5LWJpbmRpbmctdXBkYXRlcy0wMC50eHQNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4g DQo+IA0KPiAtIENocmlzdGlhbiBWb2d0DQo+IA0KPiANCj4gUFM6IEEgZmVhc2libGUsIHlldCBu b24tdHJpdmlhbCB2YXJpYXRpb24gb2YgIkVhcmx5IEJpbmRpbmcgVXBkYXRlcyBmb3IgTW9iaWxl IElQdjYiIGlzDQo+IHRvIGhhdmUgdGhlIG1vYmlsZSBub2RlIHRlbnRhdGl2ZWx5IHJlZ2lzdGVy IGEgbmV3IGNhcmUtb2YgYWRkcmVzcyAqYmVmb3JlKiBpdCBjaGFuZ2VzDQo+IGl0cyBwb2ludCBv ZiBuZXR3b3JrIGF0dGFjaG1lbnQuIFdlIGFyZSBjdXJyZW50bHkgd29ya2luZyBvbiBhIHNvbHV0 aW9uIGZvciB0aGlzDQo+IHZhcmlhdGlvbi4gV2UgaW50ZW5kIHRvIHB1Ymxpc2ggb3VyIHdvcmsg aW4gYSBzZXBhcmF0ZSBJbnRlcm5ldC1EcmFmdCBpbiB0aGUgbmVhciBmdXR1cmUuDQo+IA0KPiAN Cj4gfA0KPiB8IENocmlzdGlhbiBWb2d0DQo+IHwgSW5zdGl0dXRlIG9mIFRlbGVtYXRpY3MsIFVu aXZlcnNpdHkgb2YgS2FybHNydWhlIChUSCkNCj4gfCB3d3cudG0udWthLmRlL35jaHZvZ3QvDQo+ IHwNCg== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 10 11:20:24 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 LAA25924 for ; Tue, 10 Feb 2004 11:20:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqac8-00049T-9Z for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 11:19:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AGJuFh015953 for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 11:19:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqac8-00049E-38 for mip6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 11:19:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25900 for ; Tue, 10 Feb 2004 11:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqac7-0001Au-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 11:19:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqabB-00014V-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 11:18:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaaI-0000xt-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 11:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaaI-0003zi-8E; Tue, 10 Feb 2004 11:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaaC-0003z6-5F for mip6@optimus.ietf.org; Tue, 10 Feb 2004 11:17:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25824 for ; Tue, 10 Feb 2004 11:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaaB-0000wt-00 for mip6@ietf.org; Tue, 10 Feb 2004 11:17:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaZE-0000pO-00 for mip6@ietf.org; Tue, 10 Feb 2004 11:16:56 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AqaYI-0000i8-00 for mip6@ietf.org; Tue, 10 Feb 2004 11:15:58 -0500 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83] helo=i72ChVogt) by iramx2.ira.uni-karlsruhe.de with smtp (Exim 3.30 #10 (Debian)) id 1AqaYD-0001ZA-00; Tue, 10 Feb 2004 17:15:53 +0100 Message-ID: <023d01c3efe8$c72ea580$5347038d@tm.unikarlsruhe.de> From: "Christian Vogt" To: "Francis Dupont" Cc: References: <200402091834.i19IYcSj066036@givry.rennes.enst-bretagne.fr> Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 Date: Tue, 10 Feb 2004 16:15:53 +0100 Organization: University of Karlsruhe (TH), Institute of Telematics MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiBbLi4uXSBpbiBmYWN0IHRoZXJlIGlzIGFuIGltcG9ydGFudCBkZXRhaWwgd2hpY2ggaXMgd3Jv bmcgaW4gdGhlIGVhcmx5DQo+IGJpbmRpbmcgZHJhZnQ6IHRoZSBDTiBNVVNUIE5PVCBhY2NlcHQg YW4gZWFybHkgYmluZGluZyB1cGRhdGUgY2FycnlpbmcNCj4gYW4gYWx0ZXJuYXRlIGNhcmUtb2Yg YWRkcmVzcyBvcHRpb24gd2l0aCBhIGRpZmZlcmVudCBhZGRyZXNzIHRoYW4NCj4gdGhlIHNvdXJj ZSBhZGRyZXNzIGluIHRoZSBJUHY2IGhlYWRlciAodGhlIHBsYWNlIHdoZXJlIHRoZSBjYXJlLW9m DQo+IGFkZHJlc3MgaXMgdXN1YWxseSBmb3VuZCkuIFdpdGggdGhpcyBwcmVjYXV0aW9uIHRoZSBy ZWZsZWN0aW9uIGF0dGFjaw0KPiB1c2luZyBhbiAiZWFybHkgQ04iIGlzIG5vdCBiZXR0ZXIgKGZy b20gdGhlIGJhZCBndXkncyBwb2ludCBvZiB2aWV3KQ0KPiB0aGFuIHRoZSBzdGFuZGFyZCBvbmUu IFsuLi5dDQoNCg0KSGkgRnJhbmNpcywNCg0KeW91IGFyZSB0b3RhbGx5IHJpZ2h0LiBEZXNpZ25p bmcgRWFybHkgQmluZGluZyBVcGRhdGVzLCB3ZSBpbXBsaWNpdGx5IGFzc3VtZWQgbm90IHRvIHVz ZSB0aGUgQWx0ZXJuYXRlIENvQSBPcHRpb24uIFRoZSBJbnRlcm5ldC1EcmFmdCBmYWlscyB0byBt ZW50aW9uIHRoaXMsIGFuZCB3ZSBzaG91bGQgYWRkIGFuIGV4cGxpY2l0IHBhc3NhZ2UgaW4gdGhl IG5leHQgdmVyc2lvbi4gVGhhbmtzIGZvciBwb2ludGluZyB0byB0aGlzLg0KDQpCZXN0IHJlZ2Fy ZHMsDQoNCg0KLSBDaHJpc3RpYW4gVm9ndA0KDQoNCnwNCnwgQ2hyaXN0aWFuIFZvZ3QNCnwgSW5z dGl0dXRlIG9mIFRlbGVtYXRpY3MsIFVuaXZlcnNpdHkgb2YgS2FybHNydWhlIChUSCkNCnwgd3d3 LnRtLnVrYS5kZS9+Y2h2b2d0Lw0KfA0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiAiRnJhbmNpcyBEdXBvbnQiIDxGcmFuY2lzLkR1cG9udEBlbnN0LWJyZXRhZ25lLmZy Pg0KVG86ICJCcmlhbiBIYWxleSIgPEJyaWFuLkhhbGV5QGhwLmNvbT4NCkNjOiAiQ2hyaXN0aWFu IFZvZ3QiIDxjaHZvZ3RAdG0udWthLmRlPjsgPG1pcDZAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXks IEZlYnJ1YXJ5IDA5LCAyMDA0IDc6MzQgUE0NClN1YmplY3Q6IFJlOiBbTWlwNl0gTmV3IEktRDog RWFybHkgQmluZGluZyBVcGRhdGVzIGZvciBNb2JpbGUgSVB2NiANCg0KDQo+IEluIHlvdXIgcHJl dmlvdXMgbWFpbCB5b3Ugd3JvdGU6DQo+IA0KPiAgICBJIGJlbGlldmUgdGhlcmUgaXMgYSBuZWVk IGZvciBmYXN0ZXIgaGFuZG92ZXJzIGluIE1pcHY2IChGbWlwIGFuZCBIbWlwIA0KPiAgICBhcmUg YWRkcmVzc2luZyBzb21lIG9mIHRoaXMpLCBidXQgSSdtIG5vdCBzdXJlIEkgYWdyZWUgd2l0aCBT ZWN0aW9uIDYuMiANCj4gICAgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHBhcnQgb2Yg dGhpcyBkcmFmdC4NCj4gICAgDQo+ID0+IGFzIHRoZXJlIGlzIGN1cnJlbnRseSBzb21lIEZVRCBh Ym91dCByZWZsZWN0aW9uIGF0dGFja3Mgd2l0aA0KPiBtb2JpbGUgSVB2NiBvcHRpbWl6YXRpb25z LCBJTUhPIHdlIGhhdmUgdG8gYmUgYWNjdXJhdGUgYWJvdXQNCj4gdGhpcyBpc3N1ZS4gVGhpcyBp cyB3aHkgSSBzdWJtaXR0ZWQgdGhpcyBhZnRlcm5vb24gKGluIEV1cm9wZSkNCj4gYSBkcmFmdCBh Ym91dCB0aGlzLg0KPiANCj4gICAgID4gIENvbmNlcm5pbmcgc2VjdXJpdHkgYWdhaW5zdCBmbG9v ZGluZyBhdHRhY2tzLCBFYXJseSBCaW5kaW5nIFVwZGF0ZXMNCj4gICAgID4gIGFyZSBhdCBhIG1p bm9yIGRpc2FkdmFudGFnZSB3aXRoIHN0YW5kYXJkIGJpbmRpbmcgdXBkYXRlcywgYmVjYXVzZSBh DQo+ICAgICA+ICBtYWxpY2lvdXMgbm9kZSBtYXkgZXhwbG9pdCB0aGUgdGltZSB3aW5kb3cgZHVy aW5nIHdoaWNoIGENCj4gICAgID4gIGNvcnJlc3BvbmRlbnQgbm9kZSBzZW5kcyBkYXRhIHRvIGEg eWV0LXVudmVyaWZpZWQgY2FyZS1vZiBhZGRyZXNzLg0KPiANCj4gPT4gaW4gZmFjdCBldmVuIGlm IHRvIHZlcmlmeSBuZXcgY2FyZS1vZiBhZGRyZXNzZXMgaXMgbm90IGJhZCB0aGlzIGRvZXMNCj4g bm90IGltcHJvdmUgdGhlIHNlY3VyaXR5IGJlY2F1c2U6DQo+ICAtIHRoZSBIQSBkb2VzIG5vdCB2 ZXJpZnkgdGhlbSAoaS5lLiwgd2h5IHRvIGNsb3NlIHRoZSB3aW5kb3cgd2hlbg0KPiAgICB0aGUg ZG9vciByZW1haW5zIG9wZW4/KQ0KPiAgLSB1c2luZyBtb2JpbGUgSVB2NiBkb2VzIG5vdCBhZGQg Z29vZGllcyB0byB0aGUgc3RhbmRhcmQgcmVmbGVjdGlvbg0KPiAgICBhdHRhY2sNCj4gIC0gdGhp cyBpcyB0cnVlIGZvciBjYXJlZnVsbHkgZGVzaWduZWQgb3B0aW1pemVkIHNjaGVtZXMsIHdoaWNo IG9mIGNvdXJzZQ0KPiAgICBzaG91bGQgbm90IHZlcmlmeSBuZXcgY2FyZS1vZiBhZGRyZXNzZXMg aWYgdGhleSdkIHJlYWxseSBsaWtlIHRvDQo+ICAgIGJlIG9wdGltaXplZCAoOi0pLg0KPiANCj4g ICAgV2UncmUgdGFsa2luZyBhYm91dCB0aGlzIGF0dGFjazoNCj4gICAgDQo+ICAgIDEuIEkgdGFr ZSBjb250cm9sIG9mLCBvciBoYXZlLCBhIHN5c3RlbSB3aXRoIE1pcHY2IE1OIGZ1bmN0aW9uYWxp dHkNCj4gICAgMi4gSSBoYXZlIGl0IGRvIEhvVEkvSG9UIHdpdGggMTAsMDAwIHJhbmRvbSBzeXN0 ZW1zIHRoYXQgaGF2ZSBDTg0KPiAgICBmdW5jdGlvbmFsaXR5IHdpdGggdGhpcyBuZXcgImVhcmx5 IiBzdXBwb3J0DQo+ICAgIDMuIEkgc2VuZCBhbiBFYXJseSBCaW5kaW5nIFVwZGF0ZSB0byB0aGVt IGFsbA0KPiAgICA0LiBJbW1lZGlhdGVseSBmb2xsb3dlZCBieSBhIFRDUCBTWU4sIHBpbmcsIGV0 Yy4NCj4gICAgNS4gU29tZW9uZSBqdXN0IGdvdCBmbG9vZGVkDQo+ICAgIA0KPiA9PiBJIHByb3Bv c2Ugc29tZXRoaW5nIGVhc2llcjoNCj4gICAxLiBJIHRha2UgY29udHJvbCBvZiwgb3IgaGF2ZSwg YSBzeXN0ZW0gd2l0aCBJUHY2IGZ1bmN0aW9uYWxpdHkNCj4gICAyLiBJIHNlbmQgYW4gSFRUUCBy ZXF1ZXN0IG9yIHBpbmcgb3IgZXRjLiB0byAxMCwwMDAgcmFuZG9tIHdlYg0KPiAgICAgICAgc2Vy dmVycyB0aGF0IGhhdmUgSVB2NiBzdXBwb3J0DQo+ICAgMy4gU29tZW9uZSBqdXN0IGdvdCBmbG9v ZGVkDQo+IA0KPiAgICBFdmVuIGhhdmluZyBqdXN0IDEgc2Vjb25kICh0aGUgZHJhZnQgZ2l2ZXMg MykgZ2l2ZXMgc29tZW9uZSBhIGxvdCBvZiANCj4gICAgdGltZSBzaW5jZSB0aGV5IGNhbiBqdXN0 IGtlZXAgY2hvb3NpbmcgbmV3IHN5c3RlbXMgdG8gZmxvb2QgZnJvbSwgdW50aWwgDQo+ICAgIHRo ZWlyIE1OIGlzIGNhdWdodC4gIFRoZW4gdGhleSBtb3ZlIHRvIGFub3RoZXIgTU4gb3IgbmV0d29y ay4uLg0KPiANCj4gPT4gc28gZWl0aGVyIHRoZSByZWZsZWN0aW9uIGF0dGFjayBpcyBhY2NlcHRl ZCBvciB0aGUgb3B0aW1pemF0aW9uDQo+IGlzIG5vdCBvcHRpbWl6aW5nLg0KPiANCj4gICAgVGhp cyBwYXJ0aWN1bGFyIGF0dGFjayBpcyBub3QgcG9zc2libGUgd2l0aCByZWd1bGFyIEJpbmRpbmcg VXBkYXRlcy4NCj4gDQo+ID0+IHRvIGJlIGFjY3VyYXRlIGl0IGlzIGhhcmQgd2l0aCByZXR1cm4g cm91dGFiaWxpdHkgY2hlY2sgb24gdGhlIGNhcmUtb2YNCj4gYWRkcmVzcy4NCj4gICAgDQo+IFJl Z2FyZHMNCj4gDQo+IEZyYW5jaXMuRHVwb250QGVuc3QtYnJldGFnbmUuZnINCj4gDQo+IFBTOiBp biBmYWN0IHRoZXJlIGlzIGFuIGltcG9ydGFudCBkZXRhaWwgd2hpY2ggaXMgd3JvbmcgaW4gdGhl IGVhcmx5DQo+IGJpbmRpbmcgZHJhZnQ6IHRoZSBDTiBNVVNUIE5PVCBhY2NlcHQgYW4gZWFybHkg YmluZGluZyB1cGRhdGUgY2FycnlpbmcNCj4gYW4gYWx0ZXJuYXRlIGNhcmUtb2YgYWRkcmVzcyBv cHRpb24gd2l0aCBhIGRpZmZlcmVudCBhZGRyZXNzIHRoYW4NCj4gdGhlIHNvdXJjZSBhZGRyZXNz IGluIHRoZSBJUHY2IGhlYWRlciAodGhlIHBsYWNlIHdoZXJlIHRoZSBjYXJlLW9mDQo+IGFkZHJl c3MgaXMgdXN1YWxseSBmb3VuZCkuIFdpdGggdGhpcyBwcmVjYXV0aW9uIHRoZSByZWZsZWN0aW9u IGF0dGFjaw0KPiB1c2luZyBhbiAiZWFybHkgQ04iIGlzIG5vdCBiZXR0ZXIgKGZyb20gdGhlIGJh ZCBndXkncyBwb2ludCBvZiB2aWV3KQ0KPiB0aGFuIHRoZSBzdGFuZGFyZCBvbmUuDQo+IFBQUzog cGxlYXNlIHdhaXQgdGhlIHB1YmxpY2F0aW9uIG9mIG15IGRyYWZ0IGluIHNvbWUgZGF5cywgaXRz IG5hbWUgaXMNCj4gZHJhZnQtZHVwb250LW1pcHY2LTNib21iaW5nLTAwLnR4dCAuDQoNCg0KQ2hy aXN0aWFuIFZvZ3Qgd3JvdGU6DQoNCj4gSGksDQo+IA0KPiB3ZSBzdWJtaXR0ZWQgYSBuZXcgSW50 ZXJuZXQtRHJhZnQsIGRyYWZ0LXZvZ3QtbWlwNi1lYXJseS1iaW5kaW5nLXVwZGF0ZXMtMDAudHh0 LA0KPiB0aGF0IHByb3Bvc2VzIEVhcmx5IEJpbmRpbmcgVXBkYXRlcyBmb3IgTW9iaWxlIElQdjYg KHBsZWFzZSBzZWUgdGhlIGFic3RyYWN0IGJlbG93KS4NCj4gVGhlIHByb3Bvc2FsIGlzIGFuIG9w dGlvbmFsIGV4dGVuc2lvbiB0byBNb2JpbGUgSVB2NidzIFJvdXRlIE9wdGltaXphdGlvbiBtb2Rl Lg0KPiANCj4gV2UgcmVjb2duaXplIHRoYXQgRWFybHkgQmluZGluZyBVcGRhdGVzIGZvciBNb2Jp bGUgSVB2NiBtYXkgZml0IGludG8gZWl0aGVyIHRoZQ0KPiBtaXA2IFdHJ3Mgb3IgdGhlIG1pcHNo b3AgV0cncyBjaGFydGVyLiBXZSB3b3VsZCB0aGVyZWZvcmUgYXBwcmVjaWF0ZSBmZWVkYmFjayBm cm9tDQo+IHRoaXMgV0cgb24gd2hldGhlciB0aGUgcHJvcG9zYWwgaXMgYXBwcm9wcmlhdGUgdG8g YmUgYWRvcHRlZCBhcyBhIFdHIGl0ZW0gbGF0ZXIuDQo+IA0KPiBUaXRsZS4uLi46IEVhcmx5IEJp bmRpbmcgVXBkYXRlcyBmb3IgTW9iaWxlIElQdjYNCj4gQXV0aG9yKHMpOiBDLiBWb2d0LCBSLiBC bGVzcywgTS4gRG9sbCwgVC4gS3VlZm5lcg0KPiBGaWxlbmFtZS46IGRyYWZ0LXZvZ3QtbWlwNi1l YXJseS1iaW5kaW5nLXVwZGF0ZXMtMDAudHh0DQo+IFBhZ2VzLi4uLjogMjgNCj4gRGF0ZS4uLi4u OiAyMDA0LTAyLTA0DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhlIGxvbmcgbGF0ZW5jeSBhc3Nv Y2lhdGVkIHdpdGggTW9iaWxlIElQdjYncyBob21lLWFkZHJlc3MgYW5kDQo+ICAgIGNhcmUtb2Yt YWRkcmVzcyB0ZXN0cyBjYW4gc2lnbmlmaWNhbnRseSBpbXBhY3QgZGVsYXktc2Vuc2l0aXZlDQo+ ICAgIGFwcGxpY2F0aW9ucy4gV2UgcHJvcG9zZSBhIG1vZGlmaWVkIGJpbmRpbmctdXBkYXRlIHBy b2NlZHVyZSB0aGF0DQo+ICAgIGV2YWRlcyB0aGUgbGF0ZW5jeSBvZiBib3RoIGFkZHJlc3MgdGVz dHMuIFRoZSBtb2RpZmllZCBiaW5kaW5nIHVwZGF0ZQ0KPiAgICBydW5zIGluIGhhbGYsIG9yIGxl c3MsIG9mIHRoZSB0aW1lIHRoYXQgYSBzdGFuZGFyZCBiaW5kaW5nIHVwZGF0ZQ0KPiAgICB0YWtl cy4gTW9yZW92ZXIsIHRoZSBtb2RpZmllZCBiaW5kaW5nIHVwZGF0ZSBpcyBuZWFybHkgZXF1aXZh bGVudCB0bw0KPiAgICB0aGUgc3RhbmRhcmQgcHJvY2VkdXJlIHdpdGggcmVzcGVjdCB0byBzZWN1 cml0eSwgYW5kIGl0IGluY3JlYXNlcyB0aGUNCj4gICAgcmVzb3VyY2VzIHJlcXVpcmVkIGF0IHRo ZSBjb3JyZXNwb25kZW50IG5vZGUgb25seSBtYXJnaW5hbGx5LiBUaGUNCj4gICAgbW9kaWZpY2F0 aW9uIGlzIHJlYWxpemVkIGFzIGFuIG9wdGlvbmFsLCBhbmQgZnVsbHkNCj4gICAgYmFja3dhcmQt Y29tcGF0aWJsZSwgZXh0ZW5zaW9uIHRvIE1vYmlsZSBJUHY2Lg0KPiANCj4gVGhlIEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4gVGhlIFVSTCBpczoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtdm9ndC1taXA2LWVhcmx5LWJpbmRpbmctdXBkYXRlcy0wMC50eHQNCj4gDQo+IEJl c3QgcmVnYXJkcywNCj4gDQo+IA0KPiAtIENocmlzdGlhbiBWb2d0DQo+IA0KPiANCj4gUFM6IEEg ZmVhc2libGUsIHlldCBub24tdHJpdmlhbCB2YXJpYXRpb24gb2YgIkVhcmx5IEJpbmRpbmcgVXBk YXRlcyBmb3IgTW9iaWxlIElQdjYiIGlzDQo+IHRvIGhhdmUgdGhlIG1vYmlsZSBub2RlIHRlbnRh dGl2ZWx5IHJlZ2lzdGVyIGEgbmV3IGNhcmUtb2YgYWRkcmVzcyAqYmVmb3JlKiBpdCBjaGFuZ2Vz DQo+IGl0cyBwb2ludCBvZiBuZXR3b3JrIGF0dGFjaG1lbnQuIFdlIGFyZSBjdXJyZW50bHkgd29y a2luZyBvbiBhIHNvbHV0aW9uIGZvciB0aGlzDQo+IHZhcmlhdGlvbi4gV2UgaW50ZW5kIHRvIHB1 Ymxpc2ggb3VyIHdvcmsgaW4gYSBzZXBhcmF0ZSBJbnRlcm5ldC1EcmFmdCBpbiB0aGUgbmVhciBm dXR1cmUuDQo+IA0KPiANCj4gfA0KPiB8IENocmlzdGlhbiBWb2d0DQo+IHwgSW5zdGl0dXRlIG9m IFRlbGVtYXRpY3MsIFVuaXZlcnNpdHkgb2YgS2FybHNydWhlIChUSCkNCj4gfCB3d3cudG0udWth LmRlL35jaHZvZ3QvDQo+IHwNCg== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 10 13:27:28 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 NAA01273 for ; Tue, 10 Feb 2004 13:27:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqcb7-0005r3-I8 for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 13:27:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AIR1ea022499 for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 13:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqcb7-0005qo-9n for mip6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 13:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01240 for ; Tue, 10 Feb 2004 13:26:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcb5-0006cz-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 13:26:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqca7-0006Wy-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 13:26:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqcZE-0006RJ-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 13:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcZD-0005lG-5s; Tue, 10 Feb 2004 13:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcYI-0005hM-Cw for mip6@optimus.ietf.org; Tue, 10 Feb 2004 13:24:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01118 for ; Tue, 10 Feb 2004 13:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqcYG-0006KG-00 for mip6@ietf.org; Tue, 10 Feb 2004 13:24:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcXM-0006EO-00 for mip6@ietf.org; Tue, 10 Feb 2004 13:23:09 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AqcWZ-00062z-00 for mip6@ietf.org; Tue, 10 Feb 2004 13:22:20 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1AILca03171; Tue, 10 Feb 2004 10:21:38 -0800 X-mProtect: <200402101821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDarbwS; Tue, 10 Feb 2004 10:21:26 PST Message-ID: <402923AC.1030501@iprg.nokia.com> Date: Tue, 10 Feb 2004 10:32:12 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jahanzeb Faizan CC: Ryuji Wakikawa , mip6@ietf.org, gdommety@cisco.com, basavaraj.patil@nokia.com, Hesham El-Rewini , Mohamed Khalil Subject: Re: [Mip6] Re: Re: Home Agent Reliability and (Home Agent Selection?)] References: <4028430D.7080001@iprg.nokia.com> <004c01c3efee$73d946a0$73657781@SICLTPC1> In-Reply-To: <004c01c3efee$73d946a0$73657781@SICLTPC1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Jahanzeb, Jahanzeb Faizan wrote: > Hi Vijay, > > I am glad to hear from you about the progress in the WG. Also thanks for > your comments and suggestions regarding the modifications in our draft > (http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-00.txt ) . > Please find my comments below followed by "Jahanzeb->" > > > >>hi all, >> >>I was asked by the MIP6 WG chairs to refine the problem >>statement draft for HA reliability and use it as a basis >>for the work in the MIP6 WG. >> >>I read through your draft and have a few comments. >> >>I would like the problem statement to be expanded to >>include the case when the home link fails. if the home >>link (or a router upstream) fails, then having multiple >>Home Agents on the same link is not going to help HA >>reliability. it would be nice if the HAs can be in >>phyically separate locations. the problem statement draft >>does not have to make this the default case, but should >>allow for Home Agents to be placed in the physically >>different locations. >> > > > Jahanzeb-> > > Yes you are right in making this point of link failure, but allowing the HA > to spread around different links > > 1. will cause MN to perform multiple home registrations on different HAs > which will increase burden on air bandwidth and MN itself. > 2. Also MN has to establish IPsec Security Associations with all its HAs > which is again a big overhead. > 3. Moreover this will not solve the problem of "Delayed Failure Detection" > as we have discussed in our draft. > > So I think if we want to take link failure into consideration then we should > come up with some thing else , other than allowing HAs to exists on > different links. the idea is to document the problem completely. not look at the solution or how the problem can be solved. Home Link failure is something that needs to be documented in the problem statement. it is upto the WG later to figure out if that is something that we need to solve. > > >>section 3 now covers Failure Detection and configuring >>security associations with the new HA. I think it should >>be expanded to include HA switching. HA switching has >>two parts to it. the first, how does the MN switch to >>another HA? relying on failed BUs and MPSs will take too > > > Jahanzeb-> > > In our draft we have included the discussion about how MN will > switch to another HA on the basis of current specifications > of Mobile-IPv6. Please refer to the following para in sec 3.2 of our draft > > " Once the failure is detected, MN will try to register its Care of > Address with any other Home Agent on the subnet. For this MN must > know which other Home Agents are available on the subnet. MN MAY > start Dynamic Home Agent Discovery(DHAD)[1] protocol and as the > result will get list of available Home Agents on the subnet. MN could > then select HA_x (in our scenario) on the list as its potential > serving Home Agent. MN will send BU message to HA_x setting Home > Registration(H) bit. " sure this will work. but as I said earlier, document the problem and then look at the solutions. > > >>long. the second part, how does one HA take over from a >>failed HA? was there some shared state between the HAs >>which made it possible for one HA to take over from the >>failed HA? >> > > > Jahanzeb-> > > We have included this point in the "Solution Guidelines" section > instead of putting it in the "Problem Statement" section. Actually > according to current specifications of Mobile-Ipv6 failure of any HA on the > subnet does not drive any other HA to do any kind of recovery work , except > updating their HA Status Lists and deleting the entry for the failed HA. All > the recovery load is on MN itself i.e MN after failure of its working HA has > to register with a new HA on the subnet. we dont yet know if this is the way to go. infact this again conflicts with your "solution guideline" of keeping this transparent to the MN. > So there is no such thing or even > need of having this kind of recovery work (a new HA take overs the failed > HA) on the basis of current Mobile-IPv6 specificatios. That's why we didn't > consider it as a problem rather took it as a "Solution Requirement" > > > >>there is also the issue of load balancing. if a HA wants >>to reduce its load, it should be able to force a >>particular MN to start using another HA. >> > > > Jahanzeb-> > Yes you are right. We should inlcude it in the problem statement. great. > > > >>I dont agree with 4.3 (Seamless failure) and 4.4 (Mobile >>Node functionality). infact section 4.2 conflicts with >>both 4.3 and 4.4. I prefer the MN to know about the HA >>switch rather than put in hacks (generally dirty) to make >>the HA switch transparent to the MN. actuallty, I would >>like to see section 4 deleted from the draft. it is >>sufficient to define the problem. I see Solution Guidelines >>as a fancy term for requirements. :) requirements always >>lead to never-ending discussions. > > > Jahanzeb-> > > Actually I don't see requirement 4.2 conflicting with 4.3 and 4.4. > MN could remain ignorant about the HA failure and recovery process and at > the same time could have IPsec SAs with the new HA. I take 4.2 as a seperate requirement > than 4.3 and 4.4. then, why did it setup SAs with the new HA, if the HA switch can be kept transparent to the MN? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 10 13:54:35 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 NAA02618 for ; Tue, 10 Feb 2004 13:54:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqd1K-0008B0-UQ for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 13:54:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AIs6Zs031430 for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 13:54:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqd1K-0008Ar-Lw for mip6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 13:54:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02572 for ; Tue, 10 Feb 2004 13:54:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqd1I-000202-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 13:54:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqd0I-0001q5-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 13:53:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqczL-0001eI-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 13:52:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqczM-0006WY-2N for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 13:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqczJ-00082e-Ps; Tue, 10 Feb 2004 13:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqcyc-00081p-Ge for mip6@optimus.ietf.org; Tue, 10 Feb 2004 13:51:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02243 for ; Tue, 10 Feb 2004 13:51:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcya-0001U3-00 for mip6@ietf.org; Tue, 10 Feb 2004 13:51:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqcxe-0001IF-00 for mip6@ietf.org; Tue, 10 Feb 2004 13:50:19 -0500 Received: from email.seas.smu.edu ([129.119.113.35]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcwh-0001AS-00 for mip6@ietf.org; Tue, 10 Feb 2004 13:49:19 -0500 Received: from SICLTPC1 (sicltpc1.seas.smu.edu [129.119.101.115]) by email.engr.smu.edu (Postfix) with SMTP id 3C0EB26BF0; Tue, 10 Feb 2004 12:49:18 -0600 (CST) Message-ID: <004301c3f006$78a33de0$73657781@SICLTPC1> From: "Jahanzeb Faizan" To: "Vijay Devarapalli" Cc: "Ryuji Wakikawa" , , , , "Hesham El-Rewini" , "Mohamed Khalil" References: <4028430D.7080001@iprg.nokia.com> <004c01c3efee$73d946a0$73657781@SICLTPC1> <402923AC.1030501@iprg.nokia.com> Subject: Re: [Mip6] Re: Re: Home Agent Reliability and (Home Agent Selection?)] Date: Tue, 10 Feb 2004 12:48:27 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hi Vijay, It is good that things are progressing. Few more comments please find below. Jahanzeb ----- Original Message ----- From: "Vijay Devarapalli" To: "Jahanzeb Faizan" Cc: "Ryuji Wakikawa" ; ; ; ; "Hesham El-Rewini" ; "Mohamed Khalil" Sent: Tuesday, February 10, 2004 12:32 PM Subject: Re: [Mip6] Re: Re: Home Agent Reliability and (Home Agent Selection?)] > Hi Jahanzeb, > > Jahanzeb Faizan wrote: > > Hi Vijay, > > > > I am glad to hear from you about the progress in the WG. Also thanks for > > your comments and suggestions regarding the modifications in our draft > > (http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-00.t xt ) . > > Please find my comments below followed by "Jahanzeb->" > > > > > > > >>hi all, > >> > >>I was asked by the MIP6 WG chairs to refine the problem > >>statement draft for HA reliability and use it as a basis > >>for the work in the MIP6 WG. > >> > >>I read through your draft and have a few comments. > >> > >>I would like the problem statement to be expanded to > >>include the case when the home link fails. if the home > >>link (or a router upstream) fails, then having multiple > >>Home Agents on the same link is not going to help HA > >>reliability. it would be nice if the HAs can be in > >>phyically separate locations. the problem statement draft > >>does not have to make this the default case, but should > >>allow for Home Agents to be placed in the physically > >>different locations. > >> > > > > > > Jahanzeb-> > > > > Yes you are right in making this point of link failure, but allowing the HA > > to spread around different links > > > > 1. will cause MN to perform multiple home registrations on different HAs > > which will increase burden on air bandwidth and MN itself. > > 2. Also MN has to establish IPsec Security Associations with all its HAs > > which is again a big overhead. > > 3. Moreover this will not solve the problem of "Delayed Failure Detection" > > as we have discussed in our draft. > > > > So I think if we want to take link failure into consideration then we should > > come up with some thing else , other than allowing HAs to exists on > > different links. > > the idea is to document the problem completely. not look at > the solution or how the problem can be solved. Home Link > failure is something that needs to be documented in the problem > statement. it is upto the WG later to figure out if that is > something that we need to solve. > Jahanzeb-> I agree with you. We can include link failure problem also. > > > > > >>section 3 now covers Failure Detection and configuring > >>security associations with the new HA. I think it should > >>be expanded to include HA switching. HA switching has > >>two parts to it. the first, how does the MN switch to > >>another HA? relying on failed BUs and MPSs will take too > > > > > > Jahanzeb-> > > > > In our draft we have included the discussion about how MN will > > switch to another HA on the basis of current specifications > > of Mobile-IPv6. Please refer to the following para in sec 3.2 of our draft > > > > " Once the failure is detected, MN will try to register its Care of > > Address with any other Home Agent on the subnet. For this MN must > > know which other Home Agents are available on the subnet. MN MAY > > start Dynamic Home Agent Discovery(DHAD)[1] protocol and as the > > result will get list of available Home Agents on the subnet. MN could > > then select HA_x (in our scenario) on the list as its potential > > serving Home Agent. MN will send BU message to HA_x setting Home > > Registration(H) bit. " > > sure this will work. but as I said earlier, document > the problem and then look at the solutions. > Jahanzeb-> agreed. > > > > > >>long. the second part, how does one HA take over from a > >>failed HA? was there some shared state between the HAs > >>which made it possible for one HA to take over from the > >>failed HA? > >> > > > > > > Jahanzeb-> > > > > We have included this point in the "Solution Guidelines" section > > instead of putting it in the "Problem Statement" section. Actually > > according to current specifications of Mobile-Ipv6 failure of any HA on the > > subnet does not drive any other HA to do any kind of recovery work , except > > updating their HA Status Lists and deleting the entry for the failed HA. All > > the recovery load is on MN itself i.e MN after failure of its working HA has > > to register with a new HA on the subnet. > > we dont yet know if this is the way to go. infact this again > conflicts with your "solution guideline" of keeping this > transparent to the MN. Jahanzeb-> This is the way current Mobile-IPv6 responds to HA failure. This is not our proposed solution and sure it conflicts with the requirement of keeping failure transparent to MN. That's why we discussed this thing in the problem statement. I think there is no harm in clearly stating this point also in the problem statement. > > > So there is no such thing or even > > need of having this kind of recovery work (a new HA take overs the failed > > HA) on the basis of current Mobile-IPv6 specificatios. That's why we didn't > > consider it as a problem rather took it as a "Solution Requirement" > > > > > > > > > >>there is also the issue of load balancing. if a HA wants > >>to reduce its load, it should be able to force a > >>particular MN to start using another HA. > >> > > > > > > Jahanzeb-> > > Yes you are right. We should inlcude it in the problem statement. > > great. > > > > > > > > >>I dont agree with 4.3 (Seamless failure) and 4.4 (Mobile > >>Node functionality). infact section 4.2 conflicts with > >>both 4.3 and 4.4. I prefer the MN to know about the HA > >>switch rather than put in hacks (generally dirty) to make > >>the HA switch transparent to the MN. actuallty, I would > >>like to see section 4 deleted from the draft. it is > >>sufficient to define the problem. I see Solution Guidelines > >>as a fancy term for requirements. :) requirements always > >>lead to never-ending discussions. > > > > > > Jahanzeb-> > > > > Actually I don't see requirement 4.2 conflicting with 4.3 and 4.4. > > MN could remain ignorant about the HA failure and recovery process and at > > the same time could have IPsec SAs with the new HA. I take 4.2 as a seperate requirement > > than 4.3 and 4.4. > > then, why did it setup SAs with the new HA, if the HA switch > can be kept transparent to the MN? > > Vijay > Jahanzeb-> The requirement 4.2,4.3 does not mean that MN has to establish its SAs with the new HA by himself. That's what the whole idea is.MN should remain ignorant about what's going on on the subnet but at the same time the SAs between the MN and new HA should get established by some method. Thanks Jahanzeb _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 10 14:47:34 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 OAA05093 for ; Tue, 10 Feb 2004 14:47:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqdqd-0004FP-8N for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 14:47:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AJl7AJ016323 for mip6-archive@odin.ietf.org; Tue, 10 Feb 2004 14:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqdqd-0004FB-3c for mip6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 14:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05047 for ; Tue, 10 Feb 2004 14:47:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqdqa-0007Qg-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 14:47:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqdpb-0007IO-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 14:46:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqdoc-0007Bb-00 for mip6-web-archive@ietf.org; Tue, 10 Feb 2004 14:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqdod-00044a-4V; Tue, 10 Feb 2004 14:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqdnh-00041l-O6 for mip6@optimus.ietf.org; Tue, 10 Feb 2004 14:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04910 for ; Tue, 10 Feb 2004 14:44:02 -0500 (EST) From: Franck.Le@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqdnf-000769-00 for mip6@ietf.org; Tue, 10 Feb 2004 14:44:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqdmn-00071F-00 for mip6@ietf.org; Tue, 10 Feb 2004 14:43:09 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aqdm1-0006vo-00 for mip6@ietf.org; Tue, 10 Feb 2004 14:42:21 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AJgKv27562 for ; Tue, 10 Feb 2004 21:42:20 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 21:42:20 +0200 Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 11:42:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Feb 2004 13:42:14 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8110271C337@daebe007.americas.nokia.com> Thread-Topic: I-D ACTION:draft-le-mip6-firewalls-00.txt Thread-Index: AcPwDfzq3a3tzvyVR5CZxuMDPaWgEQ== To: X-OriginalArrivalTime: 10 Feb 2004 19:42:14.0915 (UTC) FILETIME=[FBF90D30:01C3F00D] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] I-D ACTION:draft-le-mip6-firewalls-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Mobile IPv6 and Firewalls Author(s) : F. Le Filename : draft-le-mip6-firewalls-00.txt Pages : 8 Date : 2004-2-9 =09 Firewalls are an integral part of most IP networks deployed today. Firewall technology available today is predominantly for IPv4 networks. Firewalls for IPv6 networks are slowly becoming available. In most cases, current firewall technologies do not support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will hamper large-scale deployment of the protocol. This document presents in detail some of the issues that firewalls present for Mobile IPv6 deployment. The goal of this Internet draft is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions in the MIP6 WG. A URL for this Internet-Draft is: To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-le-mip6-firewalls-00.txt". A list of Internet-Drafts directories can be found in =20 or Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-le-mip6-firewalls-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 11 11:38: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 LAA08589 for ; Wed, 11 Feb 2004 11:38:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxN0-00060J-O7 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 11:37:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGbolO023071 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 11:37:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxMz-0005zu-Rm for mip6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:37:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08576 for ; Wed, 11 Feb 2004 11:37:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxMy-000095-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 11:37:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxM4-00002Z-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 11:36:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqxLJ-0007kF-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 11:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxLG-0005gL-PV; Wed, 11 Feb 2004 11:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxL2-0005fI-Kw for mip6@optimus.ietf.org; Wed, 11 Feb 2004 11:35:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08508 for ; Wed, 11 Feb 2004 11:35:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxL1-0007ib-00 for mip6@ietf.org; Wed, 11 Feb 2004 11:35:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxKA-0007cm-00 for mip6@ietf.org; Wed, 11 Feb 2004 11:34:54 -0500 Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx with esmtp (Exim 4.12) id 1AqxJk-0007WR-00 for mip6@ietf.org; Wed, 11 Feb 2004 11:34:28 -0500 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 9607DB78B; Wed, 11 Feb 2004 10:33:57 -0600 (CST) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id EF4432A53; Wed, 11 Feb 2004 10:33:56 -0600 (CST) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id LAA0001567438; Wed, 11 Feb 2004 11:33:50 -0500 (EST) Message-ID: <402A5968.50806@hp.com> Date: Wed, 11 Feb 2004 11:33:44 -0500 From: Brian Haley Organization: Linux Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt Cc: mip6@ietf.org, Francis.Dupont@enst-bretagne.fr Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 References: <001b01c3ee73$aa4f9da0$5347038d@tm.unikarlsruhe.de> <4027C703.2080209@hp.com> <021d01c3efe8$15f14390$5347038d@tm.unikarlsruhe.de> In-Reply-To: <021d01c3efe8$15f14390$5347038d@tm.unikarlsruhe.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Christian, > Right now, I see two styles of flooding attacks which are related to our discussion: simple redirection of data and the combination of data redirection and amplification. > > (1) Simple redirection attacks: An attacker sends a packet to a CN. The packet's IP Source Address is spoofed: It contains the IP address of an attacked node, say, the victim. The packet is such that the CN responds to the victim with a packet of (approximately) the same size. This kind of flooding attack could be the well-known TCP-SYN-flooding attack. It could also be an ICMP-Echo-Request (Ping) flooding attack. Either way, this kind of attack is possible with normal IPv6, i.e., even without Mobile IPv6! > Now, Early Binding Updates come into play. Having shaken hands with the CN, the attacker redirects the data flow towards the victim with the help of an Early Binding Update message. This data stream will hold for at most TENTATIVE_BINDING_LIFETIME seconds. (TENTATIVE_BINDING_LIFETIME defaults to 3 seconds; one may - and probably should - reduce this time.) Yes, I understand that there are attacks that can be made with "regular" IPv6 and Mobile IPv6, but you are creating another possibile scenario, which I wanted to make clear. The WG would have to decide if it's worth the risk. > Again, with Early Binding Updates, the attacker's yield is a data stream towards the victim of TENTATIVE_BINDING_LIFETIME seconds' length. Isn't this yield too little to make the flooding attack a "success" (from the attacker's point of view)? But I can continue to extend this lifetime by just sending more EBUs. > I think what is most important is the relation between the attacker's yield and the attacker's "investments" in terms of state and handshaking overhead. > > Brian, you mention that the attacker could exploit thousands of CNs for its attack. Yet, the more CNs are being exploited, the more state the attacker will have to maintain. If I use ICMP Echo Request I don't need to store any state. I will have to read Francis' drafts when they come out to see how they relate to yours. Regards, -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 11 13:05:14 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 NAA11812 for ; Wed, 11 Feb 2004 13:05:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyj9-0005Oq-UT for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 13:04:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BI4lix020752 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 13:04:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyj9-0005Od-OL for mip6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 13:04:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11771 for ; Wed, 11 Feb 2004 13:04:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqyj7-0001BA-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 13:04:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqyiB-00015t-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 13:03:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqyhU-00010w-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 13:03:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqyhS-0004rk-SI; Wed, 11 Feb 2004 13:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqyhD-0004oC-Ve for mip6@optimus.ietf.org; Wed, 11 Feb 2004 13:02:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11729 for ; Wed, 11 Feb 2004 13:02:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqyhC-00010K-00 for mip6@ietf.org; Wed, 11 Feb 2004 13:02:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqygI-0000vV-00 for mip6@ietf.org; Wed, 11 Feb 2004 13:01:50 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Aqyfc-0000lA-00 for mip6@ietf.org; Wed, 11 Feb 2004 13:01:08 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1BI0Pf15031; Wed, 11 Feb 2004 19:00:25 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1BI0PSj075386; Wed, 11 Feb 2004 19:00:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402111800.i1BI0PSj075386@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haley cc: Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 In-reply-to: Your message of Wed, 11 Feb 2004 11:33:44 EST. <402A5968.50806@hp.com> Date: Wed, 11 Feb 2004 19:00:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: Yes, I understand that there are attacks that can be made with "regular" IPv6 and Mobile IPv6, but you are creating another possibile scenario, which I wanted to make clear. => this is a new scenario but without any advantages for attackers. I will have to read Francis' drafts when they come out to see how they relate to yours. => draft-dupont-mipv6-3bombing-00.txt was announced and should be in all repositories. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 11 14:05:32 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 OAA14455 for ; Wed, 11 Feb 2004 14:05:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzfU-0002Vb-69 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:05:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJ5442009637 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzfT-0002VM-Ue for mip6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:05:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14425 for ; Wed, 11 Feb 2004 14:05:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzfR-0007J8-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 14:05:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzeW-0007Bu-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 14:04:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzdl-00074m-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 14:03:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzdX-0001rJ-8O; Wed, 11 Feb 2004 14:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzdM-0001lG-2x for mip6@optimus.ietf.org; Wed, 11 Feb 2004 14:02:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14217 for ; Wed, 11 Feb 2004 14:02:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzdJ-00072T-00 for mip6@ietf.org; Wed, 11 Feb 2004 14:02:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzcN-0006vA-00 for mip6@ietf.org; Wed, 11 Feb 2004 14:01:52 -0500 Received: from zcamail04.zca.compaq.com ([161.114.32.104]) by ietf-mx with esmtp (Exim 4.12) id 1AqzbP-0006i5-00 for mip6@ietf.org; Wed, 11 Feb 2004 14:00:52 -0500 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 314F33F45; Wed, 11 Feb 2004 11:00:21 -0800 (PST) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id E9AC2951; Wed, 11 Feb 2004 13:00:17 -0600 (CST) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id OAA0002070946; Wed, 11 Feb 2004 14:00:17 -0500 (EST) Message-ID: <402A7BBB.4030504@hp.com> Date: Wed, 11 Feb 2004 14:00:11 -0500 From: Brian Haley Organization: Linux Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 References: <200402111800.i1BI0PSj075386@givry.rennes.enst-bretagne.fr> In-Reply-To: <200402111800.i1BI0PSj075386@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Francis Dupont wrote: > Yes, I understand that there are attacks that can be made with "regular" > IPv6 and Mobile IPv6, but you are creating another possibile scenario, > which I wanted to make clear. > > => this is a new scenario but without any advantages for attackers. Can you please explain why you think there are no advantages? -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 11 14:16: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 OAA15349 for ; Wed, 11 Feb 2004 14:16:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzpz-0003ec-Gw for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:15:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJFtID014040 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:15:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzpz-0003eN-BO for mip6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:15:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15298 for ; Wed, 11 Feb 2004 14:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzpw-00016c-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 14:15:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzoz-0000yq-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 14:14:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzo7-0000qn-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 14:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzo9-0003Vf-NV; Wed, 11 Feb 2004 14:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqznP-0003T1-UC for mip6@optimus.ietf.org; Wed, 11 Feb 2004 14:13:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15091 for ; Wed, 11 Feb 2004 14:13:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqznN-0000hi-00 for mip6@ietf.org; Wed, 11 Feb 2004 14:13:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzmT-0000Yz-00 for mip6@ietf.org; Wed, 11 Feb 2004 14:12:17 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzlf-0000MN-00 for mip6@ietf.org; Wed, 11 Feb 2004 14:11:27 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1BJAqf21214; Wed, 11 Feb 2004 20:10:52 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1BJAqSj075715; Wed, 11 Feb 2004 20:10:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402111910.i1BJAqSj075715@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haley cc: Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 In-reply-to: Your message of Wed, 11 Feb 2004 14:00:11 EST. <402A7BBB.4030504@hp.com> Date: Wed, 11 Feb 2004 20:10:52 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: > IPv6 and Mobile IPv6, but you are creating another possibile scenario, > which I wanted to make clear. > > => this is a new scenario but without any advantages for attackers. Can you please explain why you think there are no advantages? => what a bad guy can do or from the opposite point of view what are the possible defenses are the same with IPv6 and Mobile IPv6+Early BUs (or other optimized Mobile IPv6 schemes). The only useful things we can do are to fix optimized schemes which still accept alternate care-of addresses and, more important, to bash the router vendors who sell routers without ingress filtering support or where ingress filtering kills performance (I can give names in private). Unfortunately the second is true for IPv4 too... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 11 14:34:24 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 OAA16442 for ; Wed, 11 Feb 2004 14:34:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar07R-0005aQ-36 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:33:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJXvfZ021473 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 14:33:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar07Q-0005aG-U7 for mip6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:33:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16428 for ; Wed, 11 Feb 2004 14:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar07O-00034f-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 14:33:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar06U-0002yO-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 14:32:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar05X-0002s9-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 14:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar05Y-0005Nf-TG; Wed, 11 Feb 2004 14:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar05U-0005NA-M3 for mip6@optimus.ietf.org; Wed, 11 Feb 2004 14:31:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16345 for ; Wed, 11 Feb 2004 14:31:53 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar05S-0002rN-00 for mip6@ietf.org; Wed, 11 Feb 2004 14:31:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar04W-0002le-00 for mip6@ietf.org; Wed, 11 Feb 2004 14:30:56 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ar03s-0002g5-00 for mip6@ietf.org; Wed, 11 Feb 2004 14:30:16 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BJUFq25823 for ; Wed, 11 Feb 2004 21:30:15 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 11 Feb 2004 21:30:15 +0200 Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 11 Feb 2004 11:30:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Feb 2004 13:30:13 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DBDF3@daebe007.americas.nokia.com> Thread-Topic: Solicitation for agenda items Thread-Index: AcPw1XaYm1Sk2AiPRqavo3QkRtvFnw== To: X-OriginalArrivalTime: 11 Feb 2004 19:30:13.0151 (UTC) FILETIME=[782E5AF0:01C3F0D5] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Solicitation for agenda items Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, MIP6 WG is scheduled to meet at IETF59 on Monday, March 1st from 1300 to 1500 hrs. If you need a slot on the agenda to present/discuss a MIP6 related I-D, please send your request to the chairs by Feb 15th. In your request, please specify: 1. The I-D associated with this request 2. Why this is relevant for MIP6 3. Is this I-D within the scope of the WG charter 4. Amount of time requested -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 11 15:54:28 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 PAA22915 for ; Wed, 11 Feb 2004 15:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Mt-0004aJ-OD for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 15:53:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKrxcq017617 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 15:53:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Mt-0004a4-Jw for mip6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:53:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22847 for ; Wed, 11 Feb 2004 15:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Mr-0003xe-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 15:53:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Lz-0003q6-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 15:53:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1L3-0003j6-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 15:52:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Kz-00048m-PQ; Wed, 11 Feb 2004 15:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1KS-00047n-E7 for mip6@optimus.ietf.org; Wed, 11 Feb 2004 15:51:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22570; Wed, 11 Feb 2004 15:51:26 -0500 (EST) Message-Id: <200402112051.PAA22570@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 11 Feb 2004 15:51:26 -0500 Subject: [Mip6] I-D ACTION:draft-ietf-mip6-mipext-advapi-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,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 IPv6 Working Group of the IETF. Title : Extension to Sockets API for Mobile IPv6 Author(s) : S. Chakrabarti Filename : draft-ietf-mip6-mipext-advapi-00.txt Pages : 18 Date : 2004-2-11 This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API support for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-mipext-advapi-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-ietf-mip6-mipext-advapi-00.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-2-11160526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-mipext-advapi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-mipext-advapi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11160526.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 12 05:30:33 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 FAA17949 for ; Thu, 12 Feb 2004 05:30:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArE6f-0000P9-F2 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 05:30:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CAU5ub001554 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 05:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArE6f-0000Oz-74 for mip6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 05:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17932 for ; Thu, 12 Feb 2004 05:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArE6b-0002UP-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 05:30:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArE5c-0002Op-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 05:29:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArE4d-0002Ho-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 05:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArE4e-00009m-VV; Thu, 12 Feb 2004 05:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArE3w-00007f-B1 for mip6@optimus.ietf.org; Thu, 12 Feb 2004 05:27:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17877 for ; Thu, 12 Feb 2004 05:27:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArE3s-0002F9-00 for mip6@ietf.org; Thu, 12 Feb 2004 05:27:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArE31-00029h-00 for mip6@ietf.org; Thu, 12 Feb 2004 05:26:20 -0500 Received: from sparte.int-evry.fr ([157.159.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1ArE2S-00022Z-00 for mip6@ietf.org; Thu, 12 Feb 2004 05:25:44 -0500 Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 02A23318BA; Thu, 12 Feb 2004 11:24:54 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.1.0.29) with SMTP id M2004021211251521064 ; Thu, 12 Feb 2004 11:25:15 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id EA238318BA; Thu, 12 Feb 2004 11:24:53 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1ArDzc-0004Ih-TT; Thu, 12 Feb 2004 11:22:48 +0100 Date: Thu, 12 Feb 2004 11:22:48 +0100 From: Julien Bournelle To: mip6@ietf.org Cc: eap@frascone.com Message-ID: <20040212102248.GB16492@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Mip6] Concerning mip6 auth. and conf. based on EAP Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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, I had a quick reading of your draft and I have a few comments/questions. -1- Maybe it would be better to present the PEAPv2 case in appendix and to have a general approach in the rest of the draft. -2- You define a new application for Diameter. I think you need to define a stand-alone internet-draft for this. You can't define two protocols in one draft, can you ? May I suggest you split your draft into two parts ? -3- In your abstract, you wrote: " The same approach can be ported also to environments performing user authentication with methods other than EAP (e.g. GSM, UMTS or CDMA), by simply using PANA with null authentication to undertake MIPv6 negotiation after the user has gained IP access to the network. " I don't clearly understand what you mean: what would be the pros for the use of PANA in such a context ? -- julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 12 05:52: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 FAA18702 for ; Thu, 12 Feb 2004 05:52:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArES0-0004qv-JF for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 05:52:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CAq8bs018647 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 05:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArES0-0004qg-Es for mip6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 05:52:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18699 for ; Thu, 12 Feb 2004 05:52:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArERw-0004YH-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 05:52:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArER1-0004Tg-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 05:51:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArEQs-0004Ow-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 05:50:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArEQv-00020k-7B; Thu, 12 Feb 2004 05:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArEQ4-0001yC-AD for mip6@optimus.ietf.org; Thu, 12 Feb 2004 05:50:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18650 for ; Thu, 12 Feb 2004 05:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArEQ0-0004ON-00 for mip6@ietf.org; Thu, 12 Feb 2004 05:50:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArEP5-0004Jo-00 for mip6@ietf.org; Thu, 12 Feb 2004 05:49:08 -0500 Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx with esmtp (Exim 4.12) id 1ArEOD-00049Z-00 for mip6@ietf.org; Thu, 12 Feb 2004 05:48:13 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.204]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0HSY00H23WGIRO@dns2.cselt.it> for mip6@ietf.org; Thu, 12 Feb 2004 11:43:30 +0100 (MET) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Feb 2004 11:46:55 +0100 Received: from EXC2K01A.cselt.it ([163.162.4.34]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Feb 2004 11:46:55 +0100 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K01A.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Feb 2004 11:47:42 +0100 Date: Thu, 12 Feb 2004 11:47:42 +0100 From: Giaretta Gerardo To: Julien Bournelle , mip6@ietf.org Cc: eap@frascone.com Message-id: <625BE97BF4795E43970345790166B9BCD4DCA7@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [eap] Concerning mip6 auth. and conf. based on EAP Thread-Index: AcPxUresAn3BIEwHTdyyqUqzBqeungAAMa0Q content-class: urn:content-classes:message X-OriginalArrivalTime: 12 Feb 2004 10:47:42.0610 (UTC) FILETIME=[A4372F20:01C3F155] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] RE: [eap] Concerning mip6 auth. and conf. based on EAP Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Julien, Thanks for your comments and feedback. See inline... >=20 > Hi, >=20 > I had a quick reading of your draft and I have a few=20 > comments/questions. >=20 > -1- Maybe it would be better to present the PEAPv2 case in=20 > appendix and > to have a general approach in the rest of the draft. >=20 In this first version, we decided to describe a complete example of the = procedure, describing it using PEAPv2. Surely presenting the PEAPv2 case = in an appendix and describing the general case in the rest of the draft = may be a good idea.=20 > -2- You define a new application for Diameter. I think you need to > define a stand-alone internet-draft for this. You can't define two > protocols in one draft, can you ? May I suggest you split your draft > into two parts ? > We thought about it, but, as I said before, we have decided to describe = the complete procedure in this first version of the draft. However, I = agree with you that maybe the draft should be split in two separate = docs, one for EAP communication and the other for the new Diameter = Application. =20 > -3- In your abstract, you wrote: > " > The same approach can be ported also to environments performing user=20 > authentication with methods other than EAP (e.g. GSM, UMTS or CDMA),=20 > by simply using PANA with null authentication to undertake MIPv6=20 > negotiation after the user has gained IP access to the network.=20 > " >=20 > I don't clearly understand what you mean: what would be the=20 > pros for the > use of PANA in such a context ?=20 >=20 Maybe other procedures could be more efficient. The main advantage of = our procedure lies in the possibility of re-using those messages and = TLVs defined in the WLAN case even when the MN accesses a cellular = network: this could be a great advantage in a heterogeneous scenario. = Therefore, in this way the MN can use the same approach and the same = procedures to perform MIPv6 configuration regardless of the access = network (e.g. WLAN or GPRS). --Gerardo > --=20 > julien.bournelle@int-evry.fr > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 12 07:19:39 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 HAA20430 for ; Thu, 12 Feb 2004 07:19:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFoF-0002tP-KB for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 07:19:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CCJBQR011113 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 07:19:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFoF-0002tA-G4 for mip6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 07:19:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20425 for ; Thu, 12 Feb 2004 07:19:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArFoB-0004Da-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 07:19:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArFnF-000494-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 07:18:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArFn5-00044G-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 07:17:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFn7-0002nb-F9; Thu, 12 Feb 2004 07:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFmK-0002lr-8O for mip6@optimus.ietf.org; Thu, 12 Feb 2004 07:17:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20395 for ; Thu, 12 Feb 2004 07:17:09 -0500 (EST) From: xiaobao.chen@orange.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArFmF-00043U-00 for mip6@ietf.org; Thu, 12 Feb 2004 07:17:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArFlJ-0003z5-00 for mip6@ietf.org; Thu, 12 Feb 2004 07:16:09 -0500 Received: from mail32.messagelabs.com ([62.173.108.211]) by ietf-mx with smtp (Exim 4.12) id 1ArFl8-0003uJ-00 for mip6@ietf.org; Thu, 12 Feb 2004 07:15:58 -0500 X-VirusChecked: Checked X-Env-Sender: xiaobao.chen@orange.co.uk X-Msg-Ref: server-18.tower-32.messagelabs.com!1076588119!7529962 X-StarScan-Version: 5.1.15; banners=-,-,- Received: (qmail 6822 invoked from network); 12 Feb 2004 12:15:19 -0000 Received: from smtpout10.orange.co.uk (HELO hagrid.orange.co.uk) (193.35.135.133) by server-18.tower-32.messagelabs.com with SMTP; 12 Feb 2004 12:15:19 -0000 Received: from bit.orange.co.uk (bit.orange.co.uk) by hagrid.orange.co.uk (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Thu, 12 Feb 2004 12:15:19 +0000 Received: from ruddick (notes-gw.orange.co.uk [172.16.133.18]) by bit.orange.co.uk with SMTP id i1CCFIu04867 for ; Thu, 12 Feb 2004 12:15:18 GMT X-Lotus-FromDomain: HTLUK To: mip6@ietf.org Message-ID: <80256E38.0041EAFB.00@ruddick> Date: Thu, 12 Feb 2004 12:03:00 +0000 Mime-Version: 1.0 Content-type: text/plain; charset="us-ascii" Content-Disposition: inline Subject: [Mip6] MIP6 and 3G Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,NO_REAL_NAME autolearn=no version=2.60 As one of Europe's largest mobile operators, we see great potential of IPv6 and its mobility based on MIPv6 in 3G but we are concerned about the interworking in some deployment scenarios of MIPv6. The following draft provides detailed descriptions of possible deployment scenarios and the analysis of possible interworking problems between MIPv6 and GPRS/UMTS. http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28558.html Your comments and suggestions are welcome. Xiaobao Chen Orange SA ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ******************************************************************************* _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 12 08:28: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 IAA23024 for ; Thu, 12 Feb 2004 08:28:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGt6-0002JB-5V for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 08:28:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CDSGJF008867 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 08:28:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGt5-0002Iw-Sc for mip6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 08:28:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23011 for ; Thu, 12 Feb 2004 08:28:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArGt1-0003bP-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 08:28:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArGs2-0003VJ-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 08:27:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArGrr-0003Qi-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 08:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGrs-0002GR-TS; Thu, 12 Feb 2004 08:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArGr6-0002Fp-9x for mip6@optimus.ietf.org; Thu, 12 Feb 2004 08:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22981 for ; Thu, 12 Feb 2004 08:26:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArGr1-0003Pq-00 for mip6@ietf.org; Thu, 12 Feb 2004 08:26:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArGq3-0003LP-00 for mip6@ietf.org; Thu, 12 Feb 2004 08:25:08 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx with esmtp (Exim 4.12) id 1ArGp9-0003Gl-00 for mip6@ietf.org; Thu, 12 Feb 2004 08:24:12 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=i72mail01.tm.uka.de) by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1ArGp0-0007d5-00; Thu, 12 Feb 2004 14:24:02 +0100 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83] helo=i72ChVogt) by i72mail01.tm.uka.de with esmtp (Exim 4.30) id 1ArGoy-0002Xp-Ih; Thu, 12 Feb 2004 14:24:00 +0100 Message-ID: <007a01c3f163$18972200$5347038d@tm.unikarlsruhe.de> From: "Christian Vogt" To: "Brian Haley" Cc: , Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 Date: Thu, 12 Feb 2004 13:24:01 +0100 Organization: Institute of Telematics, University of Karlsruhe (TH) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=2.6 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCm15IGNvbW1lbnRzIGFyZSBiZXR3ZWVuIHRoZSBzbmlwcGV0cy4gWW91IHdp bGwgZmluZCB0aGUgY29tcGxldGUgZW1haWwgdGhhdCBJIGFtIHJlZmVyZW5jaW5nIGJlbG93Lg0K DQo+ID4gQWdhaW4sIHdpdGggRWFybHkgQmluZGluZyBVcGRhdGVzLCB0aGUgYXR0YWNrZXIncyB5 aWVsZCBpcyBhIGRhdGEgc3RyZWFtDQo+ID4gdG93YXJkcyB0aGUgdmljdGltIG9mIFRFTlRBVElW RV9CSU5ESU5HX0xJRkVUSU1FIHNlY29uZHMnIGxlbmd0aC4gSXNuJ3QgDQo+ID4gdGhpcyB5aWVs ZCB0b28gbGl0dGxlIHRvIG1ha2UgdGhlIGZsb29kaW5nIGF0dGFjayBhICJzdWNjZXNzIiAoZnJv bSB0aGUgDQo+ID4gYXR0YWNrZXIncyBwb2ludCBvZiB2aWV3KT8gDQoNCj4gQnV0IEkgY2FuIGNv bnRpbnVlIHRvIGV4dGVuZCB0aGlzIGxpZmV0aW1lIGJ5IGp1c3Qgc2VuZGluZyBtb3JlIEVCVXMu DQoNClRoaXMgaXMgdHJ1ZTogSGVyZSBpcyB3aGVyZSBwb2xpY2llcyBtdXN0IGNvbWUgaW50byBm b3JjZS4gSW4gYSBudXRzaGVsbCwgdGhlIENOIHNob3VsZCBub3QgYWxsb3cgbW9yZSB0aGFuIG9u ZSBwZW5kaW5nIEVCVSBwZXIgaG9tZSBhZGRyZXNzLiBUaGUgSS1EIG1lbnRpb25zIHRoaXMgYnJp ZWZseS4gTGV0IG1lIHRyeSB0byBnZXQgaW50byBtb3JlIGRlcHRoIGhlcmUuDQoNClJlY2FsbCB0 aGF0LCB3aGVuIGEgQ04gcmVjZWl2ZXMgYW4gRUJVIG1lc3NhZ2UsIHRoZSBDTiBrbm93cyB0aGF0 IHRoZSBFQlUgbWVzc2FnZSdzIGhvbWUgYWRkcmVzcyBpcyBjb3JyZWN0LiBUaGlzIGlzIGJlY2F1 c2UgYSBob21lLWFkZHJlc3MgdGVzdCBoYWQgdG8gYmUgZG9uZSBpbiBvcmRlciB0byBhdXRoZW50 aWNhdGUgdGhlIEVCVSBtZXNzYWdlLiBUaHVzLCB0aGUgQ04gY2FuIGlkZW50aWZ5IHRoZSBzZW5k ZXIgb2YgdGhlIEVCVSBtZXNzYWdlLg0KDQpIZXJlIGlzIGEgc2ltcGxlIHBvbGljeSB0aGF0IGEg Q04gbWlnaHQgdXNlIHRvIGN1cmIgdGhlIHRocmVhdCBvZiBmbG9vZGluZyBhdHRhY2tzOiBXaGVu IHRoZSBDTiByZWNlaXZlcyBhbiBFQlUgbWVzc2FnZSB3aXRoIGhvbWUgYWRkcmVzcyBIb0EgYW5k IGNhcmUtb2YgYWRkcmVzcyBDb0EsIHRoZSBDTiBjcmVhdGVzIGEgdGVudGF0aXZlIGJpbmRpbmct Y2FjaGUgZW50cnkgbWFwcGluZyBIb0EgdG8gQ29BLiBUaGUgQ04gZXhwZWN0cyB0byByZWNlaXZl IGEgc3RhbmRhcmQgQlUgbWVzc2FnZSBjb25maXJtaW5nIHRoaXMgbWFwcGluZyBiZWZvcmUgdGhl IHRlbnRhdGl2ZSBiaW5kaW5nLWNhY2hlIGVudHJ5IGV4cGlyZXMuIChUaGUgSS1EIHByb3Bvc2Vz IHRoYXQgZXhwaXJhdGlvbiBoYXBwZW5zIGFmdGVyIFRFTlRBVElWRV9CSU5ESU5HX0xJRkVUSU1F IHNlY29uZHMgPSAzIHNlY29uZHMuKQ0KDQpJZiB0aGUgQ04gZG9lcyBOT1QgcmVjZWl2ZSB0aGUg c3RhbmRhcmQgQlUgYmVmb3JlIHRoZSB0ZW50YXRpdmUgYmluZGluZy1jYWNoZSBlbnRyeSBleHBp cmVzLCB0aGUgQ04gcHV0cyBIb0Egb24gYSBibGFjayBsaXN0LiBUaGUgQ04gd2lsbCBub3QgYWNj ZXB0IEVCVXMgd2l0aCBob21lIGFkZHJlc3MgSG9BIHVudGlsIGl0IHJlY2VpdmVzIGEgcHJvcGVy bHkgYXV0aGVudGljYXRlZCwgc3RhbmRhcmQgQlUgbWVzc2FnZSB3aXRoIGhvbWUgYWRkcmVzcyBI b0EuIChPYnZpb3VzbHksIGJsYWNrLWxpc3QgZW50cmllcyBoYXZlIHRvIGV4cGlyZSBhZnRlciBh IHdoaWxlLiBZZXQsIGRpc2N1c3Npbmcgd2hhdCBhbiBhcHByb3ByaWF0ZSBleHBpcmF0aW9uIHRp bWVvdXQgY291bGQgYmUgd291bGQgZ28gdG8gZmFyIG5vdy4pDQoNCkZ1cnRoZXJtb3JlLCB3aGVu IHRoZSBDTiByZWNvZ25pemVzIHRoYXQgaXQgaXMgcnVubmluZyBvdXQgb2YgbWVtb3J5LCB0aGUg Q04gZG9lcyBubyBsb25nZXIgYWNjZXB0IEVCVXMgd2l0aCBhbnkgaG9tZSBhZGRyZXNzLiBNb25p dG9yaW5nIHJlc291cmNlcywgaG93ZXZlciwgaXMgbm90IGFuIEVCVS1zcGVjaWZpYyBiZWhhdmlv ci4gQW4gb3B0aW1pemVkIENOIHdvdWxkIHByb2JhYmx5IGRvIHRoaXMgYW55d2F5LiBUaGUgQ04g cmV0dXJucyB0byBub3JtYWwgbW9kZSB3aGVuIHN1ZmZpY2llbnQgcmVzb3VyY2VzIGhhdmUgYmVl biBmcmVlZCB1cC4NCg0KVGhlIG91dGxpbmVkIHBvbGljeSBpcyBhIGNvdW50ZXJtZWFzdXJlIGFn YWluc3QgZmxvb2RpbmcgYXR0YWNrcy4gT25lIG1heSBhcmd1ZSB0aGF0IEVCVXMgY2FuIGJlIHVz ZWQgdG8gcHVycG9zZWx5IG9jY3VweSB0aGUgcmVzb3VyY2VzIG9mIGEgQ04gYXMgd2VsbCwgZWZm ZWN0aXZlbHkgd2FnaW5nIGEgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIGFnYWluc3QgdGhlIENO LiBUbyBzb21lIGV4dGVudCwgdGhpcyBpcyB0cnVlLiBUaGUgcG9pbnQgaXMgdGhhdCBhbiBFQlUg bXVzdCBiZSAqYXV0aGVudGljYXRlZCogaW4gb3JkZXIgdG8gb2NjdXB5IHJlc291cmNlcyBhdCB0 aGUgQ04uIChBZ2FpbiwgYSBob21lLWFkZHJlc3MgdGVzdCBoYWQgdG8gYmUgZG9uZSBpbiBvcmRl ciB0byBhdXRoZW50aWNhdGUgdGhlIEVCVSBtZXNzYWdlLikgVGhpcyBraW5kIG9mIGRlbmlhbC1v Zi1zZXJ2aWNlIGF0dGFjayBpcyBwb3NzaWJsZSBpbiBzdGFuZGFyZCBNb2JpbGUgSVB2NiBhcyB3 ZWxsLg0KDQo+ID4gQnJpYW4sIHlvdSBtZW50aW9uIHRoYXQgdGhlIGF0dGFja2VyIGNvdWxkIGV4 cGxvaXQgdGhvdXNhbmRzIG9mIENOcw0KPiA+IGZvciBpdHMgYXR0YWNrLiBZZXQsIHRoZSBtb3Jl IENOcyBhcmUgYmVpbmcgZXhwbG9pdGVkLCB0aGUgbW9yZSBzdGF0ZQ0KPiA+IHRoZSBhdHRhY2tl ciB3aWxsIGhhdmUgdG8gbWFpbnRhaW4uIA0KDQo+IElmIEkgdXNlIElDTVAgRWNobyBSZXF1ZXN0 IEkgZG9uJ3QgbmVlZCB0byBzdG9yZSBhbnkgc3RhdGUuDQoNCklDTVAtRWNoby1SZXF1ZXN0IGZs b29kaW5nIGlzIG5vdCBhIE1vYmlsZS1JUHY2LXNwZWNpZmljIGF0dGFjay4gQW4gYXR0YWNrZXIg Y2FuIGRvIHRoaXMgaW4gc3RhdGljIElQdjYuDQoNCkJlc3QgcmVnYXJkcywNCg0KDQotIENocmlz dGlhbg0KDQoNCnwNCnwgQ2hyaXN0aWFuIFZvZ3QNCnwgSW5zdGl0dXRlIG9mIFRlbGVtYXRpY3Ms IFVuaXZlcnNpdHkgb2YgS2FybHNydWhlIChUSCkNCnwgd3d3LnRtLnVuaS1rYXJsc3J1aGUuZGUv fmNodm9ndC8NCnwNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkJy aWFuIEhhbGV5IiA8QnJpYW4uSGFsZXlAaHAuY29tPg0KVG86ICJDaHJpc3RpYW4gVm9ndCIgPGNo dm9ndEB0bS51a2EuZGU+DQpDYzogPG1pcDZAaWV0Zi5vcmc+OyA8RnJhbmNpcy5EdXBvbnRAZW5z dC1icmV0YWduZS5mcj4NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTEsIDIwMDQgNTozMyBQ TQ0KU3ViamVjdDogUmU6IFtNaXA2XSBOZXcgSS1EOiBFYXJseSBCaW5kaW5nIFVwZGF0ZXMgZm9y IE1vYmlsZSBJUHY2DQoNCg0KPiBIaSBDaHJpc3RpYW4sDQo+IA0KPiA+IFJpZ2h0IG5vdywgSSBz ZWUgdHdvIHN0eWxlcyBvZiBmbG9vZGluZyBhdHRhY2tzIHdoaWNoIGFyZSByZWxhdGVkDQo+ID4g dG8gb3VyIGRpc2N1c3Npb246IHNpbXBsZSByZWRpcmVjdGlvbiBvZiBkYXRhIGFuZCB0aGUgY29t YmluYXRpb24NCj4gPiBvZiBkYXRhIHJlZGlyZWN0aW9uIGFuZCBhbXBsaWZpY2F0aW9uLg0KPiA+ IA0KPiA+ICgxKSBTaW1wbGUgcmVkaXJlY3Rpb24gYXR0YWNrczogQW4gYXR0YWNrZXIgc2VuZHMg YSBwYWNrZXQgdG8gYSBDTi4NCj4gPiBUaGUgcGFja2V0J3MgSVAgU291cmNlIEFkZHJlc3MgaXMg c3Bvb2ZlZDogSXQgY29udGFpbnMgdGhlIElQIGFkZHJlc3MNCj4gPiBvZiBhbiBhdHRhY2tlZCBu b2RlLCBzYXksIHRoZSB2aWN0aW0uIFRoZSBwYWNrZXQgaXMgc3VjaCB0aGF0IHRoZSBDTg0KPiA+ IHJlc3BvbmRzIHRvIHRoZSB2aWN0aW0gd2l0aCBhIHBhY2tldCBvZiAoYXBwcm94aW1hdGVseSkg dGhlIHNhbWUgc2l6ZS4NCj4gPiBUaGlzIGtpbmQgb2YgZmxvb2RpbmcgYXR0YWNrIGNvdWxkIGJl IHRoZSB3ZWxsLWtub3duIFRDUC1TWU4tZmxvb2RpbmcgDQo+ID4gYXR0YWNrLiBJdCBjb3VsZCBh bHNvIGJlIGFuIElDTVAtRWNoby1SZXF1ZXN0IChQaW5nKSBmbG9vZGluZyBhdHRhY2suIA0KPiA+ IEVpdGhlciB3YXksIHRoaXMga2luZCBvZiBhdHRhY2sgaXMgcG9zc2libGUgd2l0aCBub3JtYWwg SVB2NiwgaS5lLiwgDQo+ID4gZXZlbiB3aXRob3V0IE1vYmlsZSBJUHY2IQ0KPiANCj4gPiBOb3cs IEVhcmx5IEJpbmRpbmcgVXBkYXRlcyBjb21lIGludG8gcGxheS4gSGF2aW5nIHNoYWtlbiBoYW5k cyB3aXRoIHRoZQ0KPiA+IENOLCB0aGUgYXR0YWNrZXIgcmVkaXJlY3RzIHRoZSBkYXRhIGZsb3cg dG93YXJkcyB0aGUgdmljdGltIHdpdGggdGhlIGhlbHANCj4gPiBvZiBhbiBFYXJseSBCaW5kaW5n IFVwZGF0ZSBtZXNzYWdlLiBUaGlzIGRhdGEgc3RyZWFtIHdpbGwgaG9sZCBmb3IgYXQNCj4gPiBt b3N0IFRFTlRBVElWRV9CSU5ESU5HX0xJRkVUSU1FIHNlY29uZHMuIChURU5UQVRJVkVfQklORElO R19MSUZFVElNRSANCj4gPiBkZWZhdWx0cyB0byAzIHNlY29uZHM7IG9uZSBtYXkgLSBhbmQgcHJv YmFibHkgc2hvdWxkIC0gcmVkdWNlIHRoaXMgdGltZS4pDQo+IA0KPiBZZXMsIEkgdW5kZXJzdGFu ZCB0aGF0IHRoZXJlIGFyZSBhdHRhY2tzIHRoYXQgY2FuIGJlIG1hZGUgd2l0aCAicmVndWxhciIg DQo+IElQdjYgYW5kIE1vYmlsZSBJUHY2LCBidXQgeW91IGFyZSBjcmVhdGluZyBhbm90aGVyIHBv c3NpYmlsZSBzY2VuYXJpbywgDQo+IHdoaWNoIEkgd2FudGVkIHRvIG1ha2UgY2xlYXIuICBUaGUg V0cgd291bGQgaGF2ZSB0byBkZWNpZGUgaWYgaXQncyB3b3J0aCANCj4gdGhlIHJpc2suDQo+IA0K PiA+IEFnYWluLCB3aXRoIEVhcmx5IEJpbmRpbmcgVXBkYXRlcywgdGhlIGF0dGFja2VyJ3MgeWll bGQgaXMgYSBkYXRhIHN0cmVhbQ0KPiA+IHRvd2FyZHMgdGhlIHZpY3RpbSBvZiBURU5UQVRJVkVf QklORElOR19MSUZFVElNRSBzZWNvbmRzJyBsZW5ndGguIElzbid0IA0KPiA+IHRoaXMgeWllbGQg dG9vIGxpdHRsZSB0byBtYWtlIHRoZSBmbG9vZGluZyBhdHRhY2sgYSAic3VjY2VzcyIgKGZyb20g dGhlIA0KPiA+IGF0dGFja2VyJ3MgcG9pbnQgb2Ygdmlldyk/IA0KPiANCj4gQnV0IEkgY2FuIGNv bnRpbnVlIHRvIGV4dGVuZCB0aGlzIGxpZmV0aW1lIGJ5IGp1c3Qgc2VuZGluZyBtb3JlIEVCVXMu DQo+IA0KPiA+IEkgdGhpbmsgd2hhdCBpcyBtb3N0IGltcG9ydGFudCBpcyB0aGUgcmVsYXRpb24g YmV0d2VlbiB0aGUgYXR0YWNrZXIncyB5aWVsZA0KPiA+IGFuZCB0aGUgYXR0YWNrZXIncyAiaW52 ZXN0bWVudHMiIGluIHRlcm1zIG9mIHN0YXRlIGFuZCBoYW5kc2hha2luZyBvdmVyaGVhZC4NCj4g PiANCj4gPiBCcmlhbiwgeW91IG1lbnRpb24gdGhhdCB0aGUgYXR0YWNrZXIgY291bGQgZXhwbG9p dCB0aG91c2FuZHMgb2YgQ05zIGZvciBpdHMNCj4gPiBhdHRhY2suIFlldCwgdGhlIG1vcmUgQ05z IGFyZSBiZWluZyBleHBsb2l0ZWQsIHRoZSBtb3JlIHN0YXRlIHRoZSBhdHRhY2tlcg0KPiA+IHdp bGwgaGF2ZSB0byBtYWludGFpbi4gDQo+IA0KPiBJZiBJIHVzZSBJQ01QIEVjaG8gUmVxdWVzdCBJ IGRvbid0IG5lZWQgdG8gc3RvcmUgYW55IHN0YXRlLg0KPiANCj4gSSB3aWxsIGhhdmUgdG8gcmVh ZCBGcmFuY2lzJyBkcmFmdHMgd2hlbiB0aGV5IGNvbWUgb3V0IHRvIHNlZSBob3cgdGhleSANCj4g cmVsYXRlIHRvIHlvdXJzLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IC1Ccmlhbg0KDQo= _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 12 10:06:47 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 KAA26325 for ; Thu, 12 Feb 2004 10:06:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArIQ2-0004wq-2X for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 10:06:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CF6MPH019014 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 10:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArIQ1-0004wb-Hc for mip6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 10:06:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26239 for ; Thu, 12 Feb 2004 10:06:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArIPv-0004tW-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 10:06:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArIP6-0004oo-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 10:05:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArIOh-0004jK-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 10:04:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArIOl-0004PA-E1; Thu, 12 Feb 2004 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArIO6-0004E5-Fe for mip6@optimus.ietf.org; Thu, 12 Feb 2004 10:04:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26040 for ; Thu, 12 Feb 2004 10:04:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArIO0-0004iC-00 for mip6@ietf.org; Thu, 12 Feb 2004 10:04:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArIN7-0004cy-00 for mip6@ietf.org; Thu, 12 Feb 2004 10:03:22 -0500 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 1ArIMC-0004RQ-00 for mip6@ietf.org; Thu, 12 Feb 2004 10:02:24 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Feb 2004 07:10:22 +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 i1CF1suA028494; Thu, 12 Feb 2004 07:01:54 -0800 (PST) Received: from cisco.com (sjc-vpn1-504.cisco.com [10.21.97.248]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQF62012; Thu, 12 Feb 2004 07:01:53 -0800 (PST) Message-ID: <402B9561.6030706@cisco.com> Date: Thu, 12 Feb 2004 07:01:53 -0800 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: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] New I-D: Hash based authentication option for MIPv6 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 - A new I-D is available for your reference. It defines MIPv6 options to permit hash based authentication between MN and HA. Abstract This document defines new mobility options to enable authentication between mobility entities. These options can be used in addition to or in lieu of IPsec to authenticate mobility messages as defined in [1]. The draft is available at: ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mipv6-authentication-option-00.txt Your comments are welcome. Alpesh _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 12 10:35:10 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 KAA28458 for ; Thu, 12 Feb 2004 10:35:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArIrU-00028i-04 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 10:34:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CFYhJJ008224 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 10:34:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArIrT-00028Z-C0 for mip6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 10:34:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28412 for ; Thu, 12 Feb 2004 10:34:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArIrN-0000AJ-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 10:34:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArIqC-0007kr-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 10:33:24 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArIpN-0007eW-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 10:32:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ArIfA-0006gA-WD for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 10:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArIfC-00014s-6u; Thu, 12 Feb 2004 10:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArIeV-000148-Dx for mip6@optimus.ietf.org; Thu, 12 Feb 2004 10:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28068 for ; Thu, 12 Feb 2004 10:21:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArIeP-0006uM-00 for mip6@ietf.org; Thu, 12 Feb 2004 10:21:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArIdX-0006ps-00 for mip6@ietf.org; Thu, 12 Feb 2004 10:20:20 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1ArIdD-0006is-00 for mip6@ietf.org; Thu, 12 Feb 2004 10:19:59 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CFJLu10929; Thu, 12 Feb 2004 09:19:22 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV68M6>; Thu, 12 Feb 2004 09:19:21 -0600 Message-ID: From: "Mohamed Khalil" To: "'Alpesh'" , mip6@ietf.org Subject: RE: [Mip6] New I-D: Hash based authentication option for MIPv6 Date: Thu, 12 Feb 2004 09:19:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F17B.20096968" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=HTML_30_40,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_01C3F17B.20096968 Content-Type: text/plain Hi Alpesh, look at draft-mkhalil-mipv6-nai-00.txt draft-mkhalil-mipv6-alloc-00.txt Actually, Kuntal is a co-author for the next version of those two drafts. -Mohamed -----Original Message----- From: Alpesh [mailto:alpesh@cisco.com] Sent: Thursday, February 12, 2004 9:02 AM To: mip6@ietf.org Subject: [Mip6] New I-D: Hash based authentication option for MIPv6 Hi - A new I-D is available for your reference. It defines MIPv6 options to permit hash based authentication between MN and HA. Abstract This document defines new mobility options to enable authentication between mobility entities. These options can be used in addition to or in lieu of IPsec to authenticate mobility messages as defined in [1]. The draft is available at: ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mipv6-authentication-optio n-00.txt Your comments are welcome. Alpesh _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 ------_=_NextPart_001_01C3F17B.20096968 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip6] New I-D: Hash based authentication option for = MIPv6

Hi Alpesh,

look at

draft-mkhalil-mipv6-nai-00.txt
draft-mkhalil-mipv6-alloc-00.txt

Actually, Kuntal is a co-author for the next version = of those two drafts.

-Mohamed

-----Original Message-----
From: Alpesh [mailto:alpesh@cisco.com]
Sent: Thursday, February 12, 2004 9:02 AM
To: mip6@ietf.org
Subject: [Mip6] New I-D: Hash based authentication = option for MIPv6


Hi -

A new I-D is available for your reference. It defines = MIPv6 options to
permit hash based authentication between
MN and HA.

        = Abstract
       
       
        = This  document  defines  new  mobility  = options  to  enable
        = authentication between mobility entities. These options can be
        used in = addition to or in lieu of IPsec to authenticate
        mobility = messages as defined in [1].
         =

The draft is available at:

ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mipv= 6-authentication-option-00.txt

Your comments are welcome.
Alpesh


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www.ietf.org/mailman/listinfo/mip6

------_=_NextPart_001_01C3F17B.20096968-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 12 16:27:03 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 QAA16953 for ; Thu, 12 Feb 2004 16:27:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOLz-0008O5-7p for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 16:26:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CLQZYI032241 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 16:26:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOLz-0008Nw-2X for mip6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 16:26:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16939 for ; Thu, 12 Feb 2004 16:26:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOLv-0006RY-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 16:26:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOL1-0006M3-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 16:25:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArOKY-0006Gb-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 16:25:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOKU-0007sF-Ay; Thu, 12 Feb 2004 16:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOJv-0007n7-EG for mip6@optimus.ietf.org; Thu, 12 Feb 2004 16:24:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16848 for ; Thu, 12 Feb 2004 16:24:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOJr-0006F6-00 for mip6@ietf.org; Thu, 12 Feb 2004 16:24:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOIy-0006AP-00 for mip6@ietf.org; Thu, 12 Feb 2004 16:23:29 -0500 Received: from zcamail04.zca.compaq.com ([161.114.32.104]) by ietf-mx with esmtp (Exim 4.12) id 1ArOIB-00060J-00 for mip6@ietf.org; Thu, 12 Feb 2004 16:22:39 -0500 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 05DF73CA0; Thu, 12 Feb 2004 13:22:11 -0800 (PST) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id C79FE2E33; Thu, 12 Feb 2004 13:21:49 -0800 (PST) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id QAA0000910736; Thu, 12 Feb 2004 16:22:09 -0500 (EST) Message-ID: <402BEE7C.8000205@hp.com> Date: Thu, 12 Feb 2004 16:22:04 -0500 From: Brian Haley Organization: Linux Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, Samita Chakrabarti References: <200402112051.PAA22570@ietf.org> In-Reply-To: <200402112051.PAA22570@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Re: I-D ACTION:draft-ietf-mip6-mipext-advapi-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Samita, I have a few comments on the draft. I noticed the syntax of the data structures and #defines changed from the last version of the draft, for example: struct ip6mh_binding_update became struct ip6_mh_binding_update and IP6MH_BU_ACK became IP6_MH_BU_ACK I could let it go :) but it is now mixing syntax from IPv6 and ICMPv6. I think if you're going to keep this change, which is like that in icmp6.h, you should go all the way and fix all the data elements: ip6mhbu_seqno turns into ip6_mh_bu_seqno I like that better anyways since I always mis-typed those since you were squishing all those chars together without a break. Another thing that would be good to do would be to #define all the ip6_mh pieces in the sub-structs, for example: struct ip6_mh_binding_error { struct ip6_mh ip6_mh_be_hdr; uint8_t ip6_mh_be_status; uint8_t ip6_mh_be_reserved; struct in6_addr ip6mhbe_homeaddr; /* home address */ /* followed by mobility options */ }; #define ip6_mh_be_proto ip6_mh_be_hdr.ip6_mh_proto #define ip6_mh_be_len ip6_mh_be_hdr.ip6_mh_len #define ip6_mh_be_type ip6_mh_be_hdr.ip6_mh_type #define ip6_mh_be_cksum ip6_mh_be_hdr.ip6_mh_cksum That way users can use the shorthand, just like all the ICMPv6 structures. You define the ip6_mh_opt structure, but no longer embed it in the opt sub-types, for example: struct ip6_mh_opt_refresh_advice { uint8_t ip6mora_type; uint8_t ip6mora_len; uint16_t ip6mora_interval; /* Refresh interval in 4 sec */ }; This could (was?, should?) be: struct ip6_mh_opt_refresh_advice { struct ip6_mh_opt ip6_mh_opt_ra_hdr; uint16_t ip6_mh_opt_ra_interval; /* Refresh interval in 4 sec */ }; #define ip6_mh_opt_ra_type ip6_mh_opt_ra_hdr.ip6_mh_opt_type #define ip6_mh_opt_ra_len ip6_mh_opt_ra_hdr.ip6_mh_opt_len The /etc/protocols entry should probably have an all-caps version for MH: ipv6-mh 135 IPV6-MH # Mobility Protocol Header I don't know the precedence for this, but it's done that way in all the different systems I looked at. I only noticed all these things since I updated my structs to the previous draft, that will teach me... Let me know if I'm too crazy about this, -Brian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobility for IPv6 Working Group of the IETF. > > Title : Extension to Sockets API for Mobile IPv6 > Author(s) : S. Chakrabarti > Filename : draft-ietf-mip6-mipext-advapi-00.txt > Pages : 18 > Date : 2004-2-11 > > This document describes data structures and API support for Mobile > IPv6 as an extension to Advanced Socket API support for IPv6. > > > Mobility Support in IPv6 introduces mobility protocol header > for IPv6. It is expected that future Mobile IPv6 applications > and implementations may need to access Mobility binding messages > and Return Routability messages for diagnostic, packet accounting > and local policy setting purposes. In order to provide portability > for Mobile IP applications that use sockets under IPv6, > standardization is needed for the Mobile IPv6 specific APIs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mip6-mipext-advapi-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-ietf-mip6-mipext-advapi-00.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. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 12 20:22:02 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 UAA29968 for ; Thu, 12 Feb 2004 20:22:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArS1N-0000f3-1V for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 20:21:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D1LX4m002540 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 20:21:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArS1M-0000et-Q1 for mip6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 20:21:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29958 for ; Thu, 12 Feb 2004 20:21:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArS1I-0007JK-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 20:21:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArS0N-0007FR-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 20:20:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArRzs-0007Be-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 20:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArRzu-0000ZW-D0; Thu, 12 Feb 2004 20:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArRzU-0000Yp-9X for mip6@optimus.ietf.org; Thu, 12 Feb 2004 20:19:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29926 for ; Thu, 12 Feb 2004 20:19:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArRzQ-0007B4-00 for mip6@ietf.org; Thu, 12 Feb 2004 20:19:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArRyS-00076e-00 for mip6@ietf.org; Thu, 12 Feb 2004 20:18:33 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1ArRxq-00072Q-00 for mip6@ietf.org; Thu, 12 Feb 2004 20:17:54 -0500 Received: from jurassic.eng.sun.com ([129.146.17.57]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i1D1Hui5008559; Thu, 12 Feb 2004 18:17:56 -0700 (MST) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i1D1HsOV486853; Thu, 12 Feb 2004 17:17:55 -0800 (PST) Message-Id: <200402130117.i1D1HsOV486853@jurassic.eng.sun.com> Date: Thu, 12 Feb 2004 17:19:50 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [Mip6] Re: I-D ACTION:draft-ietf-mip6-mipext-advapi-00.txt To: Brian.Haley@hp.com Cc: mip6@ietf.org, Samita.Chakrabarti@eng.sun.com, erik.nordmark@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TKcwhOAyq6FKvadRogcPfA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_31 SunOS 5.10 sun4u sparc Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > > I have a few comments on the draft. > Thanks. > > I noticed the syntax of the data structures and #defines changed from > the last version of the draft, for example: > > struct ip6mh_binding_update > became > struct ip6_mh_binding_update > > and > IP6MH_BU_ACK > became > IP6_MH_BU_ACK They were changed on version 02 that was submitted and presented at last IETF. The change was made because of input I received. > > I could let it go :) but it is now mixing syntax from IPv6 and ICMPv6. > I think if you're going to keep this change, which is like that in > icmp6.h, you should go all the way and fix all the data elements: > > ip6mhbu_seqno > turns into > ip6_mh_bu_seqno > > I like that better anyways since I always mis-typed those since you were > squishing all those chars together without a break. > When we discussed the prefix, it was agreed to follow RFC3542 style - also note that it was mentioned that there was no firm rule to follow everywhere. There are inconsistencies in prefix in RFC3542 as well. We followed what most people felt comfortable with. For example, the prefix of ip6_mh_binding_ack { } structure is ip6mhba_. Why ip6mh ? Because it is part of ip6mh.h as opposed to ip6.h. This is similar to the example in RFC3542: struct ip6_opt_jumbo { uint8_t ip6oj_type; uint8_t ip6oj_len; uint8_t ip6oj_jumbo_len[4]; }; Other option is to have a prefix ip6_mhba_, but that looks a bit odd, hence they are all suqeezed together. > > Another thing that would be good to do would be to #define all the > ip6_mh pieces in the sub-structs, for example: > > struct ip6_mh_binding_error { > struct ip6_mh ip6_mh_be_hdr; > uint8_t ip6_mh_be_status; > uint8_t ip6_mh_be_reserved; > struct in6_addr ip6mhbe_homeaddr; /* home address */ > /* followed by mobility options */ > }; > > #define ip6_mh_be_proto ip6_mh_be_hdr.ip6_mh_proto > #define ip6_mh_be_len ip6_mh_be_hdr.ip6_mh_len > #define ip6_mh_be_type ip6_mh_be_hdr.ip6_mh_type > #define ip6_mh_be_cksum ip6_mh_be_hdr.ip6_mh_cksum > > That way users can use the shorthand, just like all the ICMPv6 structures. > > I think it can be done. I'd like to know whether others think it's useful or required to add. Note, this can be implemenation specific. > You define the ip6_mh_opt structure, but no longer embed it in the opt > sub-types, for example: > > struct ip6_mh_opt_refresh_advice { > uint8_t ip6mora_type; > uint8_t ip6mora_len; > uint16_t ip6mora_interval; /* Refresh interval in 4 sec */ > }; > > This could (was?, should?) be: > > struct ip6_mh_opt_refresh_advice { > struct ip6_mh_opt ip6_mh_opt_ra_hdr; > uint16_t ip6_mh_opt_ra_interval; /* Refresh interval in 4 sec */ > }; > > #define ip6_mh_opt_ra_type ip6_mh_opt_ra_hdr.ip6_mh_opt_type > #define ip6_mh_opt_ra_len ip6_mh_opt_ra_hdr.ip6_mh_opt_len > > No. The option hdr is not embedded. Please check RFC3542 - it's the same style of option hdr. > The /etc/protocols entry should probably have an all-caps version for MH: > > ipv6-mh 135 IPV6-MH # Mobility Protocol Header > The third argument is there in most of the implementations, but since this document is an extension to RFC3542, I followed the semantics in RFC3542, where it does not list the third field. -Samita > I don't know the precedence for this, but it's done that way in all the > different systems I looked at. > > > I only noticed all these things since I updated my structs to the > previous draft, that will teach me... > > Let me know if I'm too crazy about this, > > -Brian > > > Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Mobility for IPv6 Working Group of the IETF. > > > > Title : Extension to Sockets API for Mobile IPv6 > > Author(s) : S. Chakrabarti > > Filename : draft-ietf-mip6-mipext-advapi-00.txt > > Pages : 18 > > Date : 2004-2-11 > > > > This document describes data structures and API support for Mobile > > IPv6 as an extension to Advanced Socket API support for IPv6. > > > > > > Mobility Support in IPv6 introduces mobility protocol header > > for IPv6. It is expected that future Mobile IPv6 applications > > and implementations may need to access Mobility binding messages > > and Return Routability messages for diagnostic, packet accounting > > and local policy setting purposes. In order to provide portability > > for Mobile IP applications that use sockets under IPv6, > > standardization is needed for the Mobile IPv6 specific APIs. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-mip6-mipext-advapi-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-ietf-mip6-mipext-advapi-00.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. > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 12 20:58:26 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 UAA01927 for ; Thu, 12 Feb 2004 20:58:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSac-0003EZ-6I for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 20:57:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D1vwPO012425 for mip6-archive@odin.ietf.org; Thu, 12 Feb 2004 20:57:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSab-0003EK-TZ for mip6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 20:57:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01881 for ; Thu, 12 Feb 2004 20:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArSaX-0003df-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 20:57:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArSZb-0003Uy-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 20:56:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArSYp-0003NR-00 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 20:56:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ArSNB-0006qA-C1 for mip6-web-archive@ietf.org; Thu, 12 Feb 2004 20:44:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSN7-0002Sl-4t; Thu, 12 Feb 2004 20:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSMf-0002SN-H4 for mip6@optimus.ietf.org; Thu, 12 Feb 2004 20:43:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01402 for ; Thu, 12 Feb 2004 20:43:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArSMb-0002Kt-00 for mip6@ietf.org; Thu, 12 Feb 2004 20:43:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArSLf-0002Gm-00 for mip6@ietf.org; Thu, 12 Feb 2004 20:42:32 -0500 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 1ArSKn-00028C-00 for mip6@ietf.org; Thu, 12 Feb 2004 20:41:37 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Feb 2004 17:49:41 +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 i1D1f8uA002499; Thu, 12 Feb 2004 17:41:08 -0800 (PST) Received: from cisco.com ([128.107.176.45]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQG32493; Thu, 12 Feb 2004 17:41:06 -0800 (PST) Message-ID: <402C2B31.3070600@cisco.com> Date: Thu, 12 Feb 2004 17:41:05 -0800 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: Mohamed Khalil CC: alpesh@cisco.com, kleung@cisco.com, chowdury@nortelnetworks.com, mip6@ietf.org Subject: Re: [Mip6] New I-D: Hash based authentication option for MIPv6 References: Content-Type: multipart/alternative; boundary="------------060606020601070607050202" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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.7 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 --------------060606020601070607050202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mohamed - Thanks for pointing out your drafts. We will go through it and evaluate the similarities. -a Mohamed Khalil wrote: > Hi Alpesh, > > look at > > draft-mkhalil-mipv6-nai-00.txt > draft-mkhalil-mipv6-alloc-00.txt > > Actually, Kuntal is a co-author for the next version of those two drafts. > > -Mohamed > > -----Original Message----- > From: Alpesh [mailto:alpesh@cisco.com] > Sent: Thursday, February 12, 2004 9:02 AM > To: mip6@ietf.org > Subject: [Mip6] New I-D: Hash based authentication option for MIPv6 > > > Hi - > > A new I-D is available for your reference. It defines MIPv6 options to > permit hash based authentication between > MN and HA. > > Abstract > > > This document defines new mobility options to enable > authentication between mobility entities. These options can be > used in addition to or in lieu of IPsec to authenticate > mobility messages as defined in [1]. > > > The draft is available at: > > ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mipv6-authentication-option-00.txt > > > Your comments are welcome. > Alpesh > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > --------------060606020601070607050202 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mohamed -

Thanks for pointing out your drafts. We will go through it and evaluate the similarities.

-a

Mohamed Khalil wrote:
RE: [Mip6] New I-D: Hash based authentication option for MIPv6

Hi Alpesh,

look at

draft-mkhalil-mipv6-nai-00.txt
draft-mkhalil-mipv6-alloc-00.txt

Actually, Kuntal is a co-author for the next version of those two drafts.

-Mohamed

-----Original Message-----
From: Alpesh [mailto:alpesh@cisco.com]
Sent: Thursday, February 12, 2004 9:02 AM
To: mip6@ietf.org
Subject: [Mip6] New I-D: Hash based authentication option for MIPv6


Hi -

A new I-D is available for your reference. It defines MIPv6 options to
permit hash based authentication between
MN and HA.

        Abstract
       
       
        This  document  defines  new  mobility  options  to  enable
        authentication between mobility entities. These options can be
        used in addition to or in lieu of IPsec to authenticate
        mobility messages as defined in [1].
        

The draft is available at:

ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mipv6-authentication-option-00.txt

Your comments are welcome.
Alpesh


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www.ietf.org/mailman/listinfo/mip6


--------------060606020601070607050202-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Feb 13 06:44:21 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 GAA05659 for ; Fri, 13 Feb 2004 06:44:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbji-0003yj-8a for mip6-archive@odin.ietf.org; Fri, 13 Feb 2004 06:43:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DBhwDF015287 for mip6-archive@odin.ietf.org; Fri, 13 Feb 2004 06:43:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbji-0003yU-4w for mip6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 06:43:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05620 for ; Fri, 13 Feb 2004 06:43:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArbjY-0000Ez-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 06:43:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arbia-00009D-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 06:42:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arbhh-00004Y-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 06:41:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbhp-0003sF-JR; Fri, 13 Feb 2004 06:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arbgy-0003qH-Ni for mip6@optimus.ietf.org; Fri, 13 Feb 2004 06:41:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05531 for ; Fri, 13 Feb 2004 06:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arbgo-0007nb-00 for mip6@ietf.org; Fri, 13 Feb 2004 06:40:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arbfq-0007ig-00 for mip6@ietf.org; Fri, 13 Feb 2004 06:39:59 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1ArbfK-0007dy-00 for mip6@ietf.org; Fri, 13 Feb 2004 06:39:26 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1DBdHj1029124 for ; Fri, 13 Feb 2004 20:39:17 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1DBdHCn025414 for ; Fri, 13 Feb 2004 20:39:17 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1DBdGnq026055 for ; Fri, 13 Feb 2004 20:39:16 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1DBdGjt026052 for ; Fri, 13 Feb 2004 20:39:16 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1DBdFwq008552 for ; Fri, 13 Feb 2004 20:39:15 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id UAA25379 for ; Fri, 13 Feb 2004 20:39:15 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id UAA07420 for ; Fri, 13 Feb 2004 20:39:14 +0900 (JST) Message-ID: <402CB836.6020802@lab.ntt.co.jp> Date: Fri, 13 Feb 2004 20:42:46 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: mip6@ietf.org Subject: Re:[Mip6] Concerning mip6 auth. and conf. based on EAP Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Gerardo, I$B!G(Bm interested in your draft. I have some comments and questions. - It is specified that AAAH send cryptographic material to MN. I think it is not necessary, when Pre-shared Key based authentication is applied to establish ISAKMP SA. Because AAA and MN can share symmetric key, EAP Key, during access authentication. And AAA and MN also can derive symmetric key from the shared key. It is specified in "draft-salowey-eap-key-deriv-02.txt". We proposed an architecture which use EAP key as service authentication. And we are going to submit revised draft which includes a method that applied the above concept to establish SA between HA and MN. - You used $B!H(BAAA$B!I(B and $B!H(BAAAH$B!I(B as authentication server. Is it a spelling mistake or not? - In actual public service network, I think it is difficult that AAAH selects proper HA in visited network. So, I think -AAAH authenticates MN, and -AAA in visited network selects proper HA and distributes cryptographic material Would you mind giving comments to this idea? Sincerely yours Mayumi, >Hi, > >we submitted a new I-D, draft-giaretta-mip6-authorization-eap-00.txt. >It defines a method for performing dynamic Mobile IPv6 authorization >and configuration relaying on a AAA infrastructure: the necessary >interaction between the AAA server of the home provider and the mobile >node is realized using EAP, exploiting the capability of some EAP >methods (e.g. PEAPv2) to convey generic information items together with >authentication data. > >The Internet-Draft is available from the on-line Internet-Drafts >directories. The URL is: >http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-00.txt > >Any comments are welcome. > >Best Regards, > >--Gerardo Giaretta -- *++++++++++++++++++++++++++++++++++++++++++ NTT Network Service Systems Laboratories Mayumi Yanagiya tel: +81 422 59 6783 fax: +81 422 37 7688 E-mail: yanagiya.mayumi@lab.ntt.co.jp +++++++++++++++++++++++++++++++++++++++++++* _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Feb 13 13:27:34 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 NAA24027 for ; Fri, 13 Feb 2004 13:27:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ari1q-0004AM-1w for mip6-archive@odin.ietf.org; Fri, 13 Feb 2004 13:27:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIR6WB016008 for mip6-archive@odin.ietf.org; Fri, 13 Feb 2004 13:27:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ari1p-0004A7-Sx for mip6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 13:27:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23992 for ; Fri, 13 Feb 2004 13:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ari1n-0003dl-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 13:27:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ari0p-0003ZG-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 13:26:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arhzr-0003VZ-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 13:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhzq-0003pb-4S; Fri, 13 Feb 2004 13:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhz6-0003dO-QB for mip6@optimus.ietf.org; Fri, 13 Feb 2004 13:24:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23903 for ; Fri, 13 Feb 2004 13:24:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arhz4-0003SO-00 for mip6@ietf.org; Fri, 13 Feb 2004 13:24:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arhy3-0003OS-00 for mip6@ietf.org; Fri, 13 Feb 2004 13:23:12 -0500 Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx with esmtp (Exim 4.12) id 1ArhxT-0003JP-00 for mip6@ietf.org; Fri, 13 Feb 2004 13:22:35 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.203]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HT10095FCB7JR@dns1.cselt.it> for mip6@ietf.org; Fri, 13 Feb 2004 19:21:07 +0100 (MET) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Feb 2004 19:22:41 +0100 Received: from EXC2K01A.cselt.it ([163.162.4.34]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Feb 2004 19:22:41 +0100 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K01A.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Feb 2004 19:22:01 +0100 Date: Fri, 13 Feb 2004 19:22:00 +0100 From: Giaretta Gerardo Subject: RE: [Mip6] Concerning mip6 auth. and conf. based on EAP To: Mayumi Yanagiya Cc: mip6@ietf.org Message-id: <625BE97BF4795E43970345790166B9BCE8CBB5@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Concerning mip6 auth. and conf. based on EAP Thread-Index: AcPyJm2mA1eFHl05R6KIBOodaCL4HAALDUDA content-class: urn:content-classes:message X-OriginalArrivalTime: 13 Feb 2004 18:22:01.0729 (UTC) FILETIME=[46546710:01C3F25E] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Mayumi, thanks for your feedback. See below for my answers... =20 >=20 > - It is specified that AAAH send cryptographic material to MN. > I think it is not necessary, when Pre-shared Key based=20 > authentication > is applied to establish ISAKMP SA. > Because AAA and MN can share symmetric key, EAP Key, during access > authentication. And AAA and MN also can derive symmetric key from > the shared key. > It is specified in "draft-salowey-eap-key-deriv-02.txt". > We proposed an architecture which use EAP key as service > authentication. > And we are going to submit revised draft which includes a method > that applied the above concept to establish SA between HA and MN. > As we have written in the Open Issues section of our draft, we think = that deriving the pre-shared key exploiting the EAP Key Management = Framework is a good approach and it might improve the security of the = architecture. We are still working on this solution. I've read = draft-yanagiya-eap-saa-00.txt: I think that the solution described is = really generic and for this reason I'm waiting for next version, more = MIPv6-related. Moreover, a better approach would be using the AAA infrastructure to = establish the ISAKMP or the IPsec SA: this approach would reduce the = number of IKE RTTs needed or totally avoid the IKE negotiation... =20 > - You used =1B$B!H=1B(BAAA=1B$B!I=1B(B and = =1B$B!H=1B(BAAAH=1B$B!I=1B(B as authentication server. > Is it a spelling mistake or not? By AAAH we mean the AAA server of the Home Provider, while by AAA we = mean a generic AAA server. >=20 > - In actual public service network, I think it is difficult that > AAAH selects proper HA in visited network. So, I think > -AAAH authenticates MN, and > -AAA in visited network selects proper HA and distributes > cryptographic material > Would you mind giving comments to this idea? >=20 In Appendix A we have described the procedure to allocate a Home Agent = in the foreign domain. As depicted in figure 13, AAAH (AAA server of the = home provider) communicates with AAAF (AAA server of the foreign = provider) to allocate the Home Agent: however, note that the HA and the = cryptogrphic material are selected by the AAAF and not by the AAAH. = Then, AAAF sends these data to AAAH through a Foreign-Home-Agent-Answer = message and the AAAH sends the data to the MN via EAP-TLVs. Obviously, = we are assuming that AAAH and AAAF share a security association. Regards, --Gerardo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Feb 13 14:28:37 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 OAA27546 for ; Fri, 13 Feb 2004 14:28:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ariyw-0001aQ-7B for mip6-archive@odin.ietf.org; Fri, 13 Feb 2004 14:28:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DJSAqv006092 for mip6-archive@odin.ietf.org; Fri, 13 Feb 2004 14:28:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ariyw-0001aB-1L for mip6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 14:28:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27543 for ; Fri, 13 Feb 2004 14:28:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ariyt-0001N4-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 14:28:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arixy-0001Jt-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 14:27:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arixp-0001Gh-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 14:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arixq-0001Sn-Hu; Fri, 13 Feb 2004 14:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arix3-0001Rq-Ph for mip6@optimus.ietf.org; Fri, 13 Feb 2004 14:26:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27516 for ; Fri, 13 Feb 2004 14:26:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arix1-0001GJ-00 for mip6@ietf.org; Fri, 13 Feb 2004 14:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AriwA-0001Cv-00 for mip6@ietf.org; Fri, 13 Feb 2004 14:25:19 -0500 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 1Arivq-000192-00 for mip6@ietf.org; Fri, 13 Feb 2004 14:24:58 -0500 Date: Fri, 13 Feb 2004 11:25:12 -0800 Subject: Re: [Mip6] Concerning mip6 auth. and conf. based on EAP From: Alper Yegin To: Giaretta Gerardo , Mayumi Yanagiya CC: Message-ID: In-Reply-To: <625BE97BF4795E43970345790166B9BCE8CBB5@EXC2K01B.cselt.it> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > As we have written in the Open Issues section of our draft, we think that > deriving the pre-shared key exploiting the EAP Key Management Framework is a > good approach and it might improve the security of the architecture. We are solving a somewhat similar problem by using EAP-based keys. Please see draft-yegin-eap-boot-rfc3118-00.txt. This is the extended version of draft-tschofenig-pana-bootstrap-rfc3118-00.txt. FYI... Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Feb 13 17:13:52 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 RAA10631 for ; Fri, 13 Feb 2004 17:13:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlYr-0002GS-6d for mip6-archive@odin.ietf.org; Fri, 13 Feb 2004 17:13:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DMDPqM008698 for mip6-archive@odin.ietf.org; Fri, 13 Feb 2004 17:13:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlYr-0002G8-0s for mip6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 17:13:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10608 for ; Fri, 13 Feb 2004 17:13:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlYo-0002zk-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 17:13:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlXt-0002vM-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 17:12:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArlXU-0002qa-00 for mip6-web-archive@ietf.org; Fri, 13 Feb 2004 17:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlXV-00029X-4x; Fri, 13 Feb 2004 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlWs-00028i-N8 for mip6@optimus.ietf.org; Fri, 13 Feb 2004 17:11:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10485 for ; Fri, 13 Feb 2004 17:11:19 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlWq-0002pX-00 for mip6@ietf.org; Fri, 13 Feb 2004 17:11:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlVu-0002lF-00 for mip6@ietf.org; Fri, 13 Feb 2004 17:10:23 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArlVV-0002gm-00 for mip6@ietf.org; Fri, 13 Feb 2004 17:09:57 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DM9rv15977 for ; Sat, 14 Feb 2004 00:09:54 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 14 Feb 2004 00:09:53 +0200 Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 16:09:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Feb 2004 16:09:38 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DBE29@daebe007.americas.nokia.com> Thread-Topic: Mobile IPv6 RFC status Thread-Index: AcPyfhDM23WxqcnaQsyLs2Bg3jSQYg== To: X-OriginalArrivalTime: 13 Feb 2004 22:09:39.0311 (UTC) FILETIME=[12E207F0:01C3F27E] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Mobile IPv6 RFC status Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, In case you are wondering what is happening with the MobileIPv6 base specifications: 1. draft-ietf-mobileip-ipv6-24.txt 2. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt I-D tracker indicates that the I-Ds are in RFC editor queue. This has been the status for a while now.=20 The draft (draft-ietf-mobileip-ipv6-24.txt) is currently with IANA. They are in the process of allocating the numbers required by this specification. It has been over 3 months now that we are waiting for IANA to complete the allocation and send the draft back to the RFC editor. Jari Arkko has been making a concerted effort to get IANA to complete their task and get the I-D back to the RFC editor. I think that draft is finally getting some traction with IANA and should be out of their hands and back with the RFC Ed. pretty soon (fingers crossed).=20 -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 15 20:41:26 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 UAA07385 for ; Sun, 15 Feb 2004 20:41:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXkn-00069f-UJ for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 20:40:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G1evvn023655 for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 20:40:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXkn-00069S-N2 for mip6-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 20:40:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07368 for ; Sun, 15 Feb 2004 20:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXkl-0007du-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 20:40:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXjo-0007aT-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 20:39:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsXiw-0007XG-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 20:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXiv-00063z-0T; Sun, 15 Feb 2004 20:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXin-00063g-LM for mip6@optimus.ietf.org; Sun, 15 Feb 2004 20:38:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07318 for ; Sun, 15 Feb 2004 20:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXil-0007W1-00 for mip6@ietf.org; Sun, 15 Feb 2004 20:38:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXhp-0007St-00 for mip6@ietf.org; Sun, 15 Feb 2004 20:37:54 -0500 Received: from fep20-0.kolumbus.fi ([193.229.0.47] helo=fep20-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1AsXhE-0007QC-00 for mip6@ietf.org; Sun, 15 Feb 2004 20:37:16 -0500 Received: from kolumbus.fi ([62.248.154.14]) by fep20-app.kolumbus.fi with ESMTP id <20040216013708.BHLD15980.fep20-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 03:37:08 +0200 Message-ID: <40301E53.2090004@kolumbus.fi> Date: Mon, 16 Feb 2004 03:35:15 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] review of draft-dupont-mipv6-3bombing-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Francis, And thanks for writing this draft. I think we need it. I pretty much agree with all that you say in the draft. I think prohibiting alternate care-of address option is a good idea, and it should be studied further. I'd like to expand a little bit on what you say in under 2.3 regarding route optimization. As you have pointed out, anyone can spoof the source address of a TCP SYN packet, so we generally can not worry too much single request - single response attacks. Except where mechanisms to defeat ingress filtering are provided, which you also mention. As Christian pointed out in his e-mail explaining the security background for early binding updates, and is also discussed in Section 2.5 of [1], we also need to consider the possible amplification factor. The problem with bombing attacks in the RO case is using first a right address, getting to see TLP sequence numbers so that fake acks can be sent, and then moving the stream to the victim's address. This can be devastating, at least under some conditions. The difference to a regular TCP SYN spoofing is that you actually get to see some inital part of the traffic, which may make things easier for the attacker. Having said this, [1] notes that different TLPs and different TCP implementations behave in different ways regarding this attack. It might be useful to shed some further light on this, to figure out exactly how serious (or not) this attack is. There is a related issue that has to do with the level of ingress filtering support in the Internet. We have more or less accepted the situation where this support is not universal. So, we can assume that we can be targets of e.g. spoofed TCP SYNs or reflected packets. I would not like to make this any worse by making it possible to be a victim of a stream of packets. Comments? --Jari [1] http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 15 20:46:21 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 UAA07521 for ; Sun, 15 Feb 2004 20:46:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXpZ-0006e9-3s for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 20:45:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G1jrgT025543 for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 20:45:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXpY-0006du-Uv for mip6-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 20:45:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07496 for ; Sun, 15 Feb 2004 20:45:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXpW-00007j-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 20:45:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXoa-000045-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 20:44:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsXnk-00001A-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 20:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXnl-0006LS-DY; Sun, 15 Feb 2004 20:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXnc-0006L1-Oj for mip6@optimus.ietf.org; Sun, 15 Feb 2004 20:43:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07462 for ; Sun, 15 Feb 2004 20:43:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXna-00000J-00 for mip6@ietf.org; Sun, 15 Feb 2004 20:43:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXml-0007lT-00 for mip6@ietf.org; Sun, 15 Feb 2004 20:43:00 -0500 Received: from fep20-0.kolumbus.fi ([193.229.0.47] helo=fep20-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1AsXlx-0007ia-00 for mip6@ietf.org; Sun, 15 Feb 2004 20:42:09 -0500 Received: from kolumbus.fi ([62.248.154.14]) by fep20-app.kolumbus.fi with ESMTP id <20040216014209.BIBK15980.fep20-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 03:42:09 +0200 Message-ID: <40301F80.2040607@kolumbus.fi> Date: Mon, 16 Feb 2004 03:40:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] rr weaknesses? Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In reading Francis' draft on bombing I came across the following statement: As the return routability is not considered by many people as very safe or efficient, some new ways to I agree about the efficiency part*. But I'm wondering if you have any specific worries about the safety part. I mean beyond issues that already exist in plain IPv4 and IPv6, such as MitMs being able to do bad things. --Jari *) Well, I guess on the overall scheme of things, 1 RTT can be considered relatively effient. But of course we'd like to get rid of even that... and there are applications that need faster operation. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 15 21:08:32 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 VAA08917 for ; Sun, 15 Feb 2004 21:08:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYB1-0008KZ-5W for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 21:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G282jZ032017 for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 21:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYAz-0008KK-48 for mip6-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 21:08:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08913 for ; Sun, 15 Feb 2004 21:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsYAw-0002BF-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 21:07:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsY9z-00027s-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 21:06:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsY94-00024Z-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 21:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsY93-0007za-VQ; Sun, 15 Feb 2004 21:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsY8v-0007z7-OF for mip6@optimus.ietf.org; Sun, 15 Feb 2004 21:05:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08747 for ; Sun, 15 Feb 2004 21:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsY8t-000236-00 for mip6@ietf.org; Sun, 15 Feb 2004 21:05:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsY82-00020X-00 for mip6@ietf.org; Sun, 15 Feb 2004 21:04:58 -0500 Received: from fep20-0.kolumbus.fi ([193.229.0.47] helo=fep20-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1AsY7C-0001xM-00 for mip6@ietf.org; Sun, 15 Feb 2004 21:04:06 -0500 Received: from kolumbus.fi ([62.248.154.14]) by fep20-app.kolumbus.fi with ESMTP id <20040216020406.BLJS15980.fep20-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 04:04:06 +0200 Message-ID: <403024A4.6020006@kolumbus.fi> Date: Mon, 16 Feb 2004 04:02:12 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt CC: Brian Haley , mip6@ietf.org Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 References: <001b01c3ee73$aa4f9da0$5347038d@tm.unikarlsruhe.de> <4027C703.2080209@hp.com> <021d01c3efe8$15f14390$5347038d@tm.unikarlsruhe.de> In-Reply-To: <021d01c3efe8$15f14390$5347038d@tm.unikarlsruhe.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 After a quick read, this draft looks interesting. Quite promising, actually. A couple of comments: - THe base draft already allows caching and re-use of home keygen tokens. (Or maybe I just thought it does? Anyway, it does not matter either way, its good that you draft explains how to do it just before movement.) - Your argument that the attacker has to keep a lot of state if multiple CNs are used. Hmm.... I memory is cheap these days. I think it is more interesting to track the bandwidth that the attacker vs. victims have to use. - Speaking of bandwidth, why not adopt a packet count lifetime instead of a time based lifetime? Three seconds can be very little on a GPRS link and quite a lot on a fiber... - Did you specify somewhere what happens if the CN does not support your scheme? Does the MN have to resend the optimistically delivered packets? Do you have simulation results on what that means for performance? --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 15 23:15:25 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 XAA12348 for ; Sun, 15 Feb 2004 23:15:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asa9o-0006Jn-Em for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 23:14:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G4EulS024281 for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 23:14:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asa9n-0006JP-Ok for mip6-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 23:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12328 for ; Sun, 15 Feb 2004 23:14:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asa9l-0001i3-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 23:14:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asa8p-0001b9-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 23:13:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asa7w-0001Wl-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 23:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asa7v-00068F-3J; Sun, 15 Feb 2004 23:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asa7I-00067C-Px for mip6@optimus.ietf.org; Sun, 15 Feb 2004 23:12:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12284 for ; Sun, 15 Feb 2004 23:12:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asa7G-0001Te-00 for mip6@ietf.org; Sun, 15 Feb 2004 23:12:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asa66-0001OO-00 for mip6@ietf.org; Sun, 15 Feb 2004 23:11:07 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Asa57-0001IJ-00 for mip6@ietf.org; Sun, 15 Feb 2004 23:10:05 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGX10L>; Sun, 15 Feb 2004 23:09:47 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04214E@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Jari Arkko'" , Francis Dupont Cc: mip6@ietf.org Subject: RE: [Mip6] rr weaknesses? Date: Sun, 15 Feb 2004 23:09:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Jari, > As the return > routability is not considered by many people as very safe or > efficient, some new ways to > > I agree about the efficiency part*. > > But I'm wondering if you have any specific worries about the > safety part. I mean beyond issues that already exist in plain > IPv4 and IPv6, such as MitMs being able to do bad things. => The vulnerability of RR is simple: If an attacker gets hold of HOT and COT, it's over he can do whatever he wants. In other words if he can generate HOTI and COTI (which is easy) and be able to receive HOT and COT then he could do whatever he wants. This is more than what can be done today in v4 or v6 because the attacker can move and continue to steal/bomb for the lifetime of the token. I know there is nothing new in what I'm saying but IMO this is the bottom line vulnerability and it's because everything is done in the clear. > *) Well, I guess on the overall scheme of things, 1 RTT can > be considered > relatively effient. => Efficiency is not an absolute thing. We need to know efficient for what? In scenarios where there is frequent mobility I don't think it's efficient in terms of air interface use or tolerable for most apps. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 05:13: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 FAA09433 for ; Mon, 16 Feb 2004 05:13:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsfkS-0001ic-Oj for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:13:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GAD87j006604 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsfkS-0001iK-9u for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 05:13:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09418 for ; Mon, 16 Feb 2004 05:13:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsfkP-0000ai-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:13:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsfjR-0000XG-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:12:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsfiV-0000Sy-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:11:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsfiP-0001cn-Hd; Mon, 16 Feb 2004 05:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsfhZ-0001bT-6t for mip6@optimus.ietf.org; Mon, 16 Feb 2004 05:10:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09340 for ; Mon, 16 Feb 2004 05:10:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsfhV-0000NP-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:10:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsfgV-0000Ix-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:09:04 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx with esmtp (Exim 4.12) id 1AsffX-0000C6-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:08:03 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=i72mail01.tm.uka.de) by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AsffO-0004KC-00; Mon, 16 Feb 2004 11:07:54 +0100 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83] helo=i72ChVogt) by i72mail01.tm.uka.de with esmtp (Exim 4.30) id 1AsffO-0004RD-4L; Mon, 16 Feb 2004 11:07:54 +0100 Message-ID: <00cd01c3f46c$617db720$5347038d@tm.unikarlsruhe.de> From: "Christian Vogt" To: "Soliman Hesham" , "Francis Dupont" , "Jari Arkko" Cc: References: <9E3BA3946476AD4EB94672712B12A85F04214E@ftmail.lab.flarion.com> Subject: Re: [Mip6] rr weaknesses? Date: Mon, 16 Feb 2004 10:08:02 +0100 Organization: Institute of Telematics, University of Karlsruhe (TH) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=2.6 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 U29saW1hbiBIZXNoYW0gd3JvdGU6DQo+IFsuLi5dDQo+ID0+IFRoZSB2dWxuZXJhYmlsaXR5IG9m IFJSIGlzIHNpbXBsZTogSWYgYW4gYXR0YWNrZXINCj4gZ2V0cyBob2xkIG9mIEhPVCBhbmQgQ09U LCBpdCdzIG92ZXIgaGUgY2FuIGRvIHdoYXRldmVyDQo+IGhlIHdhbnRzLiANCj4gWy4uLl0NCltU aGUgY29tcGxldGUgcmVmZXJlbmNlIGlzIGdpdmVuIGJlbG93Ll0NCg0KDQpIaSBTb2xpbWFuLCBo aSBGcmFuY2lzLCBoaSBKYXJpLA0KDQpJIG1pZ2h0IGFkZCB0aGF0IGdldHRpbmcgYSBIb1QgbWVz c2FnZSAtIG1vcmUgcHJlY2lzZWx5LCBhIEhvbWUgS2V5Z2VuIFRva2VuIC0gaXMgc3VmZmljaWVu dCBpZiB0aGUgYXR0YWNrZXIgd2FudHMgdG8gc3RlYWwgZGF0YSBmcm9tIGl0cyB2aWN0aW0uIEFs bCB0aGUgYXR0YWNrZXIgbmVlZHMgaXMgYW4gSVAgYWRkcmVzcyBYIHdoaWNoICgxKSBpdCBpcyBy ZWFjaGFibGUgdGhyb3VnaCAoKiksIGFuZCAoMikgd2hpY2ggaXQgY2FuIHVzZSBhcyBhIGNhcmUt b2YgYWRkcmVzcy4gVGhlIGF0dGFja2VyIHdvdWxkIHNpbXBseSBzZW5kIGEgQ29USSBtZXNzYWdl IG9uIGJlaGFsZiBvZiB0aGUgdmljdGltIHVzaW5nIFggYXMgYSBjYXJlLW9mIGFkZHJlc3MuIEl0 IHdvdWxkIG5vcm1hbGx5IHJlY2VpdmUgdGhlIHJldHVybmluZyBDb1QgbWVzc2FnZSBiZWNhdXNl IGl0IGlzIHJlYWNoYWJsZSBhdCBJUCBhZGRyZXNzIFguIEZpbmFsbHksIHRoZSBhdHRhY2tlciBj b3VsZCBhdXRoZW50aWNhdGUgYSBmYWtlZCBCVSBtZXNzYWdlIHdpdGggdGhlIGludGVyY2VwdCBI b21lIEtleWdlbiBUb2tlbiBhbmQgdGhlIENhcmUtb2YgS2V5Z2VuIFRva2VuIGZyb20gdGhlIChu b3JtYWxseSByZWNlaXZlZCkgQ29UIG1lc3NhZ2UuDQoNCldlIGhhdmUgZWxhYm9yYXRlZCBvbiB0 aGlzIGlzc3VlIGluIHNlY3Rpb24gNi4xIG9mIHRoZSBFYXJseSBCaW5kaW5nIFVwZGF0ZXMgcHJv cG9zYWwgWzFdLg0KDQpOb3RlIHRoYXQgdGhlIENhcmUtb2YgS2V5Z2VuIFRva2VuIGZyb20gYW4g b3ZlcmhlYXJkIENvVCBtZXNzYWdlIHdvdWxkIG5vdCBiZSBpbnRlcmVzdGluZyBmb3IgdGhlIGF0 dGFjayBkZXNjcmliZWQgYWJvdmUuIFRoZSByZWFzb24gaXMgdGhhdCBhIENhcmUtb2YgS2V5Z2Vu IFRva2VuIGlzIGJvdW5kIHRvIGEgcGFydGljdWxhciBjYXJlLW9mIGFkZHJlc3MuIFRoZXJlZm9y ZSwgYW4gb3ZlcmhlYXJkIENhcmUtb2YgS2V5Z2VuIFRva2VuIGNvdWxkIGJlIHVzZWQgZm9yIGEg bGF0ZXIgcmVwbGF5IGF0dGFjaywgZGlyZWN0aW5nIHRoZSB2aWN0aW0ncyBkYXRhIHRvIHRoZSB2 aWN0aW0ncyBwcmV2aW91cyBsb2NhdGlvbiBbMl0sIGJ1dCB0aGF0J3MgYWJvdXQgYWxsLg0KDQoo KikgQWN0dWFsbHksIGl0IGlzIGFscmVhZHkgc3VmZmljaWVudCBpZiB0aGUgYXR0YWNrZXIgY2Fu IGxpc3RlbiB0byBtZXNzYWdlcyBvbiB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBDTiBhbmQgSVAgYWRk cmVzcyBYLiBUaGUgYXR0YWNrZXIgd291bGQgdGhlbiBoYXZlIHRvIGVhdmVzZHJvcCBvbiB0aGUg cmV0dXJuaW5nIENvVCBtZXNzYWdlIHJhdGhlciB0aGFuICJub3JtYWxseSByZWNlaXZpbmciIGl0 Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KLSBDaHJpc3RpYW4NCg0KDQpbMV0gRWFybHkgQmluZGlu ZyBVcGRhdGVzIGZvciBNb2JpbGUgSVB2Ng0KICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXZvZ3QtbWlwNi1lYXJseS1iaW5kaW5nLXVwZGF0ZXMtMDAudHh0DQpb Ml0gTW9iaWxlIElQIHZlcnNpb24gNiBSb3V0ZSBPcHRpbWl6YXRpb24gU2VjdXJpdHkgRGVzaWdu IEJhY2tncm91bmQNCiAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1uaWthbmRlci1tb2JpbGVpcC12Ni1yby1zZWMtMDIudHh0DQoNCg0KfA0KfCBDaHJpc3RpYW4g Vm9ndA0KfCBJbnN0aXR1dGUgb2YgVGVsZW1hdGljcywgVW5pdmVyc2l0eSBvZiBLYXJsc3J1aGUg KFRIKQ0KfCB3d3cudG0udWthLmRlL35jaHZvZ3QvDQp8DQoNCg0KU29saW1hbiBIZXNoYW0gd3Jv dGU6DQo+IEphcmksDQo+IA0KPiAgPiAgICAgQXMgdGhlIHJldHVybg0KPiAgPiAgICAgcm91dGFi aWxpdHkgaXMgbm90IGNvbnNpZGVyZWQgYnkgbWFueSBwZW9wbGUgYXMgdmVyeSBzYWZlIG9yDQo+ ICA+ICAgICBlZmZpY2llbnQsIHNvbWUgbmV3IHdheXMgdG8NCj4gID4NCj4gID4gSSBhZ3JlZSBh Ym91dCB0aGUgZWZmaWNpZW5jeSBwYXJ0Ki4NCj4gID4NCj4gID4gQnV0IEknbSB3b25kZXJpbmcg aWYgeW91IGhhdmUgYW55IHNwZWNpZmljIHdvcnJpZXMgYWJvdXQgdGhlDQo+ICA+IHNhZmV0eSBw YXJ0LiBJIG1lYW4gYmV5b25kIGlzc3VlcyB0aGF0IGFscmVhZHkgZXhpc3QgaW4gcGxhaW4NCj4g ID4gSVB2NCBhbmQgSVB2Niwgc3VjaCBhcyBNaXRNcyBiZWluZyBhYmxlIHRvIGRvIGJhZCB0aGlu Z3MuDQo+IA0KPiA9PiBUaGUgdnVsbmVyYWJpbGl0eSBvZiBSUiBpcyBzaW1wbGU6IElmIGFuIGF0 dGFja2VyDQo+IGdldHMgaG9sZCBvZiBIT1QgYW5kIENPVCwgaXQncyBvdmVyIGhlIGNhbiBkbyB3 aGF0ZXZlcg0KPiBoZSB3YW50cy4gSW4gb3RoZXIgd29yZHMgaWYgaGUgY2FuIGdlbmVyYXRlIEhP VEkgYW5kIENPVEkNCj4gKHdoaWNoIGlzIGVhc3kpIGFuZCBiZSBhYmxlIHRvIHJlY2VpdmUgSE9U IGFuZCBDT1QgdGhlbg0KPiBoZSBjb3VsZCBkbyB3aGF0ZXZlciBoZSB3YW50cy4gVGhpcyBpcyBt b3JlIHRoYW4gd2hhdCBjYW4gYmUNCj4gZG9uZSB0b2RheSBpbiB2NCBvciB2NiBiZWNhdXNlIHRo ZSBhdHRhY2tlciBjYW4gbW92ZSBhbmQNCj4gY29udGludWUgdG8gc3RlYWwvYm9tYiBmb3IgdGhl IGxpZmV0aW1lIG9mIHRoZSB0b2tlbi4NCj4gDQo+IEkga25vdyB0aGVyZSBpcyBub3RoaW5nIG5l dyBpbiB3aGF0IEknbSBzYXlpbmcgYnV0IElNTw0KPiB0aGlzIGlzIHRoZSBib3R0b20gbGluZSB2 dWxuZXJhYmlsaXR5IGFuZCBpdCdzIGJlY2F1c2UNCj4gZXZlcnl0aGluZyBpcyBkb25lIGluIHRo ZSBjbGVhci4NCj4gDQo+ICA+ICopIFdlbGwsIEkgZ3Vlc3Mgb24gdGhlIG92ZXJhbGwgc2NoZW1l IG9mIHRoaW5ncywgMSBSVFQgY2FuDQo+ICA+IGJlIGNvbnNpZGVyZWQNCj4gID4gcmVsYXRpdmVs eSBlZmZpZW50Lg0KPiANCj4gPT4gRWZmaWNpZW5jeSBpcyBub3QgYW4gYWJzb2x1dGUgdGhpbmcu IFdlIG5lZWQgdG8ga25vdw0KPiBlZmZpY2llbnQgZm9yIHdoYXQ/IEluIHNjZW5hcmlvcyB3aGVy ZSB0aGVyZSBpcyBmcmVxdWVudA0KPiBtb2JpbGl0eSBJIGRvbid0IHRoaW5rIGl0J3MgZWZmaWNp ZW50IGluIHRlcm1zIG9mIGFpciBpbnRlcmZhY2UNCj4gdXNlIG9yIHRvbGVyYWJsZSBmb3IgbW9z dCBhcHBzLg0KPiANCj4gSGVzaGFtDQo= _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 05:25:39 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 FAA09893 for ; Mon, 16 Feb 2004 05:25:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asfw8-0002am-1h for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:25:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GAPCVM009958 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asfw7-0002aX-Sa for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 05:25:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09872 for ; Mon, 16 Feb 2004 05:25:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asfw4-0001JM-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:25:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsfvE-0001Gy-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:24:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asfux-0001Du-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asfuz-0002Rf-NE; Mon, 16 Feb 2004 05:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsfuA-0002RJ-AV for mip6@optimus.ietf.org; Mon, 16 Feb 2004 05:23:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09806 for ; Mon, 16 Feb 2004 05:23:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asfu6-0001CC-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:23:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsftG-00019v-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:22:15 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Asft3-00016m-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:22:01 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1GALSV25309; Mon, 16 Feb 2004 11:21:28 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1GALSSj094880; Mon, 16 Feb 2004 11:21:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402161021.i1GALSSj094880@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: mip6@ietf.org In-reply-to: Your message of Mon, 16 Feb 2004 03:35:15 +0200. <40301E53.2090004@kolumbus.fi> Date: Mon, 16 Feb 2004 11:21:28 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mip6] Re: review of draft-dupont-mipv6-3bombing-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: I'd like to expand a little bit on what you say in under 2.3 regarding route optimization. As you have pointed out, anyone can spoof the source address of a TCP SYN packet, so we generally can not worry too much single request - single response attacks. Except where mechanisms to defeat ingress filtering are provided, which you also mention. => for multiple responses either the transport implementation is very buggy and the attacker can guess what it has to put in fake acks, or the attacker is on the return path and can look at responses. I have a real concern about reflection attacks: they seems to be easy (i.e., no effective defense) when the attacker is closed to the victim, for instance on the same link. As Christian pointed out in his e-mail explaining the security background for early binding updates, and is also discussed in Section 2.5 of [1], we also need to consider the possible amplification factor. The problem with bombing attacks in the RO case is using first a right address, getting to see TLP sequence numbers so that fake acks can be sent, and then moving the stream to the victim's address. => the amplification factor is very limited: a window plus some retransmits. IMHO it is more efficient for the attacker to use more reflectors, and this does not reveal anything about the position of the attacker. This can be devastating, at least under some conditions. The difference to a regular TCP SYN spoofing is that you actually get to see some inital part of the traffic, which may make things easier for the attacker. Having said this, [1] notes that different TLPs and different TCP implementations behave in different ways regarding this attack. It might be useful to shed some further light on this, to figure out exactly how serious (or not) this attack is. => I don't believe in this attack because it does not give something against the real defense, i.e., against the ingress filtering, and of course it reveals many things about the attacker. There is a related issue that has to do with the level of ingress filtering support in the Internet. We have more or less accepted the situation where this support is not universal. So, we can assume that we can be targets of e.g. spoofed TCP SYNs or reflected packets. I would not like to make this any worse by making it possible to be a victim of a stream of packets. => IMHO the important thing is to introduce *no* new ways to bypass the ingress filtering or any efficient defense against (D)DoS attacks. And I believe this is the case of optimized RO schemes when fake alternate care-ofs are forbiden. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 05:26:42 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 FAA09951 for ; Mon, 16 Feb 2004 05:26:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asfx9-0002df-2u for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:26:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GAQFAl010128 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:26:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asfx8-0002d5-TX for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 05:26:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09926 for ; Mon, 16 Feb 2004 05:26:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asfx5-0001Mm-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asfw7-0001Jj-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:25:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asfvv-0001HM-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:24:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asfvx-0002We-Qx; Mon, 16 Feb 2004 05:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asfv8-0002TY-R6 for mip6@optimus.ietf.org; Mon, 16 Feb 2004 05:24:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09828 for ; Mon, 16 Feb 2004 05:24:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asfv5-0001Fo-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:24:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asfu8-0001CX-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:23:09 -0500 Received: from fep01-0.kolumbus.fi ([193.229.0.41] helo=fep01-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1AsftT-0001A6-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:22:27 -0500 Received: from kolumbus.fi ([62.248.154.14]) by fep01-app.kolumbus.fi with ESMTP id <20040216102227.KDSG9750.fep01-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 12:22:27 +0200 Message-ID: <40309971.90903@kolumbus.fi> Date: Mon, 16 Feb 2004 12:20:33 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org CC: James Kempf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] bootstrap problem definition Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hello, James Kempf and myself wrote an initial draft on the bootstrapping problem in mobile ipv6. No solutions, just the problem. Comments appreciated. Here's the abstract: This document discusses the creation of a security association between a mobile node and a home agent that is previously unknown to it. This problem is called the bootstrapping problem. The document discusses several different usage scenarios, as well as related issues involving informing the mobile node of changes in the home network topology and mobility management service. Limitations of the base Mobile IPv6 protocol in dealing with the scenarios are outlined. Unfortunately, we missed the I-D deadline (or I did) so you can not find it from the directories. In the meantime you can access it from: http://www.arkko.com/publications/mipv6/drafts/bootstrap.txt http://www.arkko.com/publications/mipv6/drafts/bootstrap.html --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 05:44: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 FAA10426 for ; Mon, 16 Feb 2004 05:44:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgEa-0003oF-4X for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:44:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GAiGHV014637 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:44:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgEa-0003o0-0A for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 05:44:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10331 for ; Mon, 16 Feb 2004 05:44:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsgEW-0002DV-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:44:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgDa-000259-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:43:15 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AsgCc-00020W-02 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:42:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Asg9V-0003YN-BD for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asg9U-0003Tc-BS; Mon, 16 Feb 2004 05:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asg8g-0003QK-PP for mip6@optimus.ietf.org; Mon, 16 Feb 2004 05:38:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10192 for ; Mon, 16 Feb 2004 05:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asg8d-0001oh-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asg7g-0001mc-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:37:08 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Asg7L-0001kC-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:36:47 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGXF6R>; Mon, 16 Feb 2004 05:36:32 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04215A@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Francis Dupont'" , Jari Arkko Cc: mip6@ietf.org Subject: RE: [Mip6] Re: rr weaknesses? Date: Mon, 16 Feb 2004 05:36:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > In your previous mail you wrote: > > In reading Francis' draft on bombing I came across the following > statement: > > As the return > routability is not considered by many people as very safe or > efficient, some new ways to > > I agree about the efficiency part*. > > But I'm wondering if you have any specific worries about the > safety part. I mean beyond issues that already exist in plain > IPv4 and IPv6, such as MitMs being able to do bad things. > > => the RR of Mobile IPv6 has all packets in clear somewhere > in the Internet. > IMHO the real issue is the RR assumptions are a bit weak, so > it is not > a surprise that with stronger assumptions (strong > authentication available > for instance) we can get safer mechanisms. To be short do > you agree that > HIP is safer than current Mobile IPv6 RR? => We don't even need to go that far, CGAs were safer!! I wonder why we don't extend RR with CGAs and save ourselves all this trouble... Hesham > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: we can poll the WG to see whether many people consider > that RR is not very > safe if you'd like (:-). > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 05:44:49 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 FAA10446 for ; Mon, 16 Feb 2004 05:44:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgEg-0003oX-UF for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:44:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GAiMJQ014655 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 05:44:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgEg-0003oI-QG for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 05:44:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10372 for ; Mon, 16 Feb 2004 05:44:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsgEd-0002EQ-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:44:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgDm-00026s-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:43:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AsgCf-00020W-01 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:42:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Asg1n-0003SV-U4 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 05:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asg1m-0002oz-DN; Mon, 16 Feb 2004 05:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asg0w-0002ny-Sf for mip6@optimus.ietf.org; Mon, 16 Feb 2004 05:30:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10054 for ; Mon, 16 Feb 2004 05:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asg0t-0001WS-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:30:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asg02-0001U3-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:29:15 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AsfzS-0001Rb-00 for mip6@ietf.org; Mon, 16 Feb 2004 05:28:38 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1GAS4V25960; Mon, 16 Feb 2004 11:28:04 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1GAS4Sj094951; Mon, 16 Feb 2004 11:28:04 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402161028.i1GAS4Sj094951@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: mip6@ietf.org In-reply-to: Your message of Mon, 16 Feb 2004 03:40:16 +0200. <40301F80.2040607@kolumbus.fi> Date: Mon, 16 Feb 2004 11:28:04 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mip6] Re: rr weaknesses? Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: In reading Francis' draft on bombing I came across the following statement: As the return routability is not considered by many people as very safe or efficient, some new ways to I agree about the efficiency part*. But I'm wondering if you have any specific worries about the safety part. I mean beyond issues that already exist in plain IPv4 and IPv6, such as MitMs being able to do bad things. => the RR of Mobile IPv6 has all packets in clear somewhere in the Internet. IMHO the real issue is the RR assumptions are a bit weak, so it is not a surprise that with stronger assumptions (strong authentication available for instance) we can get safer mechanisms. To be short do you agree that HIP is safer than current Mobile IPv6 RR? Regards Francis.Dupont@enst-bretagne.fr PS: we can poll the WG to see whether many people consider that RR is not very safe if you'd like (:-). _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 06:15:45 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 GAA11648 for ; Mon, 16 Feb 2004 06:15:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asgid-0005pu-4t for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 06:15:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GBFJNP022428 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 06:15:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asgic-0005pf-U7 for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 06:15:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11645 for ; Mon, 16 Feb 2004 06:15:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsgiZ-000444-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 06:15:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsghY-00041b-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 06:14:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsghL-0003z2-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 06:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsghN-0005kL-8l; Mon, 16 Feb 2004 06:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asgga-0005jv-Cj for mip6@optimus.ietf.org; Mon, 16 Feb 2004 06:13:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11592 for ; Mon, 16 Feb 2004 06:13:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsggW-0003xq-00 for mip6@ietf.org; Mon, 16 Feb 2004 06:13:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asgfd-0003vY-00 for mip6@ietf.org; Mon, 16 Feb 2004 06:12:14 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AsgfN-0003sZ-00 for mip6@ietf.org; Mon, 16 Feb 2004 06:11:57 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1GBBOV29525; Mon, 16 Feb 2004 12:11:24 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1GBBOSj095378; Mon, 16 Feb 2004 12:11:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402161111.i1GBBOSj095378@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Soliman Hesham cc: Jari Arkko , mip6@ietf.org Subject: Re: [Mip6] Re: rr weaknesses? In-reply-to: Your message of Mon, 16 Feb 2004 05:36:12 EST. <9E3BA3946476AD4EB94672712B12A85F04215A@ftmail.lab.flarion.com> Date: Mon, 16 Feb 2004 12:11:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: > To be short do you agree that > HIP is safer than current Mobile IPv6 RR? => We don't even need to go that far, CGAs were safer!! I wonder why we don't extend RR with CGAs and save ourselves all this trouble... => the answer is very simple: IPR. Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 06:27:52 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 GAA11912 for ; Mon, 16 Feb 2004 06:27:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsguL-0006OH-Vc for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 06:27:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GBRP0a024559 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 06:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsguL-0006O2-QC for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 06:27:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11899 for ; Mon, 16 Feb 2004 06:27:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsguH-0004al-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 06:27:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgtJ-0004XN-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 06:26:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asgsx-0004Th-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 06:25:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asgt0-0006H3-59; Mon, 16 Feb 2004 06:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgsC-0006E0-MC for mip6@optimus.ietf.org; Mon, 16 Feb 2004 06:25:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11805 for ; Mon, 16 Feb 2004 06:25:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asgs8-0004Sx-00 for mip6@ietf.org; Mon, 16 Feb 2004 06:25:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgrB-0004Qr-00 for mip6@ietf.org; Mon, 16 Feb 2004 06:24:10 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AsgqQ-0004M4-00 for mip6@ietf.org; Mon, 16 Feb 2004 06:23:22 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGXF9Q>; Mon, 16 Feb 2004 06:23:06 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04215C@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Francis.Dupont@enst-bretagne.fr'" Cc: Jari Arkko , mip6@ietf.org Subject: RE: [Mip6] Re: rr weaknesses? Date: Mon, 16 Feb 2004 06:23:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > > To be short do you agree that > > HIP is safer than current Mobile IPv6 RR? > > => We don't even need to go that far, CGAs were safer!! > I wonder why we don't extend RR with CGAs and save ourselves > all this trouble... > > => the answer is very simple: IPR. => Ok, but please consider the following: - It was good enough for SEND. There is no reason (at least in theory) that we can't try to get the same statements as SEND. - We don't know that other proposals (including ones being discussed now) are IPR-free. Hesham > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 08:32: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 IAA16348 for ; Mon, 16 Feb 2004 08:32:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsirG-0005ii-Qg for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 08:32:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GDWMIm021982 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 08:32:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsirG-0005iT-F2 for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 08:32:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16340 for ; Mon, 16 Feb 2004 08:32:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsirF-0003Wa-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 08:32:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsiqK-0003Sp-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 08:31:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asipy-0003P9-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 08:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipy-0005Vj-2o; Mon, 16 Feb 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsipC-0005Tj-SJ for mip6@optimus.ietf.org; Mon, 16 Feb 2004 08:30:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16092 for ; Mon, 16 Feb 2004 08:30:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsipB-0003MV-00 for mip6@ietf.org; Mon, 16 Feb 2004 08:30:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsioD-0003HU-00 for mip6@ietf.org; Mon, 16 Feb 2004 08:29:13 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AsinD-0003Bj-00 for mip6@ietf.org; Mon, 16 Feb 2004 08:28:11 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1Asin8-0004q0-00; Mon, 16 Feb 2004 14:28:06 +0100 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1Asin7-0004ny-00; Mon, 16 Feb 2004 14:28:05 +0100 Received: from borg.ipv6.tm.uni-karlsruhe.de ([2001:638:204:6:202:b3ff:feab:632e] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1Asin4-00022H-00; Mon, 16 Feb 2004 14:28:02 +0100 Received: from doll by borg.ipv6.tm.uni-karlsruhe.de with local (Exim 4.05) id 1Asin4-00070F-00; Mon, 16 Feb 2004 14:28:02 +0100 Date: Mon, 16 Feb 2004 14:28:02 +0100 From: Mark Doll To: Francis Dupont Cc: Jari Arkko , mip6@ietf.org Subject: Re: [Mip6] Re: review of draft-dupont-mipv6-3bombing-00.txt Message-Id: <20040216142802.7e41788b@borg.ipv6.tm.uni-karlsruhe.de> In-Reply-To: <200402161021.i1GALSSj094880@givry.rennes.enst-bretagne.fr> References: <40301E53.2090004@kolumbus.fi> <200402161021.i1GALSSj094880@givry.rennes.enst-bretagne.fr> X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Request-PGP: http://mark.doll.name/key.asc Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 On Mon, 16 Feb 2004 11:21:28 +0100 Francis Dupont wrote: > => the amplification factor is very limited: a window plus some > retransmits. IMHO it is more efficient for the attacker to use more > reflectors, and this does not reveal anything about the position of > the attacker. There's an important difference between traffic that the CN sends after an Early Bindung Update compared to the traffic it sends in a reflection attack due to a faked source address: All packets carry a type 2 routing header revealing the home address of the attacker to the host under attack. Regardless how many CNs an attacker uses for his attack, they all insert the same home address in the routing header---and the home address has been checked via the HoTI/HoT messages. So the attacked host knows for shure who attacks him and the only advantage an attacker gains through misusing EBUs is the amplification factor, IMHO. To close this last security gap, the CN should implement a scheme limiting the amount of data it sends after an EBU and before a fully authorized BU to the amount of data traffic is has sent to the old CoA in the last few seconds before the EBU (or maybe to twice of the amount). Regards, Mark. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 09:20: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 JAA19617 for ; Mon, 16 Feb 2004 09:20:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asjbj-0001Ea-D5 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 09:20:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GEKN4i004741 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 09:20:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asjbj-0001EO-4j for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 09:20:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19609 for ; Mon, 16 Feb 2004 09:20:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asjbh-00076i-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 09:20:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asjao-00073R-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 09:19:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsjaP-000702-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 09:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsjaP-00017N-DN; Mon, 16 Feb 2004 09:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsjZi-00016a-Ad for mip6@optimus.ietf.org; Mon, 16 Feb 2004 09:18:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19511 for ; Mon, 16 Feb 2004 09:18:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsjZg-0006xo-00 for mip6@ietf.org; Mon, 16 Feb 2004 09:18:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsjYk-0006v7-00 for mip6@ietf.org; Mon, 16 Feb 2004 09:17:19 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AsjYH-0006sC-00 for mip6@ietf.org; Mon, 16 Feb 2004 09:16:49 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1GEGDV09979; Mon, 16 Feb 2004 15:16:13 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1GEGDSj096142; Mon, 16 Feb 2004 15:16:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402161416.i1GEGDSj096142@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mark Doll cc: Jari Arkko , mip6@ietf.org Subject: Re: [Mip6] Re: review of draft-dupont-mipv6-3bombing-00.txt In-reply-to: Your message of Mon, 16 Feb 2004 14:28:02 +0100. <20040216142802.7e41788b@borg.ipv6.tm.uni-karlsruhe.de> Date: Mon, 16 Feb 2004 15:16:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: On Mon, 16 Feb 2004 11:21:28 +0100 Francis Dupont wrote: > => the amplification factor is very limited: a window plus some > retransmits. IMHO it is more efficient for the attacker to use more > reflectors, and this does not reveal anything about the position of > the attacker. There's an important difference between traffic that the CN sends after an Early Bindung Update compared to the traffic it sends in a reflection attack due to a faked source address: All packets carry a type 2 routing header revealing the home address of the attacker to the host under attack. Regardless how many CNs an attacker uses for his attack, they all insert the same home address in the routing header---and the home address has been checked via the HoTI/HoT messages. So the attacked host knows for shure who attacks him and the only advantage an attacker gains through misusing EBUs is the amplification factor, IMHO. To close this last security gap, the CN should implement a scheme limiting the amount of data it sends after an EBU and before a fully authorized BU to the amount of data traffic is has sent to the old CoA in the last few seconds before the EBU (or maybe to twice of the amount). => I have another simple suggestion: close the congestion window, i.e., behave on hand-off of the peer as a packet was lost... Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 11:21:32 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 LAA00461 for ; Mon, 16 Feb 2004 11:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslUW-0002Pq-BW for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GGL4Jh009286 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslUW-0002Ph-4W for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 11:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00354 for ; Mon, 16 Feb 2004 11:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslUU-0002ur-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:21:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslRV-0002OX-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:17:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AslQD-00029t-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:16:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AslGx-0007UD-Tu for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslGu-0000sd-QR; Mon, 16 Feb 2004 11:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslG6-0000r4-NM for mip6@optimus.ietf.org; Mon, 16 Feb 2004 11:06:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28534 for ; Mon, 16 Feb 2004 11:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslG4-0000hg-00 for mip6@ietf.org; Mon, 16 Feb 2004 11:06:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslEF-0000Iv-00 for mip6@ietf.org; Mon, 16 Feb 2004 11:04:16 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AslCH-0007ef-00 for mip6@ietf.org; Mon, 16 Feb 2004 11:02:14 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AslCA-0007KJ-00; Mon, 16 Feb 2004 17:02:06 +0100 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1AslC9-000707-00; Mon, 16 Feb 2004 17:02:05 +0100 Received: from borg.ipv6.tm.uni-karlsruhe.de ([2001:638:204:6:202:b3ff:feab:632e] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1AslC8-0002Kz-00; Mon, 16 Feb 2004 17:02:05 +0100 Received: from doll by borg.ipv6.tm.uni-karlsruhe.de with local (Exim 4.05) id 1AslC8-00020S-00; Mon, 16 Feb 2004 17:02:04 +0100 Date: Mon, 16 Feb 2004 17:02:04 +0100 From: Mark Doll To: Francis Dupont Cc: Jari Arkko , mip6@ietf.org Subject: Re: [Mip6] Re: review of draft-dupont-mipv6-3bombing-00.txt Message-Id: <20040216170204.1ad84cc2@borg.ipv6.tm.uni-karlsruhe.de> In-Reply-To: <200402161416.i1GEGDSj096142@givry.rennes.enst-bretagne.fr> References: <20040216142802.7e41788b@borg.ipv6.tm.uni-karlsruhe.de> <200402161416.i1GEGDSj096142@givry.rennes.enst-bretagne.fr> X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Request-PGP: http://mark.doll.name/key.asc Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 On Mon, 16 Feb 2004 15:16:13 +0100 Francis Dupont wrote: > => I have another simple suggestion: close the congestion window, > i.e., behave on hand-off of the peer as a packet was lost... This does not work for UDP streams. Thinking of TCP, I suppose some packets will always be lost during a handover---as long as we do not use something like an anticipated handover starting from the old care-of address with all its security implications. So TCP will go through slow start anyway. And beeing able to force TCP into slow start means that we intermix layers. Is this a good idea? (*) Mark. (*) This is not a rhethorical question. I've just never been thinking about the pros and cons. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 11:36:58 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 LAA03364 for ; Mon, 16 Feb 2004 11:36:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsljQ-0003Zv-Nr for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:36:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GGaSZc013749 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:36:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsljQ-0003Zg-JA for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 11:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03201 for ; Mon, 16 Feb 2004 11:36:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsljP-0006GG-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:36:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aslhp-0005w3-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:34:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aslg5-0005Wx-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aslg4-0003Mt-PS; Mon, 16 Feb 2004 11:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslfD-0003GH-NB for mip6@optimus.ietf.org; Mon, 16 Feb 2004 11:32:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02287 for ; Mon, 16 Feb 2004 11:32:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslfC-0005Ix-00 for mip6@ietf.org; Mon, 16 Feb 2004 11:32:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aslc6-0004dH-00 for mip6@ietf.org; Mon, 16 Feb 2004 11:28:56 -0500 Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx with esmtp (Exim 4.12) id 1AslZ7-0003rp-00 for mip6@ietf.org; Mon, 16 Feb 2004 11:25:49 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0HT60051BQQZ3H@dns2.cselt.it> for mip6@ietf.org; Mon, 16 Feb 2004 17:20:59 +0100 (MET) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Feb 2004 17:24:26 +0100 Received: from EXC2K04A.cselt.it ([163.162.161.229]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Feb 2004 17:24:26 +0100 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K04A.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Feb 2004 17:25:15 +0100 Date: Mon, 16 Feb 2004 17:25:15 +0100 From: Giaretta Gerardo Subject: RE: [Mip6] bootstrap problem definition To: Jari Arkko , mip6@ietf.org Cc: James Kempf , Guardini Ivano Message-id: <625BE97BF4795E43970345790166B9BCE8CBCC@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] bootstrap problem definition Thread-Index: AcP0dyn+bCLaJpbzRjOLiPHmmQZkxQAMdEDg content-class: urn:content-classes:message X-OriginalArrivalTime: 16 Feb 2004 16:25:15.0944 (UTC) FILETIME=[75CBB280:01C3F4A9] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jari, I read your problem statement and have some questions: 1) In section 3.2.1 you say that "...IKEv1 does not contain support for = exchanging the right kind of information, primarily the NAI, with the = mobile node.". Instead, rfc2407 and rfc2409 state that, when using = aggressive mode and pre-shared key, it is possible to use the = ID_USER_FQDN (i.e. user@domain) as peer identifier for IKE phase 1. That = could be used as the identifier of the MN (in place of the home address) = during IKE phase 1 negotiation with the HA, thus allowing for the = interaction with a backend AAA server. Am I missing something? 2) In section 4 it is not completely clear to me the descrition of the = third scenario. What is the existing security association you are = referring to? Is it the SA in place between the MN and the AAA server of = the home domain?=20 Bye, --Gerardo > -----Original Message----- > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org]On=20 > Behalf Of Jari > Arkko > Sent: Monday, February 16, 2004 11:21 AM > To: mip6@ietf.org > Cc: James Kempf > Subject: [Mip6] bootstrap problem definition >=20 >=20 >=20 > Hello, >=20 > James Kempf and myself wrote an initial draft on the bootstrapping > problem in mobile ipv6. No solutions, just the problem. Comments > appreciated. Here's the abstract: >=20 > This document discusses the creation of a security association > between a mobile node and a home agent that is previously=20 > unknown to > it. This problem is called the bootstrapping problem. =20 > The document > discusses several different usage scenarios, as well as related > issues involving informing the mobile node of changes in the home > network topology and mobility management service. =20 > Limitations of the > base Mobile IPv6 protocol in dealing with the scenarios=20 > are outlined. >=20 > Unfortunately, we missed the I-D deadline (or I did) so you can > not find it from the directories. In the meantime you can access > it from: >=20 > http://www.arkko.com/publications/mipv6/drafts/bootstrap.txt > http://www.arkko.com/publications/mipv6/drafts/bootstrap.html >=20 > --Jari >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 14:46:20 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 OAA14647 for ; Mon, 16 Feb 2004 14:46:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asogi-00030Q-PN for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 14:45:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GJjqSx011550 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 14:45:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asogi-00030D-Kn for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 14:45:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14621 for ; Mon, 16 Feb 2004 14:45:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asogf-00069K-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 14:45:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asofd-00062V-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 14:44:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asoey-0005xo-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 14:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asoev-0002ri-Rq; Mon, 16 Feb 2004 14:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsoeW-0002kn-Rn for mip6@optimus.ietf.org; Mon, 16 Feb 2004 14:43:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14480 for ; Mon, 16 Feb 2004 14:43:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsoeU-0005u3-00 for mip6@ietf.org; Mon, 16 Feb 2004 14:43:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asode-0005nj-00 for mip6@ietf.org; Mon, 16 Feb 2004 14:42:42 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Asocr-0005aw-00 for mip6@ietf.org; Mon, 16 Feb 2004 14:41:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1GJfIr31836; Mon, 16 Feb 2004 11:41:18 -0800 X-mProtect: <200402161941> 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 smtpdARuo6b; Mon, 16 Feb 2004 11:41:16 PST Message-ID: <40311CD1.7831B4A0@iprg.nokia.com> Date: Mon, 16 Feb 2004 11:41:05 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Doll CC: mip6@ietf.org Subject: Re: [Mip6] Re: review of draft-dupont-mipv6-3bombing-00.txt References: <20040216142802.7e41788b@borg.ipv6.tm.uni-karlsruhe.de> <200402161416.i1GEGDSj096142@givry.rennes.enst-bretagne.fr> <20040216170204.1ad84cc2@borg.ipv6.tm.uni-karlsruhe.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hello folks, I would also hope to avoid any TCP-specific solution. Regarding slow-start: Mark Doll wrote: > Thinking of TCP, I suppose some packets will always be lost > during a handover This is not true. With a simple context transfer approach that includes redelivery of (approx. 2) redundantly buffered packets, we can get terrific performance for voice. With a few more buffered packets, probably video. The determiniming factor, is how long is required for the reassociation to finish. That can take a long time with today's products, but it doesn't absolutely have to. > .... And beeing able > to force TCP into slow start means that we intermix layers. > Is this a good idea? Basically, no. There has been a lot of discussion about cross-layer design recently. I think it should be reframed as enabling one layer to acquire relevant information that _may_ be more efficiently provided by another layer. I think it's a much better way for sane and simple designs to result. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 15:07:06 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 PAA16293 for ; Mon, 16 Feb 2004 15:07:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asp0n-0001aF-Mp for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 15:06:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GK6bQs006087 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 15:06:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asp0n-0001ZC-DK for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:06:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16229 for ; Mon, 16 Feb 2004 15:06:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asp0k-0000Ds-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 15:06:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asozt-0000AC-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 15:05:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsozF-00006L-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 15:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsozG-0000WG-Md; Mon, 16 Feb 2004 15:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asoyp-00007F-HX for mip6@optimus.ietf.org; Mon, 16 Feb 2004 15:04:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16057 for ; Mon, 16 Feb 2004 15:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asoym-00004x-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:04:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asoxv-00001M-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:03:40 -0500 Received: from fep22-0.kolumbus.fi ([193.229.0.60] helo=fep22-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1Asox0-0007m0-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:02:42 -0500 Received: from kolumbus.fi ([62.248.154.14]) by fep22-app.kolumbus.fi with ESMTP id <20040216200240.LDYQ3524.fep22-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 22:02:40 +0200 Message-ID: <4031216D.3030903@kolumbus.fi> Date: Mon, 16 Feb 2004 22:00:45 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giaretta Gerardo CC: mip6@ietf.org, James Kempf , Guardini Ivano Subject: Re: [Mip6] bootstrap problem definition References: <625BE97BF4795E43970345790166B9BCE8CBCC@EXC2K01B.cselt.it> In-Reply-To: <625BE97BF4795E43970345790166B9BCE8CBCC@EXC2K01B.cselt.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Giaretta Gerardo wrote: > Hi Jari, > > I read your problem statement and have some questions: Thanks for taking the time to read it. > 1) In section 3.2.1 you say that "...IKEv1 does not contain support for exchanging the right kind of information, primarily the NAI, with the mobile node.". Instead, rfc2407 and rfc2409 state that, when using aggressive mode and pre-shared key, it is possible to use the ID_USER_FQDN (i.e. user@domain) as peer identifier for IKE phase 1. That could be used as the identifier of the MN (in place of the home address) during IKE phase 1 negotiation with the HA, thus allowing for the interaction with a backend AAA server. Am I missing something? In short, yes. Or you could send the DN from a cert, or an administrative name associated with the preshared secret config. Or just send the home address, and let the backend billing server sort it out... I think the primary issue is the ability to use the same kind of credentials that you would use for your network access/vpn/whatever. This part in the draft probably needs some additional work. > 2) In section 4 it is not completely clear to me the descrition of the third scenario. What is the existing security association you are referring to? Is it the SA in place between the MN and the AAA server of the home domain? No. Its the security association your host has a with the current access network in order to get network access. I may be splitting hairs with the difference between the second and the third scenario; the difference is whether you call your operator the home network or the access network and for what service the existing SA was intended for. In concrete terms, in scenario 3 you could leverage your association with your ISP, the indirect association with the local ISP that you are roaming from, or the link layer security association of your network connection. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 16:09:42 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 QAA24750 for ; Mon, 16 Feb 2004 16:09:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspzN-0006QM-DJ for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 16:09:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GL9DcA024688 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 16:09:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspzM-0006Q7-Mg for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 16:09:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24644 for ; Mon, 16 Feb 2004 16:09:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspzL-0007BD-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 16:09:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspxK-0006mb-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 16:07:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AspvI-0006Td-02 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 16:05:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aspfx-0003RG-Kn for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 15:49:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aspfq-0004Ls-9R; Mon, 16 Feb 2004 15:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspfY-0004Ki-Ov for mip6@optimus.ietf.org; Mon, 16 Feb 2004 15:48:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21471 for ; Mon, 16 Feb 2004 15:48:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspfX-0003hS-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:48:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspdT-0003KA-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:46:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AspcL-00036B-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:45:25 -0500 Received: from fep02-0.kolumbus.fi ([193.229.0.44] helo=fep02-app.kolumbus.fi) by mx2.foretec.com with esmtp (Exim 4.24) id 1AspcK-0003N0-FP for mip6@ietf.org; Mon, 16 Feb 2004 15:45:24 -0500 Received: from kolumbus.fi ([62.248.154.14]) by fep02-app.kolumbus.fi with ESMTP id <20040216204515.KSTR1464.fep02-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 22:45:15 +0200 Message-ID: <40312B68.1070807@kolumbus.fi> Date: Mon, 16 Feb 2004 22:43:20 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: Francis Dupont , mip6@ietf.org Subject: Re: [Mip6] rr weaknesses? References: <9E3BA3946476AD4EB94672712B12A85F04214E@ftmail.lab.flarion.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F04214E@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Soliman Hesham wrote: > => The vulnerability of RR is simple: If an attacker > gets hold of HOT and COT, it's over he can do whatever > he wants. In other words if he can generate HOTI and COTI > (which is easy) and be able to receive HOT and COT then > he could do whatever he wants. This is more than what can be > done today in v4 or v6 because the attacker can move and > continue to steal/bomb for the lifetime of the token. True, but it would be useful to compare this to other attacks that the same mitm can do. For instance, ARP spoofing, sending TCP RSTs, messing with TCP ACKs, dropping packets. > => Efficiency is not an absolute thing. We need to know > efficient for what? In scenarios where there is frequent > mobility I don't think it's efficient in terms of air interface > use or tolerable for most apps. I hate to press you for more information since I basically agree that we need additional optimized mechanisms. But can you say more about the specific requirements that you are looking for "most apps"? Is there a paper somewhere that has simulated mobility in some environment that shows how much time you are spending on RR signaling vs. other movement related tasks? How does home registration compare, what about IPv6 network attachment? How about 1X/11i tasks? Or link layer attachment? --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 16:09:44 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 QAA24775 for ; Mon, 16 Feb 2004 16:09:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspzQ-0006Qq-6u for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 16:09:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GL9G0l024718 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 16:09:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspzQ-0006Qb-1g for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 16:09:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24655 for ; Mon, 16 Feb 2004 16:09:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspzO-0007Bz-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 16:09:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspxN-0006n9-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 16:07:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AspvJ-0006Td-01 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 16:05:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aspfs-0003RF-EG for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 15:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aspfp-0004LB-RU; Mon, 16 Feb 2004 15:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aspf2-0004HU-RJ for mip6@optimus.ietf.org; Mon, 16 Feb 2004 15:48:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21459 for ; Mon, 16 Feb 2004 15:48:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aspf1-0003ap-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:48:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspdO-0003IL-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:46:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AspcH-00035L-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:45:22 -0500 Received: from fep02-0.kolumbus.fi ([193.229.0.44] helo=fep02-app.kolumbus.fi) by mx2.foretec.com with esmtp (Exim 4.24) id 1AspcC-0003Mf-1Q for mip6@ietf.org; Mon, 16 Feb 2004 15:45:16 -0500 Received: from kolumbus.fi ([62.248.154.14]) by fep02-app.kolumbus.fi with ESMTP id <20040216204507.KSTA1464.fep02-app.kolumbus.fi@kolumbus.fi> for ; Mon, 16 Feb 2004 22:45:07 +0200 Message-ID: <40312B60.50203@kolumbus.fi> Date: Mon, 16 Feb 2004 22:43:12 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Subject: Re: [Mip6] Re: rr weaknesses? References: <200402161111.i1GBBOSj095378@givry.rennes.enst-bretagne.fr> In-Reply-To: <200402161111.i1GBBOSj095378@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Thanks for the responses! Let me explain a little bit why initiated this thread. I was not asking for the known limits of RR. We all remember them pretty well. The most typical case is being on the path between the home agent and the correspondent node; if you are there, you don't even need to eavesdrop any of the messages as you can just initiate the procedure by yourself. The discussion on specific stronger methods is interesting -- and we should continue that discussion. We know for a fact that there are stronger methods. At least HIP and CGA can do better; it will be interesting to figure out if there are more. There is also probably methods that are equally secure but better in some other respect, such as efficiency. And methods methods that are less secure but even better again in some other way so that the end result makes sense. And then there are methods that are just no good at all ;-) Now we are getting nearer to what originally intended to ask. A year... two ago we held a BoF on alternate RO security mechanisms. If I remember correctly, most people said that their primary goal was not to increase the security of RR, but to improve its effiency. Does this still hold, or do people feel that they also need to address the security aspects? Tentative answer: it seems that optimization is still the main issue, but there is also interest for improved security? I also wanted to ask whether there was some specific new vulnerability that I had not heard. Apparently, this is not the case, if I understood the replies correctly? Finally a suggestion for the folks who responded that there are some security issues that they care about. Would you consider writing them in a draft or paper somewhere, preferrably comparing the issues with existing issues that mitms on the path can cause? We do have the old design papers, but they basically concluded that the issues are nearly identical. If people feel/know differently now, this would be good to get documented someplace. Any takers? --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 16:53:02 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 QAA29773 for ; Mon, 16 Feb 2004 16:53:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqfL-0001TQ-D0 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 16:52:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GLqZI0005658 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 16:52:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqfL-0001TB-8b for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 16:52:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29761 for ; Mon, 16 Feb 2004 16:52:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqfJ-0005Vr-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 16:52:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqeK-0005TQ-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 16:51:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asqdp-0005R9-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 16:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asqdp-0001Jt-QK; Mon, 16 Feb 2004 16:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqdO-0001It-AY for mip6@optimus.ietf.org; Mon, 16 Feb 2004 16:50:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29727 for ; Mon, 16 Feb 2004 16:50:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqdM-0005Qp-00 for mip6@ietf.org; Mon, 16 Feb 2004 16:50:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqcY-0005OQ-00 for mip6@ietf.org; Mon, 16 Feb 2004 16:49:42 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1Asqbe-0005Ki-00; Mon, 16 Feb 2004 16:48:47 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id A5C2A80019A; Mon, 16 Feb 2004 23:48:44 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1GLmi7Y023001; Mon, 16 Feb 2004 23:48:44 +0200 Received: from localhost (whaddad@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1GLmiIV022997; Mon, 16 Feb 2004 23:48:44 +0200 X-Authentication-Warning: rhea.tcs.hut.fi: whaddad owned process doing -bs Date: Mon, 16 Feb 2004 23:48:44 +0200 (EET) From: Wassim Haddad To: mip6@ietf.org Cc: mipshop@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Mip6] [Fwd: I-D ACTION:draft-haddad-mipv6-bub-01.txt] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 all, We have submitted a new updated version of the Binding Update Backhauling Proposal. It is available on: http://www.ietf.org/internet-drafts/draft-haddad-mipv6-bub-01.txt Abstract: Mobile IPv6 [1] defines two different modes to handle the mobility problem (i.e., mobile node moving accross different networks and changing its IP address). The two modes had been mainly designed for scenarios involving one mobile node and one static node (correspondent node). This document answers issues related to scenarios involving two mobile nodes (i.e., the correspodent node is also a mobile node). The document addresses also the double jumping problem where two mobile nodes move at the same time (i.e., switch to new subnets). The document proposes a new mode called 'BUB' (Binding Update Backhauling) allowing a more secure, reliable and optimized exchange of Binding Updates (BUs) between two mobile endpoints. Your comments are highly welcomed. Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 19:51:09 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 TAA16796 for ; Mon, 16 Feb 2004 19:51:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AstRg-000488-8u for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 19:50:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H0oerU015870 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 19:50:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AstRg-00047t-3s for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 19:50:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16771 for ; Mon, 16 Feb 2004 19:50:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AstRe-0002u5-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 19:50:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AstQm-0002qz-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 19:49:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AstQ8-0002na-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 19:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AstQ5-000407-S7; Mon, 16 Feb 2004 19:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AstPs-0003zd-5f for mip6@optimus.ietf.org; Mon, 16 Feb 2004 19:48:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16712 for ; Mon, 16 Feb 2004 19:48:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AstPq-0002mY-00 for mip6@ietf.org; Mon, 16 Feb 2004 19:48:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AstOx-0002j4-00 for mip6@ietf.org; Mon, 16 Feb 2004 19:47:52 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AstOc-0002es-00 for mip6@ietf.org; Mon, 16 Feb 2004 19:47:30 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGXJFW>; Mon, 16 Feb 2004 19:47:09 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042162@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Jari Arkko'" Cc: Francis Dupont , mip6@ietf.org Subject: RE: [Mip6] rr weaknesses? Date: Mon, 16 Feb 2004 19:46:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > > => The vulnerability of RR is simple: If an attacker > > gets hold of HOT and COT, it's over he can do whatever > > he wants. In other words if he can generate HOTI and COTI > > (which is easy) and be able to receive HOT and COT then > > he could do whatever he wants. This is more than what can be > > done today in v4 or v6 because the attacker can move and > > continue to steal/bomb for the lifetime of the token. > > True, but it would be useful to compare this to other attacks > that the same mitm can do. For instance, ARP spoofing, sending > TCP RSTs, messing with TCP ACKs, dropping packets. => Sure, I do think it is more vulnerable than the two cases you mention above because: a) it is not limited to the local link (the attacker need not be a neighbour) and b) the attacker can move and cause damage for some time (albeit less 10 min). Also the attack is not limited to certain types of upper layers like TCP-based attacks. So that's why it's more significant I think. Also we have a cure for the equivalent of ARP spoofing now in IPv6 (SEND). Having said all that, deep down ;), I don't take MiTM attacks too seriously unless MiTM is on the same link as the CN. So I think in theory RR is certainly weak, but in practice it's vulnerability is probably limited to attacks by neighbours on the CN's link. > > > => Efficiency is not an absolute thing. We need to know > > efficient for what? In scenarios where there is frequent > > mobility I don't think it's efficient in terms of air interface > > use or tolerable for most apps. > > I hate to press you for more information since I basically > agree that we need additional optimized mechanisms. But can > you say more about the specific requirements that you > are looking for "most apps"? Is there a paper somewhere that > has simulated mobility in some environment that shows how much > time you are spending on RR signaling vs. other movement related > tasks? How does home registration compare, what about IPv6 network > attachment? How about 1X/11i tasks? Or link layer attachment? => Wow :) I've seen a few papers, I'll try to find them and send them to you offline. In many cases each paper only addresses one part of the delay, unfortunately. But let me clarify what I was saying. I think that RR is not efficient for frequently moving MNs. This immediately excludes the 802.11 family from this discussion because, lets face it, how often are you going to handover with 802.11? I'm thinking more of cellular networks where every base station is a router (or even where a few base stations belong to the same router) and handover can be very frequent. Also, the signalling messages sizes can be come a major issue during handovers. In this case, it's almost unworkable to have to send RR signalling + HA signalling...etc Not to mention the effects of having dual stacked MNs. So in a way, it is inefficent independently of the application being used. This is of course in the context of frequent mobility. But In 802.11 type deployments, or for multihomed nodes it's probably not that bad. I think movement detection is the key issue for those types of access networks. Hope this helps. Hesham > > --Jari > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 20:31:07 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 UAA17991 for ; Mon, 16 Feb 2004 20:31:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asu4M-0006Pa-Pt for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 20:30:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H1Uc4J024645 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 20:30:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asu4M-0006PQ-Iu for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 20:30:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17964 for ; Mon, 16 Feb 2004 20:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asu4K-0004x8-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 20:30:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asu3P-0004u6-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 20:29:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asu2l-0004rh-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 20:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asu2m-0006Iv-U9; Mon, 16 Feb 2004 20:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asu2X-0006IZ-M1 for mip6@optimus.ietf.org; Mon, 16 Feb 2004 20:28:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17909 for ; Mon, 16 Feb 2004 20:28:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asu2V-0004rN-00 for mip6@ietf.org; Mon, 16 Feb 2004 20:28:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asu1a-0004oY-00 for mip6@ietf.org; Mon, 16 Feb 2004 20:27:47 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Asu1O-0004lR-00 for mip6@ietf.org; Mon, 16 Feb 2004 20:27:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1H1QlE07093; Mon, 16 Feb 2004 17:26:47 -0800 X-mProtect: <200402170126> Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzck1rp; Mon, 16 Feb 2004 17:26:46 PST Message-ID: <40316DCC.AE0A9348@iprg.nokia.com> Date: Mon, 16 Feb 2004 17:26:36 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Soliman Hesham CC: "'Jari Arkko'" , Francis Dupont , mip6@ietf.org Subject: Re: [Mip6] rr weaknesses? References: <9E3BA3946476AD4EB94672712B12A85F042162@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > => Wow :) I've seen a few papers, I'll try to find them and > send them to you offline. In many cases each paper only > addresses one part of the delay, unfortunately. But let me > clarify what I was saying. I think that RR is not efficient for > frequently moving MNs. This immediately excludes > It would be good to consolidate the current understanding on this topic. Could you post a pointer the references ? It would be useful for Mobopts as well. One could also look at the effect of RR, alongside its frequency, on applications. I hope someone will simulate various scenarios! > the 802.11 family from this discussion because, lets face it, > how often are you going to handover with 802.11? I'm thinking > In some cases (e.g., campus WLAN networks), it could be as often as when someone leaves a building for another! -Rajeev > more of cellular networks where every base station is a router > (or even where a few base stations belong to the same router) > and handover can be very frequent. Also, the signalling messages > sizes can be come a major issue during handovers. In this case, > it's almost unworkable to have to send RR signalling + HA signalling...etc > Not to mention the effects of having dual stacked MNs. > > So in a way, it is inefficent independently of the application > being used. This is of course in the context of frequent > mobility. But In 802.11 type deployments, or for multihomed > nodes it's probably not that bad. I think movement detection > is the key issue for those types of access networks. > > Hope this helps. > > Hesham > > > > > --Jari > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 20:34:09 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 UAA18108 for ; Mon, 16 Feb 2004 20:34:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asu7J-0006Wr-7X for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 20:33:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H1XfAw025083 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 20:33:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asu7J-0006WR-1Q for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 20:33:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18094 for ; Mon, 16 Feb 2004 20:33:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asu7G-00058k-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 20:33:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asu6N-00055y-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 20:32:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asu5f-000538-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 20:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asu5h-0006Qq-DC; Mon, 16 Feb 2004 20:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asu5S-0006QX-2i for mip6@optimus.ietf.org; Mon, 16 Feb 2004 20:31:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18017 for ; Mon, 16 Feb 2004 20:31:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asu5P-000527-00 for mip6@ietf.org; Mon, 16 Feb 2004 20:31:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asu4R-0004yI-00 for mip6@ietf.org; Mon, 16 Feb 2004 20:30:44 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Asu3g-0004rp-00 for mip6@ietf.org; Mon, 16 Feb 2004 20:29:56 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGXJKS>; Mon, 16 Feb 2004 20:29:39 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042165@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Rajeev Koodli'" Cc: "'Jari Arkko'" , Francis Dupont , mip6@ietf.org Subject: RE: [Mip6] rr weaknesses? Date: Mon, 16 Feb 2004 20:29:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > > > > => Wow :) I've seen a few papers, I'll try to find them and > > send them to you offline. In many cases each paper only > > addresses one part of the delay, unfortunately. But let me > > clarify what I was saying. I think that RR is not efficient for > > frequently moving MNs. This immediately excludes > > > > It would be good to consolidate the current understanding on > this topic. Could you post a pointer the references ? It would be > useful for Mobopts as well. => ok, I'll go through what I have. > > One could also look at the effect of RR, alongside its frequency, > on applications. I hope someone will simulate various scenarios! > > > > the 802.11 family from this discussion because, lets face it, > > how often are you going to handover with 802.11? I'm thinking > > > > In some cases (e.g., campus WLAN networks), it could be as > often as when someone leaves a building for another! => Yes but I'm not counting the number of handovers for all devices. I'm counting the frequency of handovers for one device. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 21:30:15 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 VAA21167 for ; Mon, 16 Feb 2004 21:30:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asuzc-0004lt-5j for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 21:29:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H2TmhR018335 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 21:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asuzb-0004le-Ub for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 21:29:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21154 for ; Mon, 16 Feb 2004 21:29:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsuzZ-0002B4-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 21:29:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asuyk-00027U-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 21:28:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asuxs-00022J-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 21:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asuxt-0004cc-4s; Mon, 16 Feb 2004 21:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asuxe-0004bz-GJ for mip6@optimus.ietf.org; Mon, 16 Feb 2004 21:27:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21016 for ; Mon, 16 Feb 2004 21:27:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asuxb-0001zY-00 for mip6@ietf.org; Mon, 16 Feb 2004 21:27:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asuwe-0001tN-00 for mip6@ietf.org; Mon, 16 Feb 2004 21:26:45 -0500 Received: from simmts6.bellnexxia.net ([206.47.199.164] helo=simmts6-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 1Asuvp-0001iy-00 for mip6@ietf.org; Mon, 16 Feb 2004 21:25:53 -0500 Received: from Toronto-HSE-ppp3862974.sympatico.ca ([67.70.29.235]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040217022522.FTLL9336.simmts6-srv.bellnexxia.net@Toronto-HSE-ppp3862974.sympatico.ca> for ; Mon, 16 Feb 2004 21:25:22 -0500 From: Wassim Haddad To: mip6 Content-Type: text/plain Message-Id: <1076984723.5886.20.camel@Atlantis> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Feb 2004 21:25:24 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Optimizing Mobile IPv6 (OMIPv6) Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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, An updated version of the OMIPv6 proposal is available on: http://www.ietf.org/internet-drafts/draft-haddad-mipv6-omipv6-01.txt Abstract: Mobile IPv6 protocol introduced the route optimization mode to allow a direct exchange of data packets between the mobile node (MN) and the correspondent node (CN). This memo is a proposal to optimize the Mobile IPv6 solution, by reducing the handoff latency and the number of signaling messages. Your comments are welcomed. Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 23:20:26 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 XAA25434 for ; Mon, 16 Feb 2004 23:20:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aswi9-0002gE-FI for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 23:19:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H4JrQg010295 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 23:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aswi8-0002fx-B4 for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 23:19:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25402 for ; Mon, 16 Feb 2004 23:19:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aswi6-00026a-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 23:19:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AswhB-00023M-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 23:18:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AswgO-0001zj-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 23:18:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AswgM-0002Qc-9B; Mon, 16 Feb 2004 23:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmSt-00083Z-VA for mip6@optimus.ietf.org; Mon, 16 Feb 2004 12:23:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06734 for ; Mon, 16 Feb 2004 12:23:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsmSs-0002cW-00 for mip6@ietf.org; Mon, 16 Feb 2004 12:23:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsmRu-0002ZZ-00 for mip6@ietf.org; Mon, 16 Feb 2004 12:22:32 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx with esmtp (Exim 4.12) id 1AsmR5-0002Wl-00 for mip6@ietf.org; Mon, 16 Feb 2004 12:21:35 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id i1GHLTPt001354 for ; Tue, 17 Feb 2004 02:21:29 +0900 (JST) Received: from cysols.com (w-zoe.priv.cysol.co.jp [192.168.0.199]) by aso.priv.cysol.co.jp (8.12.9/8.12.7) with ESMTP id i1GHLRxK023917 for ; Tue, 17 Feb 2004 02:21:29 +0900 (JST) Message-ID: <4030FC09.3090706@cysols.com> Date: Tue, 17 Feb 2004 02:21:13 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: mip6@ietf.org X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------030008050200080909090703" Subject: [Mip6] [Fwd: I-D submission] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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. --------------030008050200080909090703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D submission Date: Mon, 16 Feb 2004 22:07:49 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. To: internet-drafts@ietf.org CC: Sri Gundavelli , Ken Nagami , KOIDE Kazuhide , Glenn References: <4.3.2.7.2.20040129111245.037b2830@mira-sjcm-3.cisco.com> <401A53A4.80505@cysols.com> <401AEB1D.7050002@cysols.com> <6.0.0.20.2.20040202110039.04899dc0@gw.inetcore.com> <402F117B.4060207@cysols.com> <40302F5C.838F254D@cisco.com> Hi, Attached please find the Internet-draft draft-ietf-mip6-mipv6-mib-01.txt This is a work of the ietf-mip6-wg. I will appreciate it very much if you can kindly post the draft to the archives. Thanks and Cheers Glenn --------------030008050200080909090703 Content-Type: text/plain; name="MIPv6MIB07.out" Content-Disposition: inline; filename="MIPv6MIB07.out" Content-Transfer-Encoding: 7bit Network Working Group Glenn M. Keeni INTERNET-DRAFT Cyber Solutions Inc. Expires: August 15, 2004 Kazuhide Koide Network Working Group Tohoku University Kenichi Nagami INTEC NetCore Inc. Sri Gundavelli Cisco Systems Inc. February 16, 2004 The Mobile IPv6 MIB 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. This Internet-Draft will expire on August 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB), the the Mobile-IPv6 MIB, for use with network management protocols Expires: August 15, 2004 [Page 1] Internet Draft February 16, 2004 in the Internet community. In particular, Mobile-IPv6 MIB will be used to monitor and control Mobile Node, Home Agent and Correspondent Node functions of an MIPv6 entity. Table of Contents 1. The Internet-Standard Management Framework .................... 3 2. Overview ...................................................... 3 3. Mobile IPv6 Monitoring and Control Requirements ............... 4 4. MIB Design .................................................... 5 5. The Mobile-IPv6 MIB ........................................... 7 6. Intellectual Property .........................................39 7. Acknowledgments ...............................................39 References ........................................................40 Security Considerations ...........................................42 Authors' Addresses ................................................44 Full Copyright Statement ..........................................45 Expires: August 15, 2004 [Page 2] Internet Draft February 16, 2004 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview 2.1 The Mobile IPv6 Protocol entities. Mobile IPv6 (mipv6) [MIPv6] specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. An entity which implements the mipv6 protocol is an mipv6 entity. There are three types of entities envisaged by the mipv6 protocol. mobile node (MN): A node that can change its point of attachment from one link to another, while still being reachable via its home address. correspondent node (CN): A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary. [Note that a corespondent node does not necessarily require mipv6 support.] home agent (HA): A router on a mobile node's home link with which the mobile node has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link destined to the mobile node's home address, encapsulates them, and routes them to the mobile node's registered care-of address. This document defines the managed objects that will be required to monitor and control mipv6 entities. Expires: August 15, 2004 [Page 3] Internet Draft February 16, 2004 2.2 Terminology. The terminolgy used in this document is consistent with the definitions used in Mobile IPv6 protocol specification[MIPv6]. 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 BCP 14, RFC 2119 [RFC2119]. 3. Mobile IPv6 Monitoring and Control Requirements For managing a MIPv6 entity it is necessary to monitor the following o capabilities of MIPv6 entities o traffic due to MIPv6 o binding related statistics (at HA, CN, MN ) o binding details (at HA, CN) o history of binding updates (at HA, CN, MN) The MIPv6 protocol document stipulates that several MIPv6 related parameters should be manually configurable. The MIPv6 MIB should define managed objects that can be used to configure the related parameters. Expires: August 15, 2004 [Page 4] Internet Draft February 16, 2004 4. MIB Design. The basic principle has been to keep the MIB as simple as possible and at the same time to make it effective enough so that the essential needs of monitoring and control are met. It is envisaged that wherever possible existing MIBS will be used (e.g. IPSec MIB, Neighbour Discovery MIB, Tunnel MIB..) for monitor and control of MIPv6 entities. The MIPv6MIB comprises of following sets of groups - mipv6IP: a generic group containing objects that are common to all the mobile IPv6 entities. - mipv6HA: this group models the Home Agent service. It comprises of objects specific to the services and associated advertisement parameters offerred by the Home Agent on each of its links. It also contains objects pertaining to the maintenance of the Home Agent list on each of the links on which the service is offered. - mipv6MN: this group models the Mobile Node service. It comprises of objects specific to the Dynamic Home Agent discovery function and related parameters. It also contains objects that record the movement of the mobile node. - mipv6CN: models the Correspondent Node and is primarily scoped to its participation in the Return Routability procedure for achieving. Route Optimization triggered by the mobile node. - mipv6Notifications: defines the set of notifications that will be used to asynchronously monitor the mobile IPv6 entities. The tables contained in the above groups are as follows- mipv6BindingCacheTable : contains the BindingCache. mipv6BindingHistoryTable : the history of the Bindings. mipv6NodeTrafficTable : the mobile node-wise traffic counters. mipv6MnBLTable : contains information about the registration requests sent by the mobile node and the corresponding results. mipv6CnCounterTable : contains the mobile node-wise registration statistics. haAdvConfTable : contains the configurable advertisement parameters for all the interfaces on which the which the home agent service is advertised. haCounterTable : contains registration statistics for all mobile nodes registered Expires: August 15, 2004 [Page 5] Internet Draft February 16, 2004 with the home agent. haListTable : contains the list of all routers that are acting as home agents on each of the interfaces on which the home agent service is offered by this router. Expires: August 15, 2004 [Page 6] Internet Draft February 16, 2004 5. The Mobile-IPv6 MIB. MOBILEIPV6-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, experimental, Unsigned32, Integer32, Gauge32, OBJECT-TYPE, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- SnmpAdminString -- FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB ipv6IfIndex FROM IPV6-MIB ; mipv6MIB MODULE-IDENTITY LAST-UPDATED "200310210000Z" -- 21th October, 2003 ORGANIZATION "IETF mip6 Working Group" CONTACT-INFO " Glenn Mansfield Keeni Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 E-mail: glenn@cysols.com Kenichi Nagami Postal: INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo, 135-0075 Japan Tel: +81-3-5665-5069 E-mail: nagami@inetcore.com Postal: Kazuhide Koide Tohoku University Katahira Campus Sendai Japan Expires: August 15, 2004 [Page 7] Internet Draft February 16, 2004 Tel: +81-22-217-5454 E-mail: koide@shiratori.riec.tohoku.ac.jp Sri Gundavelli Postal: Cisco Systems 170 W.Tasman Drive, San Jose, CA 95134 USA Tel: +1-408-527-6109 Email: sgundave@cisco.com Support Group E-mail: mip6@ietf.org" DESCRIPTION " The MIB for monitoring Mobile-IPv6 entities. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC xxxx; see the RFC itself for full legal notices. " -- RFC Ed.: replace xxxx with actual RFC number & remove this note REVISION "200310210000Z" -- 21th October, 2003 DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { experimental 999 } -- will be assigned by IANA -- The major groups mipv6Notifications OBJECT IDENTIFIER ::= { mipv6MIB 0 } mipv6Objects OBJECT IDENTIFIER ::= { mipv6MIB 1 } mipv6Conformance OBJECT IDENTIFIER ::= { mipv6MIB 2 } mipv6Core OBJECT IDENTIFIER ::= { mipv6Objects 1 } mipv6MN OBJECT IDENTIFIER ::= { mipv6Objects 2 } mipv6CN OBJECT IDENTIFIER ::= { mipv6Objects 3 } mipv6HA OBJECT IDENTIFIER ::= { mipv6Objects 4 } -- The sub groups mipv6System OBJECT IDENTIFIER ::= { mipv6Core 1 } mipv6Bindings OBJECT IDENTIFIER ::= { mipv6Core 2 } mipv6Stats OBJECT IDENTIFIER ::= { mipv6Core 3 } Expires: August 15, 2004 [Page 8] Internet Draft February 16, 2004 mipv6MNSystem OBJECT IDENTIFIER ::= { mipv6MN 1 } mipv6MNDiscovery OBJECT IDENTIFIER ::= { mipv6MN 2 } mipv6MNRegistration OBJECT IDENTIFIER ::= { mipv6MN 3 } mipv6CNSystem OBJECT IDENTIFIER ::= { mipv6CN 1 } mipv6CNStats OBJECT IDENTIFIER ::= { mipv6CN 2 } mipv6HAAdvertisement OBJECT IDENTIFIER ::= { mipv6HA 1 } mipv6HAStats OBJECT IDENTIFIER ::= { mipv6HA 2 } -- Textual Conventions Mipv6ServiceDeniedCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of the status field in the Binding Ack message when the binding update was rejected. " SYNTAX BITS { reasonUnspecified (1), -- (Code 128), admProhibited (2), -- (Code 129), insufficientResource (3), -- (Code 130), homeRegistrationNotSupported (4), -- (Code 131), notHomeSubnet (5), -- (Code 132), notHomeAgentForThisMobileNode (6), -- (Code 133), duplicateAddressDetectionFailed (7), -- (Code 134), sequenceNumberOutOfWindow (8), -- (Code 135), expiredHomeNonceIndex (9), -- (Code 136), expiredCareofNonceIndex (10), -- (Code 137), expiredNonces (11), -- (Code 138), registrationTypeChangeDisallowed(12) -- (Code 139) } mipv6Entities OBJECT-TYPE SYNTAX BITS { mobileNode (0), homeAgent (1), correspondentNode (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes which Mobile IP entities are supported by this managed entity. The entity may support more than one Mobile IP entities. For example, the entity supports both Mobile Node (MN) and Home Agent (HA). Therefore, bit 0 and bit 1 are set to 1 Expires: August 15, 2004 [Page 9] Internet Draft February 16, 2004 for this object." ::= { mipv6System 1 } mipv6Enable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the Mobile IP protocol should be enabled for the managed entity. If it is disabled, the entity should disable both agent discovery and registration functions." ::= { mipv6System 2 } mipv6BindingCacheSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether binding cache is supported. " ::= { mipv6System 3 } -- mipv6BindingCache mipv6BindingCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF Mipv6BindingCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing BindingCache." ::= { mipv6Bindings 1 } mipv6BindingCacheEntry OBJECT-TYPE SYNTAX Mipv6BindingCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The details of a particular Binding." INDEX { mipv6BindingHomeAddressType, mipv6BindingHomeAddress } ::= { mipv6BindingCacheTable 1 } Mipv6BindingCacheEntry ::= SEQUENCE { mipv6BindingHomeAddressType InetAddressType, mipv6BindingHomeAddress InetAddress, mipv6BindingCOAType InetAddressType, Expires: August 15, 2004 [Page 10] Internet Draft February 16, 2004 mipv6BindingCOA InetAddress, mipv6BindingMaxSeq Unsigned32, mipv6BindingTimeGranted Unsigned32, mipv6BindingTimeCreated TimeStamp, mipv6BindingTimeRemaining Gauge32 } mipv6BindingHomeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the mipv6BindingHomeAddress that follows. " ::= { mipv6BindingCacheEntry 1 } mipv6BindingHomeAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Mobile node's home address. " ::= { mipv6BindingCacheEntry 2 } mipv6BindingCOAType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The InetAddressType of the mipv6BindingCOA that follows. " ::= { mipv6BindingCacheEntry 3 } mipv6BindingCOA OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Mobile node's care-of-address. One mobile node can have multiple bindings with different care-of-addresses." ::= { mipv6BindingCacheEntry 4 } mipv6BindingMaxSeq OBJECT-TYPE SYNTAX Unsigned32 Expires: August 15, 2004 [Page 11] Internet Draft February 16, 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of the Sequence Number field sent in previous Binding Updates to this node. " ::= { mipv6BindingCacheEntry 5 } mipv6BindingTimeGranted OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime in seconds granted to the mobile node for this registration." ::= { mipv6BindingCacheEntry 6 } mipv6BindingTimeCreated OBJECT-TYPE SYNTAX TimeStamp UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The time when this binding cache entry was created by registering the binding. " ::= { mipv6BindingCacheEntry 7 } mipv6BindingTimeRemaining OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime remaining for this entry. " ::= { mipv6BindingCacheEntry 8 } -- mipv6BindingHistory -- This table records the history of the Bindings. The size of the -- will be left to implementors. mipv6BindingHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF Mipv6BindingHistoryEntry MAX-ACCESS not-accessible STATUS current Expires: August 15, 2004 [Page 12] Internet Draft February 16, 2004 DESCRIPTION "A table containing history of the bindings. " ::= { mipv6Bindings 2 } mipv6BindingHistoryEntry OBJECT-TYPE SYNTAX Mipv6BindingHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The record of a binding ." INDEX { mipv6BindingHstHomeAddressType, mipv6BindingHstHomeAddress , mipv6BindingHstIndex} ::= { mipv6BindingHistoryTable 1 } Mipv6BindingHistoryEntry ::= SEQUENCE { mipv6BindingHstHomeAddressType InetAddressType, mipv6BindingHstHomeAddress InetAddress, mipv6BindingHstCOAType InetAddressType, mipv6BindingHstCOA InetAddress, mipv6BindingHstIndex Unsigned32, mipv6BindingHstTimeStamp TimeStamp } mipv6BindingHstHomeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the mipv6BindingHomeAddress that follows. " ::= { mipv6BindingHistoryEntry 1 } mipv6BindingHstHomeAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Mobile node's home (IP) address. " ::= { mipv6BindingHistoryEntry 2 } mipv6BindingHstCOAType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only Expires: August 15, 2004 [Page 13] Internet Draft February 16, 2004 STATUS current DESCRIPTION "The InetAddressType of the mipv6BindingCOA that follows. " ::= { mipv6BindingHistoryEntry 3 } mipv6BindingHstCOA OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Mobile node's care-of-address. One mobile node can have multiple bindings with different care-of-addresses." ::= { mipv6BindingHistoryEntry 4 } mipv6BindingHstIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index to uniquely identify this record along with the Mobile nodes HomeAddress type and HomeAddress. It should be monotonically increasing. And may wrap after reaching its max value." ::= { mipv6BindingHistoryEntry 5 } mipv6BindingHstTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp when the binding was registered." ::= { mipv6BindingHistoryEntry 6 } -- mipv6MNSystem Group mipv6MnState OBJECT-TYPE SYNTAX INTEGER { home(1), registered(2), pending(3), isolated(4), unknown(5) } MAX-ACCESS read-only STATUS current DESCRIPTION Expires: August 15, 2004 [Page 14] Internet Draft February 16, 2004 "Indicates mobile node's state of Mobile IP: home, -- MN is connected to home network. registered, -- MN is on a foreign network and has registered with the Home agent pending, -- MN has sent registration request -- and is waiting for the reply isolated, -- MN is isolated from network unknown -- MN can not determine its state." ::= { mipv6MNSystem 1 } mipv6MnHomeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The InetAddressType of the mipv6MnHomeAddress that follows. " ::= { mipv6MNSystem 2 } -- Specify the default value mipv6MnHomeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An IP address that is assigned for an extended period of time to the mobile node. It remains unchanged regardless of the mobile node's current point of attachment. If mobile node doesn't have home address assigned yet then this object will take the default value." ::= { mipv6MNSystem 3 } -- This needs to be in a history table too. mipv6MnRecentAdvReceived OBJECT IDENTIFIER ::= { mipv6MNDiscovery 1 } mipv6MnAdvSourceAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The InetAddressType of the mipv6MnAdvSourceAddress that follows. " ::= { mipv6MnRecentAdvReceived 1 } Expires: August 15, 2004 [Page 15] Internet Draft February 16, 2004 mipv6MnAdvSourceAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The source IP address of the most recently received Router Advertisement. This address could be the address of a home agent or a foreign router." ::= { mipv6MnRecentAdvReceived 2 } mipv6MnAdvMaxAdvLifetime OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum length of time that the Advertisement is considered valid in the absence of further Advertisements." REFERENCE "AdvertisementLifeTime in RFC1256." ::= { mipv6MnRecentAdvReceived 3 } mipv6MnAdvTimeReceived OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the most recently received advertisement was received." ::= { mipv6MnRecentAdvReceived 4 } -- mipv6TrafficCounters mipv6TotalTraffic OBJECT IDENTIFIER ::= { mipv6Stats 1 } mipv6InOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The mipv6 Octets received by the mipv6 entity. " ::= { mipv6TotalTraffic 1 } mipv6InPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Expires: August 15, 2004 [Page 16] Internet Draft February 16, 2004 STATUS current DESCRIPTION "The mipv6 Pkts received by the mipv6 entity. " ::= { mipv6TotalTraffic 2 } mipv6OutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of mipv6 Octets sent by the mipv6 entity. " ::= { mipv6TotalTraffic 3 } mipv6OutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of mipv6 Pkts sent by the mipv6 entity. " ::= { mipv6TotalTraffic 4 } -- mipv6NodeTrafficCounters mipv6NodeTrafficTable OBJECT-TYPE SYNTAX SEQUENCE OF Mipv6NodeTrafficEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Traffic counters per mobile node." ::= { mipv6Stats 2 } mipv6NodeTrafficEntry OBJECT-TYPE SYNTAX Mipv6NodeTrafficEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The traffic counters for a mobile node." INDEX { mipv6BindingHomeAddressType, mipv6BindingHomeAddress } ::= { mipv6NodeTrafficTable 1 } Mipv6NodeTrafficEntry ::= SEQUENCE { mipv6NodeInOctets Counter32, -- mipv6NodeHCInOctets Counter64, mipv6NodeInPkts Counter32, Expires: August 15, 2004 [Page 17] Internet Draft February 16, 2004 -- mipv6NodeHCInPkts Counter64, mipv6NodeOutOctets Counter32, -- mipv6NodeHCOutOctets Counter64, mipv6NodeOutPkts Counter32 -- mipv6NodeHCOutPkts Counter64 } mipv6NodeInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The mipv6 octets received for the mobile node. " ::= { mipv6NodeTrafficEntry 1 } mipv6NodeInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The mipv6 packets received for the mobile node. " ::= { mipv6NodeTrafficEntry 2 } mipv6NodeOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of mipv6Node octets sent to the mobile node. " ::= { mipv6NodeTrafficEntry 3 } mipv6NodeOutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of mipv6 packets sent to the mobile node. " ::= { mipv6NodeTrafficEntry 4 } -- Mobile Node Discovery Group Counter mipv6MnSolicitationsSent OBJECT-TYPE SYNTAX Counter32 Expires: August 15, 2004 [Page 18] Internet Draft February 16, 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of solicitations sent by the mobile node." ::= { mipv6MNDiscovery 2 } mipv6MnAdvertisementsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of advertisements received by the mobile node." ::= { mipv6MNDiscovery 3 } mipv6MnAdvertisementsIgnored OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of advertisements discarded by the validity check. " ::= { mipv6MNDiscovery 4 } mipv6MnMoveFromFNToFN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times that the mobile node has decided to move from one foreign network to another foreign network." ::= { mipv6MNDiscovery 5 } mipv6MnMoveFromFNToHN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times that the mobile node has decided to move from a foreign network to its home network." ::= { mipv6MNDiscovery 6 } mipv6MnAgentRebootsDectected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Expires: August 15, 2004 [Page 19] Internet Draft February 16, 2004 STATUS current DESCRIPTION "Total number of home agent reboots detected by the mobile node through sequence number of the advertisement." ::= { mipv6MNDiscovery 7 } -- Mobile Node Registration Group -- Registration table of mobile node mipv6MnBLTable OBJECT-TYPE SYNTAX SEQUENCE OF MnRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about the mobile node's attempted registration(s). The mobile node updates this table based upon Registration Requests sent and Registration Replies received in response to these requests. Certain variables within this table are also updated if when Registration Requests are retransmitted." ::= { mipv6MNRegistration 1 } mipv6MnBLEntry OBJECT-TYPE SYNTAX MnRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about one registration attempt." INDEX { mipv6MnBLNodeAddressType, mipv6MnBLNodeAddress, mipv6MnBLCOAType, mipv6MnBLCOA } ::= { mipv6MnBLTable 1 } MnRegistrationEntry ::= SEQUENCE { mipv6MnBLNodeAddressType InetAddressType, mipv6MnBLNodeAddress InetAddress, mipv6MnBLCOAType InetAddressType, mipv6MnBLCOA InetAddress, mipv6MnBLMaxSeq Unsigned32, mipv6MnBLLifeTime Unsigned32, mipv6MnBLLifeTimeRemaining Gauge32, mipv6MnBLTimeSent TimeStamp, mipv6MnBLIsAccepted TruthValue, -- mipv6MnBLSendState Integer32, Expires: August 15, 2004 [Page 20] Internet Draft February 16, 2004 mipv6MnBLRetransmissions Integer32, mipv6MnBLRetransTime TimeStamp } mipv6MnBLNodeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the mipv6MnBLNodeAddress that follows. " ::= { mipv6MnBLEntry 1 } mipv6MnBLNodeAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address of the agent as used in the destination IP address of the Registration Request. The agent may be a home agent or a correspondent node." ::= { mipv6MnBLEntry 2 } mipv6MnBLCOAType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the mipv6MnBLCOA that follows. " ::= { mipv6MnBLEntry 3 } mipv6MnBLCOA OBJECT-TYPE SYNTAX InetAddress (SIZE (16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Care-of address for the registration." ::= { mipv6MnBLEntry 4 } mipv6MnBLMaxSeq OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of the Sequence Number field sent in previous Binding Updates to this destination. Expires: August 15, 2004 [Page 21] Internet Draft February 16, 2004 " ::= { mipv6MnBLEntry 5 } mipv6MnBLLifeTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "If the registration is pending, then this is the lifetime requested by the mobile node (in seconds). If the registration has been accepted, then this is the lifetime actually granted by the home agent or the correspondent node in the reply." ::= { mipv6MnBLEntry 6 } mipv6MnBLLifeTimeRemaining OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds remaining until this registration expires. It has the same initial value as mipv6MnBLTimeRequested and is only valid if mipv6MnBLIsAccepted is TRUE." ::= { mipv6MnBLEntry 7 } mipv6MnBLTimeSent OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the last (re-)transmission occurred." ::= { mipv6MnBLEntry 8 } mipv6MnBLIsAccepted OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "true(1) if the mobile node has received a binding acknowledgment indicating that service has been accepted (status code 0 or 1); false(2) otherwise. false(2) implies that the registration is still pending." ::= { mipv6MnBLEntry 9 } mipv6MnBLRetransmissions OBJECT-TYPE Expires: August 15, 2004 [Page 22] Internet Draft February 16, 2004 SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Binding Update retransmissions sent. " ::= { mipv6MnBLEntry 10 } mipv6MnBLRetransTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the last Binding Update retransmission was sent. " ::= { mipv6MnBLEntry 11 } -- Mobile Node Registration Group Counters mipv6MnRegnCounters OBJECT IDENTIFIER ::= { mipv6MNRegistration 2 } mipv6MnControlMessagePackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of of MobileIPv6 control messages sent by the Mobile Node. These are the IPv6 datagrams with a mobility header." ::= { mipv6MnRegnCounters 1 } mipv6MnBUsToHA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Updates sent to Home Agent. " ::= { mipv6MnRegnCounters 2 } mipv6MnBUAcksFromHA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of valid binding acknowledgements received from all the home agents. " Expires: August 15, 2004 [Page 23] Internet Draft February 16, 2004 ::= { mipv6MnRegnCounters 3 } mipv6MnBUToCN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Updates sent to all the Correspondent Nodes by the MN. " ::= { mipv6MnRegnCounters 4 } mipv6MnBUAcksFromCN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of valid Binding Update ACKs received from all the Correspondent Nodes. " ::= { mipv6MnRegnCounters 5 } mipv6MnBindingErrorsFromCN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Error messages received by MN from CN. " ::= { mipv6MnRegnCounters 6 } mipv6MnICMPErrorReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ICMP Error messages received by MN from CN. " ::= { mipv6MnRegnCounters 7 } mipv6MnBRRequestsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Refresh requests Expires: August 15, 2004 [Page 24] Internet Draft February 16, 2004 received by the mobile node from all CNs." ::= { mipv6MnRegnCounters 8 } mipv6MnBLDynAgDiscoverySent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ICMP Dynamic Home Agent Address Discovery Request sent to the Mobile IPv6 Home-Agents anycast address. " ::= { mipv6MnRegnCounters 9 } -- Registration Group counters used for CN mipv6CNGlobalStats OBJECT IDENTIFIER ::= { mipv6CNStats 1 } mipv6CnBUAccepted OBJECT-TYPE -- (Code 0) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Total number of Binding Updates Accepted." ::= { mipv6CNGlobalStats 1 } mipv6CnReasonUnspecified OBJECT-TYPE -- (Code 128) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding update requests denied by the correspondent node with reason unspecified (Code 128)." ::= { mipv6CNGlobalStats 2 } mipv6CnAdmProhibited OBJECT-TYPE -- (Code 129) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding update requests denied by correspondent node with reason 'administratively prohibited' (Code 129)." ::= { mipv6CNGlobalStats 3 } mipv6CnInsufficientResource OBJECT-TYPE -- (Code 130) SYNTAX Counter32 MAX-ACCESS read-only Expires: August 15, 2004 [Page 25] Internet Draft February 16, 2004 STATUS current DESCRIPTION "Total number of binding update requests denied by the correspondent node with reason 'insufficient resources' (Code 130)." ::= { mipv6CNGlobalStats 4 } mipv6CnHomeRegnNotSupported OBJECT-TYPE -- (Code 131) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding update requests denied by correspondent node wth reason 'mobile node failed authentication' (Code 131)." ::= { mipv6CNGlobalStats 5 } mipv6CnNotHomeSubnet OBJECT-TYPE -- (Code 132) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding update requests denied by correspondent node wth reason 'not home subnet' (Code 132). " ::= { mipv6CNGlobalStats 6 } mipv6CnNotHomeAgentForThisMN OBJECT-TYPE -- (Code 133) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of registration requests denied by correspondent node wth reason 'not home home agent for this MN' (Code 133). " ::= { mipv6CNGlobalStats 7 } mipv6CnSeqNumberOutOfWindow OBJECT-TYPE -- (Code 135) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by correspondent node with message 'sequence number out of window' (Code 135). " ::= { mipv6CNGlobalStats 8 } Expires: August 15, 2004 [Page 26] Internet Draft February 16, 2004 mipv6CnExpiredHomeNonceIndex OBJECT-TYPE -- (Code 136) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Registration Requests denied by correspondent due to unrecognized/expired Home Nonce Index value (Code 136). " ::= { mipv6CNGlobalStats 9 } mipv6CnExpiredCareOfNonceIndex OBJECT-TYPE -- (Code 137) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Registration Requests denied by correspondent node due to unrecognized/expired Care-of Nonce Index (Code 137). " ::= { mipv6CNGlobalStats 10 } mipv6CnExpiredNonce OBJECT-TYPE -- (Code 138) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Registration Requests denied by correspondent node due to unrecognized/expired Home Nonce Index and Care-of Nonce Index values (Code 138). " ::= { mipv6CNGlobalStats 11 } mipv6CnRegTypeChangeDisallowed OBJECT-TYPE -- (Code 139) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Registration Requests denied by correspondent node due to mismatch of the home registration flag in the existing binding and the value of the Home Registration (H) bit in the Binding Update (Code 139). " ::= { mipv6CNGlobalStats 12 } mipv6CnCareOfTestInitReceived OBJECT-TYPE SYNTAX Counter32 Expires: August 15, 2004 [Page 27] Internet Draft February 16, 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of CoTIs received." ::= { mipv6CNGlobalStats 13 } mipv6CnHomeTestInitReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of HoTIs received." ::= { mipv6CNGlobalStats 14 } mipv6CnCareOfTestSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of CoTs sent." ::= { mipv6CNGlobalStats 15 } mipv6CnHomeTestSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of HoT sent." ::= { mipv6CNGlobalStats 16 } mipv6CnBUReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding updates received." ::= { mipv6CNGlobalStats 17 } mipv6CnBURepliesSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of acknowledgments sent for binding updates received. " ::= { mipv6CNGlobalStats 18 } mipv6CnBRSent OBJECT-TYPE Expires: August 15, 2004 [Page 28] Internet Draft February 16, 2004 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding refresh requests sent " ::= { mipv6CNGlobalStats 19 } mipv6CnBindingErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding errors sent. " ::= { mipv6CNGlobalStats 20 } -- The Correspondent Node statistics by mobile node mipv6CnCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF CnCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing CN counters." ::= { mipv6CNStats 2 } mipv6CnCounterEntry OBJECT-TYPE SYNTAX CnCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of CN counters for a mobile node." INDEX { mipv6BindingHomeAddressType, mipv6BindingHomeAddress } ::= { mipv6CnCounterTable 1 } CnCounterEntry ::= SEQUENCE { mipv6CnServiceRequestsAccepted Counter32, mipv6CnServiceRequestsDenied Counter32, mipv6CnOverallServiceTime Counter32, mipv6CnRecentServiceAcceptedTime TimeStamp, mipv6CnRecentServiceDeniedTime TimeStamp, mipv6CnRecentServiceDeniedCode Mipv6ServiceDeniedCode } Expires: August 15, 2004 [Page 29] Internet Draft February 16, 2004 mipv6CnServiceRequestsAccepted OBJECT-TYPE --(Code 0+1) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding acknowledgment messages sent with accepted by correspondent node. Values of the status field of the binding acknowledgment message is less than 128. " ::= { mipv6CnCounterEntry 1 } mipv6CnServiceRequestsDenied OBJECT-TYPE -- (Code 128 through Code 159) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding service request refusal messages sent by corespondent node. Values of the Status field of the binding acknowledgment message is equal to or greater than 128. " ::= { mipv6CnCounterEntry 2 } mipv6CnOverallServiceTime OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Overall service time (in seconds) that has accumulated for the mobile node. " ::= { mipv6CnCounterEntry 3 } mipv6CnRecentServiceAcceptedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the most recent binding update message was accepted by the corespondent node. " ::= { mipv6CnCounterEntry 4 } mipv6CnRecentServiceDeniedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current Expires: August 15, 2004 [Page 30] Internet Draft February 16, 2004 DESCRIPTION "The time at which the most recent binding update message was denied by the corespondent node. " ::= { mipv6CnCounterEntry 5 } mipv6CnRecentServiceDeniedCode OBJECT-TYPE SYNTAX Mipv6ServiceDeniedCode MAX-ACCESS read-only STATUS current DESCRIPTION "The Code indicating the reason why the most recent Registration Request for this mobile node was rejected by the corespondent node. " ::= { mipv6CnCounterEntry 6 } -- Home agent group haAdvertisementsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of valid Router Advertisements received with the Home Agent (H) bit set on all the links on which it is serving as a Home Agent. " ::= { mipv6HAAdvertisement 1 } haAdvConfTable OBJECT-TYPE SYNTAX SEQUENCE OF HaAdvertConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing configurable advertisement parameters for all interfaces on which the which the home agent service is advertised. " ::= { mipv6HAAdvertisement 2 } haAdvConfEntry OBJECT-TYPE SYNTAX HaAdvertConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires: August 15, 2004 [Page 31] Internet Draft February 16, 2004 "Advertisement parameters for one advertisement interface. " INDEX { ipv6IfIndex } ::= { haAdvConfTable 1 } HaAdvertConfEntry ::= SEQUENCE { haAdvLifetime Integer32, haAdvPreference Integer32 } haAdvLifetime OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The lifetime value for the home agent to be used in the Router advertisements. " ::= { haAdvConfEntry 1 } haAdvPreference OBJECT-TYPE SYNTAX Integer32 (4..1800) MAX-ACCESS read-create STATUS current DESCRIPTION "The preference value for the home agent to be used in the Router advertisements. Higher value denotes greater preferable. " ::= { haAdvConfEntry 2 } -- Registration Group counters HA mipv6HAGlobalStats OBJECT IDENTIFIER ::= { mipv6HAStats 1 } mipv6HaBUAccepted OBJECT-TYPE -- (Code 0) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Total number of Binding Updates accepted by this HA." ::= { mipv6HAGlobalStats 1 } mipv6HaPrefDiscoverReqd OBJECT-TYPE -- (Code 1) SYNTAX Counter32 MAX-ACCESS read-only Expires: August 15, 2004 [Page 32] Internet Draft February 16, 2004 STATUS current DESCRIPTION "The total number of 'prefix discovery necessary' messages sent by the HA." ::= { mipv6HAGlobalStats 2 } mipv6HaReasonUnspecified OBJECT-TYPE -- (Code 128) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- reason unspecified (Code 128)." ::= { mipv6HAGlobalStats 3 } mipv6HaAdmProhibited OBJECT-TYPE -- (Code 129) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- administratively prohibited (Code 129)." ::= { mipv6HAGlobalStats 4 } mipv6HaInsufficientResource OBJECT-TYPE -- (Code 130) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- insufficient resources (Code 130)." ::= { mipv6HAGlobalStats 5 } mipv6HaHomeRegnNotSupported OBJECT-TYPE -- (Code 131) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- mobile node failed authentication (Code 131)." ::= { mipv6HAGlobalStats 6 } mipv6HaNotHomeSubnet OBJECT-TYPE -- (Code 132) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " The total number of Registration Requests denied by Expires: August 15, 2004 [Page 33] Internet Draft February 16, 2004 home agent with message 'not home subnet' (Code 132)." ::= { mipv6HAGlobalStats 7 } mipv6HaNotHomeAgentForThisMN OBJECT-TYPE -- (Code 133) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent with message 'not home agent for this MN' (Code 133)" ::= { mipv6HAGlobalStats 8 } mipv6HaDupAddrDetectionFailed OBJECT-TYPE -- (Code 134) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent with message 'duplicate address detection failed' (Code 134)" ::= { mipv6HAGlobalStats 9 } mipv6HaSeqNumberOutOfWindow OBJECT-TYPE -- (Code 135) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent with message 'sequence number out of window' (Code 135) " ::= { mipv6HAGlobalStats 10 } mipv6HaExpiredHomeNonceIndex OBJECT-TYPE -- (Code 136) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " The total number of Registration Requests denied by home agent due to unrecognized/expired Home Nonce Index value (Code 137). " ::= { mipv6HAGlobalStats 11 } mipv6HaExpiredCareOfNonceIndex OBJECT-TYPE -- (Code 137) SYNTAX Counter32 MAX-ACCESS read-only STATUS current Expires: August 15, 2004 [Page 34] Internet Draft February 16, 2004 DESCRIPTION " The total number of Registration Requests denied by home agent due to unrecognized/expired Care-of Nonce Index (Code 137). " ::= { mipv6HAGlobalStats 12 } mipv6HaExpiredNonce OBJECT-TYPE -- (Code 138) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " The total number of Registration Requests denied by home agent due to unrecognized/expired Home Nonce Index and Care-of Nonce Index values (Code 138). " ::= { mipv6HAGlobalStats 13 } mipv6HaRegTypeChangeDisallowed OBJECT-TYPE -- (Code 139) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " The total number of Registration Requests denied by home agent due to mismatch of the home registration flag in the existing binding and the value of the Home Registration (H) bit in the Binding Update. " ::= { mipv6HAGlobalStats 14 } mipv6HaHomeTestInitReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Home Test Init messages received by the home agent." ::= { mipv6HAGlobalStats 15 } mipv6HaHomeTestSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Home Test messages sent by the home agent." ::= { mipv6HAGlobalStats 16 } Expires: August 15, 2004 [Page 35] Internet Draft February 16, 2004 mipv6HaBUReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total nubmer of binding updates received by the home agent. " ::= { mipv6HAGlobalStats 17 } mipv6HaBURepliesSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding acknowledgements sent by the home agent. " ::= { mipv6HAGlobalStats 18 } mipv6HaBRAdviceSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of binding acknowledgements sent by the home agent with binding refresh advice option on. " ::= { mipv6HAGlobalStats 19 } mipv6HaEncapsUnavailable OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by the home agent -- requested encapsulation unavailable (Code 72)." ::= { mipv6HAGlobalStats 20 } -- Home agent registration Counters per node haCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF HaCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires: August 15, 2004 [Page 36] Internet Draft February 16, 2004 "A table containing registration statistics for all mobile nodes registered with the home agent. " ::= { mipv6HAStats 2 } haCounterEntry OBJECT-TYPE SYNTAX HaCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "HA registration statistics for one mobile node." INDEX { mipv6BindingHomeAddressType, mipv6BindingHomeAddress } ::= { haCounterTable 1 } HaCounterEntry ::= SEQUENCE { haServiceRequestsAccepted Counter32, haServiceRequestsDenied Counter32, haOverallServiceTime Counter32, haRecentServiceAcceptedTime TimeStamp, haRecentServiceDeniedTime TimeStamp, haRecentServiceDeniedCode Mipv6ServiceDeniedCode } haServiceRequestsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of service requests for the mobile node accepted by the home agent. " ::= { haCounterEntry 1 } haServiceRequestsDenied OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of service requests for the mobile node denied by the home agent. " ::= { haCounterEntry 2 } haOverallServiceTime OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" Expires: August 15, 2004 [Page 37] Internet Draft February 16, 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "Overall service time (in seconds) that has accumulated for the mobile node since the home agent last rebooted. " ::= { haCounterEntry 3 } haRecentServiceAcceptedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the most recent Registration Request was accepted by the home agent for this mobile node." ::= { haCounterEntry 4 } haRecentServiceDeniedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the most recent Registration Request was denied by the home agent for this mobile node." ::= { haCounterEntry 5 } haRecentServiceDeniedCode OBJECT-TYPE SYNTAX Mipv6ServiceDeniedCode MAX-ACCESS read-only STATUS current DESCRIPTION "The Code indicating the reason why the most recent Registration Request for this mobile node was rejected by the home agent." ::= { haCounterEntry 6 } -- Home Agent List Table haListTable OBJECT-TYPE SYNTAX SEQUENCE OF HaListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the list of all routers that are acting as home agents on each of the interfaces Expires: August 15, 2004 [Page 38] Internet Draft February 16, 2004 on which the home agent service is offered by this router. " ::= { mipv6HAAdvertisement 3 } haListEntry OBJECT-TYPE SYNTAX HaListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a router offering the home agent service. " INDEX { ipv6IfIndex, haLinkLocalAddressType, haLinkLocalAddressType } ::= { haListTable 1 } HaListEntry ::= SEQUENCE { haLinkLocalAddressType InetAddressType, haLinkLocalAddress InetAddress, haGlobalAddressType InetAddressType, haGlobalAddress InetAddress, haPreference Integer32, haRecvLifeTime Gauge32, haRecvTimeStamp TimeStamp } haLinkLocalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type for the link-local address of the home agent that follows. " ::= { haListEntry 1 } haLinkLocalAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The link-local address of the home agent. " ::= { haListEntry 2 } haGlobalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only Expires: August 15, 2004 [Page 39] Internet Draft February 16, 2004 STATUS current DESCRIPTION "The address type for the global address of the home agent that follows. " ::= { haListEntry 3 } haGlobalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The global address of the home agent. " ::= { haListEntry 4 } haPreference OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The preference value of this home agent. Higher values indicate a more preferable home agent. The preference value is obtained from the preference field of the received Router Advertisement. " ::= { haListEntry 5 } haRecvLifeTime OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime for this home agent. " ::= { haListEntry 6 } haRecvTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the HA advertisement was received. " ::= { haListEntry 7 } -- Expires: August 15, 2004 [Page 40] Internet Draft February 16, 2004 -- Notifications -- mipv6HANotifications OBJECT IDENTIFIER ::= { mipv6Notifications 0 } mipv6MNRegistered NOTIFICATION-TYPE OBJECTS { mipv6BindingTimeCreated, mipv6BindingCOAType, mipv6BindingCOA } STATUS current DESCRIPTION "This notification is sent every time a mobile node registers with the home agent for the first time. Notifications will not be sent for subsequent updates and/or refreshes. " ::= { mipv6HANotifications 1 } mipv6MNMoved NOTIFICATION-TYPE OBJECTS { mipv6BindingTimeCreated, mipv6BindingCOAType, mipv6BindingCOA } STATUS current DESCRIPTION "This notification is sent every time a mobile node sends a binding update with a new Care-of address. Notifications will not be sent for subsequent updates and/or refreshes for the same Care-of address. " ::= { mipv6HANotifications 2 } mipv6MNBindingExpiredAtHA NOTIFICATION-TYPE OBJECTS { mipv6BindingTimeCreated, mipv6BindingCOAType, mipv6BindingCOA } STATUS current DESCRIPTION "This notification is sent when a binding for the mobile node at the Home Agent expires and no timely binding updates are received. " Expires: August 15, 2004 [Page 41] Internet Draft February 16, 2004 ::= { mipv6HANotifications 3 } mipv6MNBindingExpiredAtCN NOTIFICATION-TYPE OBJECTS { mipv6BindingTimeCreated, mipv6BindingCOAType, mipv6BindingCOA } STATUS current DESCRIPTION "This notification is sent when a binding for the mobile node at the CN expires and no timely binding updates are received. " ::= { mipv6HANotifications 4 } Expires: August 15, 2004 [Page 42] Internet Draft February 16, 2004 -- Conformance information mipv6Groups OBJECT IDENTIFIER ::= { mipv6Conformance 1 } mipv6Compliances OBJECT IDENTIFIER ::= { mipv6Conformance 2 } -- Units of conformance mipv6SystemGroup OBJECT-GROUP OBJECTS { mipv6Entities, mipv6Enable, mipv6BindingCacheSupported } STATUS current DESCRIPTION " A collection of objects for basic mipv6 monitoring." ::= { mipv6Groups 1 } mipv6BindingCacheGroup OBJECT-GROUP OBJECTS { -- mipv6BindingHomeAddressType, -- mipv6BindingHomeAddress, mipv6BindingCOAType, mipv6BindingCOA, mipv6BindingMaxSeq, mipv6BindingTimeGranted, mipv6BindingTimeCreated, mipv6BindingTimeRemaining } STATUS current DESCRIPTION " A collection of objects for monitoring the Binding cache. " ::= { mipv6Groups 2 } mipv6BindingHstGroup OBJECT-GROUP OBJECTS { -- mipv6BindingHstHomeAddressType, -- mipv6BindingHstHomeAddress, mipv6BindingHstCOAType, mipv6BindingHstCOA, -- mipv6BindingHstIndex, mipv6BindingHstTimeStamp } STATUS current DESCRIPTION " A collection of objects for monitoring the binding history. This can be used to monitor Expires: August 15, 2004 [Page 43] Internet Draft February 16, 2004 the movement of the mobile node. " ::= { mipv6Groups 3 } mipv6TotalTrafficGroup OBJECT-GROUP OBJECTS { mipv6InOctets, mipv6InPkts, mipv6OutOctets, mipv6OutPkts } STATUS current DESCRIPTION " A collection of objects for monitoring the total MIPv6 traffic. " ::= { mipv6Groups 4 } mipv6NodeTrafficGroup OBJECT-GROUP OBJECTS { mipv6NodeInOctets, mipv6NodeInPkts, mipv6NodeOutOctets, mipv6NodeOutPkts } STATUS current DESCRIPTION " A collection of objects for monitoring the MIPv6 traffic due to a mobile node. " ::= { mipv6Groups 5 } mipv6MNSystemGroup OBJECT-GROUP OBJECTS { mipv6MnState, mipv6MnHomeAddressType, mipv6MnHomeAddress } STATUS current DESCRIPTION " A collection of objects for basic monitoring of the Mobile Node. " ::= { mipv6Groups 6 } mipv6MNDiscoveryGroup OBJECT-GROUP OBJECTS { mipv6MnAdvSourceAddress, Expires: August 15, 2004 [Page 44] Internet Draft February 16, 2004 mipv6MnAdvSourceAddressType, mipv6MnAdvMaxAdvLifetime, mipv6MnAdvTimeReceived, mipv6MnSolicitationsSent, mipv6MnAdvertisementsReceived, mipv6MnAdvertisementsIgnored, mipv6MnMoveFromFNToFN, mipv6MnMoveFromFNToHN, mipv6MnAgentRebootsDectected } STATUS current DESCRIPTION " A collection of objects for monitoring the advertisement related info on the Mobile Node. " ::= { mipv6Groups 7 } mipv6MNRegistrationGroup OBJECT-GROUP OBJECTS { -- mipv6MnBLNodeAddressType, -- mipv6MnBLNodeAddress, -- mipv6MnBLCOAType, -- mipv6MnBLCOA, mipv6MnBLMaxSeq, mipv6MnBLLifeTime, mipv6MnBLLifeTimeRemaining, mipv6MnBLTimeSent, mipv6MnBLIsAccepted, mipv6MnBLRetransmissions, mipv6MnBLRetransTime, mipv6MnControlMessagePackets, mipv6MnBUsToHA, mipv6MnBUAcksFromHA, mipv6MnBUToCN, mipv6MnBUAcksFromCN, mipv6MnBindingErrorsFromCN, mipv6MnICMPErrorReceived, mipv6MnBRRequestsReceived, mipv6MnBLDynAgDiscoverySent } STATUS current DESCRIPTION " A collection of objects for monitoring the registration statistics for the mobile node. " ::= { mipv6Groups 8 } Expires: August 15, 2004 [Page 45] Internet Draft February 16, 2004 mipv6CNStatsGroup OBJECT-GROUP OBJECTS { mipv6CnServiceRequestsAccepted, mipv6CnServiceRequestsDenied, mipv6CnOverallServiceTime, mipv6CnRecentServiceAcceptedTime, mipv6CnRecentServiceDeniedTime, mipv6CnRecentServiceDeniedCode } STATUS current DESCRIPTION " A collection of objects for monitoring the control messages and corresponding statistics for each mobile node communicating with the Correspondent Node. " ::= { mipv6Groups 9 } mipv6HASystemGroup OBJECT-GROUP OBJECTS { haAdvertisementsReceived, haAdvLifetime, haAdvPreference } STATUS current DESCRIPTION " A collection of objects for monitoring the Advertisement related parameters and statistics for the Home Agent. " ::= { mipv6Groups 10 } mipv6HAListGroup OBJECT-GROUP OBJECTS { -- haLinkLocalAddressType, -- haLinkLocalAddress, haGlobalAddressType, haGlobalAddress, haPreference, haRecvLifeTime, haRecvTimeStamp } STATUS current DESCRIPTION " A collection of objects for monitoring Expires: August 15, 2004 [Page 46] Internet Draft February 16, 2004 Home Agent list on the Home Agent. " ::= { mipv6Groups 11 } mipv6HAStatsGroup OBJECT-GROUP OBJECTS { haServiceRequestsAccepted, haServiceRequestsDenied, haOverallServiceTime, haRecentServiceAcceptedTime, haRecentServiceDeniedTime, haRecentServiceDeniedCode } STATUS current DESCRIPTION " A collection of objects for monitoring registration related statistics on the Home Agent. " ::= { mipv6Groups 12 } mipv6CNGlobalStatsGroup OBJECT-GROUP OBJECTS { mipv6CnBUAccepted, mipv6CnReasonUnspecified, mipv6CnAdmProhibited, mipv6CnInsufficientResource, mipv6CnHomeRegnNotSupported, mipv6CnNotHomeSubnet, mipv6CnNotHomeAgentForThisMN, mipv6CnSeqNumberOutOfWindow, mipv6CnExpiredHomeNonceIndex, mipv6CnExpiredCareOfNonceIndex, mipv6CnExpiredNonce, mipv6CnRegTypeChangeDisallowed, mipv6CnCareOfTestInitReceived, mipv6CnHomeTestInitReceived, mipv6CnCareOfTestSent, mipv6CnHomeTestSent, mipv6CnBUReceived, mipv6CnBURepliesSent, mipv6CnBRSent, mipv6CnBindingErrors } STATUS current DESCRIPTION " A collection of objects for monitoring advertisement and registration statistics on Expires: August 15, 2004 [Page 47] Internet Draft February 16, 2004 a Correspondent node. " ::= { mipv6Groups 13 } mipv6HAGlobalStatsGroup OBJECT-GROUP OBJECTS { mipv6HaBUAccepted, mipv6HaPrefDiscoverReqd, mipv6HaReasonUnspecified, mipv6HaAdmProhibited, mipv6HaInsufficientResource, mipv6HaHomeRegnNotSupported, mipv6HaNotHomeSubnet, mipv6HaNotHomeAgentForThisMN, mipv6HaDupAddrDetectionFailed, mipv6HaSeqNumberOutOfWindow, mipv6HaExpiredHomeNonceIndex, mipv6HaExpiredCareOfNonceIndex, mipv6HaExpiredNonce, mipv6HaRegTypeChangeDisallowed, mipv6HaHomeTestInitReceived, mipv6HaHomeTestSent, mipv6HaBUReceived, mipv6HaBURepliesSent, mipv6HaBRAdviceSent, mipv6HaEncapsUnavailable } STATUS current DESCRIPTION " A collection of objects for monitoring advertisement and registration statistics on a Home Agent. " ::= { mipv6Groups 14 } mipv6NotificationGroup OBJECT-GROUP OBJECTS { mipv6MNRegistered, mipv6MNMoved, mipv6MNBindingExpiredAtHA, mipv6MNBindingExpiredAtCN } STATUS current DESCRIPTION " A collection of objects for sending Notifications from a Home Agent or Correspondent Node to the Manager about the status of a mobile node. Expires: August 15, 2004 [Page 48] Internet Draft February 16, 2004 " ::= { mipv6Groups 15 } -- Compliance statements mipv6CoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB." MODULE -- this module MANDATORY-GROUPS { mipv6SystemGroup } ::= { mipv6Compliances 1 } mipv6Compliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB and support monitoring of the BindingCache and the Total Traffic. " MODULE -- this module MANDATORY-GROUPS { mipv6SystemGroup, mipv6BindingCacheGroup, mipv6TotalTrafficGroup } ::= { mipv6Compliances 2 } mipv6Compliance3 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB and support monitoring of the BindingCache, the Binding History, the total traffic and the mobile node-wide traffic. " MODULE -- this module MANDATORY-GROUPS { mipv6SystemGroup, mipv6BindingCacheGroup, mipv6BindingHstGroup, mipv6TotalTrafficGroup, mipv6NodeTrafficGroup } ::= { mipv6Compliances 3 } mipv6MNCoreCompliance MODULE-COMPLIANCE STATUS current Expires: August 15, 2004 [Page 49] Internet Draft February 16, 2004 DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB and support monitoring of the basic Mobile Node functionality. " MODULE -- this module MANDATORY-GROUPS { mipv6MNSystemGroup } ::= { mipv6Compliances 4 } mipv6MNCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB and support monitoring of the Mobile Node functionality specifically the Discovery and Registration related statistics, " MODULE -- this module MANDATORY-GROUPS { mipv6MNSystemGroup, mipv6MNDiscoveryGroup, mipv6MNRegistrationGroup } ::= { mipv6Compliances 5 } mipv6CNCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB and support monitoring of the basic Correspondent Node functionality. " MODULE -- this module MANDATORY-GROUPS { mipv6CNGlobalStatsGroup } ::= { mipv6Compliances 6 } mipv6CNCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB and support monitoring of the basic Correspondent Node functionality. " Expires: August 15, 2004 [Page 50] Internet Draft February 16, 2004 MODULE -- this module MANDATORY-GROUPS { mipv6CNGlobalStatsGroup, mipv6CNStatsGroup } ::= { mipv6Compliances 7 } mipv6HACoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB and support monitoring of the basic Home Agent functionality. " MODULE -- this module MANDATORY-GROUPS { mipv6HASystemGroup } ::= { mipv6Compliances 8 } mipv6HACompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB and support monitoring of the Home Agent functionality specifically the Home Agent list and the Home Agent Registration related statistics, " MODULE -- this module MANDATORY-GROUPS { mipv6HASystemGroup, mipv6HAListGroup, mipv6HAStatsGroup, mipv6HAGlobalStatsGroup } ::= { mipv6Compliances 9 } mipv6NotificationCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the MOBILE-IPV6-MIB and support Notification from HA or CN to management stations about the mobile node status. " MODULE -- this module MANDATORY-GROUPS { mipv6NotificationGroup } ::= { mipv6Compliances 10 } Expires: August 15, 2004 [Page 51] Internet Draft February 16, 2004 END Expires: August 15, 2004 [Page 52] Internet Draft February 16, 2004 6. Intellectual Property 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. 7. Acknowledgments This draft is the product of discussions and deliberations carried out in the WIDE-netman group. Expires: August 15, 2004 [Page 53] Internet Draft February 16, 2004 References [Normative References] [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [MIPv6] Johnson, D., Perkins, C., Arkko J., "Mobility Support in IPv6" draft-ietf-mobileip-ipv6-24.txt, work in progress, June 30, 2003. [Informative References] [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for the Internet-Standard Management Framework", RFC 3410, Expires: August 15, 2004 [Page 54] Internet Draft February 16, 2004 December 2002. Expires: August 15, 2004 [Page 55] Internet Draft February 16, 2004 Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: mipv6Enable: This value of this object is used to enable or disable the mipv6 functionality on a mipv6 entity. Access to this MO may be abused to disrupt the mipv6 communication. haAdvLifetime: Access to this object may be abused to set the advertised lifetime to incorrect values. That will have an adverse impact on the mipv6 communication. haAdvPreference: Access to this object may be abused to force MNs into selecting the wrong HA. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: The address related objects in this MIB may be considered to be particularly sensitive and/or private. The care of address related objects reveal the location and movement of the mobile node. This information may be considered to be private and sensitive and must be carefully handled. mipv6BindingHstCOAType mipv6BindingHstCOA mipv6MnBLCOAType mipv6MnBLCOA The mobile node's home address and home agent related information may be considered to be sensitive too as these may provide clues to a malicious party on ways to disrupt the mobile nodes communication channels. mipv6BindingHstHomeAddressType, mipv6BindingHstHomeAddress, mipv6MnHomeAddressType, mipv6MnHomeAddress The Correspondent node's addresses related MOs will reveal the nodes with whom the MN is corresponding. This information may be considered private and sensitive. Expires: August 15, 2004 [Page 56] Internet Draft February 16, 2004 mipv6MnBLNodeAddressType, mipv6MnBLNodeAddress SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Expires: August 15, 2004 [Page 57] Internet Draft February 16, 2004 Authors' Addresses Glenn Mansfield Keeni Cyber Solutions Inc. 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-3204 Japan Phone: +81-22-303-4012 EMail: glenn@cysols.com Kenichi Nagami INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo, 135-0075 Japan Phone: +81-3-5665-5069 E-mail: nagami@inetcore.com Kazuhide Koide Tohoku University Katahira Campus Sendai Japan Phone: +81-22-217-5454 E-mail: koide@shiratori.riec.tohoku.ac.jp Sri Gundavelli Cisco Systems 170 W.Tasman Drive, San Jose, CA 95134 USA Phone: +1-408-527-6109 Email: sgundave@cisco.com Expires: August 15, 2004 [Page 58] Internet Draft February 16, 2004 Full Copyright statement "Copyright (C) The Internet Society (2003). 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 implmentation may be prepared, copied, published and distributed, in whole or in 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." Expires: August 15, 2004 [Page 59] --------------030008050200080909090703-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 16 23:20:28 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 XAA25451 for ; Mon, 16 Feb 2004 23:20:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aswi9-0002gU-Tr for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 23:20:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H4JrB5010312 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 23:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aswi9-0002gF-OW for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 23:19:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25406 for ; Mon, 16 Feb 2004 23:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aswi7-00026p-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 23:19:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AswhH-00023Y-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 23:19:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AswgO-0001zk-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 23:18:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AswgN-0002Qk-3V; Mon, 16 Feb 2004 23:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspoS-0004tz-2y for mip6@optimus.ietf.org; Mon, 16 Feb 2004 15:57:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23093 for ; Mon, 16 Feb 2004 15:57:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspoP-0005QY-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:57:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspnB-0005Cy-00 for mip6@ietf.org; Mon, 16 Feb 2004 15:56:38 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1Asplv-0004tl-00; Mon, 16 Feb 2004 15:55:19 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i1GKsfLc015087; Mon, 16 Feb 2004 14:54:41 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 14:50:25 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <151R69X4>; Mon, 16 Feb 2004 14:54:40 -0600 Received: from [142.133.72.37] (142.133.72.37 [142.133.72.37]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 17VGQ82H; Mon, 16 Feb 2004 15:54:44 -0500 From: Wassim Haddad Reply-To: Wassim.Haddad@ericsson.ca To: mip6 Cc: "mipshop@ietf.org" Content-Type: text/plain Organization: Ericsson Research Message-Id: <1076964933.3535.74.camel@ddgflw21> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Feb 2004 15:55:33 -0500 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Feb 2004 20:50:25.0078 (UTC) FILETIME=[8060E560:01C3F4CE] Content-Transfer-Encoding: 7bit Subject: [Mip6] [Fwd: I-D ACTION:draft-haddad-mipv6-bub-01.txt] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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, We have submitted a new updated version of the Binding Update Backhauling Proposal. It is available on: http://www.ietf.org/internet-drafts/draft-haddad-mipv6-bub-01.txt Abstract: Mobile IPv6 [1] defines two different modes to handle the mobility problem (i.e., mobile node moving accross different networks and changing its IP address). The two modes had been mainly designed for scenarios involving one mobile node and one static node (correspondent node). This document answers issues related to scenarios involving two mobile nodes (i.e., the correspodent node is also a mobile node). The document addresses also the double jumping problem where two mobile nodes move at the same time (i.e., switch to new subnets). The document proposes a new mode called 'BUB' (Binding Update Backhauling) allowing a more secure, reliable and optimized exchange of Binding Updates (BUs) between two mobile endpoints. Your comments are highly welcomed. Regards, Wassim H. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 00:17:20 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 AAA27043 for ; Tue, 17 Feb 2004 00:17:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsxbD-0005zS-VS for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 00:16:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H5GlA0023020 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 00:16:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsxbD-0005zD-NK for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 00:16:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27037 for ; Tue, 17 Feb 2004 00:16:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsxbB-0005J4-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 00:16:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsxaE-0005G7-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 00:15:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsxZW-0005Df-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 00:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsxZX-0005qM-1t; Tue, 17 Feb 2004 00:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsxZL-0005pK-M1 for mip6@optimus.ietf.org; Tue, 17 Feb 2004 00:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26991 for ; Tue, 17 Feb 2004 00:14:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsxZJ-0005Cg-00 for mip6@ietf.org; Tue, 17 Feb 2004 00:14:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsxYR-00059C-00 for mip6@ietf.org; Tue, 17 Feb 2004 00:13:55 -0500 Received: from s31xu4.systems.smu.edu ([129.119.70.133]) by ietf-mx with esmtp (Exim 4.12) id 1AsxXk-00055S-00 for mip6@ietf.org; Tue, 17 Feb 2004 00:13:12 -0500 Received: from SICLTPC1 ([129.119.251.236]) by s31xu4.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Feb 2004 23:13:06 -0600 Message-ID: <002701c3f514$985f7690$ecfb7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: Cc: , , "Hesham El-Rewini" , "Mohamed Khalil" , "Vijay Devarapalli" , "Ryuji Wakikawa" References: <005801c3f30c$44b42680$43fc7781@SICLTPC1> Subject: [Mip6] Problem Statement: Home Agent Reliability (new version) Date: Mon, 16 Feb 2004 23:11:47 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C3F4E2.4087BE50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 17 Feb 2004 05:13:07.0151 (UTC) FILETIME=[BA5FFDF0:01C3F514] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C3F4E2.4087BE50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Problem Statement: Home Agent Reliability Author(s) : J. Faizan Filename : draft-jfaizan-mipv6-ha-reliability-01.txt Pages : 12 Date : 2004-2-16 =09 In Mobile-IPv6, Mobile Node is dependent on a single Home Agent for=20 the seamless roaming over the Internet. Mobile-IPv6 also allows =20 deployment of multiple Home Agents on the subnet for providing=20 continuous service to Mobile Node in case of serving Home Agent=20 failure. But switching of service from the failed Home Agent to=20 another functional Home Agent on the Home Subnet is problematic and=20 the base Mobile-IPv6 specifications does not currently have well-described solutions. This document aims to describe and=20 illustrate these problems, and propose some guidelines for possible=20 solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-01= .txt ------=_NextPart_000_0022_01C3F4E2.4087BE50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A New Internet-Draft is available from the on-line Internet-Drafts=20 directories.

Title : Problem Statement: Home Agent=20 Reliability
Author(s)        =20         : J.=20 Faizan
Filename         =    =20     : draft-jfaizan-mipv6-ha-reliability-01.txt
Pages = :=20 12
Date : 2004-2-16

In Mobile-IPv6, Mobile Node is = dependent on a=20 single Home Agent for
the seamless roaming over the Internet. = Mobile-IPv6=20 also allows 
deployment of multiple Home Agents on the subnet = for=20 providing
continuous service to Mobile Node in case of serving Home = Agent=20
failure. But switching of service from the failed Home Agent to =
another=20 functional Home Agent on the Home Subnet is problematic and
the base = Mobile-IPv6 specifications does not currently have
well-described = solutions.=20 This document aims to describe and
illustrate these problems, and = propose=20 some guidelines for possible
solutions.

A URL for this = Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-= reliability-01.txt

------=_NextPart_000_0022_01C3F4E2.4087BE50-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 03:11:26 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 DAA15827 for ; Tue, 17 Feb 2004 03:11:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0Jn-0003Tt-1U for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 03:10:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H8AwKC013377 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 03:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0Jm-0003Tg-I9 for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 03:10:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15808 for ; Tue, 17 Feb 2004 03:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0Ji-00003h-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 03:10:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0Il-0007lr-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 03:09:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At0Hu-0007gB-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 03:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0Ht-0003ID-H7; Tue, 17 Feb 2004 03:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0Hk-0003Hx-Gd for mip6@optimus.ietf.org; Tue, 17 Feb 2004 03:08:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15756 for ; Tue, 17 Feb 2004 03:08:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0Hg-0007e9-00 for mip6@ietf.org; Tue, 17 Feb 2004 03:08:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0Gi-0007ao-00 for mip6@ietf.org; Tue, 17 Feb 2004 03:07:48 -0500 Received: from fep22-0.kolumbus.fi ([193.229.0.60] helo=fep22-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1At0Fk-0007XH-00 for mip6@ietf.org; Tue, 17 Feb 2004 03:06:49 -0500 Received: from kolumbus.fi ([62.248.154.14]) by fep22-app.kolumbus.fi with ESMTP id <20040217080648.QXIK3524.fep22-app.kolumbus.fi@kolumbus.fi>; Tue, 17 Feb 2004 10:06:48 +0200 Message-ID: <4031CB24.8090905@kolumbus.fi> Date: Tue, 17 Feb 2004 10:04:52 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: mip6@ietf.org Subject: Re: [Mip6] rr weaknesses? References: <9E3BA3946476AD4EB94672712B12A85F042162@ftmail.lab.flarion.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042162@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Soliman Hesham wrote: > Having said all that, deep down ;), I don't take MiTM > attacks too seriously unless MiTM is on the same link > as the CN. So I think in theory RR is certainly weak, > but in practice it's vulnerability is probably limited > to attacks by neighbours on the CN's link. This is roughly my feeling as well. And attacks by neighbors on the link are already pretty bad (even with SEND). > > True, but it would be useful to compare this to other attacks > > that the same mitm can do. For instance, ARP spoofing, sending > > TCP RSTs, messing with TCP ACKs, dropping packets. > > => Sure, I do think it is more vulnerable than the two > cases you mention above because: a) it is not limited > to the local link (the attacker need not be a neighbour) All the attacks that I listed are possible for the whole path, i.e. not just on the local link. > and b) the attacker can move and cause damage for some > time (albeit less 10 min). Also the attack is not All of the attacks I mentioned also cause a disruption that lasts longer than a single packet. Exactly how long... depends on the specific attack. > limited to certain types of upper layers like TCP-based Some attacks on plain IPv4/IPv6 are related to applications, but not all. ARP/ND, ICMP, just dropping packets, looking inside the packets, etc. Then we have a couple of interesting cases regarding the use of e2e security. When that is in place, be it RR/CGA/HIP, attackers can at most cause denial of service, not more. With IPsec e2e, presumably the RR signaling would be protected as well => no attack. With TLS e2e, RR would still be vulnerable, but as mentioned above the effect would be at most denial-of-service. TLS, however, is denial-of-service vulnerable in any case. > attacks. So that's why it's more significant I think. > Also we have a cure for the equivalent of ARP spoofing > now in IPv6 (SEND). In conclusion, I'd still like you or someone to write that paper that describes the issues and compares them to the issues with existing issues that mitms on the path can cause. I mean its easy for us to make short comments on the mailing list, but I think this matter is so important that it needs to be described well. And be reviewed! Don't get me wrong. I want to create new route optimization security mechanisms that are better than RR. But I just think there is a big difference in "nice to have" vs. "must have because of serious problems". Clearly we have seen and will see folks who claim the latter to market their method; it would be extremely useful to understand where we are in reality, however. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 05:27:24 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 FAA22211 for ; Tue, 17 Feb 2004 05:27:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At2RM-0005jo-Sy for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 05:26:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HAQuLv022056 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 05:26:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At2RM-0005jf-Bh for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 05:26:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22205 for ; Tue, 17 Feb 2004 05:26:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At2RJ-0003Xr-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 05:26:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At2QO-0003Vf-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 05:25:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At2PW-0003TP-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 05:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At2PW-0005d5-VI; Tue, 17 Feb 2004 05:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At2PQ-0005ce-Bp for mip6@optimus.ietf.org; Tue, 17 Feb 2004 05:24:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22175 for ; Tue, 17 Feb 2004 05:24:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At2PN-0003SZ-00 for mip6@ietf.org; Tue, 17 Feb 2004 05:24:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At2OO-0003QO-00 for mip6@ietf.org; Tue, 17 Feb 2004 05:23:53 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1At2NP-0003Lj-00 for mip6@ietf.org; Tue, 17 Feb 2004 05:22:52 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1HAMI817780; Tue, 17 Feb 2004 11:22:18 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1HAMISj099982; Tue, 17 Feb 2004 11:22:19 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402171022.i1HAMISj099982@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Soliman Hesham , mip6@ietf.org Subject: Re: [Mip6] rr weaknesses? In-reply-to: Your message of Tue, 17 Feb 2004 10:04:52 +0200. <4031CB24.8090905@kolumbus.fi> Date: Tue, 17 Feb 2004 11:22:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: This is roughly my feeling as well. And attacks by neighbors on the link are already pretty bad (even with SEND). => I agree, for instance a reflection attack works very well (no defense at all). Then we have a couple of interesting cases regarding the use of e2e security. When that is in place, be it RR/CGA/HIP, attackers can at most cause denial of service, not more. With IPsec e2e, presumably the RR signaling would be protected => I believe you'd like to mean RO signaling. as well => no attack. With TLS e2e, RR would still be vulnerable, but as mentioned above the effect would be at most denial-of-service. TLS, however, is denial-of-service vulnerable in any case. => I agree, and as the RO signaling is at the network layer IPsec is the solution of choice. Don't get me wrong. I want to create new route optimization security mechanisms that are better than RR. => IMHO we need stronger assumptions to do that. For instance (again) if strong authentication is available for MN and CN, IPsec is a solution. But I just think there is a big difference in "nice to have" vs. "must have because of serious problems". Clearly we have seen and will see folks who claim the latter to market their method; it would be extremely useful to understand where we are in reality, however. => I have a concern here: some documents or implementations can make "better" RO security mechanisms impossible to use. We have to be very careful as perhaps there are some such mechanisms not yet discovered/invented. Regards Francis.Dupont@enst-bretagne.fr PS: we should publish all the previous documents about the subject as information RFCs ASAP (i.e., put them in the RFC editor queue waiting for draft-24). _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 07:23:30 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 HAA25068 for ; Tue, 17 Feb 2004 07:23:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At4Fg-0003Xk-If for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 07:23:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HCN0ht013609 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 07:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At4Fg-0003XQ-AU for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 07:23:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25058 for ; Tue, 17 Feb 2004 07:22:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At4Ff-0001ui-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 07:22:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At4Eh-0001ry-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 07:22:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At4Do-0001pa-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 07:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At4Dm-0003Ps-1V; Tue, 17 Feb 2004 07:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At4Ct-0003OX-RM for mip6@optimus.ietf.org; Tue, 17 Feb 2004 07:20:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24999 for ; Tue, 17 Feb 2004 07:20:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At4Ct-0001mB-00 for mip6@ietf.org; Tue, 17 Feb 2004 07:20:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At4Bt-0001iN-00 for mip6@ietf.org; Tue, 17 Feb 2004 07:19:05 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1At4BC-0001cm-00 for mip6@ietf.org; Tue, 17 Feb 2004 07:18:22 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGXLF5>; Tue, 17 Feb 2004 07:18:04 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042167@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Jari Arkko'" Cc: mip6@ietf.org Subject: RE: [Mip6] rr weaknesses? Date: Tue, 17 Feb 2004 07:18:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > Then we have a couple of interesting cases regarding the > use of e2e security. When that is in place, be it RR/CGA/HIP, > attackers can at most cause denial of service, not more. > With IPsec e2e, presumably the RR signaling would be protected > as well => no attack. => Not sure about this statement, when you say e2e you mean MN - CN, right? In this case the RR signalling _may_ be protected if all traffic is protected. But if the protection does not cover all traffic then of course the CN - HA path will still be vulnerable even if the connections between the MN and CN are covered with IPsec. Of course RR + CGA is not vulnerable to that. With TLS e2e, RR would still be vulnerable, => Yes. > but as mentioned above the effect would be at most denial-of-service. > TLS, however, is denial-of-service vulnerable in any case. => Yes it's a DoS attack on IPsec/TLS protected traffic. But it's still another (new) DoS attack. > In conclusion, I'd still like you or someone to write that > paper that describes the issues and compares them to the > issues with existing issues that mitms on the path can > cause. I mean its easy for us to make short comments on > the mailing list, but I think this matter is so important > that it needs to be described well. And be reviewed! => I remember the DT wrote a long analysis on residual threat of RR. That might be a good start. I still have the text file you got rid of it ;) > Don't get me wrong. I want to create new route optimization > security mechanisms that are better than RR. But I just think > there is a big difference in "nice to have" vs. "must have > because of serious problems". Clearly we have seen and will > see folks who claim the latter to market their method; it > would be extremely useful to understand where we are in > reality, however. => I don't have a strong opinion on needing a new mechanism. I just think that it's cautious to have a more secure option in case we missed something or some attacks became worse than we expected. If that happens in future we might not have the time to standardise one immediately (IETF is not getting any faster!). But I know this is a very paranoid argument that might not find much support. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 07:34:32 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 HAA25402 for ; Tue, 17 Feb 2004 07:34:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At4QM-0004AI-Mz for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 07:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HCY2JT016004 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 07:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At4QM-0004A3-If for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 07:34:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25355 for ; Tue, 17 Feb 2004 07:34:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At4QL-0002YY-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 07:34:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At4PN-0002TP-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 07:33:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At4OP-0002Om-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 07:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At4OO-0003ny-ML; Tue, 17 Feb 2004 07:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At4Nc-0003mm-Ta for mip6@optimus.ietf.org; Tue, 17 Feb 2004 07:31:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25243 for ; Tue, 17 Feb 2004 07:31:11 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At4Nc-0002Ln-00 for mip6@ietf.org; Tue, 17 Feb 2004 07:31:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At4Md-0002HJ-00 for mip6@ietf.org; Tue, 17 Feb 2004 07:30:12 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1At4Lo-0002D5-00 for mip6@ietf.org; Tue, 17 Feb 2004 07:29:20 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HCTId20765 for ; Tue, 17 Feb 2004 14:29:18 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Feb 2004 14:29:18 +0200 Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 17 Feb 2004 06:29:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] rr weaknesses? Date: Tue, 17 Feb 2004 06:29:16 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DBE40@daebe007.americas.nokia.com> Thread-Topic: [Mip6] rr weaknesses? Thread-Index: AcP1UJ3xEIIALc8hQuasRgJyvO1f0QAAGKNQ To: , Cc: X-OriginalArrivalTime: 17 Feb 2004 12:29:17.0067 (UTC) FILETIME=[A8DC45B0:01C3F551] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Don't get me wrong. I want to create new route optimization > > security mechanisms that are better than RR. But I just think > > there is a big difference in "nice to have" vs. "must have > > because of serious problems". Clearly we have seen and will > > see folks who claim the latter to market their method; it > > would be extremely useful to understand where we are in > > reality, however. >=20 > =3D> I don't have a strong opinion on needing a new=20 > mechanism. I just think that it's cautious to have=20 > a more secure option in case we missed something=20 > or some attacks became worse than we expected. If that > happens in future we might not have the time to standardise > one immediately (IETF is not getting any faster!).=20 > But I know this is a very paranoid argument that might=20 > not find much support. I think this thread is based on paranoia. I think the MIPv6 design team ignored the threats and security issues with RR when this was work was done over a year ago. We seem to be revisiting the same issues. The security issues that are being discussed now are not new. These have been considered. More secure means of accomplishing RO should be considered in the WG for MIP6. But I would argue against dismissing RR as being insufficient at this time.=20 >=20 > Hesham >=20 -Raj >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 08:51:33 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 IAA27941 for ; Tue, 17 Feb 2004 08:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5cu-0000wT-Mu for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 08:51:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HDp4la003618 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 08:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5cu-0000wH-Fz for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 08:51:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27896 for ; Tue, 17 Feb 2004 08:51:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At5ct-00008M-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 08:51:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At5bu-00001k-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 08:50:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At5aw-0007jg-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 08:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5av-0000iG-Gk; Tue, 17 Feb 2004 08:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5a2-0000h1-7z for mip6@optimus.ietf.org; Tue, 17 Feb 2004 08:48:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27770 for ; Tue, 17 Feb 2004 08:48:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At5a0-0007ea-00 for mip6@ietf.org; Tue, 17 Feb 2004 08:48:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At5Z4-0007aZ-00 for mip6@ietf.org; Tue, 17 Feb 2004 08:47:07 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1At5YC-0007V6-00 for mip6@ietf.org; Tue, 17 Feb 2004 08:46:12 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1HDjbm31771; Tue, 17 Feb 2004 14:45:37 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1HDjbSj000697; Tue, 17 Feb 2004 14:45:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402171345.i1HDjbSj000697@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mark Doll cc: Jari Arkko , mip6@ietf.org Subject: Re: [Mip6] Re: review of draft-dupont-mipv6-3bombing-00.txt In-reply-to: Your message of Mon, 16 Feb 2004 17:02:04 +0100. <20040216170204.1ad84cc2@borg.ipv6.tm.uni-karlsruhe.de> Date: Tue, 17 Feb 2004 14:45:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: > => I have another simple suggestion: close the congestion window, > i.e., behave on hand-off of the peer as a packet was lost... This does not work for UDP streams. => it should work with congestion controlled streams. Thinking of TCP, I suppose some packets will always be lost during a handover---as long as we do not use something like an anticipated handover starting from the old care-of address with all its security implications. So TCP will go through slow start anyway. And beeing able to force TCP into slow start means that we intermix layers. Is this a good idea? (*) => if some packets will always be lost the answer is yes, if this assumption is false no, but in any case as the path has changed something should be done, i.e., upper layers should get the "hand-off" event. BTW in experiments I saw very different behaviors between TCP connections with different profiles (for instance telnet (interactive) and FTP (bulk transfer)) so IMHO it's worth our attention. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 08:58:34 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 IAA28365 for ; Tue, 17 Feb 2004 08:58:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5ji-0001Xr-FK for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 08:58:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HDw6mW005933 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 08:58:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5ji-0001Xc-A8 for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 08:58:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28343 for ; Tue, 17 Feb 2004 08:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At5jg-0000lS-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 08:58:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At5ig-0000ga-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 08:57:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At5hh-0000by-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 08:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5hi-0001Gv-9L; Tue, 17 Feb 2004 08:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5gq-0001Co-Bo for mip6@optimus.ietf.org; Tue, 17 Feb 2004 08:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28201 for ; Tue, 17 Feb 2004 08:55:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At5go-0000Xj-00 for mip6@ietf.org; Tue, 17 Feb 2004 08:55:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At5fx-0000TN-00 for mip6@ietf.org; Tue, 17 Feb 2004 08:54:13 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1At5fC-0000Js-00 for mip6@ietf.org; Tue, 17 Feb 2004 08:53:26 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1HDqpm32319; Tue, 17 Feb 2004 14:52:51 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1HDqpSj000735; Tue, 17 Feb 2004 14:52:52 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402171352.i1HDqpSj000735@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: Mark Doll , mip6@ietf.org Subject: Re: [Mip6] Re: review of draft-dupont-mipv6-3bombing-00.txt In-reply-to: Your message of Mon, 16 Feb 2004 11:41:05 PST. <40311CD1.7831B4A0@iprg.nokia.com> Date: Tue, 17 Feb 2004 14:52:51 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: I would also hope to avoid any TCP-specific solution. => but IMHO you believe in the usefulness of congestion control (:-). Regarding slow-start: => this was more a slow-restart. Mark Doll wrote: > Thinking of TCP, I suppose some packets will always be lost > during a handover This is not true. With a simple context transfer approach that includes redelivery of (approx. 2) redundantly buffered packets, we can get terrific performance for voice. With a few more buffered packets, probably video. => in this case you don't send a RR/RO signaling to the CN, i.e., I agree but your argument doesn't apply. There has been a lot of discussion about cross-layer design recently. I think it should be reframed as enabling one layer to acquire relevant information that _may_ be more efficiently provided by another layer. I think it's a much better way for sane and simple designs to result. => this has been more about layer 2 / layer 3. In the case we are talking about something should be done, perhaps not what I proposed in addition to limit the sending buffer... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 10:05:33 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 KAA01637 for ; Tue, 17 Feb 2004 10:05:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6mW-0001iD-M7 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 10:05:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HF53lc006476 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6mU-0001f0-Uu for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 10:05:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01498 for ; Tue, 17 Feb 2004 10:04:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6mS-0005ws-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 10:05:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6l4-0005j7-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 10:03:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At6jZ-0005U5-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 10:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6jY-00086o-Ls; Tue, 17 Feb 2004 10:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At6is-0007ar-Du for mip6@optimus.ietf.org; Tue, 17 Feb 2004 10:01:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01148 for ; Tue, 17 Feb 2004 10:01:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At6iq-0005R1-00 for mip6@ietf.org; Tue, 17 Feb 2004 10:01:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At6hy-0005MM-00 for mip6@ietf.org; Tue, 17 Feb 2004 10:00:23 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1At6hF-0005FG-00 for mip6@ietf.org; Tue, 17 Feb 2004 09:59:38 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1HEwtL04765; Tue, 17 Feb 2004 15:58:55 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1HEwtSj000899; Tue, 17 Feb 2004 15:58:55 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402171458.i1HEwtSj000899@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: mip6@ietf.org, James Kempf Subject: Re: [Mip6] bootstrap problem definition In-reply-to: Your message of Mon, 16 Feb 2004 12:20:33 +0200. <40309971.90903@kolumbus.fi> Date: Tue, 17 Feb 2004 15:58:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 I have many comments about your bootstrap I-D: - first the problems in the abstract and in the introduction are not the same: in the abstract the home environment is dynamic and the mobile node does not know it enough. In the introduction the only problem of the mobile node is that it has lost the context, in particular the IPsec one (no security association of any type). Of course the problem you described, what I call "dynamic bootstrap", is even harder. - (1. intro) with IKEv1 the MN does not need to have a statically defined home address and the reason you gave is wrong: the home address is unknown during the phase 1. I agree that a static home address is easier because it makes authorization rules static, but this is not a requirement, just the case you have a chance to get implemented (:-). - dynamic home agent address discovery is a security nightmare: I agree we should not rely on it. - (2. MIPv6 conf) all MN-HA mobility signaling (not communications) are required to be protected by IPsec. - (3.1.1. Dyn H@ Assignment) dynamically assigned is not the opposite of statically configurated. And there are known extensions (widely implemented but not standardized) of IKEv1 to support dynamically assigned "internal" addresses. - Home prefix change is not a valid issue because the home agent can infer the new home address from the old one. - Same for duplicate address collision because the authorization stuff can, when it occurs, accept any address which is not in use or authorized for another client. - I don't understand the "addressing privacy" issue: the home address can be a RFC 3041 one. This even makes dynamic authorization easy (first come first served)... - (3.1.2 Dyn HA@ assignment) this is only about manual keying, isn't it? (note that IMHO the manual keying is very incompatible with dynamic bootstrap, I'd like to focus on the IKE case) - (3.2.1 AAA) Even I agree that IKE should be clearly integrated with an AAA system your statement that it can work only with certificates is not true. - Interconnected PKIs are poor replacements for a real AAA infrastructure but they (can) work. - IMHO the main advantage of an AAA infrastructure is some security properties for the care-of address, perhaps this is the only way to get more than a return routability check (included in IKE which uses many messages in both ways :-). - NAI == USER-FQDN, the real issue is AAA and NAI are user oriented when IKEv1 is system oriented. - (3.2.2 Opp/Local discovery) The idea of using the DNS to get infos about the home was in a very old message of someone from Digital in this list (I can grep into my archive to find the reference). - (3.3.1 Dormant mode MN) IPv6 prefix change is a matter of weeks or months. IMHO the real issue is not with nodes in low power dormant mode, but with MNs which are used every X months (every IETF meetings for instance :-). - (4. scenarios) The first scenario (no pre-existing relationship) has a little chance to work with IKEv1 which requires strong mutual authentication and authorization. - the second one is interesting and should be shown to VPN server sellers. IMHO this can be a good extension to standard VPNs, and there is no home address assignment issue as VPN stuff in general includes an "internal" address management. - if I understand the third scenario, the idea is to use the local AAA system for access control to do some kind of "local mobility"? - I don't understand the fourth/last scenario: there is no way to "turn" security associations. And IMHO IPsec people will be very against any attempt to define this kind of things. - you should add a reference to AAA/MIPv6 requirement document (draft-le-aaa-mipv6-requirements-03.txt) which was resubmitted by Frank Le (our editor) as AAA gives all you'd like: care-of assignment, home agent assignment, home address assignment, security properties for all of them, including for the care-of, fast or very fast creation of the first IPsec SAs, etc. So the (to come) solution document about dynamic bootstrap should be only when an AAA infrastructure is not available/used (:-). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 12:31:50 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 MAA19985 for ; Tue, 17 Feb 2004 12:31:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At945-0007K0-R5 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 12:31:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HHVLZS028141 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 12:31:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At945-0007Jo-Ib for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 12:31:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19945 for ; Tue, 17 Feb 2004 12:31:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At944-0001uY-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 12:31:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At93K-0001q5-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 12:30:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At92o-0001kY-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 12:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At92o-00077O-2I; Tue, 17 Feb 2004 12:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At920-00075z-Ud for mip6@optimus.ietf.org; Tue, 17 Feb 2004 12:29:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19776 for ; Tue, 17 Feb 2004 12:29:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At91z-0001fe-00 for mip6@ietf.org; Tue, 17 Feb 2004 12:29:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At912-0001Zg-00 for mip6@ietf.org; Tue, 17 Feb 2004 12:28:13 -0500 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 1At908-0001QU-00 for mip6@ietf.org; Tue, 17 Feb 2004 12:27:16 -0500 Message-ID: <020e01c3f57b$5310fa70$936015ac@dclkempt40> From: "James Kempf" To: "Soliman Hesham" , "'Francis Dupont'" , "Jari Arkko" Cc: References: <9E3BA3946476AD4EB94672712B12A85F04215A@ftmail.lab.flarion.com> Subject: Re: [Mip6] Re: rr weaknesses? Date: Tue, 17 Feb 2004 09:27:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > => We don't even need to go that far, CGAs were safer!! > I wonder why we don't extend RR with CGAs and save ourselves > all this trouble... > Same issue as originally: IPR. Unfortunately, the release for SEND only applies to ND. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 12:35:04 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 MAA20279 for ; Tue, 17 Feb 2004 12:35:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At97F-0007g5-PA for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 12:34:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HHYbFn029507 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 12:34:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At97F-0007fo-JQ for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 12:34:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20262 for ; Tue, 17 Feb 2004 12:34:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At97E-0002Iq-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 12:34:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At96S-0002D1-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 12:33:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At95h-00025c-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 12:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At95h-0007Y1-TR; Tue, 17 Feb 2004 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At95D-0007X1-6r for mip6@optimus.ietf.org; Tue, 17 Feb 2004 12:32:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20072 for ; Tue, 17 Feb 2004 12:32:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At95B-00022H-00 for mip6@ietf.org; Tue, 17 Feb 2004 12:32:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At94G-0001wi-00 for mip6@ietf.org; Tue, 17 Feb 2004 12:31:32 -0500 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 1At93q-0001r4-00 for mip6@ietf.org; Tue, 17 Feb 2004 12:31:06 -0500 Message-ID: <026e01c3f57b$dfe7d180$936015ac@dclkempt40> From: "James Kempf" To: "Mark Doll" , "Francis Dupont" Cc: "Jari Arkko" , References: <20040216142802.7e41788b@borg.ipv6.tm.uni-karlsruhe.de><200402161416.i1GEGDSj096142@givry.rennes.enst-bretagne.fr> <20040216170204.1ad84cc2@borg.ipv6.tm.uni-karlsruhe.de> Subject: Re: [Mip6] Re: review of draft-dupont-mipv6-3bombing-00.txt Date: Tue, 17 Feb 2004 09:31:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > Thinking of TCP, I suppose some packets will always be lost during a > handover---as long as we do not use something like an anticipated > handover starting from the old care-of address with all its security > implications. So TCP will go through slow start anyway. And beeing able > to force TCP into slow start means that we intermix layers. Is this a > good idea? (*) > Doesn't have to be the case if something like FMIP is used. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 13:08:48 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 NAA22848 for ; Tue, 17 Feb 2004 13:08:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9du-0002lj-4D for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 13:08:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HI8M4A010637 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 13:08:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9dt-0002lU-Um for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:08:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22814 for ; Tue, 17 Feb 2004 13:08:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9ds-0005VB-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:08:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9d3-0005RX-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:07:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At9ca-0005N4-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9cb-0002IT-8u; Tue, 17 Feb 2004 13:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9cC-0002H2-BQ for mip6@optimus.ietf.org; Tue, 17 Feb 2004 13:06:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22673 for ; Tue, 17 Feb 2004 13:06:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9c9-0005Ky-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:06:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9bE-0005EH-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:05:37 -0500 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 1At9aP-000568-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:04:45 -0500 Message-ID: <02d201c3f580$92c6b1a0$936015ac@dclkempt40> From: "James Kempf" To: "Jari Arkko" , "Soliman Hesham" Cc: "Francis Dupont" , References: <9E3BA3946476AD4EB94672712B12A85F04214E@ftmail.lab.flarion.com> <40312B68.1070807@kolumbus.fi> Subject: Re: [Mip6] rr weaknesses? Date: Tue, 17 Feb 2004 10:05:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > I hate to press you for more information since I basically > agree that we need additional optimized mechanisms. But can > you say more about the specific requirements that you > are looking for "most apps"? Is there a paper somewhere that > has simulated mobility in some environment that shows how much > time you are spending on RR signaling vs. other movement related > tasks? How does home registration compare, what about IPv6 network > attachment? How about 1X/11i tasks? Or link layer attachment? > We had a paper in Internetworking03 last summer which measured RR signaling delay on a network that simulated a regional HA/CN based on an RTT to the HA and CN of 60 ms (about what I measured with ping between our San Jose office and Berkeley). Here is a table of results: Time BU w.o. RR 116 ms RR 119 ms Total 235 ms This cost would be expected typically on a per subnet move basis, and would naturally increase as the CN/HA distance increased and decrease as it decreased. Typical .11 handover times run about 100-200 ms (see Bill Arbaugh's paper on the topic) w.o. .11i reauth, but the AP and card manufacturers are working on improving this, as is the 802.11 WG, since VoIPo802.11 is *the* hot topic right now. I don't have any figures for raw cdma2K 1X attachment, but I think that is not too relevent, since 3GPP2 also has support for L2 mobility that takes care of forwarding packets for in-progress sessions. For VoIP, I think 235 ms is not acceptable, to say nothing of 435 ms if L2 mobility is taken into account, since it will be very noticable. However, by using FMIP and context transfer (as Charlie mentioned in a previous note), the handover time can be reduced substantially, since the local repair of routing between the access routers would be expected to be very fast if the access network deployment is properly done (about 1 RTT between the new AR and old). Alternatively, by deploying an HMIP MAP on every leaf subnet and running a sliding buffer at the MAP, one could cover most of the delay, with a risk of introducing ringing artifacts occasionally should the buffer end up with more than 2 or 3 packets. Some data comparing these approaches (perhaps for MOBOPTS?) would be very interesting. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 13:20: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 NAA24072 for ; Tue, 17 Feb 2004 13:20:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9pH-0004qn-Ao for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 13:20:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIK6ku018605 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 13:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9pF-0004pz-PZ for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:20:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23991 for ; Tue, 17 Feb 2004 13:20:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9pD-0006uX-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:20:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9o9-0006k8-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:18:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At9nF-0006Zu-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9nG-0004Sb-H9; Tue, 17 Feb 2004 13:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9ma-0004IC-JP for mip6@optimus.ietf.org; Tue, 17 Feb 2004 13:17:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23663 for ; Tue, 17 Feb 2004 13:17:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9mY-0006UA-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:17:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9lZ-0006Lh-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:16:18 -0500 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 1At9ke-0006Dw-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:15:20 -0500 Message-ID: <031801c3f582$0dc1e3b0$936015ac@dclkempt40> From: "James Kempf" To: "Rajeev Koodli" , "Soliman Hesham" Cc: "'Jari Arkko'" , "Francis Dupont" , References: <9E3BA3946476AD4EB94672712B12A85F042162@ftmail.lab.flarion.com> <40316DCC.AE0A9348@iprg.nokia.com> Subject: Re: [Mip6] rr weaknesses? Date: Tue, 17 Feb 2004 10:15:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > > the 802.11 family from this discussion because, lets face it, > > how often are you going to handover with 802.11? I'm thinking > > > > In some cases (e.g., campus WLAN networks), it could be as > often as when someone leaves a building for another! > The primary determinating factor would seem to be the access network configuration. If the access network is configured with many APs per subnet, then the MN only pays the L3 handover cost very rarely, and mostly not at all if the coverage area of the subnet is such as to handle 80-90% of the handovers in-subnet. As a practical matter, most 802.11 and 3G cellular deployments today are so configured, so the L2 handover cost is really the determining factor. However, that is not to say that this will always remain so. Future wireless link protocols may result in a lower AP to subnet ratio. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 13:40:33 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 NAA25640 for ; Tue, 17 Feb 2004 13:40:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA8a-00074y-3H for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 13:40:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIe3KQ027194 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 13:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA8X-00074L-8u for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:40:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25475 for ; Tue, 17 Feb 2004 13:39:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtA8V-00018r-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:39:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtA72-0000u2-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:38:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtA6N-0000o4-01 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:37:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1At9yy-0006Hd-KW for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9ys-0006On-EY; Tue, 17 Feb 2004 13:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9y6-0006ML-Sy for mip6@optimus.ietf.org; Tue, 17 Feb 2004 13:29:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24879 for ; Tue, 17 Feb 2004 13:29:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9y4-00007S-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9xA-00003t-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:28:16 -0500 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 1At9wC-00000L-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:27:17 -0500 Message-ID: <037d01c3f583$ba1eafc0$936015ac@dclkempt40> From: "James Kempf" To: "Francis Dupont" , "Jari Arkko" Cc: "Soliman Hesham" , References: <200402171022.i1HAMISj099982@givry.rennes.enst-bretagne.fr> Subject: Re: [Mip6] rr weaknesses? Date: Tue, 17 Feb 2004 10:27:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > Don't get me wrong. I want to create new route optimization > security mechanisms that are better than RR. > > => IMHO we need stronger assumptions to do that. For instance (again) > if strong authentication is available for MN and CN, IPsec is a > solution. > Agree, but there is still the issue of bombing attacks by an MN sending a CoA that it is not at to the CN. This practically assures that the CoTI/CoT sequence will be required for any protocol that does end to end route optimization (MIP RO, HIP, etc.) and even for moving an IPsec SAs ala MOBIKE. So there is a practical limit to how much signaling delay can be eliminated for end to end host-based authentication. The only way I can see removing that limit is somehow getting the last hop router involved, but I don't want to go there. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 13:43:04 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 NAA25920 for ; Tue, 17 Feb 2004 13:43:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAB2-0007b9-2p for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 13:42:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HIgae0029201 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 13:42:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAB1-0007au-Ua for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 13:42:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25907 for ; Tue, 17 Feb 2004 13:42:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAAz-0001Wn-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:42:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAAA-0001RF-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:41:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtA9a-0001Kh-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 13:41:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA9Z-0007D1-UP; Tue, 17 Feb 2004 13:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtA99-00078w-CU for mip6@optimus.ietf.org; Tue, 17 Feb 2004 13:40:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25675 for ; Tue, 17 Feb 2004 13:40:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtA97-0001Gq-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:40:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtA7u-00013V-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:39:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtA6e-0000o4-00 for mip6@ietf.org; Tue, 17 Feb 2004 13:38:04 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by mx2.foretec.com with esmtp (Exim 4.24) id 1At9rQ-00068y-Ug for mip6@ietf.org; Tue, 17 Feb 2004 13:22:21 -0500 Message-ID: <036e01c3f583$07c3cfe0$936015ac@dclkempt40> From: "James Kempf" To: "Jari Arkko" , "Soliman Hesham" Cc: References: <9E3BA3946476AD4EB94672712B12A85F042162@ftmail.lab.flarion.com> <4031CB24.8090905@kolumbus.fi> Subject: Re: [Mip6] rr weaknesses? Date: Tue, 17 Feb 2004 10:22:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > In conclusion, I'd still like you or someone to write that > paper that describes the issues and compares them to the > issues with existing issues that mitms on the path can > cause. I mean its easy for us to make short comments on > the mailing list, but I think this matter is so important > that it needs to be described well. And be reviewed! > > Don't get me wrong. I want to create new route optimization > security mechanisms that are better than RR. But I just think > there is a big difference in "nice to have" vs. "must have > because of serious problems". Clearly we have seen and will > see folks who claim the latter to market their method; it > would be extremely useful to understand where we are in > reality, however. > Yes, I agree. A review paper with measurements in it would be a great place to start, along with an analysis of what is not understood and needs to be measured. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 14:11:52 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 OAA27728 for ; Tue, 17 Feb 2004 14:11:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAcu-0002Cu-4y for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:11:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJBO6j008478 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:11:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAct-0002Cf-Qn for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 14:11:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27716 for ; Tue, 17 Feb 2004 14:11:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAcr-0003jB-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAbw-0003fo-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:10:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtAbZ-0003cA-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAba-00025e-G9; Tue, 17 Feb 2004 14:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAao-00023z-Q7 for mip6@optimus.ietf.org; Tue, 17 Feb 2004 14:09:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27621 for ; Tue, 17 Feb 2004 14:09:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAam-0003a4-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:09:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAZo-0003WE-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:08:12 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AtAYr-0003QV-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:07:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1HJ6Rc31882; Tue, 17 Feb 2004 11:06:27 -0800 X-mProtect: <200402171906> Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtylctQ; Tue, 17 Feb 2004 11:06:25 PST Message-ID: <40326627.D1D3CDAD@iprg.nokia.com> Date: Tue, 17 Feb 2004 11:06:15 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Soliman Hesham , "'Jari Arkko'" , Francis Dupont , mip6@ietf.org Subject: Re: [Mip6] rr weaknesses? References: <9E3BA3946476AD4EB94672712B12A85F042162@ftmail.lab.flarion.com> <40316DCC.AE0A9348@iprg.nokia.com> <031801c3f582$0dc1e3b0$936015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James Kempf wrote: > > > > In some cases (e.g., campus WLAN networks), it could be as > > often as when someone leaves a building for another! > > > > The primary determinating factor would seem to be the access network > configuration. If the access network is configured with many APs per subnet, > then the MN only pays the L3 handover cost very rarely, and mostly not at > all if the coverage area of the subnet is such as to handle 80-90% of the > handovers in-subnet. > I think this is an administrative issue. In a campus, different business units, different academic departments tend to have subnets of their own. Perhaps for good reasons. So, I tend to believe that you can circumvent the subnet handover problem up to a certain point. > > As a practical matter, most 802.11 and 3G cellular deployments today are so > configured, so the L2 handover cost is really the determining factor. > However, that is not to say that this will always remain so. Future wireless > link protocols may result in a lower AP to subnet ratio. > On the other hand, if the range is increased by an order of magnitude, there could be fewer subnet handovers. -Rajeev > > jak > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 14:20:55 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 OAA28199 for ; Tue, 17 Feb 2004 14:20:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAlf-00030S-0c for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:20:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJKQvg011550 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:20:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAle-00030D-RR for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 14:20:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28138 for ; Tue, 17 Feb 2004 14:20:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAlc-0004NN-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:20:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAkl-0004JR-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:19:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtAkE-0004Em-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:18:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAkG-0002jc-Bc; Tue, 17 Feb 2004 14:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAjX-0002bh-L6 for mip6@optimus.ietf.org; Tue, 17 Feb 2004 14:18:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27950 for ; Tue, 17 Feb 2004 14:18:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAjV-0004Bb-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:18:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAiY-000479-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:17:15 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AtAhc-00041E-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:16:16 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1HJFdL26504; Tue, 17 Feb 2004 20:15:39 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1HJFdSj002243; Tue, 17 Feb 2004 20:15:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200402171915.i1HJFdSj002243@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" cc: "Jari Arkko" , "Soliman Hesham" , mip6@ietf.org Subject: Re: [Mip6] rr weaknesses? In-reply-to: Your message of Tue, 17 Feb 2004 10:27:40 PST. <037d01c3f583$ba1eafc0$936015ac@dclkempt40> Date: Tue, 17 Feb 2004 20:15:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 In your previous mail you wrote: > Don't get me wrong. I want to create new route optimization > security mechanisms that are better than RR. > > => IMHO we need stronger assumptions to do that. For instance (again) > if strong authentication is available for MN and CN, IPsec is a > solution. > Agree, but there is still the issue of bombing attacks by an MN sending a CoA that it is not at to the CN. => you should read my draft about 3rd party bombing. This practically assures that the CoTI/CoT sequence will be required for any protocol that does end to end route optimization (MIP RO, HIP, etc.) and even for moving an IPsec SAs ala MOBIKE. => this is sure way to kill performance as you add a RTT. So there is a practical limit to how much signaling delay can be eliminated for end to end host-based authentication. The only way I can see removing that limit is somehow getting the last hop router involved, but I don't want to go there. => perhaps you suggest something like AAA which as far as I know the only reasonnable way to make more than to trust the MN to put its real care-of address or some kind of return routability check (AAA is both stronger and more efficient). Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 14:24:48 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 OAA28365 for ; Tue, 17 Feb 2004 14:24:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtApQ-0003Yf-Pu for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:24:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJOKX2013671 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:24:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtApQ-0003YQ-Kn for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 14:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28341 for ; Tue, 17 Feb 2004 14:24:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtApO-0004eo-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:24:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAoY-0004c7-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:23:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtAo8-0004YQ-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAo9-0003PL-Mf; Tue, 17 Feb 2004 14:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAng-0003Li-3I for mip6@optimus.ietf.org; Tue, 17 Feb 2004 14:22:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28289 for ; Tue, 17 Feb 2004 14:22:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAnd-0004XM-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:22:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAmj-0004TO-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:21:33 -0500 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 1AtAmK-0004Ok-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:21:08 -0500 Message-ID: <046301c3f58b$3f3eb7c0$936015ac@dclkempt40> From: "James Kempf" To: "Rajeev Koodli" Cc: "Soliman Hesham" , "'Jari Arkko'" , "Francis Dupont" , References: <9E3BA3946476AD4EB94672712B12A85F042162@ftmail.lab.flarion.com> <40316DCC.AE0A9348@iprg.nokia.com> <031801c3f582$0dc1e3b0$936015ac@dclkempt40> <40326627.D1D3CDAD@iprg.nokia.com> Subject: Re: [Mip6] rr weaknesses? Date: Tue, 17 Feb 2004 11:21:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > > As a practical matter, most 802.11 and 3G cellular deployments today are so > > configured, so the L2 handover cost is really the determining factor. > > However, that is not to say that this will always remain so. Future wireless > > link protocols may result in a lower AP to subnet ratio. > > > > On the other hand, if the range is increased by an order of magnitude, > there could be fewer subnet handovers. > Sure. But there's a problem with line of sight as the frequency goes up. This isn't the right mailing list to get into that, though. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 14:26:50 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 OAA28477 for ; Tue, 17 Feb 2004 14:26:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtArP-0003rx-49 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:26:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJQNHx014867 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtArO-0003ri-OI for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 14:26:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28443 for ; Tue, 17 Feb 2004 14:26:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtArM-0004mT-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:26:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAqO-0004iX-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:25:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtAq5-0004fj-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAq7-0003cw-HS; Tue, 17 Feb 2004 14:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtApO-0003Xz-Qg for mip6@optimus.ietf.org; Tue, 17 Feb 2004 14:24:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28335 for ; Tue, 17 Feb 2004 14:24:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtApM-0004eb-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:24:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAoW-0004bj-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:23:25 -0500 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 1AtAnx-0004YI-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:22:49 -0500 Message-ID: <046b01c3f58b$7b639950$936015ac@dclkempt40> From: "James Kempf" To: "Francis Dupont" Cc: "Jari Arkko" , "Soliman Hesham" , References: <200402171915.i1HJFdSj002243@givry.rennes.enst-bretagne.fr> Subject: Re: [Mip6] rr weaknesses? Date: Tue, 17 Feb 2004 11:23:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > Agree, but there is still the issue of bombing attacks by an MN sending a > CoA that it is not at to the CN. > > => you should read my draft about 3rd party bombing. > OK. > This practically assures that the CoTI/CoT > sequence will be required for any protocol that does end to end route > optimization (MIP RO, HIP, etc.) and even for moving an IPsec SAs ala > MOBIKE. > > => this is sure way to kill performance as you add a RTT. > > So there is a practical limit to how much signaling delay can be > eliminated for end to end host-based authentication. The only way I can see > removing that limit is somehow getting the last hop router involved, but I > don't want to go there. > > => perhaps you suggest something like AAA which as far as I know the > only reasonnable way to make more than to trust the MN to put its real > care-of address or some kind of return routability check (AAA is both > stronger and more efficient). > That's one possibility. Another might be a routing header with a signature from the last hop router, if the last hop router has a certificate (re. SEND). But, like I said, I'd rather not go there. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 14:41:59 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 OAA29422 for ; Tue, 17 Feb 2004 14:41:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtB64-00064D-5m for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:41:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJfWmw023315 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:41:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtB63-00063y-Sw for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 14:41:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29416 for ; Tue, 17 Feb 2004 14:41:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtB61-0005yP-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:41:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtB59-0005uP-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:40:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtB4a-0005pI-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:40:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtB4b-0005tP-MQ; Tue, 17 Feb 2004 14:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtB3s-0005rX-BF for mip6@optimus.ietf.org; Tue, 17 Feb 2004 14:39:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29235 for ; Tue, 17 Feb 2004 14:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtB3p-0005mS-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:39:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtB2q-0005gf-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:38:13 -0500 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 1AtB1r-0005ZZ-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:37:12 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2004 11:45:28 +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 i1HJad4U009393; Tue, 17 Feb 2004 11:36:39 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-72.cisco.com [128.107.163.72]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQI89515; Tue, 17 Feb 2004 11:36:38 -0800 (PST) Message-ID: <40326D46.5080105@cisco.com> Date: Tue, 17 Feb 2004 11:36:38 -0800 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: mip6@ietf.org CC: gdommety@cisco.com, basavaraj.patil@nokia.com, alpesh@cisco.com, kleung@cisco.com, chowdury@nortelnetworks.com, mkhalil@nortelnetworks.com, haseebak@nortelnetworks.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] [MIPv6] - New I-D - Authentication mechanism in MIPv6 - draft-patel-mipv6-auth-protocol-01.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 - A new I-D are available for comments. It describes a hash based authentication for MIPv6. Abstract This document defines new mobility options to enable authentication between mobility entities. These options can be used in addition to or in lieu of IPsec to authenticate mobility messages as defined in [1]. Location: ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-auth-protocol-01.txt Your comments are welcome. Alpesh _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 14:51:48 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 OAA29814 for ; Tue, 17 Feb 2004 14:51:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBFZ-0006Ty-2G for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:51:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJpLNJ024912 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 14:51:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBFY-0006Tj-SA for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 14:51:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29806 for ; Tue, 17 Feb 2004 14:51:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBFW-0006Z4-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:51:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBEb-0006WR-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:50:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtBEH-0006TZ-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 14:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBEI-0006Mw-NZ; Tue, 17 Feb 2004 14:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBDc-0006Ly-Ke for mip6@optimus.ietf.org; Tue, 17 Feb 2004 14:49:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29745 for ; Tue, 17 Feb 2004 14:49:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBDZ-0006ST-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:49:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBCh-0006Pn-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:48:24 -0500 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 1AtBC5-0006Kk-00 for mip6@ietf.org; Tue, 17 Feb 2004 14:47:45 -0500 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 i1HJlC1m000822; Tue, 17 Feb 2004 11:47:12 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-72.cisco.com [128.107.163.72]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQI90851; Tue, 17 Feb 2004 11:46:59 -0800 (PST) Message-ID: <40326FB3.2000609@cisco.com> Date: Tue, 17 Feb 2004 11:46:59 -0800 From: Alpesh Patel 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: mip6@ietf.org, gdommety@cisco.com, basavaraj.patil@nokia.com, alpesh@cisco.com, kleung@cisco.com, chowdury@nortelnetworks.com, mkhalil@nortelnetworks.com, haseebak@nortelnetworks.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] [MIPv6] - New ID - NAI option in MIPv6 - draft-patel-mipv6-nai-option-01.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hi - A new ID is available for your reference. It defines a NAI option for use in mobility control messages (mipv6). Location : ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-nai-option-01.txt Abstract This document defines new mobility option to identify mobility entities using a network access identifier. This option can be used in messages containing a mobility header. Your comments are welcome. Alpesh _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 15:16:08 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 PAA02046 for ; Tue, 17 Feb 2004 15:16:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBd6-0000XD-AO for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 15:15:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HKFenV002049 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 15:15:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBd6-0000Wy-6R for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:15:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02001 for ; Tue, 17 Feb 2004 15:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBd4-0000hM-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 15:15:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBc5-0000cY-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 15:14:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtBbV-0000X3-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 15:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBbV-0008OB-6u; Tue, 17 Feb 2004 15:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBay-0008Gc-PG for mip6@optimus.ietf.org; Tue, 17 Feb 2004 15:13:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01747 for ; Tue, 17 Feb 2004 15:13:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBax-0000Vo-00 for mip6@ietf.org; Tue, 17 Feb 2004 15:13:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBa7-0000S5-00 for mip6@ietf.org; Tue, 17 Feb 2004 15:12:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AtBZe-0000NK-00 for mip6@ietf.org; Tue, 17 Feb 2004 15:12:06 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 17 Feb 2004 12:12:08 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1HKBYuA007656 for ; Tue, 17 Feb 2004 12:11:34 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-72.cisco.com [128.107.163.72]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQI93791; Tue, 17 Feb 2004 12:11:33 -0800 (PST) Message-ID: <40327575.1040907@cisco.com> Date: Tue, 17 Feb 2004 12:11:33 -0800 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: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] [Fwd: [MIPv6] - New ID - Dynamic allocation of address in MIPv6 - draft-mkhalil-mipv6-alloc-01.txt] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hi - A new ID is available for your reference. It defines a mechanism to allocate a home address to the MN during the binding signaling. Location: ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-mkhalil-mipv6-alloc-01.txt Abstract Static configuration of the MN's (Mobile Node) home address is a very cumbersome task and a provisioning nightmare for the Service Providers. With millions of subscribers, a typical Service Provider stands to incur considerable expenses in order to manually configure all of its MN's home address. The ability to dynamically and securely allocate MN's home address, therefore, can immensely aid in providing a cost-effective and efficient device management alternative to the Service Providers. This draft provides a simple method for dynamically allocating MN's home address in a secure manner. Your comments are welcome. Alpesh _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 16:30:50 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 QAA07066 for ; Tue, 17 Feb 2004 16:30:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCnP-0001Y0-0p for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 16:30:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HLUMfX005947 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 16:30:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCnO-0001Xq-Ob for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 16:30:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07060 for ; Tue, 17 Feb 2004 16:30:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCnM-0007LY-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 16:30:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCmU-0007Io-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 16:29:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtCm6-0007Fm-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 16:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCm5-0001Rb-8H; Tue, 17 Feb 2004 16:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtClO-0001Q7-B2 for mip6@optimus.ietf.org; Tue, 17 Feb 2004 16:28:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07011 for ; Tue, 17 Feb 2004 16:28:15 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtClM-0007DK-00 for mip6@ietf.org; Tue, 17 Feb 2004 16:28:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCkQ-0007As-00 for mip6@ietf.org; Tue, 17 Feb 2004 16:27:19 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AtCjf-000790-00 for mip6@ietf.org; Tue, 17 Feb 2004 16:26:31 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HLQUH12809 for ; Tue, 17 Feb 2004 23:26:30 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 17 Feb 2004 23:26:29 +0200 Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 17 Feb 2004 15:26:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2004 15:26:28 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DBE59@daebe007.americas.nokia.com> Thread-Topic: Draft Agenda for MIP6 WG meeting at IETF59 Thread-Index: AcP1nLOJfaIDZMtJQSaGNWmK84WISQ== To: X-OriginalArrivalTime: 17 Feb 2004 21:26:28.0415 (UTC) FILETIME=[B43DACF0:01C3F59C] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Draft Agenda for MIP6 WG meeting at IETF59 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Draft Agenda for the MIP6 WG meeting at IETF59: [Note: Order and final agenda subject to change] Monday, March 1st, 2004 1300-1500 Afternoon Sessions I INT mip6 Mobility for IPv6 WG ----------------------------------------------------------- 1. Agenda, Bluesheets, Note takers 5 Mins 2. WG Docs Update 10 Mins Chairs draft-ietf-mobileip-ipv6-24.txt draft-ietf-mobileip-mipv6-ha-ipsec-06.txt draft-ietf-mip6-mipv6-mib-01.txt raft-ietf-mip6-mipext-advapi-00.txt 3. Dual Stack Mobile IPv6 20 Mins Hesham Soliman I-D: draft-soliman-v4v6-mipv4-00.txt draft-tsirtsis-dsmip-problem-00.txt 3. BUB: Binding Update Backhauling 10 Mins Wasim Haddad I-D: draft-haddad-mipv6-bub-01.txt 4. Optimizing Mobile IPv6 (OMIPv6) 5 Mins Wasim Haddad I-D: draft-haddad-mipv6-omipv6-01.txt 5. Mobile IPv6 and Firewalls - Problem statement 10 Mins Franck Le I-D: draft-le-mip6-firewalls-00.txt 6. The Mobile IPv6 Bootstrapping Problem 15 Mins James Kempf I-D: http://www.arkko.com/publications/mipv6/drafts/bootstrap.txt 7. Authentication Option for Mobile IPv6 25 Mins=20 Mobile IP Network Access Identifier Extension for IPv6 Secure and Dynamic Allocation of Home Address for MIPv6 Alpesh Patel/Kent Leung/Mohamed Khalil I-Ds: draft-patel-mipv6-authentication-option-00.txt=20 = ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-mkhalil-mipv6-alloc-01.txt draft-mkhalil-mipv6-nai-00.txt =20 8. MIPv6 bootstrapping via AAA - Problem/Requirements 10 Mins Yoshihiro Ohba/Franck Le I-D: draft-ohnishi-mip6-aaa-problem-statement-00.txt draft-le-aaa-mipv6-requirements-02.txt =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 17 18:03: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 SAA14123 for ; Tue, 17 Feb 2004 18:03:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEFS-0003XH-HO for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 18:03:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HN3QQo013587 for mip6-archive@odin.ietf.org; Tue, 17 Feb 2004 18:03:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEFS-0003X0-A3 for mip6-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 18:03:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14078 for ; Tue, 17 Feb 2004 18:03:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEFP-0000ht-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 18:03:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtEEV-0000fA-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 18:02:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtEE6-0000cV-00 for mip6-web-archive@ietf.org; Tue, 17 Feb 2004 18:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEE6-0002FY-9F; Tue, 17 Feb 2004 18:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtEDb-0001pI-Lj for mip6@optimus.ietf.org; Tue, 17 Feb 2004 18:01:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14017 for ; Tue, 17 Feb 2004 18:01:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtEDY-0000b7-00 for mip6@ietf.org; Tue, 17 Feb 2004 18:01:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtECZ-0000YJ-00 for mip6@ietf.org; Tue, 17 Feb 2004 18:00:28 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AtEC6-0000UN-00 for mip6@ietf.org; Tue, 17 Feb 2004 17:59:58 -0500 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i1HMxT0J001534 for ; Tue, 17 Feb 2004 14:59:29 -0800 (PST) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i1HMxRT9132267 for ; Tue, 17 Feb 2004 14:59:28 -0800 (PST) Message-Id: <200402172259.i1HMxRT9132267@jurassic.eng.sun.com> Date: Tue, 17 Feb 2004 15:01:25 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti To: mip6@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lNx+n3r8gcwAxGZihp80MQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_31 SunOS 5.10 sun4u sparc Subject: [Mip6] MIP6API - draft-ietf-mip6-mipext-advapi-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 The MIP6API draft has been published as the WG item. http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-00.txt Please read and send comments. We have received Brian Haley's comments so far. Please note that if implementors like, I would be interested in getting feedback on the MIP6API draft at the Connectathon next week and close any new issues. Thanks, -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 18 01:59:48 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 BAA02144 for ; Wed, 18 Feb 2004 01:59:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtLfz-0001t3-Nr for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 01:59:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I6xJ9a007252 for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 01:59:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtLfz-0001st-Go for mip6-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 01:59:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02088 for ; Wed, 18 Feb 2004 01:59:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtLfw-0000lc-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 01:59:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtLeE-0000NA-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 01:57:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtLar-0007hM-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 01:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtLar-0001Lo-4O; Wed, 18 Feb 2004 01:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtLaT-0001LN-8J for mip6@optimus.ietf.org; Wed, 18 Feb 2004 01:53:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01574 for ; Wed, 18 Feb 2004 01:53:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtLaP-0007dF-00 for mip6@ietf.org; Wed, 18 Feb 2004 01:53:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtLZS-0007bT-00 for mip6@ietf.org; Wed, 18 Feb 2004 01:52:35 -0500 Received: from s31xu4.systems.smu.edu ([129.119.70.133]) by ietf-mx with esmtp (Exim 4.12) id 1AtLYd-0007Zn-00 for mip6@ietf.org; Wed, 18 Feb 2004 01:51:44 -0500 Received: from SICLTPC1 ([129.119.251.139]) by s31xu4.systems.smu.edu with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Feb 2004 00:51:38 -0600 Message-ID: <001101c3f5eb$851177a0$8bfb7781@SICLTPC1> Reply-To: "Jahanzeb Faizan" From: "Jahanzeb Faizan" To: Subject: [Mip6] Virtual Home Agent Reliability Protocol (VHAR) - new version Date: Wed, 18 Feb 2004 00:50:33 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C3F5B9.371ABD40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 18 Feb 2004 06:51:38.0654 (UTC) FILETIME=[A85183E0:01C3F5EB] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C3F5B9.371ABD40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Virtual Home Agent Reliability Protocol (VHAR) Author(s) : J. Faizan , M. Khalil and H. El-Rewini Filename : draft-jfaizan-mipv6-vhar-01.txt Pages : 22 Date : 2004-2-17 =09 Current specification of Mobile-IPv6 [1] does not provide Home Agent=20 Reliability and Load Balancing in the Home Network [12]. The aim of this draft is to introduce Virtual Home Agent Reliability Protocol as = the solution. In this protocol multiple Home Agents and Recovery Home = Agents coexist on the same subnet and share the same IP Address. Only = one of them is active at a time and serves the Mobile Node. The Home=20 Agent failure and failover mechanisms are completely transparent to=20 the Mobile Node which is required for minimal service interruption=20 time. This protocol does not introduce any new Mobile-IPv6 message=20 over the air interface and thus helps reducing the overall overhead. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-vhar-01.txt ------=_NextPart_000_000E_01C3F5B9.371ABD40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
A New Internet-Draft is available from the on-line Internet-Drafts=20 directories.


Title : Virtual Home Agent Reliability = Protocol=20 (VHAR)
Author(s)         =    =20     : J. Faizan , M. Khalil and H.=20 El-Rewini
Filename         =    =20     : draft-jfaizan-mipv6-vhar-01.txt
Pages : 22
= Date :=20 2004-2-17

   Current specification of Mobile-IPv6 [1] = does not=20 provide Home Agent
   Reliability and Load Balancing in = the Home=20 Network [12]. The aim of
   this draft is to introduce = Virtual Home=20 Agent Reliability Protocol as
   the solution. In this = protocol=20 multiple Home Agents and Recovery Home
   Agents coexist = on the=20 same subnet and share the same IP Address. Only
   one of = them is=20 active at a time and serves the Mobile Node. The Home
   = Agent=20 failure and failover mechanisms are completely transparent to =
  =20 the Mobile Node which is required for minimal service interruption=20
   time. This protocol does not introduce any new = Mobile-IPv6=20 message
   over the air interface and thus helps reducing = the=20 overall overhead.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-vhar-01.txt
------=_NextPart_000_000E_01C3F5B9.371ABD40-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 18 08:06: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 IAA09216 for ; Wed, 18 Feb 2004 08:06:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtROf-0003dx-N2 for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 08:05:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ID5n0r014002 for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 08:05:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtROf-0003dl-Gc for mip6-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 08:05:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09211 for ; Wed, 18 Feb 2004 08:05:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtROe-0004Su-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 08:05:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtRNl-0004Qp-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 08:04:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtRMy-0004OU-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 08:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRMv-0003YA-Jd; Wed, 18 Feb 2004 08:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtRMi-0003Xs-Io for mip6@optimus.ietf.org; Wed, 18 Feb 2004 08:03:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09157 for ; Wed, 18 Feb 2004 08:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtRMh-0004N3-00 for mip6@ietf.org; Wed, 18 Feb 2004 08:03:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtRLn-0004LB-00 for mip6@ietf.org; Wed, 18 Feb 2004 08:02:51 -0500 Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx with esmtp (Exim 4.12) id 1AtRLL-0004Iv-00 for mip6@ietf.org; Wed, 18 Feb 2004 08:02:23 -0500 Received: OMGO id i1ID29Po013545; Wed, 18 Feb 2004 22:02:09 +0900 (JST) Received: OTM-MIX0 id i1ID28HF016034; Wed, 18 Feb 2004 22:02:08 +0900 (JST) Received: JC-SMTP from localhost (keiichi00.osaka.iij.ad.jp [192.168.65.65]) id i1ID27XR027660; Wed, 18 Feb 2004 22:02:08 +0900 (JST) Date: Wed, 18 Feb 2004 22:01:00 +0900 (JST) Message-Id: <20040218.220100.107776028.keiichi@iij.ad.jp> To: Samita.Chakrabarti@eng.sun.com Cc: Brian.Haley@hp.com, mip6@ietf.org, erik.nordmark@sun.com Subject: Re: [Mip6] Re: I-D ACTION:draft-ietf-mip6-mipext-advapi-00.txt From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <200402130117.i1D1HsOV486853@jurassic.eng.sun.com> References: <200402130117.i1D1HsOV486853@jurassic.eng.sun.com> X-Mailer: Mew version 4.0.62 on Emacs 21.3.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hello Samita and Brian, From: Samita Chakrabarti Subject: Re: [Mip6] Re: I-D ACTION:draft-ietf-mip6-mipext-advapi-00.txt Date: Thu, 12 Feb 2004 17:19:50 -0800 (PST) > > > > I noticed the syntax of the data structures and #defines changed from > > the last version of the draft, for example: > > > > struct ip6mh_binding_update > > became > > struct ip6_mh_binding_update > > > > and > > IP6MH_BU_ACK > > became > > IP6_MH_BU_ACK > > > They were changed on version 02 that was submitted and presented at > last IETF. The change was made because of input I received. > > > > > I could let it go :) but it is now mixing syntax from IPv6 and ICMPv6. > > I think if you're going to keep this change, which is like that in > > icmp6.h, you should go all the way and fix all the data elements: > > > > ip6mhbu_seqno > > turns into > > ip6_mh_bu_seqno > > > > I like that better anyways since I always mis-typed those since you were > > squishing all those chars together without a break. I was also surprised by this change. (I did sed on my code :-) But, I can go with the current draft. At least, the convention is consistent to me. All member names are squeezed, all structure names and macro names have a break. > > Another thing that would be good to do would be to #define all the > > ip6_mh pieces in the sub-structs, for example: > > > > struct ip6_mh_binding_error { > > struct ip6_mh ip6_mh_be_hdr; > > uint8_t ip6_mh_be_status; > > uint8_t ip6_mh_be_reserved; > > struct in6_addr ip6mhbe_homeaddr; /* home address */ > > /* followed by mobility options */ > > }; > > > > #define ip6_mh_be_proto ip6_mh_be_hdr.ip6_mh_proto > > #define ip6_mh_be_len ip6_mh_be_hdr.ip6_mh_len > > #define ip6_mh_be_type ip6_mh_be_hdr.ip6_mh_type > > #define ip6_mh_be_cksum ip6_mh_be_hdr.ip6_mh_cksum > > > > That way users can use the shorthand, just like all the ICMPv6 structures. > > I think it can be done. I'd like to know whether others think it's useful > or required to add. Note, this can be implemenation specific. This is a matter of teste, but, I like defining shortcuts. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 18 08:50:26 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 IAA10753 for ; Wed, 18 Feb 2004 08:50:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS5N-0007cK-6D for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 08:49:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IDnvkH029274 for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 08:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS5N-0007c5-1w for mip6-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 08:49:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10729 for ; Wed, 18 Feb 2004 08:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtS5L-0007FV-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 08:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtS4O-0007BI-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 08:48:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtS3U-00077B-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 08:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS3V-0007Jo-42; Wed, 18 Feb 2004 08:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS3J-0007J2-R7 for mip6@optimus.ietf.org; Wed, 18 Feb 2004 08:47:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10632 for ; Wed, 18 Feb 2004 08:47:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtS3I-00075M-00 for mip6@ietf.org; Wed, 18 Feb 2004 08:47:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtS2K-00071o-00 for mip6@ietf.org; Wed, 18 Feb 2004 08:46:48 -0500 Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx with esmtp (Exim 4.12) id 1AtS1L-0006xR-00 for mip6@ietf.org; Wed, 18 Feb 2004 08:45:47 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HTA009848TW5E@dns1.cselt.it> for mip6@ietf.org; Wed, 18 Feb 2004 14:44:20 +0100 (MET) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Feb 2004 14:45:56 +0100 Received: from EXC2K05A.cselt.it ([163.162.36.101]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Feb 2004 14:45:56 +0100 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K05A.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Feb 2004 14:45:14 +0100 Date: Wed, 18 Feb 2004 14:45:14 +0100 From: Giaretta Gerardo To: mip6@ietf.org Cc: Guardini Ivano Message-id: <625BE97BF4795E43970345790166B9BCD4DCBE@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Comments on draft-le-aaa-mipv6-requirements-03 thread-index: AcP2JTKYTPaFcL7fSSCrk1glQ4ShPw== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 18 Feb 2004 13:45:14.0806 (UTC) FILETIME=[6FE5CD60:01C3F625] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Comments on draft-le-aaa-mipv6-requirements-03 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I read draft-le-aaa-mipv6-requirements-03 and have the following = questions: 1) In the draft are you providing requirements on a specific a Diameter = Mobile IPv6 Application to be developed (as explicitely mentioned in the = abstract and in the introduction) or are you referring to general = requirements on the interaction between AAA and MIPv6? 2) In the introduction it is stated that Mobile IPv6 does not have the = equivalent of a Foreign Agent and as a result does not offer any = mechanism by which the visited network can authenticate and authorize = user access. As a consequence it is suggested the specification of a new = Diameter Mobile IPv6 Application supporting, among the other features, = also local and remote network access control. This is certainly an = option that may be useful in certain enviroments. Nevertheless, I think = that an additional requirement for a solution to integrate AAA and MIPv6 = should be the easy deployability in existing network infastructures, = where user authentication and authorization is commonly performed = relying on mechanisms that are not related at all with Mobile IPv6 (e.g. = EAP, cellular protocols). In such situations, it might be useful to = continue to handle user access authorization with the already deployed = mechanisms and exploit the MIPv6 Diameter extentions only for MIPv6 = service authorization and configuration. Comments? --Gerardo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 18 15:55:34 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 PAA20112 for ; Wed, 18 Feb 2004 15:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYio-0003JZ-03 for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 15:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IKt5sX012741 for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 15:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYin-0003JQ-RX for mip6-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 15:55:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20038 for ; Wed, 18 Feb 2004 15:55:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtYim-0006qG-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 15:55:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtYho-0006kT-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 15:54:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtYgp-0006f6-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 15:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYgo-0002sM-Ov; Wed, 18 Feb 2004 15:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtYgN-0002qt-P3 for mip6@optimus.ietf.org; Wed, 18 Feb 2004 15:52:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19866 for ; Wed, 18 Feb 2004 15:52:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtYgM-0006dA-00 for mip6@ietf.org; Wed, 18 Feb 2004 15:52:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtYfD-0006XZ-00 for mip6@ietf.org; Wed, 18 Feb 2004 15:51:24 -0500 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1AtYep-0006Te-00 for mip6@ietf.org; Wed, 18 Feb 2004 15:50:59 -0500 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A37F112EDC; Wed, 18 Feb 2004 15:50:58 -0500 (EST) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id B655CDFA; Wed, 18 Feb 2004 12:50:36 -0800 (PST) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id PAA0002036473; Wed, 18 Feb 2004 15:50:49 -0500 (EST) Message-ID: <4033D023.8040607@hp.com> Date: Wed, 18 Feb 2004 15:50:43 -0500 From: Brian Haley Organization: Linux Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti Cc: mip6@ietf.org, erik.nordmark@sun.com Subject: Re: [Mip6] Re: I-D ACTION:draft-ietf-mip6-mipext-advapi-00.txt References: <200402130117.i1D1HsOV486853@jurassic.eng.sun.com> In-Reply-To: <200402130117.i1D1HsOV486853@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Samita Chakrabarti wrote: >>I noticed the syntax of the data structures and #defines changed from >>the last version of the draft, for example: >> >> struct ip6mh_binding_update >>became >> struct ip6_mh_binding_update >> >>and >> IP6MH_BU_ACK >>became >> IP6_MH_BU_ACK > > They were changed on version 02 that was submitted and presented at > last IETF. The change was made because of input I received. Ok. > When we discussed the prefix, it was agreed to follow RFC3542 style - also > note that it was mentioned that there was no firm rule to follow everywhere. > There are inconsistencies in prefix in RFC3542 as well. We followed what > most people felt comfortable with. > > For example, the prefix of ip6_mh_binding_ack { } structure is ip6mhba_. > > Why ip6mh ? Because it is part of ip6mh.h as opposed to ip6.h. > > This is similar to the example in RFC3542: > struct ip6_opt_jumbo { > uint8_t ip6oj_type; > uint8_t ip6oj_len; > uint8_t ip6oj_jumbo_len[4]; > }; > > Other option is to have a prefix ip6_mhba_, but that looks a bit > odd, hence they are all suqeezed together. Ok regarding this and the other RFC 3542 style comments, I just noticed the change... >>Another thing that would be good to do would be to #define all the >>ip6_mh pieces in the sub-structs, for example: >> >>struct ip6_mh_binding_error { >> struct ip6_mh ip6_mh_be_hdr; >> uint8_t ip6_mh_be_status; >> uint8_t ip6_mh_be_reserved; >> struct in6_addr ip6mhbe_homeaddr; /* home address */ >> /* followed by mobility options */ >>}; >> >>#define ip6_mh_be_proto ip6_mh_be_hdr.ip6_mh_proto >>#define ip6_mh_be_len ip6_mh_be_hdr.ip6_mh_len >>#define ip6_mh_be_type ip6_mh_be_hdr.ip6_mh_type >>#define ip6_mh_be_cksum ip6_mh_be_hdr.ip6_mh_cksum >> >>That way users can use the shorthand, just like all the ICMPv6 structures. > > I think it can be done. I'd like to know whether others think it's useful > or required to add. Note, this can be implemenation specific. Implementation-specific is fine, I just think most will want them. -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 18 17:43:21 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 RAA27253 for ; Wed, 18 Feb 2004 17:43:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaP8-0000Ak-3Q for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 17:42:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IMgsEZ000658 for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 17:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaP7-0000AX-QL for mip6-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 17:42:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27147 for ; Wed, 18 Feb 2004 17:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtaP5-0006O1-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 17:42:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtaO9-0006FP-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 17:41:54 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtaNS-0006CT-01 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 17:41:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtaCi-0006JB-Ty for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 17:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaCh-0005z9-Gt; Wed, 18 Feb 2004 17:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtaCI-0005yQ-CM for mip6@optimus.ietf.org; Wed, 18 Feb 2004 17:29:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26794 for ; Wed, 18 Feb 2004 17:29:34 -0500 (EST) From: Franck.Le@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtaCG-0005u0-00 for mip6@ietf.org; Wed, 18 Feb 2004 17:29:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtaBK-0005t3-00 for mip6@ietf.org; Wed, 18 Feb 2004 17:28:38 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AtaB1-0005s8-00 for mip6@ietf.org; Wed, 18 Feb 2004 17:28:20 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1IMSJH04069 for ; Thu, 19 Feb 2004 00:28:19 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Feb 2004 00:28:19 +0200 Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 18 Feb 2004 14:28:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Comments on draft-le-aaa-mipv6-requirements-03 Date: Wed, 18 Feb 2004 16:28:00 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8110271C3C9@daebe007.americas.nokia.com> Thread-Topic: Comments on draft-le-aaa-mipv6-requirements-03 Thread-Index: AcP2JTKYTPaFcL7fSSCrk1glQ4ShPwASOvVg To: , Cc: X-OriginalArrivalTime: 18 Feb 2004 22:28:00.0883 (UTC) FILETIME=[77895430:01C3F66E] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Gerardo, Thank you for your comments, please find some below. > -----Original Message----- > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org]On Behalf Of ext > Giaretta Gerardo > Sent: 18 February, 2004 07:45 AM > To: mip6@ietf.org > Cc: Guardini Ivano > Subject: [Mip6] Comments on draft-le-aaa-mipv6-requirements-03 >=20 >=20 >=20 > Hi, >=20 > I read draft-le-aaa-mipv6-requirements-03 and have the=20 > following questions: >=20 > 1) In the draft are you providing requirements on a specific=20 > a Diameter Mobile IPv6 Application to be developed (as=20 > explicitely mentioned in the abstract and in the=20 > introduction) or are you referring to general requirements on=20 > the interaction between AAA and MIPv6? The goal of the MIPv6 AAA Requirements draft is to identify and describe = the requirements that the Mobile IPv6 protocol needs from the AAA = infrastructure. The requirements are therefore not specific to any = application but generic.=20 The intent is to reuse as much as possible of existing AAA application = solutions. If an existing Diameter Application can fulfill all the = identified requirements, it should be used. Otherwise a new Diameter = Application can be considered > 2) In the introduction it is stated that Mobile IPv6 does not=20 > have the equivalent of a Foreign Agent and as a result does=20 > not offer any mechanism by which the visited network can=20 > authenticate and authorize user access. As a consequence it=20 > is suggested the specification of a new Diameter Mobile IPv6=20 > Application supporting, among the other features, also local=20 > and remote network access control. This is certainly an=20 > option that may be useful in certain enviroments.=20 > Nevertheless, I think that an additional requirement for a=20 > solution to integrate AAA and MIPv6 should be the easy=20 > deployability in existing network infastructures, where user=20 > authentication and authorization is commonly performed=20 > relying on mechanisms that are not related at all with Mobile=20 > IPv6 (e.g. EAP, cellular protocols). In such situations, it=20 > might be useful to continue to handle user access=20 > authorization with the already deployed mechanisms and=20 > exploit the MIPv6 Diameter extentions only for MIPv6 service=20 > authorization and configuration. We agree that an easy to deploy solution should be prefered. This aspect = should however not result in the sacrifice of some required features.=20 Ease of deployability is a generic requirement for any protocol or = product and hence cannot be made a specific requirement in this case. If = you want, we could add a new requirement "The solution should require, = if possible, minimal modification/dsiruption to current existing = infrastructure". Franck _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Feb 23 15:22:56 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 PAA17850 for ; Mon, 23 Feb 2004 15:22:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMay-00074y-CL for mip6-archive@odin.ietf.org; Mon, 23 Feb 2004 15:22:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NKMSgC027206 for mip6-archive@odin.ietf.org; Mon, 23 Feb 2004 15:22:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMay-00074j-4L for mip6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 15:22:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17797 for ; Mon, 23 Feb 2004 15:22:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvMaw-00006k-00 for mip6-web-archive@ietf.org; Mon, 23 Feb 2004 15:22:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvMa6-00001x-00 for mip6-web-archive@ietf.org; Mon, 23 Feb 2004 15:21:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvMZl-0007le-00 for mip6-web-archive@ietf.org; Mon, 23 Feb 2004 15:21:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMZa-0006nh-3H; Mon, 23 Feb 2004 15:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMZ8-0006R8-LS for mip6@optimus.ietf.org; Mon, 23 Feb 2004 15:20:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17748 for ; Mon, 23 Feb 2004 15:20:32 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvMZ7-0007kM-00 for mip6@ietf.org; Mon, 23 Feb 2004 15:20:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvMYG-0007fy-00 for mip6@ietf.org; Mon, 23 Feb 2004 15:19:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AvMXo-0007az-00 for mip6@ietf.org; Mon, 23 Feb 2004 15:19:12 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1NKJ2H12467 for ; Mon, 23 Feb 2004 22:19:04 +0200 (EET) X-Scanned: Mon, 23 Feb 2004 22:18:47 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i1NKIlJ3025560 for ; Mon, 23 Feb 2004 22:18:47 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00VOJqvi; Mon, 23 Feb 2004 22:18:45 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1NKIi707747 for ; Mon, 23 Feb 2004 22:18:44 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 23 Feb 2004 12:18:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2004 14:18:43 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DBEAE@daebe007.americas.nokia.com> Thread-Topic: MIP6 Agenda - Revised Thread-Index: AcP6Sju6tH2DpyUzROSuy1v2pBXVuA== To: X-OriginalArrivalTime: 23 Feb 2004 20:18:43.0555 (UTC) FILETIME=[3BDFC330:01C3FA4A] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] MIP6 Agenda - Revised Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Agenda for the MIP6 WG meeting at IETF59: Monday, March 1st, 2004 1300-1500 Afternoon Sessions I INT mip6 Mobility for IPv6 WG ----------------------------------------------------------- 1. Agenda, Bluesheets, Note takers 5 Mins 2. WG Docs Update 5 Mins Chairs draft-ietf-mobileip-ipv6-24.txt draft-ietf-mobileip-mipv6-ha-ipsec-06.txt draft-ietf-mip6-mipv6-mib-01.txt raft-ietf-mip6-mipext-advapi-00.txt 3. Dual Stack Mobile IPv6 20 Mins Hesham Soliman I-D: draft-soliman-v4v6-mipv4-00.txt draft-tsirtsis-dsmip-problem-02.txt In the absence of ubiquituous IPv6 access networks, dual-Stack MIP6 clients can benefit from the capability to operate in IPv4 only networks. This will benefit the deployment case for MIP6. This discussion will explore the proposed solution and whether the MIP6 WG should work on this problem. 3. BUB: Binding Update Backhauling 10 Mins Wasim Haddad I-D: draft-haddad-mipv6-bub-01.txt Enhancement to Route Optimization when two end-points are mobile. Does this address any security issue that is inherent with the current scheme? 4. Optimizing Mobile IPv6 (OMIPv6) 5 Mins Wasim Haddad I-D: draft-haddad-mipv6-omipv6-01.txt Optimization of RO via a DH exchange between MN-CN. Is signaling overhead of RO messages mandate a more optimal scheme? 5. Mobile IPv6 and Firewalls - Problem statement 10 Mins Franck Le I-D: draft-le-mip6-firewalls-00.txt MIP6 deployment will need to deal with firewalls. Problem that firewalls will bring to MIP6 deployment in networks are to be discussed here.=20 6. The Mobile IPv6 Bootstrapping Problem 20 Mins James Kempf I-D: http://www.arkko.com/publications/mipv6/drafts/bootstrap.txt Bootstrapping of MIP6 is a WG charter item. This discussion will focus on the problem statement and scope of this work. 7. Authentication Option for Mobile IPv6 10 Mins=20 Mobile IP Network Access Identifier Extension for IPv6 Alpesh Patel/Kent Leung/Mohamed Khalil I-Ds:=20 ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-auth-protocol-0= 1.txt ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-nai-option-01.t= xt An IPsec alternative for securing BUs between the MN and HA. Why is this needed and proposed solution discussion. =20 8. MIPv6 interaction with AAA - Problem/Requirements 10 Mins Yoshihiro Ohba/Franck Le I-D: draft-ohnishi-mip6-aaa-problem-statement-00.txt draft-le-aaa-mipv6-requirements-02.txt Discussion on MIP6 and AAA. Is a AAA application for MIP6 needed? Is there a need for MIP6 and AAA to be closely coupled? Can AAA be used as a means for bootstrapping in managed networks? 9. Home Agent Reliability - Problem statement 5 Mins Jahanzeb Faizan/Ryuji Wakikawa I-D: draft-jfaizan-mipv6-ha-reliability-01.txt Home agent reliability is a WG charter item. Problem statement has been discussed at the last IETF as well. The intent of this slot is to determine if the WG agrees on the problem statement presented in this I-D and if the WG should adopt it and proceed to solutions. =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 24 03:39:30 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 DAA07008 for ; Tue, 24 Feb 2004 03:39:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvY5k-0001gg-7k for mip6-archive@odin.ietf.org; Tue, 24 Feb 2004 03:39:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O8d0OT006482 for mip6-archive@odin.ietf.org; Tue, 24 Feb 2004 03:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvY5j-0001gT-Oi for mip6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 03:38:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06982 for ; Tue, 24 Feb 2004 03:38:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvY5h-0002VT-00 for mip6-web-archive@ietf.org; Tue, 24 Feb 2004 03:38:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvY4t-0002Py-00 for mip6-web-archive@ietf.org; Tue, 24 Feb 2004 03:38:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvY3y-0002Jt-00 for mip6-web-archive@ietf.org; Tue, 24 Feb 2004 03:37:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvY3s-0001My-Pr; Tue, 24 Feb 2004 03:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvY3c-0001Kl-1y for mip6@optimus.ietf.org; Tue, 24 Feb 2004 03:36:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06813 for ; Tue, 24 Feb 2004 03:36:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvY3Z-0002Go-00 for mip6@ietf.org; Tue, 24 Feb 2004 03:36:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvY2e-0002Az-00 for mip6@ietf.org; Tue, 24 Feb 2004 03:35:48 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 1AvY1k-00026F-00 for mip6@ietf.org; Tue, 24 Feb 2004 03:34:52 -0500 Received: (qmail 24365 invoked from network); 24 Feb 2004 08:34:57 -0000 Received: from unknown (HELO clarinet.u-strasbg.fr) (130.79.90.171) by clarinet.u-strasbg.fr with RC4-MD5 encrypted SMTP; 24 Feb 2004 08:34:57 -0000 Message-ID: <403B0C99.3060801@clarinet.u-strasbg.fr> Date: Tue, 24 Feb 2004 09:34:33 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] multihoming pb statement Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 all, This email gives the status of the work we've done on multihoming analysis since the last IETF. After the discussion we had at the last IETF about the draft draft-mip6-montavont-multihoming-pb-statement-00 we investigated the multihoming problem statement more deeply: as it was suggested, we tried to write scenario and definitions not linked to any existing protocol/potential solution (such as MIPv6). Instead, we worked on the node multihoming issues: which situation can lead a node to be multihomed, what are the benefits that a node can expect from a specific case of multihoming... This draft is designed to be applied to fixed hosts, fixed routers, mobile hosts and mobile routers. We summurized this work in the draft: draft-multihoming-generic-goals-and-benefits-00.txt available from the IETF archives. An update of this draft would be available in two weeks. It is expected that from this generic draft, we write other documents that analyse the generic scenarios with a specific solution. The relevant scenarios will be identified and the feasability of the goals/benefits will be investigated. The document draft-ng-nemo-multihoming-issues-03.txt investigates the network mobility specific issues while we are writing another document specific to MIPv6 (which is not yet published). These two documents follow the guidine given in the generic draft. As the draft specific to network mobility is already written, we expect to present the generic draft in the NEMO WG at the next IETF. As this draft is independant from any solution and gives the generic problem statement of multihoming of nodes, we invite anybody who has interest in multihoming to participate to this presentation. Nicolas* * _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 24 20:37: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 UAA21326 for ; Tue, 24 Feb 2004 20:37:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvnyS-0007A5-0W for mip6-archive@odin.ietf.org; Tue, 24 Feb 2004 20:36:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P1aVmn027521 for mip6-archive@odin.ietf.org; Tue, 24 Feb 2004 20:36:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvnyR-00079o-Pv for mip6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 20:36:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21317 for ; Tue, 24 Feb 2004 20:36:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvnyP-0001ZR-00 for mip6-web-archive@ietf.org; Tue, 24 Feb 2004 20:36:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvnxS-0001Ua-00 for mip6-web-archive@ietf.org; Tue, 24 Feb 2004 20:35:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avnx2-0001PM-00 for mip6-web-archive@ietf.org; Tue, 24 Feb 2004 20:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avnx0-000701-S3; Tue, 24 Feb 2004 20:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvnwV-0006y2-8f for mip6@optimus.ietf.org; Tue, 24 Feb 2004 20:34:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21229 for ; Tue, 24 Feb 2004 20:34:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvnwT-0001Oe-00 for mip6@ietf.org; Tue, 24 Feb 2004 20:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvnvY-0001Jg-00 for mip6@ietf.org; Tue, 24 Feb 2004 20:33:33 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Avnuz-0001EK-00; Tue, 24 Feb 2004 20:32:57 -0500 Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1Avnul-0000Wt-00; Wed, 25 Feb 2004 02:32:43 +0100 Date: Wed, 25 Feb 2004 02:32:33 +0100 From: Henrik Levkowetz To: mip4@ietf.org, mip6@ietf.org Cc: Pete McCann , Pekka Savola , Jonne Soininen , Basavaraj Patil , Gopal Dommety Message-Id: <20040225023233.12c02fed.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Wed__25_Feb_2004_02_32_33_+0100_P_4CIJTgUJhjW3oK" Subject: [Mip6] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 --Signature=_Wed__25_Feb_2004_02_32_33_+0100_P_4CIJTgUJhjW3oK Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Proposal of a bar-bof --------------------- With the coming (we hope) of heterogenous deployment of IPv4 and IPv6 access and transport networks, and Mobile Nodes with MIPv4 and/or MIPv6 capability and IPv4 and/or IPv6 stacks, the question has been raised of how to best run Mobile IP in such circumstances, and some solutions has been proposed. The "trivial cases" of MIP4 carrying IPv4 in an all-IPv4 network, and MIP6 carrying IPv6 in an all-IPv6 network are covered in the MIPv4 and MIPv6 standards. But by one way of counting, that still leaves about 6 combinations (14 if you count NAT-PT versions) which may occur in practice which are not covered by the current standards. A number of drafts (some mentioned below) has been written, proposing solutions to some of these cases. Some cases may be handled without any additional MIP work if other transition mechanisms such as e.g. ISATAP is available, but as a Mobile Node may be expected to come across all conceivable kinds of visited networks, it cannot rely on any particular other transition mechanism being in place. Below is a list of possible combinations of Host IP stack version, MIP client/agent version and transport network IP version, followed by a short summary of my understanding of where the current and proposed solutions fit in. There exist 8 similar combinations using NAT-PT which are not explicitly listed here. Which solutions will be needed? Which should we work on? How much interest does this have currently? We plan to hold a bar-bof in Seoul, to see how many show up, and what kind of interest there is in this subject. Place will be announced on the lists Monday March 1st, and in the MIP4 and MIP6 sessions. Henrik Table of MIP4/6-IP4/6 combinations: =================================== # MN's MIP Access Transpt Short description IP-stack Client Net & HA if. --- -------- ------ ------ ------- ----------------- 1 IPv4 MIP v4 IP v4 v4 "native MIPv4" 2 IPv6 " " v4 "IPv6 in MIPv4" 3 IPv4 MIP v6 " v4 "IPv4 in MIPv6 over IPv4" 4 IPv6 " " v4 "MIPv6 over IPv4" 5 IPv4 MIP v4 IP v6 v6 "MIPv4 over IPv6" 6 IPv6 " " v6 "IPv6 in MIPv4 over IPv6" 7 IPv4 MIP v6 " v6 "IPv4 in MIPv6" 8 IPv6 " " v6 "native MIPv6" --- -------- ------ ------ ------- ----------------- Variant 1 is the native IP/MIP combination for v4 Variant 2 would be supported by the MIPv4 signalling extensions proposed in draft-tsirtsis-v4v6-mipv4-00.txt Variant 5 is known to be supported by an experimental thesis implementation and is fairly simple Variant 6 is known to be supported by an experimental thesis implementation and is fairly simple Variant 7 would be supported by the MIPv6 signalling extensions proposed in draft-soliman-v4v6-mipv4-00.txt Variant 8 is the native IP/MIP combination for v6 --Signature=_Wed__25_Feb_2004_02_32_33_+0100_P_4CIJTgUJhjW3oK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAO/sxeVhrtTJkXCMRAvr4AJ4+PL5qlNO7VgOs2a/DR0vPFo89UACfSxgD sYaIOMNBOcN2NCeCFzlL/qc= =nX5b -----END PGP SIGNATURE----- --Signature=_Wed__25_Feb_2004_02_32_33_+0100_P_4CIJTgUJhjW3oK-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Feb 24 20:40: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 UAA21503 for ; Tue, 24 Feb 2004 20:40:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avo2B-0007tA-AT for mip6-archive@odin.ietf.org; Tue, 24 Feb 2004 20:40:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P1eNk2030318 for mip6-archive@odin.ietf.org; Tue, 24 Feb 2004 20:40:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avo2B-0007sv-6h for mip6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 20:40:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21483 for ; Tue, 24 Feb 2004 20:40:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avo29-0001ru-00 for mip6-web-archive@ietf.org; Tue, 24 Feb 2004 20:40:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avo1C-0001nr-00 for mip6-web-archive@ietf.org; Tue, 24 Feb 2004 20:39:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avo0q-0001k0-00 for mip6-web-archive@ietf.org; Tue, 24 Feb 2004 20:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avo0s-0007Vu-0V; Tue, 24 Feb 2004 20:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avo0G-0007UL-AG for mip6@optimus.ietf.org; Tue, 24 Feb 2004 20:38:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21418 for ; Tue, 24 Feb 2004 20:38:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avo0D-0001jJ-00 for mip6@ietf.org; Tue, 24 Feb 2004 20:38:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvnzM-0001er-00 for mip6@ietf.org; Tue, 24 Feb 2004 20:37:29 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Avnyt-0001aJ-00; Tue, 24 Feb 2004 20:36:59 -0500 Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1Avnyr-0000XV-00; Wed, 25 Feb 2004 02:36:57 +0100 Date: Wed, 25 Feb 2004 02:36:57 +0100 From: Henrik Levkowetz To: mip4@ietf.org, mip6@ietf.org Message-Id: <20040225023657.260676cd.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: [Mip6] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Proposal of a bar-bof --------------------- With the coming (we hope) of heterogenous deployment of IPv4 and IPv6 access and transport networks, and Mobile Nodes with MIPv4 and/or MIPv6 capability and IPv4 and/or IPv6 stacks, the question has been raised of how to best run Mobile IP in such circumstances, and some solutions has been proposed. The "trivial cases" of MIP4 carrying IPv4 in an all-IPv4 network, and MIP6 carrying IPv6 in an all-IPv6 network are covered in the MIPv4 and MIPv6 standards. But by one way of counting, that still leaves about 6 combinations (14 if you count NAT-PT versions) which may occur in practice which are not covered by the current standards. A number of drafts (some mentioned below) has been written, proposing solutions to some of these cases. Some cases may be handled without any additional MIP work if other transition mechanisms such as e.g. ISATAP is available, but as a Mobile Node may be expected to come across all conceivable kinds of visited networks, it cannot rely on any particular other transition mechanism being in place. Below is a list of possible combinations of Host IP stack version, MIP client/agent version and transport network IP version, followed by a short summary of my understanding of where the current and proposed solutions fit in. There exist 8 similar combinations using NAT-PT which are not explicitly listed here. Which solutions will be needed? Which should we work on? How much interest does this have currently? We plan to hold a bar-bof in Seoul, to see how many show up, and what kind of interest there is in this subject. Place will be announced on the lists Monday March 1st, and in the MIP4 and MIP6 sessions. Henrik Table of MIP4/6-IP4/6 combinations: =================================== # MN's MIP Access Transpt Short description IP-stack Client Net & HA if. --- -------- ------ ------ ------- ----------------- 1 IPv4 MIP v4 IP v4 v4 "native MIPv4" 2 IPv6 " " v4 "IPv6 in MIPv4" 3 IPv4 MIP v6 " v4 "IPv4 in MIPv6 over IPv4" 4 IPv6 " " v4 "MIPv6 over IPv4" 5 IPv4 MIP v4 IP v6 v6 "MIPv4 over IPv6" 6 IPv6 " " v6 "IPv6 in MIPv4 over IPv6" 7 IPv4 MIP v6 " v6 "IPv4 in MIPv6" 8 IPv6 " " v6 "native MIPv6" --- -------- ------ ------ ------- ----------------- Variant 1 is the native IP/MIP combination for v4 Variant 2 would be supported by the MIPv4 signalling extensions proposed in draft-tsirtsis-v4v6-mipv4-00.txt Variant 5 is known to be supported by an experimental thesis implementation and is fairly simple Variant 6 is known to be supported by an experimental thesis implementation and is fairly simple Variant 7 would be supported by the MIPv6 signalling extensions proposed in draft-soliman-v4v6-mipv4-00.txt Variant 8 is the native IP/MIP combination for v6 -- Henrik -- Outside of a dog a book is man's best friend. Inside of a dog it's too dark to read. -- Groucho Marx _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 25 09:06:17 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 JAA17010 for ; Wed, 25 Feb 2004 09:06:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvzfZ-00037B-IU for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 09:05:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PE5no4011973 for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 09:05:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvzfZ-000372-Ck for mip6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:05:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16996 for ; Wed, 25 Feb 2004 09:05:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvzfX-0002pR-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 09:05:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avzed-0002jb-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 09:04:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avzdp-0002ei-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 09:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avzdp-0002yf-A7; Wed, 25 Feb 2004 09:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avzdb-0002xz-0B for mip6@optimus.ietf.org; Wed, 25 Feb 2004 09:03:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16946 for ; Wed, 25 Feb 2004 09:03:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvzdZ-0002dS-00 for mip6@ietf.org; Wed, 25 Feb 2004 09:03:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avzce-0002Yf-00 for mip6@ietf.org; Wed, 25 Feb 2004 09:02:49 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Avzbm-0002PJ-00; Wed, 25 Feb 2004 09:01:54 -0500 content-class: urn:content-classes:message Date: Wed, 25 Feb 2004 09:01:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Thread-Index: AcP7P6eNgyNdLZsyQZa+iK217qbrvQAYzOJg From: "Tsirtsis George" To: "Henrik Levkowetz" , , Cc: "Pete McCann" , "Pekka Savola" , "Jonne Soininen" , "Basavaraj Patil" , "Gopal Dommety" Content-Transfer-Encoding: quoted-printable Subject: [Mip6] RE: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Henrik, I am not entirely sure what some of the combinations implied below = mean... like "IPv4 only node with MIPv6 and v6HA". Such combinations do not work = and *do not need* to work. So, I either misunderstood your e-mail or the = scope of the discussion is smaller than you imply. If you are an IPv4 ONLY mobile then you have to use MIPv4 and a v4HA = ...no choice really. If you are an IPv6 ONLY mobile then you have to use MIPv6 and a v6HA = ...no choice really. The question is what you use if you are Dual-Stack. The IESG asked us a while ago to write a problem statement on this, = which we did (recently resubmitted), see http://www.ietf.org/internet-drafts/draft-tsirtsis-dsmip-problem-02.txt. = I would suggest people have a look at that and try to think if we have = missed something in the problem statement.=20 The BAR-BOF should as a minimum examine the problem statement and = suggest additions/changes if required. Now, if we also figure out how much = interest there is in the subject and which WG(s) is(are) going to take up any = work that is required, that would be a result! George > -----Original Message----- > From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On Behalf Of > Henrik Levkowetz > Sent: Wednesday, February 25, 2004 1:33 AM > To: mip4@ietf.org; mip6@ietf.org > Cc: Pete McCann; Pekka Savola; Jonne Soininen; Basavaraj Patil; Gopal > Dommety > Subject: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof >=20 >=20 >=20 > Proposal of a bar-bof > --------------------- >=20 > With the coming (we hope) of heterogenous deployment of IPv4 and IPv6 > access and transport networks, and Mobile Nodes with MIPv4=20 > and/or MIPv6 > capability and IPv4 and/or IPv6 stacks, the question has been raised > of how to best run Mobile IP in such circumstances, and some solutions > has been proposed. =20 >=20 > The "trivial cases" of MIP4 carrying IPv4 in an all-IPv4 network, and > MIP6 carrying IPv6 in an all-IPv6 network are covered in the MIPv4 and > MIPv6 standards. But by one way of counting, that still=20 > leaves about 6 > combinations (14 if you count NAT-PT versions) which may occur in > practice which are not covered by the current standards. A number of > drafts (some mentioned below) has been written, proposing solutions > to some of these cases. >=20 > Some cases may be handled without any additional MIP work if other > transition mechanisms such as e.g. ISATAP is available, but=20 > as a Mobile > Node may be expected to come across all conceivable kinds of visited > networks, it cannot rely on any particular other transition mechanism > being in place. >=20 > Below is a list of possible combinations of Host IP stack version, MIP > client/agent version and transport network IP version, followed by a > short summary of my understanding of where the current and proposed > solutions fit in. There exist 8 similar combinations using NAT-PT > which are not explicitly listed here. >=20 > Which solutions will be needed? Which should we work on? How much > interest does this have currently? =20 >=20 > We plan to hold a bar-bof in Seoul, to see how many show up, and what > kind of interest there is in this subject. Place will be announced > on the lists Monday March 1st, and in the MIP4 and MIP6 sessions. >=20 > Henrik >=20 >=20 >=20 > Table of MIP4/6-IP4/6 combinations: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > # MN's MIP Access Transpt Short=20 > description > IP-stack Client Net & HA if.=09 > --- -------- ------ ------ -------=09 > ----------------- > 1 IPv4 MIP v4 IP v4 v4 "native MIPv4"=09 > 2 IPv6 " " v4 "IPv6 in MIPv4"=09 >=20 > 3 IPv4 MIP v6 " v4 "IPv4=20 > in MIPv6 over IPv4" > 4 IPv6 " " v4 "MIPv6=20 > over IPv4" >=20 > 5 IPv4 MIP v4 IP v6 v6 "MIPv4=20 > over IPv6" > 6 IPv6 " " v6 "IPv6=20 > in MIPv4 over IPv6" >=20 > 7 IPv4 MIP v6 " v6 "IPv4 in MIPv6" > 8 IPv6 " " v6 "native MIPv6" > --- -------- ------ ------ -------=09 > ----------------- >=20 > Variant 1 is the native IP/MIP combination for v4 >=20 > Variant 2 would be supported by the MIPv4 signalling=20 > extensions proposed in > draft-tsirtsis-v4v6-mipv4-00.txt >=20 > Variant 5 is known to be supported by an experimental=20 > thesis implementation > and is fairly simple >=20 > Variant 6 is known to be supported by an experimental=20 > thesis implementation > and is fairly simple >=20 > Variant 7 would be supported by the MIPv6 signalling=20 > extensions proposed in > draft-soliman-v4v6-mipv4-00.txt >=20 > Variant 8 is the native IP/MIP combination for v6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 25 09:40:18 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 JAA18440 for ; Wed, 25 Feb 2004 09:40:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0CV-0006lk-Cj for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 09:39:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEdpXl026014 for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 09:39:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0CV-0006lT-69 for mip6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:39:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18392 for ; Wed, 25 Feb 2004 09:39:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0CT-0006VL-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 09:39:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0BY-0006PO-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 09:38:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0Aj-0006KW-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 09:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0Aj-0006Mz-IV; Wed, 25 Feb 2004 09:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0Ab-0006Ln-2T for mip6@optimus.ietf.org; Wed, 25 Feb 2004 09:37:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18348 for ; Wed, 25 Feb 2004 09:37:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0AZ-0006JA-00 for mip6@ietf.org; Wed, 25 Feb 2004 09:37:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw09h-0006DB-00 for mip6@ietf.org; Wed, 25 Feb 2004 09:36:58 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw092-00061l-00; Wed, 25 Feb 2004 09:36:17 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i1PEZTjv029729; Wed, 25 Feb 2004 15:35:29 +0100 Date: Wed, 25 Feb 2004 15:35:29 +0100 From: Henrik Levkowetz To: "Tsirtsis George" Cc: , , "Pete McCann" , "Pekka Savola" , "Jonne Soininen" , "Basavaraj Patil" , "Gopal Dommety" Message-Id: <20040225153529.7c8fd8d3.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: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Wed__25_Feb_2004_15_35_29_+0100_TNzf0iVIo7lbmIBr" X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Subject: [Mip6] Re: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 --Signature=_Wed__25_Feb_2004_15_35_29_+0100_TNzf0iVIo7lbmIBr Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi George, On Wednesday, 25 Feb 2004, Tsirtsis George wrote: > Henrik, > > I am not entirely sure what some of the combinations implied below > mean... like "IPv4 only node with MIPv6 and v6HA". Such combinations > do not work and*do not need* to work. So, I either misunderstood your > e-mail or the scope of the discussion is smaller than you imply. You've misunderstood a bit. There's no implied "... only node" for the first column in the table. Turn it around, and suppose you have an application in your dual-stack MN which will only talk IPv4, and what you have is a MIP6 client and HA. That's the "IPv4 with MIPv6 and v6HA" case. Sorry if the table was insufficiently clear. [snip] > The IESG asked us a while ago to write a problem statement on this, > which we did (recently resubmitted), see > http://www.ietf.org/internet-drafts/draft-tsirtsis-dsmip-problem-02.txt. > I would suggest people have a look at that and try to think if we have > missed something in the problem statement. Yes, I saw that just recently but haven't had time to read it. Was it announced on the mip4 list? I didn't notice it there... (I also flag all drafts with -mip-, -mobileip-, -mip4-, -mip6- in the name for reading, but this draft fell through there too... ,:) Should be able to read it during the next couple of days. > The BAR-BOF should as a minimum examine the problem statement and > suggest additions/changes if required. Now, if we also figure out how > much interest there is in the subject and which WG(s) is(are) going to > take up any work that is required, that would be a result! Yes. The minimum result I would expect is that we mutually understand the problem area and what needs different people have better after the bar-bof. Henrik > > > -----Original Message----- > > From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On Behalf Of > > Henrik Levkowetz > > Sent: Wednesday, February 25, 2004 1:33 AM > > To: mip4@ietf.org; mip6@ietf.org > > Cc: Pete McCann; Pekka Savola; Jonne Soininen; Basavaraj Patil; > > Gopal Dommety > > Subject: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof > > > > > > > > Proposal of a bar-bof > > --------------------- > > > > With the coming (we hope) of heterogenous deployment of IPv4 and > > IPv6 access and transport networks, and Mobile Nodes with MIPv4 > > and/or MIPv6 > > capability and IPv4 and/or IPv6 stacks, the question has been raised > > of how to best run Mobile IP in such circumstances, and some > > solutions has been proposed. > > > > The "trivial cases" of MIP4 carrying IPv4 in an all-IPv4 network, > > and MIP6 carrying IPv6 in an all-IPv6 network are covered in the > > MIPv4 and MIPv6 standards. But by one way of counting, that still > > leaves about 6 > > combinations (14 if you count NAT-PT versions) which may occur in > > practice which are not covered by the current standards. A number > > of drafts (some mentioned below) has been written, proposing > > solutions to some of these cases. > > > > Some cases may be handled without any additional MIP work if other > > transition mechanisms such as e.g. ISATAP is available, but > > as a Mobile > > Node may be expected to come across all conceivable kinds of visited > > networks, it cannot rely on any particular other transition > > mechanism being in place. > > > > Below is a list of possible combinations of Host IP stack version, > > MIP client/agent version and transport network IP version, followed > > by a short summary of my understanding of where the current and > > proposed solutions fit in. There exist 8 similar combinations using > > NAT-PT which are not explicitly listed here. > > > > Which solutions will be needed? Which should we work on? How much > > interest does this have currently? > > > > We plan to hold a bar-bof in Seoul, to see how many show up, and > > what kind of interest there is in this subject. Place will be > > announced on the lists Monday March 1st, and in the MIP4 and MIP6 > > sessions. > > > > Henrik > > > > > > > > Table of MIP4/6-IP4/6 combinations: > > =================================== > > > > # MN's MIP Access Transpt Short > > description > > IP-stack Client Net & HA if. > > --- -------- ------ ------ ------- > > ----------------- > > 1 IPv4 MIP v4 IP v4 v4 "native MIPv4" > > 2 IPv6 " " v4 "IPv6 in MIPv4" > > > > 3 IPv4 MIP v6 " v4 "IPv4 > > in MIPv6 over IPv4" > > 4 IPv6 " " v4 "MIPv6 > > over IPv4" > > > > 5 IPv4 MIP v4 IP v6 v6 "MIPv4 > > over IPv6" > > 6 IPv6 " " v6 "IPv6 > > in MIPv4 over IPv6" > > > > 7 IPv4 MIP v6 " v6 "IPv4 in MIPv6" > > 8 IPv6 " " v6 "native MIPv6" > > --- -------- ------ ------ ------- > > ----------------- > > > > Variant 1 is the native IP/MIP combination for v4 > > > > Variant 2 would be supported by the MIPv4 signalling > > extensions proposed in > > draft-tsirtsis-v4v6-mipv4-00.txt > > > > Variant 5 is known to be supported by an experimental > > thesis implementation > > and is fairly simple > > > > Variant 6 is known to be supported by an experimental > > thesis implementation > > and is fairly simple > > > > Variant 7 would be supported by the MIPv6 signalling > > extensions proposed in > > draft-soliman-v4v6-mipv4-00.txt > > > > Variant 8 is the native IP/MIP combination for v6 > > > > --Signature=_Wed__25_Feb_2004_15_35_29_+0100_TNzf0iVIo7lbmIBr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAPLKxeVhrtTJkXCMRAmiTAJ0UG8IRs8fHCiQVsEyjBRptdKkVLQCgiKkp 4u/nithfA0FHo8QHl2uD+TY= =KHi9 -----END PGP SIGNATURE----- --Signature=_Wed__25_Feb_2004_15_35_29_+0100_TNzf0iVIo7lbmIBr-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 25 09:58:14 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 JAA19123 for ; Wed, 25 Feb 2004 09:58:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0Tr-0008HA-69 for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 09:57:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEvlul031812 for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 09:57:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0Tq-0008H1-Vx for mip6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:57:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19094 for ; Wed, 25 Feb 2004 09:57:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0Tp-0000RZ-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 09:57:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0Su-0000LZ-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 09:56:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0S9-0000Gr-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 09:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0SA-00088p-87; Wed, 25 Feb 2004 09:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0RN-00086y-AG for mip6@optimus.ietf.org; Wed, 25 Feb 2004 09:55:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18944 for ; Wed, 25 Feb 2004 09:55:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0RL-00008x-00 for mip6@ietf.org; Wed, 25 Feb 2004 09:55:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0QR-0007n2-00 for mip6@ietf.org; Wed, 25 Feb 2004 09:54:16 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0PQ-0007ep-00 for mip6@ietf.org; Wed, 25 Feb 2004 09:53:12 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PErBqY005048 for ; Wed, 25 Feb 2004 15:53:11 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 15:53:11 +0100 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBPG05; Wed, 25 Feb 2004 15:53:11 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Feb 2004 15:53:09 +0100 Message-ID: X-Sybari-Trust: 45378188 c77f3eb6 0a449737 00000138 From: "Karen E. Nielsen (AH/TED)" To: mip6@ietf.org Subject: RE: [Mip6] I-D ACTION:draft-ietf-mip6-mipv6-mib-01.txt Date: Wed, 25 Feb 2004 15:53:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Feb 2004 14:53:11.0602 (UTC) FILETIME=[16BFC120:01C3FBAF] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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, I (still) find it diffecult to understand the mipv6nodetraffic counters and why they are part of the generic group, I do not suppose that these counters are relevant for a MN which is not a HA or a CN - ? Further It is unclear to me what the counters exactly cover. For the mipv6NodeInpkts, the phrase "The mipv6 packets received _for_ the mobile node" confuses me - does this refer to the packets which are intercepted on behalf of the mobile node (HA intercept) ? or packets egressing the MN=HA tunnel ? or simply packets received _from_ the MN ? Similar, wrt mipv6NodeOutOctets what does the phrase "The number of mipv6Node octets sent to the mobile node" mean - does it refer to ockets sent with routing header to the mobile node or ? Thanks, Karen > -----Original Message----- > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: 18. februar 2004 15:59 > Cc: mip6@ietf.org > Subject: [Mip6] I-D ACTION:draft-ietf-mip6-mipv6-mib-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Mobility for IPv6 Working > Group of the IETF. > > Title : The Mobile IPv6 MIB > Author(s) : G. Keeni, K. Nagami, K. Koide, S. Gundavelli > Filename : draft-ietf-mip6-mipv6-mib-01.txt > Pages : 59 > Date : 2004-2-18 > > This memo defines a portion of the Management Information > Base (MIB), the the Mobile-IPv6 MIB, for use with network > management protocols in the Internet community. In > particular, Mobile-IPv6 MIB will be used to monitor and > control Mobile Node, Home Agent and Correspondent Node > functions of an MIPv6 entity. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipv6-mib-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mip6-mipv6-mib-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip6-mipv6-mib-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 25 17:49:31 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 RAA20297 for ; Wed, 25 Feb 2004 17:49:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7pv-0003j9-Nk for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 17:49:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PMn3j2014326 for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 17:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7pv-0003iz-6z for mip6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 17:49:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20267 for ; Wed, 25 Feb 2004 17:48:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7ps-00001O-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 17:49:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7ot-0007j8-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 17:48:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7nv-0007dD-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 17:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7nw-0003D9-A0; Wed, 25 Feb 2004 17:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvxET-0007VI-Os for mip6@optimus.ietf.org; Wed, 25 Feb 2004 06:29:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11261 for ; Wed, 25 Feb 2004 06:29:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvxEP-0003Xj-00 for mip6@ietf.org; Wed, 25 Feb 2004 06:29:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvxDW-0003Rn-00 for mip6@ietf.org; Wed, 25 Feb 2004 06:28:43 -0500 Received: from myra.general.services.metu.edu.tr ([144.122.144.147]) by ietf-mx with esmtp (Exim 4.12) id 1AvxCd-0003LN-00; Wed, 25 Feb 2004 06:27:48 -0500 Received: from metu.edu.tr (ee-167-166.eee.metu.edu.tr [144.122.167.166]) by myra.general.services.metu.edu.tr (8.11.7/8.11.7) with ESMTP id i1PBRLB13692; Wed, 25 Feb 2004 13:27:27 +0200 (EET) Message-ID: <403C7A1A.7080200@metu.edu.tr> Date: Wed, 25 Feb 2004 12:34:02 +0200 From: Buyurman Baykal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Updated CFP for Med-Hoc-Net'04 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We apologize if you receive multiple copies of this message ------------------------------------------------------------------------------ ANNOUNCEMENTS: - PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004. - PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM ------------------------------------------------------------------------------ Med-Hoc-Net 2004 The Third Annual Mediterranean Ad Hoc Networking Workshop June 27-30, 2004, Bodrum, Turkey http://www.medhoc04/diit/unict.it Call for Papers ------------------------------------------------------------------------------ Scope: Ad hoc network applications are emerging continuously imposing their own stringent constraints which cannot be fulfilled by generic approaches and thus spur new research efforts. Therefore, ad hoc networks attract growing attention from the research community. The aim of Med-Hoc-Net 2004 is to serve as a platform for researchers and visionaries from academia, research labs, and industry from all over the globe to share their ideas, views, results, and experiences in the field of ad-hoc networking and communications. Med-Hoc-Net 2004 will include presentations of theoretical and experimental achievements, innovative ad-hoc systems, prototyping efforts, case studies, and advancements in technology directly affecting ad-hoc networking and communications infrastructures. The papers solicited in Med-Hoc-Net 2004 cover a variety of topics including but not limited to: - Novel ad-hoc network architectures and applications, - Sensor network applications and protocols, - Implementations, testbeds, and prototypes, - Interfacing ad-hoc systems with different networks, - Resource discovery and management, - Power management and control, - Call admission and traffic shaping policies for ad-hoc networks, - Multimedia location services, - Self organization and network reconfiguration, - Protocols for QoS support in ad-hoc networks, - QoS support in Bluetooth, HIPERLAN, IEEE 802.11 etc., - MAC protocols, scheduling, and radio resource sharing in ad hoc networks, - Unicast and multicast routing algorithms and protocols, - Transport layer protocols for multi-hop networks, - Congestion control, - Performance evaluation of ad-hoc network protocols through simulations, analysis, and measurements, - Security in ad-hoc networks, - Fault tolerance and error recovery - Signal processing algorithms (coding, compression) for ad-hoc networks The program committee will referee all papers, and accepted papers will be published in the conference proceedings. Papers of particular merit will be published in the Elsevier Ad Hoc Networks Journal. Manuscripts must be formatted according to the IEEE double-column standard format, except the font size, which must be 11pt. Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or their equivalent. The maximum length of the manuscript is 12 pages. NEW: THE PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004 PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM Papers should be submitted in pdf or ps format through EDAS system (http://edas.info) according to the following timetable: Important Dates: Full Paper Electronic Submission: March 12, 2004 Tutorial proposal submission: April 15, 2004 Notification of Acceptance/Rejection: May 3, 2004 Camera ready submission of full papers: May 17, 2004 Tutorial date: June 27, 2004 Conference dates: June 28-30, 2004 Organization Committee: General Chair: Ian F. Akyildiz, Georgia Institute of Technology, USA General Vice Chair: Erdal Cayirci, Istanbul Technical University, TURKEY Technical Program Chairs: Giacomo Morabito, University of Catania, ITALY Eylem Ekici, Ohio State University, USA Tutorial Chairs: Francesca Cuomo, University of Rome - La Sapienza, ITALY Christos Douligeris, University of Piraeus, GREECE Publicity Chairs: Buyurman Baykal, Middle East Technical University, TURKEY Jaudelice Cavalcante de Oliveira, Drexel University, USA Registration Chair: Sebnem Baydere, Yeditepe University, TURKEY Technical Program Committee: Khaldoun Al Agha, Laboratoire de Recherche en Informatique, FRANCE Hamid Aghvami, King's College London, UK Eitan Altman, INRIA, FRANCE Roberto Battiti, University of Trento, ITALY Raouf Boutaba, University of Waterloo, CANADA Walid Dabbous, INRIA, FRANCE Magda El Zarki, University of California at Irvine, USA Luigi Fratta, Politecnico di Milano, ITALY Mario Gerla, UCLA, USA Paul J. M. Havinga, University of Twente, NETHERLANDS Ahmed Helmy, University of Southern California, USA Farouk Kamoun, ENSI, TUNISIA Holger Karl, Technical University of Berlin, GERMANY Ulf Korner, Lund Institute of Technology, SWEDEN Bhaskar Krishnamachari, University of Southern California, USA Marwan Krunz, University of Arizona, USA Albert Levi, Sabanci University, TURKEY Janise McNair, University of Florida, USA Lazaros Merakos, University of Athens, GREECE Ioanis Nikolaidis, University of Alberta, CANADA Ariel Orda, Technion, ISRAEL Sergio Palazzo, University of Catania, ITALY Giovanni Pau, UCLA, USA Chiara Petrioli, University of Rome "La Sapienza", ITALY Andreas Pitsillides, University of Cyprus, CYPRUS Guy Pujolle, LIP6, FRANCE Paolo Santi, CNR, ITALY Adrian Segall, Technion, ISRAEL Ness Shroff, Purdue University, USA Moshe Sidi, Technion, ISRAEL Raghupathy Sivakumar, Georgia Institute of Technology, USA Ioannis Stavrakakis, University of Athens, GREECE Ivan Stojmenovic, University of Ottawa, CANADA Violet R. Syrotiuk, Arizona State University, USA Leandros Tassiulas, University of Thessaly, GREECE Damla Turgut, University of Central Florida, USA Bernhard H. Walke, Aachen University of Technology, GERMANY Wenye Wang, North Carolina State University, USA Michele Zorzi, University of Ferrara, ITALY _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Feb 25 18:58:49 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 SAA24805 for ; Wed, 25 Feb 2004 18:58:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8v2-0000Ux-1Q for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 18:58:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PNwOAt001915 for mip6-archive@odin.ietf.org; Wed, 25 Feb 2004 18:58:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8v1-0000Uo-Th for mip6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 18:58:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24802 for ; Wed, 25 Feb 2004 18:58:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8uy-0007gu-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 18:58:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw8u6-0007ar-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 18:57:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8tg-0007Tl-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 18:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8tg-0000J4-TK; Wed, 25 Feb 2004 18:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8so-0000Ew-5i for mip6@optimus.ietf.org; Wed, 25 Feb 2004 18:56:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24561 for ; Wed, 25 Feb 2004 18:56:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8sk-0007OW-00 for mip6@ietf.org; Wed, 25 Feb 2004 18:56:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw8rl-0007Cd-00 for mip6@ietf.org; Wed, 25 Feb 2004 18:55:02 -0500 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 1Aw8qm-0006yr-00 for mip6@ietf.org; Wed, 25 Feb 2004 18:54:00 -0500 Received: from ajamwal-u60.cisco.com (ajamwal-u60.cisco.com [128.107.132.155]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1PNrRuB011135; Wed, 25 Feb 2004 15:53:27 -0800 (PST) Date: Wed, 25 Feb 2004 15:53:27 -0800 (PST) From: Sri Gundavelli To: "Karen E. Nielsen (AH/TED)" cc: mip6@ietf.org Subject: RE: [Mip6] I-D ACTION:draft-ietf-mip6-mipv6-mib-01.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 On Wed, 25 Feb 2004, Karen E. Nielsen (AH/TED) wrote: > Hi, > > I (still) find it diffecult to understand the > mipv6nodetraffic counters and why they are part of > the generic group, The group is anchored under the stats sub group and that is a generic group for counters. > > I do not suppose that these counters are relevant > for a MN which is not a HA or a CN - ? > These counters are relevant from the point of view of a home agent. It reflects the traffic between the HA and the MN. > Further It is unclear to me what > the counters exactly cover. > > For the mipv6NodeInpkts, the phrase > "The mipv6 packets received _for_ the mobile node" > confuses me - does this refer to the packets which are intercepted > on behalf of the mobile node (HA intercept) ? > or packets egressing the MN=HA tunnel ? > or simply packets received _from_ the MN ? These are the packets intercepted by the HA for the MN. There is some terminology problem and we will fix that in our next submission. We tried to fix it in this version, but could not complete it. > > Similar, wrt mipv6NodeOutOctets what does the phrase > "The number of mipv6Node octets sent to the mobile node" > mean - does it refer to ockets sent with routing header to the mobile node > or ? All traffic from HA to the MN. Thanks for your review. We will fix the terminology and add more description to some of these objects. Thanks ! Sri/ > > Thanks, > Karen > > > -----Original Message----- > > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org]On Behalf Of > > Internet-Drafts@ietf.org > > Sent: 18. februar 2004 15:59 > > Cc: mip6@ietf.org > > Subject: [Mip6] I-D ACTION:draft-ietf-mip6-mipv6-mib-01.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Mobility for IPv6 Working > > Group of the IETF. > > > > Title : The Mobile IPv6 MIB > > Author(s) : G. Keeni, K. Nagami, K. Koide, S. Gundavelli > > Filename : draft-ietf-mip6-mipv6-mib-01.txt > > Pages : 59 > > Date : 2004-2-18 > > > > This memo defines a portion of the Management Information > > Base (MIB), the the Mobile-IPv6 MIB, for use with network > > management protocols in the Internet community. In > > particular, Mobile-IPv6 MIB will be used to monitor and > > control Mobile Node, Home Agent and Correspondent Node > > functions of an MIPv6 entity. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipv6-mib-01.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-mip6-mipv6-mib-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-mip6-mipv6-mib-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 26 00:00:45 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 AAA05689 for ; Thu, 26 Feb 2004 00:00:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDdC-0007Af-9A for mip6-archive@odin.ietf.org; Thu, 26 Feb 2004 00:00:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q50Iki027564 for mip6-archive@odin.ietf.org; Thu, 26 Feb 2004 00:00:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDdC-0007AV-2o for mip6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 00:00:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05674 for ; Thu, 26 Feb 2004 00:00:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwDd9-0004Nz-00 for mip6-web-archive@ietf.org; Thu, 26 Feb 2004 00:00:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwDcD-0004JX-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 23:59:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwDbx-0004FN-00 for mip6-web-archive@ietf.org; Wed, 25 Feb 2004 23:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDbx-00074b-1C; Wed, 25 Feb 2004 23:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwDbG-0006xs-F0 for mip6@optimus.ietf.org; Wed, 25 Feb 2004 23:58:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05620 for ; Wed, 25 Feb 2004 23:58:15 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwDbE-0004Eg-00 for mip6@ietf.org; Wed, 25 Feb 2004 23:58:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwDaO-0004Ae-00 for mip6@ietf.org; Wed, 25 Feb 2004 23:57:25 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AwDa2-00045a-00 for mip6@ietf.org; Wed, 25 Feb 2004 23:57:03 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1Q4v2t07507 for ; Thu, 26 Feb 2004 06:57:02 +0200 (EET) X-Scanned: Thu, 26 Feb 2004 06:56:55 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1Q4utls016511 for ; Thu, 26 Feb 2004 06:56:55 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 0094MbPA; Thu, 26 Feb 2004 06:56:54 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1Q4usO24112 for ; Thu, 26 Feb 2004 06:56:54 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 25 Feb 2004 20:56:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Feb 2004 22:56:53 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EFC67@daebe007.americas.nokia.com> Thread-Topic: Please review the following I-Ds for MIP6 meeting on March 1st Thread-Index: AcP8JPOyCxRj6+CfRDijWcUuUQLcOw== To: X-OriginalArrivalTime: 26 Feb 2004 04:56:53.0428 (UTC) FILETIME=[F3B56740:01C3FC24] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Please review the following I-Ds for MIP6 meeting on March 1st Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Please review the following I-Ds for the MIP6 WG meeting on Monday. draft-soliman-v4v6-mipv4-00.txt draft-tsirtsis-dsmip-problem-02.txt draft-ietf-mip6-mipv6-mib-01.txt draft-ietf-mip6-mipext-advapi-00.txt draft-haddad-mipv6-bub-01.txt draft-haddad-mipv6-omipv6-01.txt draft-le-mip6-firewalls-00.txt http://www.arkko.com/publications/mipv6/drafts/bootstrap.txt ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-auth-protocol-0= 1.txt ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-nai-option-01.t= xt draft-ohnishi-mip6-aaa-problem-statement-00.txt draft-le-aaa-mipv6-requirements-03.txt draft-jfaizan-mipv6-ha-reliability-01.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Feb 26 04:26:58 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 EAA00550 for ; Thu, 26 Feb 2004 04:26:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHmo-0004Hy-92 for mip6-archive@odin.ietf.org; Thu, 26 Feb 2004 04:26:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q9QUUs016470 for mip6-archive@odin.ietf.org; Thu, 26 Feb 2004 04:26:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHmm-0004HZ-Oc for mip6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 04:26:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00536 for ; Thu, 26 Feb 2004 04:26:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwHmj-0006IB-00 for mip6-web-archive@ietf.org; Thu, 26 Feb 2004 04:26:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwHlm-0006DN-00 for mip6-web-archive@ietf.org; Thu, 26 Feb 2004 04:25:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwHlP-00068q-00 for mip6-web-archive@ietf.org; Thu, 26 Feb 2004 04:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHlO-00048E-Aa; Thu, 26 Feb 2004 04:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHkq-00046O-9p for mip6@optimus.ietf.org; Thu, 26 Feb 2004 04:24:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00466 for ; Thu, 26 Feb 2004 04:24:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwHkn-00067J-00 for mip6@ietf.org; Thu, 26 Feb 2004 04:24:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwHjp-00061o-00 for mip6@ietf.org; Thu, 26 Feb 2004 04:23:26 -0500 Received: from [211.225.219.76] (helo=nt6.introcom.net) by ietf-mx with smtp (Exim 4.12) id 1AwHjJ-0005x8-00 for mip6@ietf.org; Thu, 26 Feb 2004 04:22:53 -0500 Received: from younheehan (202.20.192.58) by nt6.introcom.net (211.225.219.76) with [Nmail V3.3 20021108(S)] for from ; Thu, 26 Feb 2004 18:23:14 +0900 Message-ID: <039c01c3fc4a$18dc8330$182f024b@younheehan> From: "Youn-Hee Han" To: , Date: Thu, 26 Feb 2004 18:22:46 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Subject: [Mip6] Current Schemes for Movement Detection Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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=3.3 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBhbGwsDQogDQpPdXIgdGVhbSBkaWQgd29yayBvbiBwZXJmb3JtYW5jZSBldmFsdWF0aW9u IG9mIGN1cnJlbnQgTUlQdjYgDQogbW92ZW1lbnQgZGV0ZWN0aW9uIChNRCkgc2NoZW1lcy4gDQog DQogV2UgaW1wbGVtZW50ZWQgNCBNRCBzY2hlbWVzIGFzIGZvbGxvd3M7DQoxKSBFQ1MgKEVhZ2Vy IENlbGwgU3dpdGNoaW5nKSwgDQoyKSBOVUQgbGlrZSwgDQogMykgMSBOUyBhbmQgdGltZW91dCwg DQogNCkgUkEgYmVhY29uaW5nLg0KICANCiBXZSBhbHNvIG1lYXN1cmVkIDEpIE1EIGRlbGF5IGFu ZCAyKSBFcnJvciByYXRlIG9mIA0KIGVhY2ggc2NoZW1lIG9uIGEgdGVzdGJlZC4gDQogDQogQWN0 dWFsbHksIHdlIGpvaW5lZCB0aGUgRVRTSSBJUHY2IElPUCB0ZXN0IGF0IGxhc3QgeWVhcg0KYW5k IGFza2VkIGVhY2ggTUlQdjYtaW1wbGVtZW50YXRpb24gdGVhbSBob3cgdG8gaW1wbGVtZW50DQpN RCBzY2hlbWUuIFN1cnByaXNpbmdseSwgZWFjaCB0ZWFtIHJlYWxpemVkIGl0IHRvdGFsbHkgZGlm ZmVyZW50bHkNCmFzIGZvbGxvd3M7DQoxKSBFQ1MgKEVhZ2VyIENlbGwgU3dpdGNoaW5nKSAtIDQg dGVhbXMNCjIpIE5VRCBsaWtlLCAtIDEgdGVhbQ0KMykgMSBOUyBhbmQgdGltZW91dCAtIDEgdGVh bQ0KNCkgUkEgYmVhY29uaW5nIC0gMSB0ZWFtLg0KIA0KV2UgdGhpbmsgRE5BIG1heSBiZSB0aGUg bmF0dXJhbCBwbGFjZSBmb3IgdGhpcyB3b3JrIA0KIGFuZCBtYW55IE1JUHY2IGVuZ2luZWVycy9y ZXNlYXJjaGVycyB3aWxsIGJlIGludGVyZXN0ZWQgaW4gdGhpcyB3b3JrLg0KIA0KV2UgdGhpbmsg dGhpcyB3b3JrIHdpbGwgaGVscCBmb2xrcyB0byB1bmRlcnN0YW5kIE1EIGJldHRlciANCiBhbmQg Y2FuIHNlcnZlIGFzIGEgdmFsdWFibGUgaW5wdXQgZm9yIEwyIHRyaWdnZXJzLCBmb3IgZXhhbXBs ZSANCiBJRUVFIDgwMi4yMS4gV2Ugd2lsbCBzaG93IGhvdyBNRCBwZXJmb3JtYW5jZSwgbm90IG9u bHkgc3BlZWQgDQogYnV0IGFsc28gcHJlY2lzaW9uLCBpbXByb3ZlZCB3aXRoIEwyIHRyaWdnZXIu DQogDQogV2UgZGlkbid0IHN1Ym1pdCBhIGRyYWZ0IHlldCBidXQgeW91IGNhbiBmaW5kIHRoZSBk b2N1bWVudCBvZiANCiBvdXIgd29yayBhdDogDQogIA0KIGh0dHA6Ly93d3cudGhpbmtvbndlYi5j b20vc2FpdC9NRC5wZGYNCiANCiBUaGFua3MuDQogDQogLSBZSA0KIA0KIA0KIA0KIA== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Feb 27 20:51: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 UAA10045 for ; Fri, 27 Feb 2004 20:51:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awtcx-0005N7-0J for mip6-archive@odin.ietf.org; Fri, 27 Feb 2004 20:50:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S1ooB3020643 for mip6-archive@odin.ietf.org; Fri, 27 Feb 2004 20:50:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awtcw-0005Mr-GY for mip6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 20:50:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10036 for ; Fri, 27 Feb 2004 20:50:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awtcu-0000uI-00 for mip6-web-archive@ietf.org; Fri, 27 Feb 2004 20:50:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awtby-0000o5-00 for mip6-web-archive@ietf.org; Fri, 27 Feb 2004 20:49:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwtbB-0000i8-00 for mip6-web-archive@ietf.org; Fri, 27 Feb 2004 20:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwtbB-0005C2-3F; Fri, 27 Feb 2004 20:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awtb0-0005BP-2S for mip6@optimus.ietf.org; Fri, 27 Feb 2004 20:48:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09989 for ; Fri, 27 Feb 2004 20:48:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awtax-0000gm-00 for mip6@ietf.org; Fri, 27 Feb 2004 20:48:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwtaP-0000ap-00 for mip6@ietf.org; Fri, 27 Feb 2004 20:48:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AwtZc-0000N4-00 for mip6@ietf.org; Fri, 27 Feb 2004 20:47:24 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1S1kbV15141; Fri, 27 Feb 2004 17:46:37 -0800 X-mProtect: <200402280146> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIPZdMN; Fri, 27 Feb 2004 17:46:34 PST Message-ID: <403FF5D7.6090308@iprg.nokia.com> Date: Fri, 27 Feb 2004 17:58:47 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alpesh Patel CC: mip6@ietf.org, gdommety@cisco.com, basavaraj.patil@nokia.com, kleung@cisco.com, chowdury@nortelnetworks.com, mkhalil@nortelnetworks.com, haseebak@nortelnetworks.com Subject: Re: [Mip6] [MIPv6] - New ID - NAI option in MIPv6 - draft-patel-mipv6-nai-option-01.txt References: <40326FB3.2000609@cisco.com> In-Reply-To: <40326FB3.2000609@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Alpesh, you probably should acknowledge the authors of draft-le-mobileip-naiv6-00.txt. I have made it available at http://people.nokia.net/vijayd/draft-le-mobileip-naiv6-00.txt the NAI option from the above draft. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Length | Sub-Type | NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ this draft was published in April 2001. Vijay Alpesh Patel wrote: > > Hi - > > A new ID is available for your reference. It defines a NAI option for > use in mobility control messages (mipv6). > > Location : > ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-nai-option-01.txt > > Abstract > > > This document defines new mobility option to identify mobility > entities using a network access identifier. This option can be > used in messages containing a mobility header. > > Your comments are welcome. > Alpesh > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Feb 27 21:00: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 VAA10495 for ; Fri, 27 Feb 2004 21:00:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwtlX-0005ra-P3 for mip6-archive@odin.ietf.org; Fri, 27 Feb 2004 20:59:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S1xhkl022532 for mip6-archive@odin.ietf.org; Fri, 27 Feb 2004 20:59:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwtlX-0005rL-Ft for mip6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 20:59:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10460 for ; Fri, 27 Feb 2004 20:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwtlV-0001zC-00 for mip6-web-archive@ietf.org; Fri, 27 Feb 2004 20:59:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awtkf-0001tH-00 for mip6-web-archive@ietf.org; Fri, 27 Feb 2004 20:58:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awtjr-0001nk-00 for mip6-web-archive@ietf.org; Fri, 27 Feb 2004 20:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awtjt-0005ly-5M; Fri, 27 Feb 2004 20:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awtjj-0005lg-QP for mip6@optimus.ietf.org; Fri, 27 Feb 2004 20:57:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10417 for ; Fri, 27 Feb 2004 20:57:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awtjh-0001mX-00 for mip6@ietf.org; Fri, 27 Feb 2004 20:57:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awtip-0001gn-00 for mip6@ietf.org; Fri, 27 Feb 2004 20:56:55 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Awti5-0001Tg-00 for mip6@ietf.org; Fri, 27 Feb 2004 20:56:09 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1S1tPe29100; Fri, 27 Feb 2004 17:55:25 -0800 X-mProtect: <200402280155> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkjatyq; Fri, 27 Feb 2004 17:55:22 PST Message-ID: <403FF7E7.3010803@iprg.nokia.com> Date: Fri, 27 Feb 2004 18:07:35 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alpesh CC: mip6@ietf.org, gdommety@cisco.com, basavaraj.patil@nokia.com, kleung@cisco.com, chowdury@nortelnetworks.com, mkhalil@nortelnetworks.com, haseebak@nortelnetworks.com Subject: Re: [Mip6] [MIPv6] - New I-D - Authentication mechanism in MIPv6 - draft-patel-mipv6-auth-protocol-01.txt References: <40326D46.5080105@cisco.com> In-Reply-To: <40326D46.5080105@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 again, acknowledge Charlie for the Authentication Data Sub-option from Mobile IPv6 draft 15 section 5.6 of http://people.nokia.net/vijayd/mip6/draft-ietf-mobileip-ipv6-15.txt 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | = Authentication Data (variable length) = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vijay Alpesh wrote: > > Hi - > > A new I-D are available for comments. It describes a hash based > authentication for MIPv6. > > Abstract This document defines new > mobility options to enable authentication between mobility > entities. These options can be used in addition to or in lieu of > IPsec to authenticate mobility messages as defined in [1]. > Location: > ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-auth-protocol-01.txt > > > Your comments are welcome. > Alpesh > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Feb 27 21:43:17 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 VAA12165 for ; Fri, 27 Feb 2004 21:43:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwuRF-0008P5-TR for mip6-archive@odin.ietf.org; Fri, 27 Feb 2004 21:42:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S2gnsm032299 for mip6-archive@odin.ietf.org; Fri, 27 Feb 2004 21:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwuRF-0008Os-Lj for mip6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 21:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12146 for ; Fri, 27 Feb 2004 21:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwuRC-0006oy-00 for mip6-web-archive@ietf.org; Fri, 27 Feb 2004 21:42:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwuQJ-0006jZ-00 for mip6-web-archive@ietf.org; Fri, 27 Feb 2004 21:41:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwuPU-0006dr-00 for mip6-web-archive@ietf.org; Fri, 27 Feb 2004 21:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwuPV-0008IG-51; Fri, 27 Feb 2004 21:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwuPK-0008Gw-I3 for mip6@optimus.ietf.org; Fri, 27 Feb 2004 21:40:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12105 for ; Fri, 27 Feb 2004 21:40:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwuPH-0006cu-00 for mip6@ietf.org; Fri, 27 Feb 2004 21:40:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwuON-0006Xc-00 for mip6@ietf.org; Fri, 27 Feb 2004 21:39:51 -0500 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 1AwuO2-0006Rv-00 for mip6@ietf.org; Fri, 27 Feb 2004 21:39:31 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2004 18:49:48 +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 i1S2ct4U021465; Fri, 27 Feb 2004 18:38:55 -0800 (PST) Received: from cisco.com (sjc-vpn4-171.cisco.com [10.21.80.171]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS66902; Fri, 27 Feb 2004 18:38:54 -0800 (PST) Message-ID: <403FFF3D.1050407@cisco.com> Date: Fri, 27 Feb 2004 18:38:53 -0800 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: Vijay Devarapalli CC: mip6@ietf.org, gdommety@cisco.com, basavaraj.patil@nokia.com, kleung@cisco.com, chowdury@nortelnetworks.com, mkhalil@nortelnetworks.com, haseebak@nortelnetworks.com Subject: Re: [Mip6] [MIPv6] - New I-D - Authentication mechanism in MIPv6 - draft-patel-mipv6-auth-protocol-01.txt References: <40326D46.5080105@cisco.com> <403FF7E7.3010803@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Sure. I was not aware of it - started following from a later ID. In next version -a Vijay Devarapalli wrote: > again, acknowledge Charlie for the Authentication Data Sub-option > from Mobile IPv6 draft 15 > > section 5.6 of > http://people.nokia.net/vijayd/mip6/draft-ietf-mobileip-ipv6-15.txt > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 4 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Security Parameters Index (SPI) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > = Authentication Data (variable length) = > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Vijay > > Alpesh wrote: > >> >> Hi - >> >> A new I-D are available for comments. It describes a hash based >> authentication for MIPv6. >> >> Abstract This document defines new >> mobility options to enable authentication between mobility >> entities. These options can be used in addition to or in lieu >> of IPsec to authenticate mobility messages as defined in [1]. >> Location: >> ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-auth-protocol-01.txt >> >> >> Your comments are welcome. >> Alpesh >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www.ietf.org/mailman/listinfo/mip6 > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Feb 28 07:34:33 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 HAA14993 for ; Sat, 28 Feb 2004 07:34:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax3fP-0000XN-Qy for mip6-archive@odin.ietf.org; Sat, 28 Feb 2004 07:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SCY3w3002064 for mip6-archive@odin.ietf.org; Sat, 28 Feb 2004 07:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax3fP-0000XD-LF for mip6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 07:34:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14962 for ; Sat, 28 Feb 2004 07:34:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax3fP-00001m-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 07:34:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax3eS-0007k2-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 07:33:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax3dV-0007do-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 07:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax3dS-0000Ml-56; Sat, 28 Feb 2004 07:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax3cU-0000GA-WE for mip6@optimus.ietf.org; Sat, 28 Feb 2004 07:31:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14828 for ; Sat, 28 Feb 2004 07:31:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax3cU-0007WR-00 for mip6@ietf.org; Sat, 28 Feb 2004 07:31:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax3bV-0007QK-00 for mip6@ietf.org; Sat, 28 Feb 2004 07:30:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ax3aZ-0007Km-00 for mip6@ietf.org; Sat, 28 Feb 2004 07:29:03 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 6911F6A908; Sat, 28 Feb 2004 14:28:58 +0200 (EET) Message-ID: <40408907.7000805@kolumbus.fi> Date: Sat, 28 Feb 2004 14:26:47 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: mip6@ietf.org, James Kempf Subject: Re: [Mip6] bootstrap problem definition References: <200402171458.i1HEwtSj000899@givry.rennes.enst-bretagne.fr> In-Reply-To: <200402171458.i1HEwtSj000899@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Francis and sorry to take so long to get back to your comments. Thanks for the comments, they were very relevant. Some discussion inline: > I have many comments about your bootstrap I-D: > - first the problems in the abstract and in the introduction > are not the same: in the abstract the home environment is dynamic Yes. This needs to be corrected. > and the mobile node does not know it enough. In the introduction > the only problem of the mobile node is that it has lost the context, > in particular the IPsec one (no security association of any type). > Of course the problem you described, what I call "dynamic bootstrap", > is even harder. Dynamic boostrap may be a good name for this. > - (1. intro) with IKEv1 the MN does not need to have a statically > defined home address and the reason you gave is wrong: the home > address is unknown during the phase 1. I agree that a static home > address is easier because it makes authorization rules static, but > this is not a requirement, just the case you have a chance to get > implemented (:-). Ok. > - dynamic home agent address discovery is a security nightmare: I agree > we should not rely on it. I agree that its a security problem, but its also possible that a future protocol would be capable of providing home agent discovery without the problems ;-) > - (2. MIPv6 conf) all MN-HA mobility signaling (not communications) are > required to be protected by IPsec. Right. Thanks for catching this. > - (3.1.1. Dyn H@ Assignment) dynamically assigned is not the opposite > of statically configurated. And there are known extensions (widely > implemented but not standardized) of IKEv1 to support dynamically > assigned "internal" addresses. Ok. In IKEv2 this supposed to change, as there will be a standard. > - Home prefix change is not a valid issue because the home agent can > infer the new home address from the old one. True. But it still needs to do something, i.e., "infer". > - Same for duplicate address collision because the authorization stuff > can, when it occurs, accept any address which is not in use or > authorized for another client. Right, but once again there needs to be some behaviour in the home agent to handle this. > - I don't understand the "addressing privacy" issue: the home address > can be a RFC 3041 one. This even makes dynamic authorization easy > (first come first served)... It is easy, but once again both end points have to do something (setup appropriate policy entries) and we also need to specify somewhere that the home agent should do FCFS. > - (3.1.2 Dyn HA@ assignment) this is only about manual keying, isn't it? > (note that IMHO the manual keying is very incompatible with dynamic > bootstrap, I'd like to focus on the IKE case) That's a good constraint for the work, I agree. But dynamic home agent assignment isn't necessarily solved by just using IKE. Once more you have to have policy entries in place. Maybe not a big deal, but it has to get done (and specified so that we can rely on this to be the standard functionality). > - (3.2.1 AAA) Even I agree that IKE should be clearly integrated with > an AAA system your statement that it can work only with certificates > is not true. Our text is too unclear here. I'm not even myself sure what this sentence meant. But I think we can agree on the following: - It would be desireable to integrate a MIPv6 home agent security system with AAA (on an optional basis; end-to-end security should still be possible) - AAA integration in IKEv1 is generally non-existent or at least non-standardized. - AAA integration in IKEv2 should work at least if EAP authentication is used. There's currently no "IKEv2 AAA" application defined, but I think RFC 3579 (RADIUS EAP) or draft-ietf-aaa-eap-04.txt (Diameter EAP) should work. One caveat: I'm not sure we have defined link layer or service type for IPsec gateways anywhere. But that's a small detail. > - Interconnected PKIs are poor replacements for a real AAA infrastructure > but they (can) work. Yes. > - IMHO the main advantage of an AAA infrastructure is some security > properties for the care-of address, perhaps this is the only way > to get more than a return routability check (included in IKE which > uses many messages in both ways :-). Perhaps, though I'd have to see the specific side-by-side comparisons on required roundtrips and security properties. And this would only work if the mobile and correspondent nodes were both under the same AAA or at least roaming infrastructure; this may be quite an assumption. But I agree that in theory at least AAA could be used to provide some assurance of address validity. In any case, we can mention this issue in the draft as one potential advantage. I do think there are others, however, the main one being that most users typically have some sort of a subscription within an AAA system whereas most users don't yet have any MIPv6 SAs. > - NAI == USER-FQDN, the real issue is AAA and NAI are user oriented > when IKEv1 is system oriented. That's true. Another issue is availability of AAA applications and protocols that fit the authentication model in IKE. > - (3.2.2 Opp/Local discovery) The idea of using the DNS to get infos > about the home was in a very old message of someone from Digital > in this list (I can grep into my archive to find the reference). Please do! > - (3.3.1 Dormant mode MN) IPv6 prefix change is a matter of weeks > or months. IMHO the real issue is not with nodes in low power > dormant mode, but with MNs which are used every X months (every > IETF meetings for instance :-). I think I agree. > - (4. scenarios) The first scenario (no pre-existing relationship) > has a little chance to work with IKEv1 which requires strong > mutual authentication and authorization. Well, there's always opportunistic IPsec. But I agree its in general unworkable with the combination of MIPv6 and IKE, for reasons that we stated in the draft. > - the second one is interesting and should be shown to VPN server > sellers. IMHO this can be a good extension to standard VPNs, > and there is no home address assignment issue as VPN stuff in > general includes an "internal" address management. Yes. There could be different styles of address management here, as you point out the internal address might directly be the home address too. I suspect this might not be the only case, though. > - if I understand the third scenario, the idea is to use the local > AAA system for access control to do some kind of "local mobility"? No, you turn the relationship with the local AAA system into something else which can then be used for semi-long-term global mobility. Or at least for the duration that you are interested in the assigned home address. This is very similar to scenario 2, except that the existing SA comes from an access network, perhaps even access network that you use temporarily. > - I don't understand the fourth/last scenario: there is no way to > "turn" security associations. And IMHO IPsec people will be very > against any attempt to define this kind of things. "turn X into Y" = "generate a new Y based on X" Can you list some security concerns in this operation? > - you should add a reference to AAA/MIPv6 requirement document > (draft-le-aaa-mipv6-requirements-03.txt) which was resubmitted > by Frank Le (our editor) as AAA gives all you'd like: care-of > assignment, home agent assignment, home address assignment, > security properties for all of them, including for the care-of, > fast or very fast creation of the first IPsec SAs, etc. > So the (to come) solution document about dynamic bootstrap should > be only when an AAA infrastructure is not available/used (:-). Right. Thanks. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Feb 28 08:40:37 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 IAA16732 for ; Sat, 28 Feb 2004 08:40:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4hM-0004kP-R8 for mip6-archive@odin.ietf.org; Sat, 28 Feb 2004 08:40:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SDe8J3018243 for mip6-archive@odin.ietf.org; Sat, 28 Feb 2004 08:40:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4hM-0004kA-1w for mip6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 08:40:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16702 for ; Sat, 28 Feb 2004 08:40:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4hK-000703-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 08:40:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax4gL-0006ta-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 08:39:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4fK-0006j0-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 08:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4fI-0004XP-RS; Sat, 28 Feb 2004 08:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4eS-0004FM-4t for mip6@optimus.ietf.org; Sat, 28 Feb 2004 08:37:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16642 for ; Sat, 28 Feb 2004 08:37:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4eQ-0006hw-00 for mip6@ietf.org; Sat, 28 Feb 2004 08:37:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax4dV-0006d6-00 for mip6@ietf.org; Sat, 28 Feb 2004 08:36:10 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4ck-0006Xy-00 for mip6@ietf.org; Sat, 28 Feb 2004 08:35:22 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 4816B6A909; Sat, 28 Feb 2004 15:35:19 +0200 (EET) Message-ID: <40409893.5010504@kolumbus.fi> Date: Sat, 28 Feb 2004 15:33:07 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: franck.le@nokia.com, mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] comments on draft-le-aaa-mipv6-requirements-03.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Franck and others, and thanks for submitting this document. I think we do need a discussion and requirements for AAA and MIPv6. Here are some comments based on reading your document: > Mobile IP defines a method that allows a Mobile Node to change its > point of attachment to the Internet with minimal service disruption. > But Mobile IP in itself does not provide any specific support for > mobility across different administrative domains, which limits the > applicability of Mobile IP in a large-scale commercial deployment. I think we need some new or different terms here. I'm not sure "mobility" is the right term above. Roaming or network access instead? You seem to use "roam" yourself further in the text. > AAA protocols such as Diameter precisely enable mobile users to roam > and obtain service in networks that may not necessarily be owned by > their home service provider. For Mobile IP to be deployed in > commercial networks, there therefore has to be AAA support for the > protocol. Technically, this is not exactly the case. There is no reason why you'd have to bind network access and mobility service together. In fact, doing so may limit the deployment of mobility to only those locations which offer a sufficiently updated network service, AAA infrastructure, and are willing to provide this service. Don't get me wrong -- I think AAA support for MIPv6 would be a good thing. Just that I think the stated reason is not as you write above. I believe the reason has more to do with the ease at which you can enroll yourself to a "Mobile IPv6" service. Here AAA can help, in different ways, not all necessarily binding access and mobility to each other. To give you a practical example, the use of EAP authentication is currently popular in many planned networks and protocols, such as 802.11 or PANA. Now, if you mobile node is doing EAP FOO authentication to get access, would we really need anything else than a way to do EAP FOO with your home agent as well? Both the access network and the home agent could then, independently, contact the user's authentication server using AAA protocols such as RADIUS or Diameter. [I'm not necessarily proposing this as the solution, but just trying to give you an example. It may not be such a great idea to put EAP into all sorts of protocols beyond network access. See draft-ietf-eap-rfc2284bis-09.txt for an applicability statement.] > When a client belonging to one administrative domain (called the > home domain) roams to another administrative domain (called the > foreign domain) and needs to use the local network resources, an > attendant in the foreign domain is likely to require that the > client provides some credentials that can be authenticated before > access to the resources is permitted. These credentials may be > something the foreign domain understands, but in most cases they > are assigned by, and understood only by the home domain, and may > be used for setting up secure channels with the mobile node. I agree that this is needed. But I'm not sure we need to set a requirement for this, as it is a feature which seems to be exhibited by most current or planned access networks. For instance, systems that employ 802.1X can do this. UMTS can do this. PANA can do this. Are you suggesting that where MIPv6 is used, these existing schemes have to be abandoned and replaced by something new? Or that a second local authentication needs to take place? Or maybe I'm missing something obvious... > A modification to the basic model that is required is the need to > support and utilize Local Security Associations. LSAs have been > recently introduced in IETF ([3], [5]). After an initial successful Some variants of this approach already exist in EAP methods that can do fast reauthentication or re-attachment. > The Diameter Mobile IPv6 Application is a new application extension Does this mean that a network which currently offers e.g. 802.11i + RADIUS + IPv6 would be unable to support Mobile IPv6 until the network has been upgraded to use Diameter? I would really like to promote Diameter usage, but realistically, I think we need assume that existing AAA networks are used too, and we should try to place as little new requirements on them as possible. For instance, is there a way where we could accommodate MIPv6 AAA requirements without requiring more than RADIUS EAP or Diameter EAP support at the AAA infrastructure? Or can we make some parts of the AAA exchange optional, so that you get *some* functionality even if you just do basic 802.1X + RADIUS. > - Either AAA server MUST be able to obtain, or to coordinate the > allocation of, a suitable IP address for the customer, upon > request by the customer > > - AAA servers MUST be able to identify the client by some means > other than its IP address > > And so are the derived ones such as: > > - Policy in the home domain may dictate that the home agent instead > of the AAAH manages the allocation of the home IP address for the > mobile node. AAA servers MUST be able to coordinate the allocation > of an IP address for the mobile node at least in this way. All of these requirements appear to be supported by Diameter NASREQ (for instance). > - In the Diameter support for MIPv6, mobiles nodes SHOULD use the > NAI Hmm... the NAI is more or less built-in to AAA protocols. But I think you mean that the mobile node - home agent communication SHOULD use the NAI? > This implies that at the initial registration the mobile node needs > to be authenticated and authorized, and mobility procedures need to > be performed (e.g. between the foreign agent and the home agent) to > guarantee the mobile node can use Mobile IP. Foreign agent? > As a result, latency is reduced > by handling the initial registration in conjunction with AAA and the > mobile IP mobility agents. I'm not sure I understood the procedure from this. So the initial exchange is between mobile node - foreign agent - home agent, and the subsequent exchanges use a reduced scheme? > Moreover, subsequent registrations, and authentication could be > optimized thanks to LSA. Re-use of an existing (local) SA across movements is possible, but there are a couple of interesting issues that you need to consider. For instance, some fast re-auth schemes in wireless LAN environments have suffered from issues discussed in Sections 1.4 and 1.4.1 of draft-ietf-eap-keying-01.txt. I'm not 100% convinced that we can optimize without losing some of the typical AAA authorization checks. It may be possible to do optimization for those cases where the home AAA explicitly informs the local AAA that e.g. no dynamic checks are being made. In conclusion, I think your document makes a good job at listing the requirements, but I see the following issues in front of us that we should discuss: 1) Is the "MIPv6 AAA" a replacement for existing AAA mechanisms designed for purely roaming (non-MIP) nodes? If not, we should concentrate only on the additional MIPv6-related requirements here and not on the basic access related requirements which form the majority of what you listed above. If yes, I see a big deployment problem. It would be better for mobile IPv6 to adapt to existing access networks than to try change them. 2) Can we live with RADIUS EAP and Diameter EAP for the network access part even for MIPv6 nodes? 3) What exactly are the MIPv6-specific features that we need from AAA? LSA? Maybe. The care-of address verification that Francis mentioned? Maybe. Piggybacking both BUs and access auth in the same messages, as suggested e.g. in draft-josefsson? (Not sure how that would work; IP is not up at the time you are doing EAP.) What else? --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Feb 28 09:22:41 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 JAA17467 for ; Sat, 28 Feb 2004 09:22:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5M5-0006k5-QK for mip6-archive@odin.ietf.org; Sat, 28 Feb 2004 09:22:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SEMDh4025911 for mip6-archive@odin.ietf.org; Sat, 28 Feb 2004 09:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5M5-0006jq-7W for mip6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 09:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17464 for ; Sat, 28 Feb 2004 09:22:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5M3-0002vd-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 09:22:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax5L7-0002qH-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 09:21:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5Kw-0002kk-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 09:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5Kw-0006eb-LR; Sat, 28 Feb 2004 09:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5KB-0006UH-EJ for mip6@optimus.ietf.org; Sat, 28 Feb 2004 09:20:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17431 for ; Sat, 28 Feb 2004 09:20:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5K9-0002jl-00 for mip6@ietf.org; Sat, 28 Feb 2004 09:20:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax5JE-0002e7-00 for mip6@ietf.org; Sat, 28 Feb 2004 09:19:17 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5Ir-0002Y6-00 for mip6@ietf.org; Sat, 28 Feb 2004 09:18:53 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id CFFD26A909; Sat, 28 Feb 2004 16:18:50 +0200 (EET) Message-ID: <4040A2C7.9080804@kolumbus.fi> Date: Sat, 28 Feb 2004 16:16:39 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ohnishi.hiroyuki@lab.ntt.co.jp, mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Ohnish and others, and thank you as well for submitting this requirements document. Like I said before, we need a discussion in this space. I generally agree with your requirements. Some comments below: > If MN moves across different administrative domains in a > commercial network, Mobile IPv6 requires AAA's support. As I stated before, strictly speaking, its network access that requires clients to have credentials and access networks to employ AAA. But as defined today at least, Mobile IPv6 does not require it. It maybe beneficial to have AAA support in MIPv6, though. And then we have another issue having the right type of credentials (e.g. passwords vs. IPsec SAs) for large-scale deployment. In fact, I sense that this is probably the crucial issue. Unless... access network providers want a piece of the "mobility business", i.e., want to be involved in the transactions for non-technical reasons. > it should be > noted that the informative description is not advocating or > recommending the same approach adopted to Mobile IPv4 to be used for > Mobile IPv6. This is wise. > 2.1 Roaming to foreign domain > > Mobile IPv6 supports MN's mobility. But if MN moves to a foreign > domain, the foreign domain requires the way of Authentication, > Authorization and Accounting. RFC2977 shows requirements for this > scheme. RFC2977 shows the applications of AAA to the Mobile IP, e.g. > the basic model, the local payment model, the local home agent model > and so on. When a node with HTTP support roams to a different domain, its going to need AAA or it won't get access. This does not necessarily mean that we have to add AAA support HTTP. So, I think it would be valuable to break down the above requirement in smaller pieces that talk about MIPv6 specific requirements. For instance, it may be that local home agent assignment is such a requirement. > A solution for dynamically and securely assigning > home address prefix to mobile node with involving an appropriate > authentication and authorization protocol is demanded. I agree, though I worry what this means protocol-wise. Right now, we would not like to add a new AAA feature to basic IPv6 discovery functions. Existing link layers aren't easily modified, and EAP may not be the appropriate vehicle to download a lot of material and parameters for IP layer functions. So how can we realize this function? > In Mobile IPv6 architecture, there is no FA unlike Mobile IPv4. The > fundamental problem that needs to be solved is to support the usage > cases described in Section 2 without introducing FA in Mobile IPv6. > This would lead to a need to define a MIPv6 Service Aware AAA > Attendant (MSAAA), which is an AAA attendant to provide AAA for > Mobile IPv6 service for MN. The MSAAA may be integrated with an AAA > attendant of other protocol or service, or may be integrated with > MIPv6 home agent, depending on Mobile IPv6 service models. The > protocol to transfer information between HA and AAA server is needed > in every above MSAAA deployment scenarios. I like the possibility of placing the MSAAA in the home agent. Placing them in the access network may limit deployment to just some specific network type that can be designed with this in mind. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Feb 28 17:38:05 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 RAA07097 for ; Sat, 28 Feb 2004 17:38:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxD5W-0000Ma-I4 for mip6-archive@odin.ietf.org; Sat, 28 Feb 2004 17:37:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SMbc6M001379 for mip6-archive@odin.ietf.org; Sat, 28 Feb 2004 17:37:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxD5V-0000Ls-Oq for mip6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 17:37:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07079 for ; Sat, 28 Feb 2004 17:37:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxD5T-0002Q0-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 17:37:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxD4h-0002Ia-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 17:36:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxD3x-0002Am-00 for mip6-web-archive@ietf.org; Sat, 28 Feb 2004 17:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxD3x-0008PH-A7; Sat, 28 Feb 2004 17:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwptP-00086p-Dc for mip6@optimus.ietf.org; Fri, 27 Feb 2004 16:51:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26505 for ; Fri, 27 Feb 2004 16:51:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwptN-0003U7-00 for mip6@ietf.org; Fri, 27 Feb 2004 16:51:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwpsQ-0003Oj-00 for mip6@ietf.org; Fri, 27 Feb 2004 16:50:35 -0500 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1Awprb-0003JW-00 for mip6@ietf.org; Fri, 27 Feb 2004 16:49:43 -0500 Received: from unknown (HELO eremmell) (elmic@sbcglobal.net@64.170.248.130 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 27 Feb 2004 21:49:42 -0000 From: "Ed Remmell" To: Cc: "Odile@Treck" , "Jimmy Zhang" Date: Fri, 27 Feb 2004 13:49:45 -0800 Message-ID: <000001c3fd7b$9dd93b50$0700a8c0@eremmell> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C3FD38.8FB5FB50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Mip6] MIPv6 issue (IPsec/IKE interaction) Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C3FD38.8FB5FB50 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Hello - We saw an interesting problem occur when we tested MIPv6 with IPsec/IKE: when the MN does a L3 move at the start of phase 2 SA negotiation with the HA, IKE Quick Mode does not complete. It may be our problem, it may be a spec issue. In any case, it is probably a good MIPv6 interop scenario. Please refer to attached packet capture "quickModeFailsAfterMove.pcap" which has filtered out everything except for the IKE messages. We saw this issue happen during our testing, because we set the policy lifetime (in seconds) to 120 seconds, the phase 1 ISAKMP and phase 2 IPsec SAs were re-keyed very frequently (every 90 seconds or so). When we tested, we had the MN register with the HA from a foreign link (K-bit in BU set to 1), this setup the phase 1 ISAKMP and phase 2 IPsec SAs between the MN and HA. Then we had the MN move home. The SAs are maintained while the MN is home. Then we had KameCN start a FTP MGET of a large file from the MN (MN is FTP server). During this FTP, we had the MN move to foreign link. Refer to packet #7 in "quickModeFailsAfterMove.pcap", what is happening is that the MN is rekeying its phase 2 IPsec SAs (Quick Mode exachange), but it starts this *AFTER* it has moved to the foreign link so it is sending these from its care-of address 3ffe:ffff::20b:dbff:ffe94:83fc. The HA doesn't have any phase 1 ISAKMP SA associated with that care-of address, instead it has one associated with the MN's home address 3ffe:aaaa::bbbb (see packets #3-5) which was re-keyed while the MN was at home. So, the HA doesn't recognize these Quick Mode packets sent by the MN (because it hasn't yet received any BU K=1 from the MN); the MN retransmits Quick Mode (packets# 8-10) but the HA does not respond. Eventually the MN will timeout Quick Mode, and recover by re-keying the phase 1 ISAKMP SA. But, this can take a long time (2 minutes or so). BTW, we used our own HA-Lite simulator for this testing, because we are unaware of any open source MIPv6 HA that supports IPsec/IKE that we can use to test against. The BU must be protected using IPsec, so the IKE must complete first before it can be sent. It seems that in this scenario the MN should be able to use the old phase 2 IPsec SAs it had at home to protect the BU, to be able to register with the HA from the foreign link without needing to wait for Quick Mode to complete successfully. But, for some reason it didn't send the BU to the HA. Thanks. - Ed Remmell Treck, Inc. (formerly Elmic Systems, USA) Best of Show Winner, ESC 2003 Click on the link and take a look! http://cmp.iconvention.com/escshowdaily/v33/index.cvn?ID=10183 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.593 / Virus Database: 376 - Release Date: 2/20/2004 ------=_NextPart_000_0001_01C3FD38.8FB5FB50 Content-Type: application/octet-stream; name="quickModeFailsAfterMove.pcap" Content-Disposition: attachment; filename="quickModeFailsAfterMove.pcap" Content-Transfer-Encoding: base64 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAnHEAAEjnAwCCAAAAggAAAAAL25SD/AAA9GDOnYbdYAAA AABMEUA//qqqAAAAAAIA9P/+YM6dP/6qqgAAAAAAAAAAAAC7uwH0AfQATIJ7md/2o68m193Yvrnu LPfFUwgQBQFLc83RAAAARCXBbclSlT6l9tfjfvNAIRUthaIHWJCQ9DzVd4dVzC6M35EBlBU0ZTmt cQAA2ykEAIIAAACCAAAAAAD0YM6dAAvblIP8ht1gAAAAAEwRQD/+qqoAAAAAAAAAAAAAu7s//qqq AAAAAAIA9P/+YM6dAfQB9ABMQhmZ3/ajrybX3di+ue4s98VTCBAFAfuQQ2UAAABEBflc5Hfi81YI QUA4Gw1KrdEXHji+Clb38k5KETFiTLtsng0og6hC9ElyAAC/iAYATQEAAE0BAAAAC9uUg/wAAPRg zp2G3WAAAAABFxFAP/6qqgAAAAACAPT//mDOnT/+qqoAAAAAAAAAAAAAu7sB9AH0ARdGJwM9a3hJ d9AGAAAAAAAAAAABEAQAAAAAAAAAAQ8EAABAAAAAAQAAAAEAAAA0AQEAAQAAACwBAQAAgAEABYAC AAKAAwABgAQAAoALAAEADAAEAAABLIALAAKADIAACgAAhBBxRkO8cBycpXwQbhtAStJ4p7dFx7LS R4+mYss+f0TtqeEZGRgFG2Kd7+LiSCMSFKdPXU4+JT0FyItJqEUFkmFdqDzjbRjPTQHVBrwCAK6K 8uqcoYRC5ob9wIgD7e/SwGQwmk5tyy+fMx6B6U3ixoKblBa+fiUQExqzVnlrwmb3BQAAFCNHjh06 devWrFixY8ePHz4AAAAbAhEB9GhvbWVhZ2VudC5lbG1pYy5jb21JcgAAD4kGAGYBAABmAQAAAAD0 YM6dAAvblIP8ht1gAAAAATARQD/+qqoAAAAAAAAAAAAAu7s//qqqAAAAAAIA9P/+YM6dAfQB9AEw Bw8DPWt4SXfQBojD6QsFGVJCARAEAAAAAAAAAAEoBAAAQAAAAAEAAAABAAAANAEBAAEAAAAsAQEA AIABAAWAAgACgAMAAYAEAAKACwABAAwABAAAASyACwACgAyAAAoAAITHMpiJWeKHlLYsPt4HXR1M rIwkwbzI3FpK5AHjckpSMwMxqpj5PfHPWwUbC3wKB7J5qhG4n9e8o55706OEm4xYe64G/sYC0SOJ khaKeGKG3DuD6o2nCb9im8NLvs9X1C+N+fO7NVvm5O7sWwnY5HKZAssy5FOPteDW7TYjMBodUAUA ABRmzJgxY8aMGTNmzJgxY8ePCAAAHAMRAfRtb2JpbGVub2RlQGVsbWljLmNvbQAAABgQJEVjKrHs MnmkPZS5RUIr3uoGLklyAAB9iQYAcgAAAHIAAAAAC9uUg/wAAPRgzp2G3WAAAAAAPBFAP/6qqgAA AAACAPT//mDOnT/+qqoAAAAAAAAAAAAAu7sB9AH0ADybnQM9a3hJd9AGiMPpCwUZUkIIEAQAAAAA AAAAADQAAAAYzJ1/CiNkVwIstn7n/yM30CgR3HhJcgAAh4kGAJIAAACSAAAAAAvblIP8AAD0YM6d ht1gAAAAAFwRQD/+qqoAAAAAAgD0//5gzp0//qqqAAAAAAAAAAAAALu7AfQB9ABcLXMDPWt4SXfQ BojD6QsFGVJCCBAFAaFlFIgAAABUDHjt4CErZukQtnbvuRkHep7fXUTBRVaZgZXNlHgWJFrhx7P0 lkQpbwJetASBsl0gAOF0tUx07ShRcgAA16kGAHoBAAB6AQAAAAEDL3fgAAvblIP8ht1gAAAAAUQR QD/+//8AAAAAAgvb//6Ug/w//qqqAAAAAAIA9P/+YM6dAfQB9AFE0HIDPWt4SXfQBojD6QsFGVJC CBAgASGVM3sAAAE8tkzojggRHOnQ4rFEMnkmIGbKV/6OxRdeWgE4XxgNp9jj5acQ2g0EJddxF6B7 YOts1D/cRR/oH2a94kPYpFdFaNRqh3ma5V2hdg3HD0lqiYni1fKII/eG5l/wlKz/l3UaJ5BscLCl NODDdJYTp4Gb6/j5bMjPszqYJGIwf9Gvvod11SkGU8+zWBVrze37EjOd3QcWQkCVB3vUAPnoRv7U LI78j+mwyNI/dPFlqeoMhZ/M7EC+0R4aFeOMhcisZVMlXWPHgk13mdMsIw2Z6SSf3NPHT/hB0xtI x3RaDgL2isn/KgKoZBQaC3dYV4Ne4FAqS6LS9qvDeF03c5iy0tMaHEPypsH+JHJ8KuZSVUGi1H7r Re0PfuSpul18I4hPankEYHIAAFbkBgB6AQAAegEAAAABAy934AAL25SD/IbdYAAAAAFEEUA//v// AAAAAAIL2//+lIP8P/6qqgAAAAACAPT//mDOnQH0AfQBRNByAz1reEl30AaIw+kLBRlSQggQIAEh lTN7AAABPLZM6I4IERzp0OKxRDJ5JiBmylf+jsUXXloBOF8YDafY4+WnENoNBCXXcRege2DrbNQ/ 3EUf6B9mveJD2KRXRWjUaod5muVdoXYNxw9JaomJ4tXyiCP3huZf8JSs/5d1GieQbHCwpTTgw3SW E6eBm+v4+WzIz7M6mCRiMH/Rr76HddUpBlPPs1gVa83t+xIznd0HFkJAlQd71AD56Eb+1CyO/I/p sMjSP3TxZanqDIWfzOxAvtEeGhXjjIXIrGVTJV1jx4JNd5nTLCMNmekkn9zTx0/4QdMbSMd0Wg4C 9orJ/yoCqGQUGgt3WFeDXuBQKkui0varw3hdN3OYstLTGhxD8qbB/iRyfCrmUlVBotR+60XtD37k qbpdfCOIT2p5BH5yAABoWQcAegEAAHoBAAAAAQMvd+AAC9uUg/yG3WAAAAABRBFAP/7//wAAAAAC C9v//pSD/D/+qqoAAAAAAgD0//5gzp0B9AH0AUTQcgM9a3hJd9AGiMPpCwUZUkIIECABIZUzewAA ATy2TOiOCBEc6dDisUQyeSYgZspX/o7FF15aAThfGA2n2OPlpxDaDQQl13EXoHtg62zUP9xFH+gf Zr3iQ9ikV0Vo1GqHeZrlXaF2DccPSWqJieLV8ogj94bmX/CUrP+XdRonkGxwsKU04MN0lhOngZvr +PlsyM+zOpgkYjB/0a++h3XVKQZTz7NYFWvN7fsSM53dBxZCQJUHe9QA+ehG/tQsjvyP6bDI0j90 8WWp6gyFn8zsQL7RHhoV44yFyKxlUyVdY8eCTXeZ0ywjDZnpJJ/c08dP+EHTG0jHdFoOAvaKyf8q AqhkFBoLd1hXg17gUCpLotL2q8N4XTdzmLLS0xocQ/Kmwf4kcnwq5lJVQaLUfutF7Q9+5Km6XXwj iE9qeQSrcgAAAwkIAHoBAAB6AQAAAAEDL3fgAAvblIP8ht1gAAAAAUQRQD/+//8AAAAAAgvb//6U g/w//qqqAAAAAAIA9P/+YM6dAfQB9AFE0HIDPWt4SXfQBojD6QsFGVJCCBAgASGVM3sAAAE8tkzo jggRHOnQ4rFEMnkmIGbKV/6OxRdeWgE4XxgNp9jj5acQ2g0EJddxF6B7YOts1D/cRR/oH2a94kPY pFdFaNRqh3ma5V2hdg3HD0lqiYni1fKII/eG5l/wlKz/l3UaJ5BscLClNODDdJYTp4Gb6/j5bMjP szqYJGIwf9Gvvod11SkGU8+zWBVrze37EjOd3QcWQkCVB3vUAPnoRv7ULI78j+mwyNI/dPFlqeoM hZ/M7EC+0R4aFeOMhcisZVMlXWPHgk13mdMsIw2Z6SSf3NPHT/hB0xtIx3RaDgL2isn/KgKoZBQa C3dYV4Ne4FAqS6LS9qvDeF03c5iy0tMaHEPypsH+JHJ8KuZSVUGi1H7rRe0PfuSpul18I4hPankE ------=_NextPart_000_0001_01C3FD38.8FB5FB50-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 02:13:15 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 CAA09148 for ; Sun, 29 Feb 2004 02:13:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxL82-0000om-2v for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 02:12:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T7CkCx003144 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 02:12:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxL81-0000oO-LM for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 02:12:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09106 for ; Sun, 29 Feb 2004 02:12:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxL7y-0006mw-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 02:12:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxL75-0006i2-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 02:11:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxL6N-0006cm-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 02:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxL6L-0000BE-7g; Sun, 29 Feb 2004 02:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxL63-000067-Mx for mip6@optimus.ietf.org; Sun, 29 Feb 2004 02:10:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08211 for ; Sun, 29 Feb 2004 02:10:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxL60-0006ao-00 for mip6@ietf.org; Sun, 29 Feb 2004 02:10:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxL59-0006Vt-00 for mip6@ietf.org; Sun, 29 Feb 2004 02:09:48 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AxL4N-0006K7-00 for mip6@ietf.org; Sun, 29 Feb 2004 02:08:59 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTU007013U5TL@mailout3.samsung.com> for mip6@ietf.org; Sun, 29 Feb 2004 16:08:29 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTU002RI3U5VE@mailout3.samsung.com> for mip6@ietf.org; Sun, 29 Feb 2004 16:08:29 +0900 (KST) Received: from Alperyegin ([124.232.210.3]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTU00KW63U5P3@mmp2.samsung.com> for mip6@ietf.org; Sun, 29 Feb 2004 16:08:29 +0900 (KST) Date: Sat, 28 Feb 2004 23:08:29 -0800 From: Alper Yegin To: mip6@ietf.org Message-id: <000001c3fe92$d5678f00$e22f10ac@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Mip6] Comments on kempf-mip6-bootstrap Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hello James, Jari, I've just read the draft. Please see my comments below. With IKEv1, the mobile node needs to have a statically defined home address in order that the home agent can make an authorization decision and identify the credentials during the IKE Phase 1 ISAKMP exchange. In this document, we discuss why these constraints may be problematic in some deployment scenarios. IKEv2 allows named SPIs with address selectors set to NULL. Names can be NAI and FQDN. If we use IKEv2, do we still have a problem? However, support for dynamic home address assignment would be desirable for the following reasons: DHCP-based address assignment Some ISPs may want to use DHCPv6 from the home network to configure home addresses [7]. I think we are concerned that the MN might get different DHCP addresses each time it asks for one. Note that deployments can ensure that the host (MN) gets the same IP address (home address) by supplying a client-id with DHCP requests. So, this may not be a problem. Currently, the address of the home agent is specified in the security policy database. Support for multiple home agents requires the configuration of multiple security policy database entries. We are talking about SPDs on the MN, right? If so, is this a problem? MN can set the HA address in the SPD once it determines which HA it will be using. The challenge is, I think, bootstrapping the keys for a given HA. Ease of deployment ISP may want to allow "opportunistic" discovery and utilization of its mobility services without any prearranged contact. These scenarios will require dynamic home address assignment. ... and keys. The current IKEv1-based dynamic key exchange protocol described in [5] has no integration with backend authentication, authorization and accounting techniques unless the authentication credentials and trust relationships use certificates. Isn't this an implementation issue? For example can't I use LDAP to retrieve the keys for a MN when my HA receives an IKE request? Well, there isn't a RADIUS or Diameter application for this scenario, maybe this is what you mean. But I think this doesn't require integration of IKE with RADIUS/Diameter. Using certificates may require the ISP to deploy a PKI, which may not be possible or desirable in certain circumstances. Where a traditional AAA infrastructure is used, the home agent is not able to leverage authentication and authorization information established between the mobile node, the foreign AAA server, and the home AAA server when the mobile node gains access to the foreign network, in order to authenticate the mobile node's identity and determine if the mobile node is authorized for mobility service. This is talking about integration of AAA for network access and AAA for mobility management. I think "AAA for mobility management" does not necessarily imply this level of integration. The lack of connection to the AAA infrastructure also means the home agent does not know where to issue accounting records at appropriate times during the mobile node's session, as determined by the business relationship between the home ISP and the mobile node's owner. Presumably, some backend AAA protocol between the home agent and home AAA could be utilized but IKEv1 does not contain support for exchanging the right kind of information, primarily the NAI [6], with the mobile node. Mobility management and network access are two separate services. We shouldn't assume they have to be integrated. The home agent discovery protocol does not support "opportunistic" or local discovery mechanisms in a roaming partner's local access network. It is expected that the mobile node must know the prefix of the home subnet in order to be able to discover a home agent, it must either obtain that information through prefix update or have it statically configured. A more typical pattern for interdomain service discovery in the Internet is that the client (mobile node in this case) knows the domain name of the service, and uses DNS in some manner to find the server in the other domain. For local service discovery, DHCP is typically used. If HAs are located on the visited links, then the current dynamic home agent discovery is good enough. If they are somewhere deeper in the access network, then a DHCP-based discovery, or what HMIP approach can be utilized. Another scenario involves turning an existing security association in the user's home network for a different purpose into a new security association suitable for protecting Mobile IPv6. For instance, an existing security association for a VPN service could be used to generate suitable Mobile IPv6 security associations, on a first-come-first-served home address basis. Wouldn't some (most?) problems we encountered with the Mobile IPv6 service also apply to the VPN service? For instance, when the mobile node boots and connects to the network for the first time, it could create a security association with the access operator's home agent. This home agent could then be used as the mobile node moves into a different position or even into a different access network. We are applying this type of a technique to the DHCP security problem. Please see draft-yegin-eap-boot-rfc3118-00.txt Regards, Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 06:14:15 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 GAA16387 for ; Sun, 29 Feb 2004 06:14:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxOtI-0007DF-7W for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 06:13:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TBDmpQ027719 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 06:13:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxOtI-0007D0-0T for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 06:13:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16376 for ; Sun, 29 Feb 2004 06:13:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxOtE-00046x-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 06:13:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxOsJ-00042W-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 06:12:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxOrX-0003yW-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 06:11:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxOrZ-00075C-0f; Sun, 29 Feb 2004 06:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxOrL-00074s-Rb for mip6@optimus.ietf.org; Sun, 29 Feb 2004 06:11:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16364 for ; Sun, 29 Feb 2004 06:11:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxOrI-0003xW-00 for mip6@ietf.org; Sun, 29 Feb 2004 06:11:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxOqJ-0003tW-00 for mip6@ietf.org; Sun, 29 Feb 2004 06:10:44 -0500 Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx with esmtp (Exim 4.12) id 1AxOpO-0003lz-00 for mip6@ietf.org; Sun, 29 Feb 2004 06:09:46 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.204]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0HTU00K4DERZPS@dns2.cselt.it> for mip6@ietf.org; Sun, 29 Feb 2004 12:04:47 +0100 (MET) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Sun, 29 Feb 2004 12:08:21 +0100 Received: from EXC2K05A.cselt.it ([163.162.36.101]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Sun, 29 Feb 2004 12:08:20 +0100 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K05A.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Sun, 29 Feb 2004 12:09:15 +0100 Date: Sun, 29 Feb 2004 12:09:14 +0100 From: Giaretta Gerardo Subject: RE: [Mip6] comments on draft-le-aaa-mipv6-requirements-03.txt To: Jari Arkko Cc: franck.le@nokia.com, mip6@ietf.org Message-id: <625BE97BF4795E43970345790166B9BCD4DCE1@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] comments on draft-le-aaa-mipv6-requirements-03.txt Thread-Index: AcP+ACRfAUCSNRJ/QZmBzQez8UxCoQArwzsQ content-class: urn:content-classes:message X-OriginalArrivalTime: 29 Feb 2004 11:09:15.0747 (UTC) FILETIME=[7801FB30:01C3FEB4] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jari and Franck, >=20 > Technically, this is not exactly the case. There is no reason=20 > why you'd > have to bind network access and mobility service together. In fact, > doing so may limit the deployment of mobility to only those locations > which offer a sufficiently updated network service, AAA=20 > infrastructure, > and are willing to provide this service. >=20 > Don't get me wrong -- I think AAA support for MIPv6 would be a good > thing. Just that I think the stated reason is not as you write above. > I believe the reason has more to do with the ease at which you can > enroll yourself to a "Mobile IPv6" service. Here AAA can help, in > different ways, not all necessarily binding access and mobility to > each other. >=20 This is exactly what I would say in my previous post (maybe I have been = less clear). =09 I think that network access authorization and "Mobile IPv6 service" = authorization should not be bound together; indeed I think it is = desirable to authorize the use of "Mobile IPv6" service separately from = the network access authorization. > > To give you a practical example, the use of EAP authentication is > currently popular in many planned networks and protocols, such as > 802.11 or PANA. Now, if you mobile node is doing EAP FOO=20 > authentication > to get access, would we really need anything else than a way to > do EAP FOO with your home agent as well? Both the access network > and the home agent could then, independently, contact the user's > authentication server using AAA protocols such as RADIUS or Diameter. I think this could be a very good approach...=20 > > The Diameter Mobile IPv6 Application is a new=20 > application extension >=20 > Does this mean that a network which currently offers e.g. 802.11i + > RADIUS + IPv6 would be unable to support Mobile IPv6 until the network > has been upgraded to use Diameter? I would really like to promote > Diameter usage, but realistically, I think we need assume=20 > that existing > AAA networks are used too, and we should try to place as little new > requirements on them as possible. >=20 > For instance, is there a way where we could accommodate MIPv6 AAA > requirements without requiring more than RADIUS EAP or Diameter EAP > support at the AAA infrastructure? Or can we make some parts of the > AAA exchange optional, so that you get *some* functionality even > if you just do basic 802.1X + RADIUS. > Well, I know we are talking about requirements and not about solutions, = but we have proposed (see = http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap= -00.txt) a way to authorize and configure Mobile IPv6 based on EAP. = MIPv6 information are carried by EAP-TLV and for this reason the = solution requires only RADIUS EAP or Diameter EAP. Only AAAH - HA = communication needs a new Diameter Application. Moreover, also this new = application could be avoided if, as you said, we have a way to do EAP = between MN and HA. Regards, --Gerardo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 06:51:18 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 GAA17484 for ; Sun, 29 Feb 2004 06:51:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPT9-0000vu-Pc for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 06:50:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TBopaD003580 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 06:50:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPT9-0000vf-Kn for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 06:50:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17474 for ; Sun, 29 Feb 2004 06:50:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxPT5-00077s-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 06:50:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxPSD-00072d-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 06:49:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxPRK-0006xZ-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 06:48:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPRN-0000nn-P6; Sun, 29 Feb 2004 06:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPRN-0000nc-4V for mip6@optimus.ietf.org; Sun, 29 Feb 2004 06:49:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17411 for ; Sun, 29 Feb 2004 06:48:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxPRJ-0006xG-00 for mip6@ietf.org; Sun, 29 Feb 2004 06:48:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxPQT-0006rv-00 for mip6@ietf.org; Sun, 29 Feb 2004 06:48:06 -0500 Received: from minos.ocn.ne.jp ([211.129.13.148] helo=smtp.minos.ocn.ne.jp) by ietf-mx with esmtp (Exim 4.12) id 1AxPPr-0006ll-00 for mip6@ietf.org; Sun, 29 Feb 2004 06:47:27 -0500 Received: from [127.0.0.1] (unknown [218.37.231.194]) by smtp.minos.ocn.ne.jp (Postfix) with ESMTP id 65B431DEF; Sun, 29 Feb 2004 20:47:22 +0900 (JST) Date: Sun, 29 Feb 2004 20:49:04 +0900 From: Hiroyuki OHNISHI To: Jari Arkko Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt Cc: mip6@ietf.org In-Reply-To: <4040A2C7.9080804@kolumbus.fi> References: <4040A2C7.9080804@kolumbus.fi> Message-Id: <20040229194536.4597.OHNISHI.HIROYUKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Jari, Thank you for your comments. On Sat, 28 Feb 2004 16:16:39 +0200 Jari Arkko wrote: > > Hi Ohnish and others, and thank you as well for submitting this > requirements document. Like I said before, we need a discussion > in this space. > > I generally agree with your requirements. Some comments below: > > > If MN moves across different administrative domains in a > > commercial network, Mobile IPv6 requires AAA's support. > > As I stated before, strictly speaking, its network access that > requires clients to have credentials and access networks to employ > AAA. > > But as defined today at least, Mobile IPv6 does not require it. > It maybe beneficial to have AAA support in MIPv6, though. > As you mentioned, "roaming" is related to network access control. I think AAA for network access and AAA for Mobile IPv6 are different. Since this sentense seems to imply AAA for network access, I think it is better to delete this sentense. > And then we have another issue having the right type of credentials > (e.g. passwords vs. IPsec SAs) for large-scale deployment. In fact, > I sense that this is probably the crucial issue. > > Unless... access network providers want a piece of the "mobility > business", i.e., want to be involved in the transactions for > non-technical reasons. > > > it should be > > noted that the informative description is not advocating or > > recommending the same approach adopted to Mobile IPv4 to be used for > > Mobile IPv6. > > This is wise. > > > 2.1 Roaming to foreign domain > > > > Mobile IPv6 supports MN's mobility. But if MN moves to a foreign > > domain, the foreign domain requires the way of Authentication, > > Authorization and Accounting. RFC2977 shows requirements for this > > scheme. RFC2977 shows the applications of AAA to the Mobile IP, e.g. > > the basic model, the local payment model, the local home agent model > > and so on. > > When a node with HTTP support roams to a different domain, its going > to need AAA or it won't get access. This does not necessarily mean > that we have to add AAA support HTTP. So, I think it would be valuable > to break down the above requirement in smaller pieces that talk about > MIPv6 specific requirements. For instance, it may be that local home > agent assignment is such a requirement. > As you mentioned, local home agent assignment is one requirement. And local home assignment and bootstrapping betwenn local HA and MN are also requirements. These requirements can be stated in 2.3-2.4. So I can delete this section 2.1. But I am not sure how AAA for Mobile IPv6 should be related to AAA for network access now. > > A solution for dynamically and securely assigning > > home address prefix to mobile node with involving an appropriate > > authentication and authorization protocol is demanded. > > I agree, though I worry what this means protocol-wise. Right now, > we would not like to add a new AAA feature to basic IPv6 discovery > functions. Existing link layers aren't easily modified, and EAP may > not be the appropriate vehicle to download a lot of material and > parameters for IP layer functions. So how can we realize this > function? I assume using some host configuration protocols to assign such kind of Mobile IPv6 specific information. > > > In Mobile IPv6 architecture, there is no FA unlike Mobile IPv4. The > > fundamental problem that needs to be solved is to support the usage > > cases described in Section 2 without introducing FA in Mobile IPv6. > > This would lead to a need to define a MIPv6 Service Aware AAA > > Attendant (MSAAA), which is an AAA attendant to provide AAA for > > Mobile IPv6 service for MN. The MSAAA may be integrated with an AAA > > attendant of other protocol or service, or may be integrated with > > MIPv6 home agent, depending on Mobile IPv6 service models. The > > protocol to transfer information between HA and AAA server is needed > > in every above MSAAA deployment scenarios. > > I like the possibility of placing the MSAAA in the home agent. > Placing them in the access network may limit deployment to > just some specific network type that can be designed with this in > mind. > If MN knows HA's address, you can deploy MSAAA into HA. But I want to handle dynamic HA address assignment scenario. In that case, I think deployment of MSAAA to HA does not work well. 1-- Hiroyuki > --Jari > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 -- Hiroyuki OHNISHI _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 07:35:28 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 HAA19149 for ; Sun, 29 Feb 2004 07:35:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQ9r-0005VI-2D for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 07:34:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TCYxZf021156 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 07:34:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQ9q-0005V9-Uk for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 07:34:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19142 for ; Sun, 29 Feb 2004 07:34:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQ9q-0004Wg-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 07:34:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQ8w-0004Rj-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 07:34:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxQ7z-0004M8-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 07:33:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQ7x-0005Jv-D7; Sun, 29 Feb 2004 07:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxQ7q-0005IY-Mb for mip6@optimus.ietf.org; Sun, 29 Feb 2004 07:32:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19108 for ; Sun, 29 Feb 2004 07:32:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxQ7q-0004LJ-00 for mip6@ietf.org; Sun, 29 Feb 2004 07:32:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxQ6s-0004Gi-00 for mip6@ietf.org; Sun, 29 Feb 2004 07:31:54 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxQ6B-0004CJ-00 for mip6@ietf.org; Sun, 29 Feb 2004 07:31:11 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id CD0286A90B; Sun, 29 Feb 2004 14:31:08 +0200 (EET) Message-ID: <4041D7DD.6070503@kolumbus.fi> Date: Sun, 29 Feb 2004 14:15:25 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hiroyuki OHNISHI Cc: mip6@ietf.org Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt References: <4040A2C7.9080804@kolumbus.fi> <20040229194536.4597.OHNISHI.HIROYUKI@lab.ntt.co.jp> In-Reply-To: <20040229194536.4597.OHNISHI.HIROYUKI@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hiroyuki and thanks for your quick response! What you say seems reasonable. Just continuing on one item below: >>> A solution for dynamically and securely assigning >>> home address prefix to mobile node with involving an appropriate >>> authentication and authorization protocol is demanded. >> >>I agree, though I worry what this means protocol-wise. Right now, >>we would not like to add a new AAA feature to basic IPv6 discovery >>functions. Existing link layers aren't easily modified, and EAP may >>not be the appropriate vehicle to download a lot of material and >>parameters for IP layer functions. So how can we realize this >>function? > > I assume using some host configuration protocols to assign such kind of > Mobile IPv6 specific information. Can you name some specific example as to what protocol you are thinking? Presumably, the information would have to be secured somehow, at least if you are handing out keys to access the home agent. DHCP? ND, but that would presumably not be secure? SEND? EAP TLVs? 802.11 IEs? --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 10:45:30 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 KAA27601 for ; Sun, 29 Feb 2004 10:45:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxT7m-0002bP-Vo for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 10:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TFj21V009971 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 10:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxT7k-0002ak-9k for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 10:45:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27587 for ; Sun, 29 Feb 2004 10:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxT7h-0000oA-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 10:44:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxT6l-0000gl-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 10:44:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxT5q-0000Z7-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 10:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxT5p-0002DC-PZ; Sun, 29 Feb 2004 10:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxT59-0002A7-EK for mip6@optimus.ietf.org; Sun, 29 Feb 2004 10:42:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27487 for ; Sun, 29 Feb 2004 10:42:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxT56-0000U7-00 for mip6@ietf.org; Sun, 29 Feb 2004 10:42:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxT4N-0000Mz-00 for mip6@ietf.org; Sun, 29 Feb 2004 10:41:32 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxT3Z-0000Eo-00 for mip6@ietf.org; Sun, 29 Feb 2004 10:40:41 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7FE1C6A908; Sun, 29 Feb 2004 17:40:36 +0200 (EET) Message-ID: <40420770.2000403@kolumbus.fi> Date: Sun, 29 Feb 2004 17:38:24 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt Cc: mip6@ietf.org References: <001b01c3ee73$aa4f9da0$5347038d@tm.unikarlsruhe.de> <4027C703.2080209@hp.com> <021d01c3efe8$15f14390$5347038d@tm.unikarlsruhe.de> <403024A4.6020006@kolumbus.fi> <020001c3f4a2$faeb74c0$5347038d@tm.unikarlsruhe.de> In-Reply-To: <020001c3f4a2$faeb74c0$5347038d@tm.unikarlsruhe.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I already sent some comments earlier, but I reread this draft prior to the meeting. Here are some additional comments. Overall I find your draft quite promising. There's probably a need to change the approach to byte counts rather than fixed time limits, as dicussed earlier. > We propose a modified binding-update procedure that > evades the latency of both address tests. If this draft goes further, it might make sense to separate the home address and care-of address optimizations. That is, you could have one draft that explains how the home address tests can be initiated before handover takes place. Or would this be considered too simple for a draft?... I don't know. Maybe with some simulation data should be included, and rules to tell when it makes sense: delay at movement vs. potentially unnecessary messaging if we didn't move after all. Anyway, this part of the optimization would work well with any other optimization scheme as well, not just the care-of-test-less early binding updates. Or without any other optimization. > before changing its point of network attachment. At home, the mobile > node does not use Mobile IPv6. It hence does not run a home-address > test, and it does not acquire a Home Keygen Token, before it moves to > a foreign link. Also, when the mobile node powers on at a foreign I don't see a reason why the predictive home test strategy wouldn't work even in this case. In either case, you have to have some ability to "guess" that you will be moving soon, or otherwise you'll just be doing some extra signaling. > One may consider letting the mobile node perform a home-address test > even while being at home. This could accelerate handovers from the > home link to a foreign link. The Home Test Init and Home Test > messages would continue to obey to the rules defined in sections 9.4 > and 11.6 of [1], except that they would not have to be tunneled > between the mobile node and its home agent. This is true. But if you are going to adopt predictive home tests, I would apply them even to the home case. Perhaps the separate draft that I suggested makes sense, because you would also have to describe the exception that you talk about in the above. > These observations lead to the following exception: When a mobile > node wants to register a new care-of address with a correspondent > node, and the mobile node does not yet know a valid Home Keygen > Token, the mobile node runs a standard binding update instead of an > Early Binding Update. When the standard binding update is complete, > the mobile node can communicate through its new care-of address. The Presumably you could do an EBU as soon as you receive the Home Test message. I think this would simplify your state machine. > test. We claim that testing the mobile node's reachability at its new > care-of address may also be done at (3). Data transmission to and > from the new care-of address may wait or, as with Early Binding > Updates, start with appropriate restrictions until the mobile node > has provided proof to the correspondent node that it is reachable at > its new care-of address. This is the issue we discussed earlier. As has been stated by Francis and others, in the Internet we already (unfortunately, since ingress filtering is not ubiquitous) have the possibility to spoof source addresses, leading to 1-1 reflection attacks on e.g. TCP SYN packets. So 1-1 reflection is not necessarily something we need to prevent in Mobile IPv6. Base RR attempts, however, to prevent 1-N reflection attacks where you send one (or some) packets and get many more packets to the victim's network. The basic scenario is tricking someone into opening a stream, and moving the stream towards the victim and letting the "someone" pump data towards the victim for a while. Your -00 draft with the 3 second time limit still has this issue, as a CN which supports EBUs could pump 3 seconds of data stream to the victim. How serious is this? It depends on the interface speed and effort needed to open the particular stream. Lets say 10 packets to open the stream and get over the slow start (maybe someone can help me with the actual numbers...). If the CN is a mobile on a congested GPRS link, there may not be many packets sent during the 3 seconds. But if the CN is an idle web server on an OC-3 link there could be a lot of packets, particularly since the attacker can send some spoofed TCP ACKs, having learned the sequence numbers while opening the stream. However, if as suggested you would change the approach to specifically take this into account, this would no longer be a problem. Basically, a CN would agree to send out at most X bytes of traffic while in the tentative state, where X is, say, 10 % of the bytes sent by the MN during the last few minutes. This would result in the attacker (mobile node) having to send at least 100 bytes to get just 10 bytes to the attacker, clearly less than the 1-1 reflection simply using TCP SYNs. Still, the 10% is more than enough to transfer the data needed until the care-of test answer arrives: if you have a constant data rate, 10% of data sent during three minutes gives you 18 s to complete the care-of address test. If you exceed X, you move the stream back to the home address. The drawback of this scheme is that on the first binding you may be unable to do this, even if you had ongoing data transfer with the mobile while it was at home. This is because the IP stack would not be counting the received bytes. The Home Keygen Token and > the Care-of Keygen Token are likely to arrive at the mobile node via > disjoint paths: The former passes through the mobile node's home > agent, the latter does not. An attacker will thus have a hard time to > capture both tokens. Strictly speaking, this is not the main worry. As documented in [1], the attacker is free to choose the care-of path. So I would worry more about attackers posing as mobile nodes and doing the RR test than attackers being able to eavesdrop on an RR test performed by a legitimate node. In order to pose as a mobile node, you need to be on the path to the home agent, and your draft does not change that so I think you are ok. (Also, if you are on the path to the home agent you can do all sorts of other nasty stuff.) (You say all this later in the text, but I just wanted to say that two paths are not a protection in RR, your method, or other methods.) > Another way to mitigate the threat of flooding attacks is to grant > Early Binding Updates to trusted nodes only. Recall that the I wouldn't put too much emphasis on this. However, if we had some stronger home test mechanisms (e.g. CGA), you could combine EBUs with them, getting more security. --Jari [1] http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 17:27:50 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 RAA12936 for ; Sun, 29 Feb 2004 17:27:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZP7-0003y0-QO for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 17:27:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TMRLal015244 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 17:27:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZP7-0003xn-LB for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 17:27:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12910 for ; Sun, 29 Feb 2004 17:27:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZP5-0007jR-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 17:27:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZOA-0007e8-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 17:26:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxZNp-0007YL-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 17:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZNp-0003sE-QW; Sun, 29 Feb 2004 17:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZN9-0003p6-QT for mip6@optimus.ietf.org; Sun, 29 Feb 2004 17:25:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12850 for ; Sun, 29 Feb 2004 17:25:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZN7-0007XW-00 for mip6@ietf.org; Sun, 29 Feb 2004 17:25:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZMC-0007Sb-00 for mip6@ietf.org; Sun, 29 Feb 2004 17:24:21 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AxZLU-0007O3-00 for mip6@ietf.org; Sun, 29 Feb 2004 17:23:36 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1TMNY89014305; Mon, 1 Mar 2004 07:23:34 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1TMNY2E020610; Mon, 1 Mar 2004 07:23:34 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA20608 ; Mon, 1 Mar 2004 07:23:34 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA02170; Mon, 1 Mar 2004 07:23:33 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA14432; Mon, 1 Mar 2004 07:23:33 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1TMNWTH010450; Mon, 1 Mar 2004 07:23:32 +0900 (JST) Received: from steelhead ([159.119.168.108]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTV0084HA76NH@tsbpo1.po.toshiba.co.jp>; Mon, 1 Mar 2004 07:23:31 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AwcSB-0000L4-00; Thu, 26 Feb 2004 23:30:35 -0800 Date: Thu, 26 Feb 2004 23:30:35 -0800 From: Yoshihiro Ohba Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt In-reply-to: <4041D7DD.6070503@kolumbus.fi> To: Jari Arkko Cc: Hiroyuki OHNISHI , mip6@ietf.org Message-id: <20040227073035.GA1132@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <4040A2C7.9080804@kolumbus.fi> <20040229194536.4597.OHNISHI.HIROYUKI@lab.ntt.co.jp> <4041D7DD.6070503@kolumbus.fi> Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Hi Jari, On Sun, Feb 29, 2004 at 02:15:25PM +0200, Jari Arkko wrote: > Hi Hiroyuki and thanks for your quick response! What you > say seems reasonable. Just continuing on one item below: > > >>> A solution for dynamically and securely assigning > >>> home address prefix to mobile node with involving an appropriate > >>> authentication and authorization protocol is demanded. > >> > >>I agree, though I worry what this means protocol-wise. Right now, > >>we would not like to add a new AAA feature to basic IPv6 discovery > >>functions. Existing link layers aren't easily modified, and EAP may > >>not be the appropriate vehicle to download a lot of material and > >>parameters for IP layer functions. So how can we realize this > >>function? > > > >I assume using some host configuration protocols to assign such kind of > >Mobile IPv6 specific information. > > Can you name some specific example as to what protocol you are thinking? > Presumably, the information would have to be secured somehow, at least > if you are handing out keys to access the home agent. DHCP? ND, but > that would presumably not be secure? SEND? EAP TLVs? 802.11 IEs? In my personal opinion, DHCP is the most appropriate protocol. I am not viewing ND as a general-purpose host configuration protocol that is appropriate to carry Mobile IPv6 parameters in visiting networks. As you mentioned, the information needs to be secured. More specifically the information needs to be at least integrity protected and replay protected. RFC3118 (DHCP authentication) satisfies such a requirement. Also, this kind of model would require the cryptographic key used for DHCP authentication to be bootstrapped from a AAA-Key derived from *any* EAP method that can generate keys. draft-yegin-eap-boot-rfc3118-00.txt describes such a method and I think that the draft is important. Anyway, this is more than problem statement and I would like to focus on problem statement at this moment... Best regards, Yoshihiro Ohba > > --Jari > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 17:48: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 RAA13883 for ; Sun, 29 Feb 2004 17:48:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZjX-0005gX-80 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 17:48:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TMmRnA021847 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 17:48:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZjX-0005gI-3l for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 17:48:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13874 for ; Sun, 29 Feb 2004 17:48:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZjU-00026H-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 17:48:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZiX-00020R-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 17:47:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxZi8-0001uS-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 17:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZiA-0005aW-3U; Sun, 29 Feb 2004 17:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZhh-0005a4-I8 for mip6@optimus.ietf.org; Sun, 29 Feb 2004 17:46:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13784 for ; Sun, 29 Feb 2004 17:46:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZhf-0001tv-00 for mip6@ietf.org; Sun, 29 Feb 2004 17:46:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZgt-0001nC-00 for mip6@ietf.org; Sun, 29 Feb 2004 17:45:44 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AxZgF-0001eO-00 for mip6@ietf.org; Sun, 29 Feb 2004 17:45:03 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1TMj289020517; Mon, 1 Mar 2004 07:45:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1TMj2nX029211; Mon, 1 Mar 2004 07:45:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA29210 ; Mon, 1 Mar 2004 07:45:02 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA08249; Mon, 1 Mar 2004 07:45:02 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA18425; Mon, 1 Mar 2004 07:45:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1TMj0TH013851; Mon, 1 Mar 2004 07:45:01 +0900 (JST) Received: from steelhead ([159.119.168.108]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTV00978B6YK2@tsbpo1.po.toshiba.co.jp>; Mon, 1 Mar 2004 07:44:59 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AwcdR-0000Lp-00; Thu, 26 Feb 2004 23:42:13 -0800 Date: Thu, 26 Feb 2004 23:42:13 -0800 From: Yoshihiro Ohba Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt In-reply-to: <20040227073035.GA1132@steelhead> To: Jari Arkko Cc: Hiroyuki OHNISHI , mip6@ietf.org Message-id: <20040227074213.GD1132@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <4040A2C7.9080804@kolumbus.fi> <20040229194536.4597.OHNISHI.HIROYUKI@lab.ntt.co.jp> <4041D7DD.6070503@kolumbus.fi> <20040227073035.GA1132@steelhead> Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Correction: "RFC3118 (DHCP authentication)" -> "RFC3315". Yoshihiro Ohba On Thu, Feb 26, 2004 at 11:30:35PM -0800, Yoshihiro Ohba wrote: > Hi Jari, > > On Sun, Feb 29, 2004 at 02:15:25PM +0200, Jari Arkko wrote: > > Hi Hiroyuki and thanks for your quick response! What you > > say seems reasonable. Just continuing on one item below: > > > > >>> A solution for dynamically and securely assigning > > >>> home address prefix to mobile node with involving an appropriate > > >>> authentication and authorization protocol is demanded. > > >> > > >>I agree, though I worry what this means protocol-wise. Right now, > > >>we would not like to add a new AAA feature to basic IPv6 discovery > > >>functions. Existing link layers aren't easily modified, and EAP may > > >>not be the appropriate vehicle to download a lot of material and > > >>parameters for IP layer functions. So how can we realize this > > >>function? > > > > > >I assume using some host configuration protocols to assign such kind of > > >Mobile IPv6 specific information. > > > > Can you name some specific example as to what protocol you are thinking? > > Presumably, the information would have to be secured somehow, at least > > if you are handing out keys to access the home agent. DHCP? ND, but > > that would presumably not be secure? SEND? EAP TLVs? 802.11 IEs? > > In my personal opinion, DHCP is the most appropriate protocol. I am > not viewing ND as a general-purpose host configuration protocol that > is appropriate to carry Mobile IPv6 parameters in visiting networks. > As you mentioned, the information needs to be secured. More > specifically the information needs to be at least integrity protected > and replay protected. RFC3118 (DHCP authentication) satisfies such a > requirement. Also, this kind of model would require the cryptographic > key used for DHCP authentication to be bootstrapped from a AAA-Key > derived from *any* EAP method that can generate keys. > draft-yegin-eap-boot-rfc3118-00.txt describes such a method and I > think that the draft is important. > > Anyway, this is more than problem statement and I would like to focus > on problem statement at this moment... > > Best regards, > > Yoshihiro Ohba > > > > > > --Jari > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 18:35:49 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 SAA16339 for ; Sun, 29 Feb 2004 18:35:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaSw-00065H-Hl for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 18:35:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TNZMav023384 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 18:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaSv-000655-Ry for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 18:35:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16332 for ; Sun, 29 Feb 2004 18:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxaSs-0005vK-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 18:35:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxaRx-0005qU-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 18:34:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxaRd-0005lX-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 18:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaRd-0005r0-6Z; Sun, 29 Feb 2004 18:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaQy-0005nP-Bd for mip6@optimus.ietf.org; Sun, 29 Feb 2004 18:33:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16281 for ; Sun, 29 Feb 2004 18:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxaQv-0005jt-00 for mip6@ietf.org; Sun, 29 Feb 2004 18:33:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxaPx-0005fc-00 for mip6@ietf.org; Sun, 29 Feb 2004 18:32:18 -0500 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 1AxaP7-0005au-00 for mip6@ietf.org; Sun, 29 Feb 2004 18:31:25 -0500 Message-ID: <014b01c3ff1c$35e4cc60$3e6015ac@dclkempt40> From: "James Kempf" To: "Alper Yegin" , References: <000001c3fe92$d5678f00$e22f10ac@sisa.samsung.com> Subject: Re: [Mip6] Comments on kempf-mip6-bootstrap Date: Sun, 29 Feb 2004 15:31:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Alper, Thanx for the comments. Replies below. > I've just read the draft. Please see my comments below. > > With IKEv1, the mobile node needs to have a > statically defined home address in order that the home agent can make > an authorization decision and identify the credentials during the IKE > Phase 1 ISAKMP exchange. In this document, we discuss why these > constraints may be problematic in some deployment scenarios. > > IKEv2 allows named SPIs with address selectors set to NULL. Names can be > NAI and FQDN. If we use IKEv2, do we still have a problem? > IKEv2 helps for this part of the problem. > > However, support for dynamic home address assignment would be > desirable for the following reasons: > > DHCP-based address assignment > > Some ISPs may want to use DHCPv6 from the home network to > configure home addresses [7]. > > I think we are concerned that the MN might get different DHCP addresses > each time it asks for one. Note that deployments can ensure that the > host (MN) gets the same IP address (home address) by supplying a > client-id with DHCP requests. So, this may not be a problem. > > Having the addresses be fully dynamic would involve less administrative burden than having them be partially static. But partially static addresses might be a good solution for some deployment cases. > Currently, the address of the home agent is specified in the security > policy database. Support for multiple home agents requires the > configuration of multiple security policy database entries. > > We are talking about SPDs on the MN, right? If so, is this a problem? MN > can set the HA address in the SPD once it determines which HA it will be > using. The challenge is, I think, bootstrapping the keys for a given HA. > There's an issue of configuring the SPD, if the HA is discovered dynamically. Presumably, this would be better done automatically, as it is not something that most users would typically not want to deal with. But, yes, key distribution is the primary problem. > Ease of deployment > > ISP may want to allow "opportunistic" discovery and utilization of > its mobility services without any prearranged contact. These > scenarios will require dynamic home address assignment. > > ... and keys. > Yes. > > The current IKEv1-based dynamic key exchange protocol described in > [5] has no integration with backend authentication, authorization and > accounting techniques unless the authentication credentials and trust > relationships use certificates. > > Isn't this an implementation issue? For example can't I use LDAP to > retrieve the keys for a MN when my HA receives an IKE request? Well, > there isn't a RADIUS or Diameter application for this scenario, maybe > this is what you mean. But I think this doesn't require integration of > IKE with RADIUS/Diameter. > AAA and the HA can communicate auth/authz information via LDAP. There's an issue of how the MN identifies itself to the HA independently of its home address. IKEv2 helps with these problems, as you note above. There is still an issue with accounting records, however, even if IKEv2 is used. > Using certificates may require the ISP to deploy a PKI, which may not > be possible or desirable in certain circumstances. Where a > traditional AAA infrastructure is used, the home agent is not able to > leverage authentication and authorization information established > between the mobile node, the foreign AAA server, and the home AAA > server when the mobile node gains access to the foreign network, in > order to authenticate the mobile node's identity and determine if the > mobile node is authorized for mobility service. > > This is talking about integration of AAA for network access and AAA for > mobility management. I think "AAA for mobility management" does not > necessarily imply this level of integration. > What level of integration do you think is necessary for AAA for mobility management? > The lack of connection to the AAA infrastructure also means the home > agent does not know where to issue accounting records at appropriate > times during the mobile node's session, as determined by the business > relationship between the home ISP and the mobile node's owner. > Presumably, some backend AAA protocol between the home agent and home > AAA could be utilized but IKEv1 does not contain support for > exchanging the right kind of information, primarily the NAI [6], with > the mobile node. > > Mobility management and network access are two separate services. We > shouldn't assume they have to be integrated. > When we wrote this paragraph, we didn't assume they are. The paragraph is just trying to say that the mobility service provider might need some support for issuing accounting records on the appropriate event boundaries. If you can think of some text that makes this clearer, please post it. > The home agent discovery protocol does not support "opportunistic" or > local discovery mechanisms in a roaming partner's local access > network. It is expected that the mobile node must know the prefix of > the home subnet in order to be able to discover a home agent, it must > either obtain that information through prefix update or have it > statically configured. A more typical pattern for interdomain > service discovery in the Internet is that the client (mobile node in > this case) knows the domain name of the service, and uses DNS in some > manner to find the server in the other domain. For local service > discovery, DHCP is typically used. > > If HAs are located on the visited links, then the current dynamic home > agent discovery is good enough. If they are somewhere deeper in the > access network, then a DHCP-based discovery, or what HMIP approach can > be utilized. > This paragaph is trying to making a statement about 1) a lack of particular functionality in the existing MIP spec and 2) how that functionality is typically provided for other Internet services. It is not attempting to make a statement about a solution for MIP. I think it advisable to keep solutions out of a problem statement document. We could add a final statement to make that clearer if you like. > Another scenario involves turning an existing security association in > the user's home network for a different purpose into a new security > association suitable for protecting Mobile IPv6. For instance, an > existing security association for a VPN service could be used to > generate suitable Mobile IPv6 security associations, on a > first-come-first-served home address basis. > > Wouldn't some (most?) problems we encountered with the Mobile IPv6 > service also apply to the VPN service? > I'm not sure I understand your point. Could you clarify? > For instance, when > the mobile node boots and connects to the network for the first time, > it could create a security association with the access operator's > home agent. This home agent could then be used as the mobile node > moves into a different position or even into a different access > network. > > We are applying this type of a technique to the DHCP security problem. > Please see draft-yegin-eap-boot-rfc3118-00.txt > > Good to see that we have some solutions under consideration. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 19:02:05 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 TAA17266 for ; Sun, 29 Feb 2004 19:02:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxasN-0007pG-5p for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 19:01:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2101dJX030081 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 19:01:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxasM-0007p6-UP for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:01:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17241 for ; Sun, 29 Feb 2004 19:01:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxasJ-0000DH-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 19:01:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxarT-000057-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 19:00:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axaqq-0007k3-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 19:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axaqs-0007ZQ-Lm; Sun, 29 Feb 2004 19:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axaq7-0007W5-V1 for mip6@optimus.ietf.org; Sun, 29 Feb 2004 18:59:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16977 for ; Sun, 29 Feb 2004 18:59:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axaq4-0007fC-00 for mip6@ietf.org; Sun, 29 Feb 2004 18:59:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxapA-0007Yf-00 for mip6@ietf.org; Sun, 29 Feb 2004 18:58:21 -0500 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 1AxaoY-0007TP-00 for mip6@ietf.org; Sun, 29 Feb 2004 18:57:42 -0500 Message-ID: <016101c3ff1f$e52ebb60$3e6015ac@dclkempt40> From: "James Kempf" To: "Hiroyuki OHNISHI" , "Jari Arkko" Cc: References: <4040A2C7.9080804@kolumbus.fi> <20040229194536.4597.OHNISHI.HIROYUKI@lab.ntt.co.jp> Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt Date: Sun, 29 Feb 2004 15:58:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > As you mentioned, "roaming" is related to network access control. > I think AAA for network access and AAA for Mobile IPv6 are different. > Since this sentense seems to imply AAA for network access, I think it is > better to delete this sentense. > It is also related to charging for mobility service. The access network provider might want to charge differentially for users that move and those that want to stay at a fixed location. > > And then we have another issue having the right type of credentials > > (e.g. passwords vs. IPsec SAs) for large-scale deployment. In fact, > > I sense that this is probably the crucial issue. > > > > Unless... access network providers want a piece of the "mobility > > business", i.e., want to be involved in the transactions for > > non-technical reasons. > > They might. Some ISPs today charge different rates for fixed IP addresses as opposed to DHCP allocated addresses. There's no technical reason for this (and opinions vary about its desirability). jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 19:48:50 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 TAA19302 for ; Sun, 29 Feb 2004 19:48:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbbY-0003XD-2s for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 19:48:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i210mKfl013581 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 19:48:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbbX-0003Wy-Ue for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:48:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19292 for ; Sun, 29 Feb 2004 19:48:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbbW-0004bL-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 19:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axbac-0004Wv-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 19:47:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxbaG-0004Rr-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 19:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbaH-0003P0-IS; Sun, 29 Feb 2004 19:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbZW-0003Nk-FV for mip6@optimus.ietf.org; Sun, 29 Feb 2004 19:46:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19191 for ; Sun, 29 Feb 2004 19:46:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbZU-0004QN-00 for mip6@ietf.org; Sun, 29 Feb 2004 19:46:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbYc-0004LT-00 for mip6@ietf.org; Sun, 29 Feb 2004 19:45:19 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AxbXb-0004CY-00 for mip6@ietf.org; Sun, 29 Feb 2004 19:44:15 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTV00704GOW0K@mailout2.samsung.com> for mip6@ietf.org; Mon, 01 Mar 2004 09:43:44 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTV001DTGOWYY@mailout2.samsung.com> for mip6@ietf.org; Mon, 01 Mar 2004 09:43:44 +0900 (KST) Received: from Alperyegin ([124.232.210.2]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTV00DSVGOVQJ@mmp2.samsung.com> for mip6@ietf.org; Mon, 01 Mar 2004 09:43:44 +0900 (KST) Date: Sun, 29 Feb 2004 16:43:44 -0800 From: Alper Yegin Subject: RE: [Mip6] Comments on kempf-mip6-bootstrap In-reply-to: <014b01c3ff1c$35e4cc60$3e6015ac@dclkempt40> To: "'James Kempf'" , mip6@ietf.org Message-id: <000001c3ff26$407b04f0$e22f10ac@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Jim, > > The current IKEv1-based dynamic key exchange protocol described in > > [5] has no integration with backend authentication, authorization and > > accounting techniques unless the authentication credentials and trust > > relationships use certificates. > > > > Isn't this an implementation issue? For example can't I use LDAP to > > retrieve the keys for a MN when my HA receives an IKE request? Well, > > there isn't a RADIUS or Diameter application for this scenario, maybe > > this is what you mean. But I think this doesn't require integration of > > IKE with RADIUS/Diameter. > > > > AAA and the HA can communicate auth/authz information via LDAP. There's an > issue of how the MN identifies itself to the HA independently of its home > address. IKEv2 helps with these problems, as you note above. There is > still > an issue with accounting records, however, even if IKEv2 is used. What is the accounting issue? HA should simply collect some counters, and any centralized accounting server should be able to query HA via SNMP. > > > Using certificates may require the ISP to deploy a PKI, which may not > > be possible or desirable in certain circumstances. Where a > > traditional AAA infrastructure is used, the home agent is not able to > > leverage authentication and authorization information established > > between the mobile node, the foreign AAA server, and the home AAA > > server when the mobile node gains access to the foreign network, in > > order to authenticate the mobile node's identity and determine if the > > mobile node is authorized for mobility service. > > > > This is talking about integration of AAA for network access and AAA for > > mobility management. I think "AAA for mobility management" does not > > necessarily imply this level of integration. > > > > What level of integration do you think is necessary for AAA for mobility > management? I think this is a different discussion than what this I-D should be addressing. We should discuss it under another thread. > > > The lack of connection to the AAA infrastructure also means the home > > agent does not know where to issue accounting records at appropriate > > times during the mobile node's session, as determined by the business > > relationship between the home ISP and the mobile node's owner. > > Presumably, some backend AAA protocol between the home agent and home > > AAA could be utilized but IKEv1 does not contain support for > > exchanging the right kind of information, primarily the NAI [6], with > > the mobile node. > > > > Mobility management and network access are two separate services. We > > shouldn't assume they have to be integrated. > > > > When we wrote this paragraph, we didn't assume they are. The paragraph is > just trying to say that the mobility service provider might need some > support for issuing accounting records on the appropriate event boundaries. OK, I see. > > > Another scenario involves turning an existing security association in > > the user's home network for a different purpose into a new security > > association suitable for protecting Mobile IPv6. For instance, an > > existing security association for a VPN service could be used to > > generate suitable Mobile IPv6 security associations, on a > > first-come-first-served home address basis. > > > > Wouldn't some (most?) problems we encountered with the Mobile IPv6 > > service also apply to the VPN service? > > > > I'm not sure I understand your point. Could you clarify? For example, the problems encountered in using dynamically allocated home addresses with IKEv1 would also be applicable to the VPN solution. Or, discovering and having dynamic keys with a Home agent is equivalent to doing those with a VPN gateway. So I think you'd encounter the similar problems with the VPN solution, hence bootstrapping off of a VPN solution is more like moving the problem around. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 19:56: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 TAA19472 for ; Sun, 29 Feb 2004 19:56:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbjK-0003pz-44 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 19:56:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i210uMNt014745 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 19:56:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbjJ-0003pk-Pb for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:56:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19460 for ; Sun, 29 Feb 2004 19:56:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbjH-0005B8-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 19:56:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbiK-00055i-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 19:55:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axbi2-00050i-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 19:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbi2-0003iJ-6v; Sun, 29 Feb 2004 19:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbhL-0003hE-RX for mip6@optimus.ietf.org; Sun, 29 Feb 2004 19:54:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19393 for ; Sun, 29 Feb 2004 19:54:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbhJ-0004zu-00 for mip6@ietf.org; Sun, 29 Feb 2004 19:54:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbgH-0004uh-00 for mip6@ietf.org; Sun, 29 Feb 2004 19:53:13 -0500 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 1Axbfe-0004qu-00 for mip6@ietf.org; Sun, 29 Feb 2004 19:52:34 -0500 Message-ID: <01ea01c3ff27$8f154890$3e6015ac@dclkempt40> From: "James Kempf" To: "Alper Yegin" , References: <000001c3ff26$407b04f0$e22f10ac@sisa.samsung.com> Subject: Re: [Mip6] Comments on kempf-mip6-bootstrap Date: Sun, 29 Feb 2004 16:53:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > What is the accounting issue? HA should simply collect some counters, > and any centralized accounting server should be able to query HA via > SNMP. > Sure. But it might be cleaner for the HA to be able to issue its own accounting records directly into the AAA system, as opposed to using a gateway. Fewer moving parts. > I think this is a different discussion than what this I-D should be > addressing. We should discuss it under another thread. > OK. But, isn't there a connection? The HA might want to use IKEv2 to check auth/authz for mobility service via the AAA system. > > I'm not sure I understand your point. Could you clarify? > > For example, the problems encountered in using dynamically allocated > home addresses with IKEv1 would also be applicable to the VPN solution. > Or, discovering and having dynamic keys with a Home agent is equivalent > to doing those with a VPN gateway. So I think you'd encounter the > similar problems with the VPN solution, hence bootstrapping off of a VPN > solution is more like moving the problem around. > Yes, that's true. I think the idea here is that if a VPN gateway exists and is also an HA, the mobility service could somehow "upgrade" a VPN SA to a Mobile IP SA if the user suddenly decided it wanted to move, rather than have to establish a separate SA. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 20:15:50 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 UAA20165 for ; Sun, 29 Feb 2004 20:15:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc1f-0005h1-QI for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 20:15:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211FJi2021877 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 20:15:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc1f-0005gm-Lo for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:15:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20156 for ; Sun, 29 Feb 2004 20:15:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axc1d-0006ue-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 20:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axc0v-0006qH-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 20:14:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axc0O-0006lz-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 20:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc0P-0005PG-KM; Sun, 29 Feb 2004 20:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbzg-0005Ka-S9 for mip6@optimus.ietf.org; Sun, 29 Feb 2004 20:13:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20107 for ; Sun, 29 Feb 2004 20:13:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axbze-0006l8-00 for mip6@ietf.org; Sun, 29 Feb 2004 20:13:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axbyy-0006hF-00 for mip6@ietf.org; Sun, 29 Feb 2004 20:12:33 -0500 Received: from mac-0-40-96-34-df-d2.dhcp.ietf59.or.kr ([218.37.230.226] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AxbyM-0006bk-00; Sun, 29 Feb 2004 20:11:54 -0500 Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1AxbyB-0004VM-00; Mon, 01 Mar 2004 02:11:43 +0100 Date: Mon, 1 Mar 2004 02:11:42 +0100 From: Henrik Levkowetz To: Henrik Levkowetz Cc: mip4@ietf.org, mip6@ietf.org Message-Id: <20040301021142.243d8a67.henrik@levkowetz.com> In-Reply-To: <20040225023657.260676cd.henrik@levkowetz.com> References: <20040225023657.260676cd.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: [Mip6] Re: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Bar-bof details: We have a proposed time and place for this bar-bof: Tuesday morning 7:00 - in the seating area outside Emerald. Possibly we can use Emerald if more people turn up than the area can hold. The first idea of having it Monday night at 10:00 has been scrapped as some key persons who are newly arrived from the states will be dead on their feet at that time. Henrik Wednesday 25 February 2004, Henrik Levkowetz wrote: > > Proposal of a bar-bof > --------------------- > > With the coming (we hope) of heterogenous deployment of IPv4 and IPv6 > access and transport networks, and Mobile Nodes with MIPv4 and/or MIPv6 > capability and IPv4 and/or IPv6 stacks, the question has been raised > of how to best run Mobile IP in such circumstances, and some solutions > has been proposed. > > The "trivial cases" of MIP4 carrying IPv4 in an all-IPv4 network, and > MIP6 carrying IPv6 in an all-IPv6 network are covered in the MIPv4 and > MIPv6 standards. But by one way of counting, that still leaves about 6 > combinations (14 if you count NAT-PT versions) which may occur in > practice which are not covered by the current standards. A number of > drafts (some mentioned below) has been written, proposing solutions > to some of these cases. > > Some cases may be handled without any additional MIP work if other > transition mechanisms such as e.g. ISATAP is available, but as a Mobile > Node may be expected to come across all conceivable kinds of visited > networks, it cannot rely on any particular other transition mechanism > being in place. > > Below is a list of possible combinations of Host IP stack version, MIP > client/agent version and transport network IP version, followed by a > short summary of my understanding of where the current and proposed > solutions fit in. There exist 8 similar combinations using NAT-PT > which are not explicitly listed here. > > Which solutions will be needed? Which should we work on? How much > interest does this have currently? > > We plan to hold a bar-bof in Seoul, to see how many show up, and what > kind of interest there is in this subject. Place will be announced > on the lists Monday March 1st, and in the MIP4 and MIP6 sessions. > > Henrik > > > > Table of MIP4/6-IP4/6 combinations: > =================================== > > # MN's MIP Access Transpt Short description > IP-stack Client Net & HA if. > --- -------- ------ ------ ------- ----------------- > 1 IPv4 MIP v4 IP v4 v4 "native MIPv4" > 2 IPv6 " " v4 "IPv6 in MIPv4" > > 3 IPv4 MIP v6 " v4 "IPv4 in MIPv6 over IPv4" > 4 IPv6 " " v4 "MIPv6 over IPv4" > > 5 IPv4 MIP v4 IP v6 v6 "MIPv4 over IPv6" > 6 IPv6 " " v6 "IPv6 in MIPv4 over IPv6" > > 7 IPv4 MIP v6 " v6 "IPv4 in MIPv6" > 8 IPv6 " " v6 "native MIPv6" > --- -------- ------ ------ ------- ----------------- > > Variant 1 is the native IP/MIP combination for v4 > > Variant 2 would be supported by the MIPv4 signalling extensions proposed in > draft-tsirtsis-v4v6-mipv4-00.txt > > Variant 5 is known to be supported by an experimental thesis implementation > and is fairly simple > > Variant 6 is known to be supported by an experimental thesis implementation > and is fairly simple > > Variant 7 would be supported by the MIPv6 signalling extensions proposed in > draft-soliman-v4v6-mipv4-00.txt > > Variant 8 is the native IP/MIP combination for v6 > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 21:06:27 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 VAA23726 for ; Sun, 29 Feb 2004 21:06:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axcog-0002sU-GV for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 21:05:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2125wn1011061 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 21:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axcog-0002sK-9n for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:05:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23562 for ; Sun, 29 Feb 2004 21:05:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axcod-0005Ev-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 21:05:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axcnt-000559-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 21:05:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axcmn-0004tO-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 21:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcZH-0001JH-RN; Sun, 29 Feb 2004 20:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcYJ-00017A-VI for mip6@optimus.ietf.org; Sun, 29 Feb 2004 20:49:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22306 for ; Sun, 29 Feb 2004 20:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcYH-00031z-00 for mip6@ietf.org; Sun, 29 Feb 2004 20:49:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcX8-0002ln-00 for mip6@ietf.org; Sun, 29 Feb 2004 20:47:52 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AxcVT-0002Jw-00 for mip6@ietf.org; Sun, 29 Feb 2004 20:46:07 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i211jX0J026596; Sun, 29 Feb 2004 17:45:34 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i211jUQ29781; Mon, 1 Mar 2004 02:45:30 +0100 (MET) Date: Sun, 29 Feb 2004 17:45:33 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt To: James Kempf Cc: Hiroyuki OHNISHI , Jari Arkko , mip6@ietf.org In-Reply-To: "Your message with ID" <016101c3ff1f$e52ebb60$3e6015ac@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > It is also related to charging for mobility service. The access network > provider might want to charge differentially for users that move and those > that want to stay at a fixed location. The distinction between "mobilty" and "mobile IP" is critical here. I don't think the access network can charge differently for mobility without help from the home AAA support. For instance, the access network here in the Lotte hotel can't know that a day ago I was in California. You can try to charge extra for mobile IP, but wouldn't that mean that folks would use mobility at other layers e.g. client-only protocols that don't need reachability at a fixed IP address? Given that we want to increase deployment of mobile IP, since it is a platform for interesting upper layer services, having the access provider charge more for mobile IP seems counterproductive. That doesn't prevent the home provider to charge for maintaining the fixed IP address precence and tunneling, but you actually want those charges to be small to drive deployment. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 21:45:21 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 VAA26283 for ; Sun, 29 Feb 2004 21:45:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdQL-0007Gl-Kn for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 21:44:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i212irIK027937 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 21:44:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdQL-0007GW-Fk for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:44:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26221 for ; Sun, 29 Feb 2004 21:44:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdQI-00027j-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 21:44:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdPE-0001xt-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 21:43:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxdOW-0001pR-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 21:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdOY-00075f-4f; Sun, 29 Feb 2004 21:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdOG-000753-4n for mip6@optimus.ietf.org; Sun, 29 Feb 2004 21:42:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26075 for ; Sun, 29 Feb 2004 21:42:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdOD-0001nF-00 for mip6@ietf.org; Sun, 29 Feb 2004 21:42:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdNV-0001do-00 for mip6@ietf.org; Sun, 29 Feb 2004 21:41:57 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxdMT-0001Rg-00 for mip6@ietf.org; Sun, 29 Feb 2004 21:40:53 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 6C2A56A90A for ; Mon, 1 Mar 2004 04:40:47 +0200 (EET) Message-ID: <4042A22A.9000400@kolumbus.fi> Date: Mon, 01 Mar 2004 04:38:34 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] mipv6 base draft status Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 A brief update before the meeting. The base specification has been under a very lengthy processing at IANA, but as of last week, they have completed the IANA actions. (This lengthy wait for IANA is by the way not just our problem, it has affected many other specifications at the IETF too. Apparently there some people have left for a maternity leave and some new ones come in etc.) The status at the RFC Editor web site says still "IANA", but this may be because the RFC editors have not yet processed the result from IANA and/or they maybe here for the meeting. I'll be monitoring the situation and will ping the relevant parties to make sure that things move forward. Hopefully we are very soon in AUTH48, at which time I'll make a few minor editorial modifications that people have suggested over the months. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 22:50: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 WAA29136 for ; Sun, 29 Feb 2004 22:50:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxeRj-0003bU-K0 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 22:50:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i213oN4R013849 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 22:50:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxeRj-0003bI-CZ for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 22:50:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29130 for ; Sun, 29 Feb 2004 22:50:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxeRf-0000XI-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 22:50:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxeQk-0000St-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 22:49:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxeQN-0000Oh-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 22:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxeQO-0003UU-MY; Sun, 29 Feb 2004 22:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxePm-0003SJ-Vo for mip6@optimus.ietf.org; Sun, 29 Feb 2004 22:48:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29086 for ; Sun, 29 Feb 2004 22:48:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxePj-0000Nt-00 for mip6@ietf.org; Sun, 29 Feb 2004 22:48:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxeOn-0000Jm-00 for mip6@ietf.org; Sun, 29 Feb 2004 22:47:22 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxeOF-0000Fi-00 for mip6@ietf.org; Sun, 29 Feb 2004 22:46:47 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 5DCA36A90A; Mon, 1 Mar 2004 05:46:45 +0200 (EET) Message-ID: <4042B1A0.3050307@kolumbus.fi> Date: Mon, 01 Mar 2004 05:44:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, Wassim Haddad Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] comments on draft-haddad-mipv6-omipv6-01.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 Wassim and others, I have reviewed this document. I think its excellent that you are working on optimizations. I think we need them, and there appears to be at least some level of consensus on that in the group as well. I also like your approach in the sense that it does not expect to use any security infrastructure, I think that is the right thing to do. And I think that you have also managed to avoid potential CPU DoS issues that are inherent in Diffie-Hellman- based schemes, which is good. But you mention that your intent is to provide a more secure signaling scheme than RR is. However (and perhaps I'm missing something obvious), it seems that the proposed use of Diffie-Hellman has security impacts which actually make it less secure than standard RR. My concerns are listed below; after that there are some suggested modifications which can make your protocol more secure. "Kilroy was here first" -attack If I have understood correctly, in OMIPv6, any change to the binding cache must be authenticated via the derived shared secret. It is even not possible to rerun RR and OMIPv6 without proving the possession of the shared secret. As a result, once a shared secret is established, it is hard for other parties to change the binding. This is normally a positive thing, however, it becomes negative if it happens that the initial DH exchange was compromised and is now in control of the binding. It can perhaps be argued that this attack is hard, because the attacker would have to be both on the mobile node - correspondent node and home agent - correspondent node paths. However, there is another attack, much more serious that can be executed easily [draft-aura]. More specifically, an attacker can initiate an RR and DH exchange all by himself, without compromising any ongoing legitimate exchange. If the attacker does this before the mobile node in question has established the binding, the mobile node can no longer communicate with the correspondent node at all. Moreover, all the communications from the correspondent node intended to the mobile node go to a location selected by the attacker. In order to execute this attack, one needs to defeat the RR protocol. But this only requires presence on the path from the home agent to the correspondent node. It is not an issue in RR, since nodes that are on that path can perform equally bad attacks anyway and RR limits the vulnerability by requiring that the attack is all the time on this path. With OMIPv6, the attacker would no longer need to be on the path permanently, only once. This attack is particularly dangerous for non-mobile nodes. One would normally not assume that hosts without Mobile IPv6 support are vulnerable to problems in Mobile IPv6. However, when the correspondent node supports OMIPv6, an attacker who is at least temporarily on the path between the victim and the correspondent node can now cause the victim's traffic to be permanently redirected (the attacker may have to refresh the binding now and then, but he no longer has to be on the path). For instance, an attacker who temporarily visits an office Wireless LAN could set up an OMIPv6-protected binding at www.cnn.com for the office proxy server. As a result, all communications between the proxy server and the www server would fail. This vulnerability is serious, because a temporary problem expands into a more permanent problem, and can affect any IPv6 node even without Mobile IPv6 support. "Recovery mechanism" -attack Nodes can reboot and forget their state, or get an address that someone else was using a while ago. As discussed in [draft-aura], it is necessary to have a recovery mechanism. In essence, such recovery mechanism should be able to undo an OMIPv6-protected binding. For instance, a persistent ICMP error could lead to the correspondent node into believing that the binding is invalid. Unfortunately, such recovery mechanisms can be exploited by attackers, making it possible to undo a legitimately created OMIPv6-protected binding, and create a new one in place (for instance in the method discussed in the previous section). OMIPv6 is currently missing a recovery mechanism, however. Perhaps it can be designed in a way that there is no attack. Summary While the first attack described above is similar to the one that exists in RR, its results are worse than in OMIPv6. Findings in [draft-aura] make it hard to see an easy way to fix this; basically a "leap-of-faith" or PBK like approach does not sound suitable for the RO problem, even if they can be successfully used in, e.g., application layer protocols. The basic problem is that there is no user confirmation about making the leap of faith, leading to the possibility of the attacker doing the operation before you. Then again, I could be missing something. Let me know what. Possible suggestions on how to improve the security of your approach: - In [draft-roe] we proposed a scheme that incorporated Diffie-Hellman which did not rely _just_ on the RR as its initial authentication. Instead, it used a combination of RR and CGA tests. I don't remember if we actually eliminated all but the first home test messages; it seems that at least some optimization is possible there even if we didn't do in the draft. I think we are going to need something like this, maybe not exactly the same proposal, but something better than RR if the Kbm is to be made more permanent. - While avoiding security infrastructure and configuration is indeed very much desired, I would note that a DH authenticated by a pre-configured shared key between the home agent (or mobile node) and correspondent node would NOT be vulnerable to issues that I described above. Similarly, AAA could be used to authenticate the D-H somehow. I think this is what [draft-le] did. - If RR as initial authentication for D-H is deemed sufficient, there would be simpler protocols that would accomplish what you want to do. As you know, unauthenticated Diffie-Hellman is vulnerable to MiTM attacks by active attackers. It seems that this holds true of RR itself as well; nothing is gained by attackers who just eavesdrop; they have to at least send the Binding Update. So, if RR as initial authentication was deemed sufficient, it would seem that simply using RR-derived Kbm as the long-term key would be sufficient, and no D-H would be needed. - I won't comment here about skipping care-of address tests as there are other threads in this mailing list about that. But I think something along the lines of draft-vogt sounds promising to reduce the signaling delays related to care-of address tests. Some other notes: > and a correspondent node (CN). Such mode is efficient, but it > raises many security concerns and generates an excessive amount > of redundant mobility signaling messages. As I have said before on the list in other contexts, IMHO it would be good if people who feel there are significant issues would document these issues and make it possible for the rest of us to review the findings. Existing analysis in e.g. draft-nikander and in the old design team notes points to very similar risks that exist for on-path attackers anyway. > Note that the main objective behind duplicating the second DH > message is the potential ability to reveal a possible MiTM > attack on the first one (i.e., if the malicious node knows the > Kbm). By duplicating the second DH message, a successful MiTM > attack will consist on attacking two duplicated messages sent > on two different paths at the same time, which will probably > make such kind of attack more difficult. This is correct, but only if you look at attackers who intend to eavesdrop on your signaling. This is just one class of an attack, and I would argue that the more interesting class is where attackers actually spoof the RR or OMIPv6 messages. For that, as discussed in draft-aura, the two paths do not really help. The attacker has to be on the home - cn path, but he can choose the other path freely. > long shared secret Hmm... I think the length is not the issue here. Generally in cryptography we feel relatively safe after a certain key length. In base MIPv6, this is 20 octets for the Kbm. I don't think we need more. What may be more relevant, however, is *how* you get those key octets and how much security that procedure offers. For instance, a CGA-type procedure would enable us to have more assurance that the mobile node is who he says he is than the home test procedure. > In order to reduce the handover latency, the MN will send the > BU on the direct path immediately after receiving a BA message > from its HA. Note that the MN MAY duplicate the BU message and > send a copy on the path going via its HA. Only one copy is > enough to update the CN's binding cache entry. In this case, > the BU sent via the HA MUST have the same sequence number than > the one sent via the direct path. I didn't quite get this. If the sequence numbers are the same, won't the other BU be dropped. Why would then want to send two? Can you explain? References [draft-aura] http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt [draft-roe] http://www.arkko.com/publications/draft-roe-mobileip-updateauth-02.txt [draft-vogt] http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt [draft-le] draft-le-mobileip-dh-01.txt, expired _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Feb 29 23:08:13 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 XAA29590 for ; Sun, 29 Feb 2004 23:08:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxeiY-0004pK-MZ for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 23:07:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2147kXS018540 for mip6-archive@odin.ietf.org; Sun, 29 Feb 2004 23:07:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxeiY-0004ox-82 for mip6-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:07:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29581 for ; Sun, 29 Feb 2004 23:07:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxeiT-0001tz-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 23:07:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axehk-0001pH-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 23:06:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axego-0001ki-00 for mip6-web-archive@ietf.org; Sun, 29 Feb 2004 23:05:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axegr-0004XM-G6; Sun, 29 Feb 2004 23:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxegI-0004VS-5A for mip6@optimus.ietf.org; Sun, 29 Feb 2004 23:05:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29512 for ; Sun, 29 Feb 2004 23:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxegE-0001jd-00 for mip6@ietf.org; Sun, 29 Feb 2004 23:05:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxefN-0001fE-00 for mip6@ietf.org; Sun, 29 Feb 2004 23:04:30 -0500 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 1Axef2-0001a7-00 for mip6@ietf.org; Sun, 29 Feb 2004 23:04:08 -0500 Message-ID: <024001c3ff42$523cb320$3e6015ac@dclkempt40> From: "James Kempf" To: "Erik Nordmark" Cc: "Hiroyuki OHNISHI" , "Jari Arkko" , References: Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt Date: Sun, 29 Feb 2004 20:04:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: 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 > The distinction between "mobilty" and "mobile IP" is critical here. > > I don't think the access network can charge differently for > mobility without help from the home AAA support. For instance, > the access network here in the Lotte hotel can't know that > a day ago I was in California. > > You can try to charge extra for mobile IP, but wouldn't that mean that > folks would use mobility at other layers e.g. client-only protocols > that don't need reachability at a fixed IP address? > I was thinking of an access network provider that wanted to charge more for a client that changed its address "frequently" (where frequently is somewhat ill defined) as opposed to one that kept the same address for a long session. Mobile IP has certain fixed per node costs in terms of signaling that are definitely not there for a node that gets a lease on its DHCP address and hangs on to it until the lease expires. That would be the justification for charging more. > Given that we want to increase deployment of mobile IP, > since it is a platform for interesting upper layer services, having > the access provider charge more for mobile IP seems counterproductive. > Like I said, people's opinions about whether or not this is desirable can vary. :-) But I don't think the IETF should be engineering the protocol to favor one business model over another (see draft-iab-e2e-futures-txt for a discussion of tussles and how standards should work in the face of them). So far, I don't see anything in the protocol that does. > That doesn't prevent the home provider to charge for maintaining the fixed > IP address precence and tunneling, but you actually want those charges to > be small to drive deployment. > Sure. But XYZ network provider might view the extra capacity they need to install in their access network for Mobile IP signaling as a reason for charging. Though, in the end, it is probably far less than than what they need to accommodate spam. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6