From mailman-admin@ietf.org Sat May 1 10:35:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21009 for ; Sat, 1 May 2004 10:35:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJuJ9-0001VJ-Bh for nemo-archive@lists.ietf.org; Sat, 01 May 2004 09:13:31 -0400 Date: Sat, 01 May 2004 09:13:31 -0400 Message-ID: <20040501131331.27207.56701.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From exim@www1.ietf.org Sat May 1 12:52:59 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01477 for ; Sat, 1 May 2004 12:52:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxB9-0005Ct-TA for nemo-archive@odin.ietf.org; Sat, 01 May 2004 12:17:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41GHR0I020011 for nemo-archive@odin.ietf.org; Sat, 1 May 2004 12:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJugx-0004sv-A3 for nemo-web-archive@optimus.ietf.org; Sat, 01 May 2004 09:38:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14031 for ; Sat, 1 May 2004 09:38:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJugv-0004NF-JK for nemo-web-archive@ietf.org; Sat, 01 May 2004 09:38:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJug9-0004BG-00 for nemo-web-archive@ietf.org; Sat, 01 May 2004 09:37:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJufC-0003xe-00 for nemo-web-archive@ietf.org; Sat, 01 May 2004 09:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJu8Z-0000wa-Uc for nemo-web-archive@ietf.org; Sat, 01 May 2004 09:02:35 -0400 Date: Sat, 01 May 2004 09:02:35 -0400 Message-ID: <20040501130235.27207.16789.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-web-archive@ietf.org: List Password // URL ---- -------- nemo@ietf.org dawauv https://www1.ietf.org/mailman/options/nemo/nemo-web-archive%40ietf.org From nemo-admin@ietf.org Mon May 3 03:08: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 DAA10780 for ; Mon, 3 May 2004 03:08:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXL1-0003Hx-8G; Mon, 03 May 2004 02:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXFk-0000JA-SP for nemo@optimus.ietf.org; Mon, 03 May 2004 02:48:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09945 for ; Mon, 3 May 2004 02:48:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKXFh-0002B3-2t for nemo@ietf.org; Mon, 03 May 2004 02:48:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKXCh-0001eT-00 for nemo@ietf.org; Mon, 03 May 2004 02:45:28 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BKXAa-0001FN-00 for nemo@ietf.org; Mon, 03 May 2004 02:43:16 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i436bb1u006471 for ; Mon, 3 May 2004 15:37:37 +0900 Message-Id: <200405030637.i436bb1u006471@popeye.snu.ac.kr> From: "Jongkeun Na" To: Date: Mon, 3 May 2004 15:43:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <40925CA9.6000101@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQuvKRkBmVpnOEhTY2rVutJ0rnCFgCHEpgw X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] new draft submitted about NEMO RO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Just to inform you that we've submitted a new draft on the route optimization. I don't know why that draft was not appeared in this mailing list. Anyway, any feedback from you all is welcomed. Thanks. http://www.ietf.org/internet-drafts/draft-na-nemo-path-control-header-00.txt /Jongkeun From exim@www1.ietf.org Mon May 3 03:33:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12060 for ; Mon, 3 May 2004 03:33:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXmR-0006km-DE for nemo-archive@odin.ietf.org; Mon, 03 May 2004 03:22:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i437MNHD025952 for nemo-archive@odin.ietf.org; Mon, 3 May 2004 03:22:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXgp-0003cd-4f for nemo-web-archive@optimus.ietf.org; Mon, 03 May 2004 03:16:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11299 for ; Mon, 3 May 2004 03:16:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKXgn-0006wo-1J for nemo-web-archive@ietf.org; Mon, 03 May 2004 03:16:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKXce-0006G4-00 for nemo-web-archive@ietf.org; Mon, 03 May 2004 03:12:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKXY8-0005Te-00 for nemo-web-archive@ietf.org; Mon, 03 May 2004 03:07:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXL1-0003Hx-8G; Mon, 03 May 2004 02:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXFk-0000JA-SP for nemo@optimus.ietf.org; Mon, 03 May 2004 02:48:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09945 for ; Mon, 3 May 2004 02:48:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKXFh-0002B3-2t for nemo@ietf.org; Mon, 03 May 2004 02:48:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKXCh-0001eT-00 for nemo@ietf.org; Mon, 03 May 2004 02:45:28 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BKXAa-0001FN-00 for nemo@ietf.org; Mon, 03 May 2004 02:43:16 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i436bb1u006471 for ; Mon, 3 May 2004 15:37:37 +0900 Message-Id: <200405030637.i436bb1u006471@popeye.snu.ac.kr> From: "Jongkeun Na" To: Date: Mon, 3 May 2004 15:43:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <40925CA9.6000101@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQuvKRkBmVpnOEhTY2rVutJ0rnCFgCHEpgw Content-Transfer-Encoding: 7bit Subject: [nemo] new draft submitted about NEMO RO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, Just to inform you that we've submitted a new draft on the route optimization. I don't know why that draft was not appeared in this mailing list. Anyway, any feedback from you all is welcomed. Thanks. http://www.ietf.org/internet-drafts/draft-na-nemo-path-control-header-00.txt /Jongkeun From nemo-admin@ietf.org Mon May 3 21:18:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15170 for ; Mon, 3 May 2004 21:18:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKoXR-0003GY-TM; Mon, 03 May 2004 21:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKoVY-0002tH-OG for nemo@optimus.ietf.org; Mon, 03 May 2004 21:14:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15027 for ; Mon, 3 May 2004 21:14:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKoVW-0003ZU-50 for nemo@ietf.org; Mon, 03 May 2004 21:14:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKoUd-0003Sj-00 for nemo@ietf.org; Mon, 03 May 2004 21:13:08 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1BKoU4-0003Lb-00 for nemo@ietf.org; Mon, 03 May 2004 21:12:32 -0400 Received: from localhost ([130.194.13.81]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L9P03VLOSO90HW1K@vaxh.its.monash.edu.au> for nemo@ietf.org; Tue, 4 May 2004 11:07:22 +1000 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id EF6011B000C; Tue, 04 May 2004 11:07:21 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id DEB7F12400B; Tue, 04 May 2004 11:07:21 +1000 (EST) Date: Tue, 04 May 2004 11:07:21 +1000 From: Greg Daley Subject: Re: [nemo] [Fwd: I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt] To: Christophe Janneteau Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <4096ECC9.9030106@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <40925CA9.6000101@motorola.com> 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Christophe (and the other authors), Thanks for producing this document! The principles are good (i've only been able to skim through though). I have some comments regarding multicast routing protocols, though. Please correct me if I'm wrong, but it seems that in the draft you indicate that routing protocols don't need to be run on the local routers or the MRs. While this is indeed correct, there is the possibility that an MR could run a multicast routing protocol between itself (on its downstream interfaces) and its local routers, as if it were a router on the fixed Internet. Certainly, the local fixed routers don't need only to be proxies. The requirement for proxying arises only from the discontinuity of trust between visiting MRs and the network which hosts them (the access network or superior NEMO). In this case, the visiting MR still needs to run MLD proxying to the visited network in order to get route optimized (Remote Subscription) service. Within its own network, it may be possible to propagate routing information either from the home network, or created by proxying to the visited network, acting as a multicast border router for this information. This information could be passed to all fixed routers within the NEMO, although visiting mobile routers wouldn't be able to receive such messages since they're not in the same routing domain. This would give some flexibility as to where the MR sources its traffic (from visited or home networks), without requiring changes to how multicast routing is configured on non-mobile routers. Is it worthwhile to indicate this possibility in the document or an appendix? Please let me know what you think. Greg Christophe Janneteau wrote: > Hi All, > > Just to inform you that we have submitted a new I-D on the support of IP > multicast for mobile networks. The proposal relies on the use of the > MLD-based multicast forwarding mechanism (from magma WG) inside the > mobile network. > > I was expecting the draft to be announced on the NEMO mailing list too, > but it was not...this is why I am sending this email now. > > Thanks > Christophe > > ------------------------------------------------------------------------ > > Subject: > I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt > From: > > Date: > Wed, 28 Apr 2004 15:29:14 -0400 > To: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Multicast for Mobile Networks with MLD-Proxy > Author(s) : C. Janneteau, et al. > Filename : draft-janneteau-nemo-multicast-mldproxy-00.txt > Pages : 13 > Date : 2004-4-28 > > This document addresses the problem of delivering IPv6 multicast > traffic to nodes inside a mobile network. An approach based on the > deployment of "MLD-based Multicast Forwarding (MLD-proxying)" [1] > in the mobile network, combined with the use of MLD [2][3] between > the mobile router (MR) and the visited network, is proposed. Such a > configuration allows multicast support for mobile networks, without > the need to run a multicast routing protocol. In addition of being > simple to implement and deploy, this approach provides global > mobility in the Internet, and optimal multicast routing with nested > mobile networks, while optimizing network and radio resources. This > document does not specify new protocols, nor extensions to existing > protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-janneteau-nemo-multicast-mldproxy-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-janneteau-nemo-multicast-mldproxy-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-janneteau-nemo-multicast-mldproxy-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. From exim@www1.ietf.org Mon May 3 21:21:39 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15291 for ; Mon, 3 May 2004 21:21:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKobV-0004BL-Um for nemo-archive@odin.ietf.org; Mon, 03 May 2004 21:20:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i441KD92016071 for nemo-archive@odin.ietf.org; Mon, 3 May 2004 21:20:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKoaW-0003zY-Rz for nemo-web-archive@optimus.ietf.org; Mon, 03 May 2004 21:19:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15229 for ; Mon, 3 May 2004 21:19:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKoaU-0004EV-7U for nemo-web-archive@ietf.org; Mon, 03 May 2004 21:19:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKoZZ-00046k-00 for nemo-web-archive@ietf.org; Mon, 03 May 2004 21:18:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKoZA-0003yS-00 for nemo-web-archive@ietf.org; Mon, 03 May 2004 21:17:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKoXR-0003GY-TM; Mon, 03 May 2004 21:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKoVY-0002tH-OG for nemo@optimus.ietf.org; Mon, 03 May 2004 21:14:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15027 for ; Mon, 3 May 2004 21:14:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKoVW-0003ZU-50 for nemo@ietf.org; Mon, 03 May 2004 21:14:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKoUd-0003Sj-00 for nemo@ietf.org; Mon, 03 May 2004 21:13:08 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1BKoU4-0003Lb-00 for nemo@ietf.org; Mon, 03 May 2004 21:12:32 -0400 Received: from localhost ([130.194.13.81]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L9P03VLOSO90HW1K@vaxh.its.monash.edu.au> for nemo@ietf.org; Tue, 4 May 2004 11:07:22 +1000 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id EF6011B000C; Tue, 04 May 2004 11:07:21 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id DEB7F12400B; Tue, 04 May 2004 11:07:21 +1000 (EST) Date: Tue, 04 May 2004 11:07:21 +1000 From: Greg Daley Subject: Re: [nemo] [Fwd: I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt] To: Christophe Janneteau Cc: nemo@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <4096ECC9.9030106@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <40925CA9.6000101@motorola.com> Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Christophe (and the other authors), Thanks for producing this document! The principles are good (i've only been able to skim through though). I have some comments regarding multicast routing protocols, though. Please correct me if I'm wrong, but it seems that in the draft you indicate that routing protocols don't need to be run on the local routers or the MRs. While this is indeed correct, there is the possibility that an MR could run a multicast routing protocol between itself (on its downstream interfaces) and its local routers, as if it were a router on the fixed Internet. Certainly, the local fixed routers don't need only to be proxies. The requirement for proxying arises only from the discontinuity of trust between visiting MRs and the network which hosts them (the access network or superior NEMO). In this case, the visiting MR still needs to run MLD proxying to the visited network in order to get route optimized (Remote Subscription) service. Within its own network, it may be possible to propagate routing information either from the home network, or created by proxying to the visited network, acting as a multicast border router for this information. This information could be passed to all fixed routers within the NEMO, although visiting mobile routers wouldn't be able to receive such messages since they're not in the same routing domain. This would give some flexibility as to where the MR sources its traffic (from visited or home networks), without requiring changes to how multicast routing is configured on non-mobile routers. Is it worthwhile to indicate this possibility in the document or an appendix? Please let me know what you think. Greg Christophe Janneteau wrote: > Hi All, > > Just to inform you that we have submitted a new I-D on the support of IP > multicast for mobile networks. The proposal relies on the use of the > MLD-based multicast forwarding mechanism (from magma WG) inside the > mobile network. > > I was expecting the draft to be announced on the NEMO mailing list too, > but it was not...this is why I am sending this email now. > > Thanks > Christophe > > ------------------------------------------------------------------------ > > Subject: > I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt > From: > > Date: > Wed, 28 Apr 2004 15:29:14 -0400 > To: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Multicast for Mobile Networks with MLD-Proxy > Author(s) : C. Janneteau, et al. > Filename : draft-janneteau-nemo-multicast-mldproxy-00.txt > Pages : 13 > Date : 2004-4-28 > > This document addresses the problem of delivering IPv6 multicast > traffic to nodes inside a mobile network. An approach based on the > deployment of "MLD-based Multicast Forwarding (MLD-proxying)" [1] > in the mobile network, combined with the use of MLD [2][3] between > the mobile router (MR) and the visited network, is proposed. Such a > configuration allows multicast support for mobile networks, without > the need to run a multicast routing protocol. In addition of being > simple to implement and deploy, this approach provides global > mobility in the Internet, and optimal multicast routing with nested > mobile networks, while optimizing network and radio resources. This > document does not specify new protocols, nor extensions to existing > protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-janneteau-nemo-multicast-mldproxy-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-janneteau-nemo-multicast-mldproxy-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-janneteau-nemo-multicast-mldproxy-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. From nemo-admin@ietf.org Tue May 4 06:53:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22070 for ; Tue, 4 May 2004 06:53:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIt-0000bg-HJ; Tue, 04 May 2004 06:37:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKwi2-0008P5-4s for nemo@optimus.ietf.org; Tue, 04 May 2004 05:59:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19439 for ; Tue, 4 May 2004 05:59:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKwhy-0003ES-Cl for nemo@ietf.org; Tue, 04 May 2004 05:59:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKwgy-000320-00 for nemo@ietf.org; Tue, 04 May 2004 05:58:25 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1BKwfx-0002jg-00 for nemo@ietf.org; Tue, 04 May 2004 05:57:21 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i449r3fW008242; Tue, 4 May 2004 02:53:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i449vFUL031947; Tue, 4 May 2004 04:57:16 -0500 Received: from motorola.com (zfr01-2135.crm.mot.com [10.161.201.135]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0B7CE863810; Tue, 4 May 2004 11:57:15 +0200 (CEST) Message-ID: <409768F9.3020500@motorola.com> Date: Tue, 04 May 2004 11:57:13 +0200 From: Christophe Janneteau 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: greg.daley@eng.monash.edu.au Cc: nemo@ietf.org, Christophe Janneteau-ACJ006 Subject: Re: [nemo] [Fwd: I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt] References: <40925CA9.6000101@motorola.com> <4096ECC9.9030106@eng.monash.edu.au> In-Reply-To: <4096ECC9.9030106@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Greg, Thanks a lot for reading the draft and commenting on it. Greg Daley wrote: > I have some comments regarding multicast routing protocols, > though. > > Please correct me if I'm wrong, but it seems that in the > draft you indicate that routing protocols don't need to > be run on the local routers or the MRs. Yes, in the draft we say that it is possible to route multicast packets inside the moving network, without running a multicast routing protocol internally, by using MLD-proxying (from magma WG). In the introduction, we also briefly mention another approach where fixed routers in the moving network run the same multicast routing protocol as the routers in the MR's home network, so that multicast signalling can take place over the MRHA tunnel. > While this is indeed correct, there is the possibility > that an MR could run a multicast routing protocol > between itself (on its downstream interfaces) and its > local routers, as if it were a router on the fixed Internet. > > Certainly, the local fixed routers don't need only to be > proxies. > > The requirement for proxying arises only from the discontinuity > of trust between visiting MRs and the network which hosts them > (the access network or superior NEMO). > > In this case, the visiting MR still needs to run MLD proxying to > the visited network in order to get route optimized (Remote > Subscription) service. Exactly, I agree. A multicast routing protocol can be run inside the moving network. In this case, the MR has basically two possibilities in hand: 1) behave as a regular multicast router and exchange multicast signalling with its home network over the MR-HA tunnel. Of course routing is not optimized in that case. OR 2) Interact with the multicast router (AR) on the visited link, in order to optimize the routing path. Because it is possible that MR and AR do not run the same multicast routing protocol, and also mainly because of the trusting issue you mentioned, it is generally not possible for MR and AR to exchange multicast routing signalling directly. On the other hand MLD protocol can be used by MR, to inform AR about the multicast groups it wants to receive traffic for. MR should then acts as a multicast _gateway_ to "translate" group subscription received on its ingress interface (with the routing protocol) into MLD reports on its egress interface towards AR. For the version 00 of the draft we exlicitly avoided going to deep into 2) in order to stick to the simplest concept first. Our intention was to present a simple approach that would base only on well-known and specified mechanisms. This is why we focused only on the simplest form of multicast _gateway_ to be placed on MR that is a MLD-proxy mapping MLD into MLD (as specified in magma WG). More complex form of gateway would map routing protocol into MLD. Is 2) what you have in mind? > Within its own network, it may be possible to propagate > routing information either from the home network, or created by > proxying to the visited network, acting as a multicast border > router for this information. > > This information could be passed to all fixed routers within the > NEMO, although visiting mobile routers wouldn't be able to > receive such messages since they're not in the same routing domain. > > This would give some flexibility as to where the MR sources its > traffic (from visited or home networks), without requiring changes > to how multicast routing is configured on non-mobile routers. I agree. This provides flexibility, at the cost of deploying a more complex function on the MR, the border router/gateway. Another aspect to consider is the size of the moving network and the additional cost introduced by deploying a multicast routing protocol internally. In not-too-big moving network, running MLD-proxy on internal fixed routers inside the moving network may be more advantageous that a multicast routing protocol. > Is it worthwhile to indicate this possibility in the document or > an appendix? Yes, you are right we should have a paragraph on this in future update. Thanks, Christophe > Please let me know what you think. > > Greg > From exim@www1.ietf.org Tue May 4 07:10:53 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23721 for ; Tue, 4 May 2004 07:10:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxjX-0008By-Dr for nemo-archive@odin.ietf.org; Tue, 04 May 2004 07:05:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44B57F5031480 for nemo-archive@odin.ietf.org; Tue, 4 May 2004 07:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxeD-0006hM-00 for nemo-web-archive@optimus.ietf.org; Tue, 04 May 2004 06:59:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22463 for ; Tue, 4 May 2004 06:59:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKxe8-0000FY-RB for nemo-web-archive@ietf.org; Tue, 04 May 2004 06:59:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxbo-0007Nh-00 for nemo-web-archive@ietf.org; Tue, 04 May 2004 06:57:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxaQ-00072l-01 for nemo-web-archive@ietf.org; Tue, 04 May 2004 06:55:42 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKxY4-000562-4B for nemo-web-archive@ietf.org; Tue, 04 May 2004 06:53:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIt-0000bg-HJ; Tue, 04 May 2004 06:37:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKwi2-0008P5-4s for nemo@optimus.ietf.org; Tue, 04 May 2004 05:59:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19439 for ; Tue, 4 May 2004 05:59:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKwhy-0003ES-Cl for nemo@ietf.org; Tue, 04 May 2004 05:59:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKwgy-000320-00 for nemo@ietf.org; Tue, 04 May 2004 05:58:25 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1BKwfx-0002jg-00 for nemo@ietf.org; Tue, 04 May 2004 05:57:21 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i449r3fW008242; Tue, 4 May 2004 02:53:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i449vFUL031947; Tue, 4 May 2004 04:57:16 -0500 Received: from motorola.com (zfr01-2135.crm.mot.com [10.161.201.135]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0B7CE863810; Tue, 4 May 2004 11:57:15 +0200 (CEST) Message-ID: <409768F9.3020500@motorola.com> Date: Tue, 04 May 2004 11:57:13 +0200 From: Christophe Janneteau 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: greg.daley@eng.monash.edu.au Cc: nemo@ietf.org, Christophe Janneteau-ACJ006 Subject: Re: [nemo] [Fwd: I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt] References: <40925CA9.6000101@motorola.com> <4096ECC9.9030106@eng.monash.edu.au> In-Reply-To: <4096ECC9.9030106@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Hi Greg, Thanks a lot for reading the draft and commenting on it. Greg Daley wrote: > I have some comments regarding multicast routing protocols, > though. > > Please correct me if I'm wrong, but it seems that in the > draft you indicate that routing protocols don't need to > be run on the local routers or the MRs. Yes, in the draft we say that it is possible to route multicast packets inside the moving network, without running a multicast routing protocol internally, by using MLD-proxying (from magma WG). In the introduction, we also briefly mention another approach where fixed routers in the moving network run the same multicast routing protocol as the routers in the MR's home network, so that multicast signalling can take place over the MRHA tunnel. > While this is indeed correct, there is the possibility > that an MR could run a multicast routing protocol > between itself (on its downstream interfaces) and its > local routers, as if it were a router on the fixed Internet. > > Certainly, the local fixed routers don't need only to be > proxies. > > The requirement for proxying arises only from the discontinuity > of trust between visiting MRs and the network which hosts them > (the access network or superior NEMO). > > In this case, the visiting MR still needs to run MLD proxying to > the visited network in order to get route optimized (Remote > Subscription) service. Exactly, I agree. A multicast routing protocol can be run inside the moving network. In this case, the MR has basically two possibilities in hand: 1) behave as a regular multicast router and exchange multicast signalling with its home network over the MR-HA tunnel. Of course routing is not optimized in that case. OR 2) Interact with the multicast router (AR) on the visited link, in order to optimize the routing path. Because it is possible that MR and AR do not run the same multicast routing protocol, and also mainly because of the trusting issue you mentioned, it is generally not possible for MR and AR to exchange multicast routing signalling directly. On the other hand MLD protocol can be used by MR, to inform AR about the multicast groups it wants to receive traffic for. MR should then acts as a multicast _gateway_ to "translate" group subscription received on its ingress interface (with the routing protocol) into MLD reports on its egress interface towards AR. For the version 00 of the draft we exlicitly avoided going to deep into 2) in order to stick to the simplest concept first. Our intention was to present a simple approach that would base only on well-known and specified mechanisms. This is why we focused only on the simplest form of multicast _gateway_ to be placed on MR that is a MLD-proxy mapping MLD into MLD (as specified in magma WG). More complex form of gateway would map routing protocol into MLD. Is 2) what you have in mind? > Within its own network, it may be possible to propagate > routing information either from the home network, or created by > proxying to the visited network, acting as a multicast border > router for this information. > > This information could be passed to all fixed routers within the > NEMO, although visiting mobile routers wouldn't be able to > receive such messages since they're not in the same routing domain. > > This would give some flexibility as to where the MR sources its > traffic (from visited or home networks), without requiring changes > to how multicast routing is configured on non-mobile routers. I agree. This provides flexibility, at the cost of deploying a more complex function on the MR, the border router/gateway. Another aspect to consider is the size of the moving network and the additional cost introduced by deploying a multicast routing protocol internally. In not-too-big moving network, running MLD-proxy on internal fixed routers inside the moving network may be more advantageous that a multicast routing protocol. > Is it worthwhile to indicate this possibility in the document or > an appendix? Yes, you are right we should have a paragraph on this in future update. Thanks, Christophe > Please let me know what you think. > > Greg > From nemo-admin@ietf.org Fri May 7 02:10:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25026 for ; Fri, 7 May 2004 02:10:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyTo-0004AI-Ny; Fri, 07 May 2004 02:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyRO-0002SV-1a for nemo@optimus.ietf.org; Fri, 07 May 2004 02:02:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17034 for ; Fri, 7 May 2004 02:02:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLyRK-0002Qg-Fv for nemo@ietf.org; Fri, 07 May 2004 02:02:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLyQX-00021X-00 for nemo@ietf.org; Fri, 07 May 2004 02:01:41 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1BLyPu-0001ZL-00 for nemo@ietf.org; Fri, 07 May 2004 02:01:02 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 0D6805D3C0; Fri, 7 May 2004 15:00:20 +0900 (JST) Date: Fri, 7 May 2004 15:00:20 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: "Jongkeun Na" , Christophe.Janneteau@motorola.com Message-Id: <20040507150020.4b67a179.ernst@sfc.wide.ad.jp> In-Reply-To: <200405030637.i436bb1u006471@popeye.snu.ac.kr> References: <40925CA9.6000101@motorola.com> <200405030637.i436bb1u006471@popeye.snu.ac.kr> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Subject: [nemo] About new drafts Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit To all draft authors, Note that individually submitted drafts don't get announced on the nemo WG list if you don't **EXPLICITLY** ask the secretariat to do so. Thierry. On Mon, 3 May 2004 15:43:00 +0900 "Jongkeun Na" wrote: > Hi all, > > Just to inform you that we've submitted a new draft on the route > optimization. I don't know why that draft was not appeared in this mailing > list. Anyway, any feedback from you all is welcomed. Thanks. > http://www.ietf.org/internet-drafts/draft-na-nemo-path-control-header-00.txt > > /Jongkeun > From nemo-admin@ietf.org Fri May 7 02:17:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28396 for ; Fri, 7 May 2004 02:17:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyae-0008Lw-Og; Fri, 07 May 2004 02:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyVz-0005UH-36 for nemo@optimus.ietf.org; Fri, 07 May 2004 02:07:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21682 for ; Fri, 7 May 2004 02:07:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLyVv-0004RC-AL for nemo@ietf.org; Fri, 07 May 2004 02:07:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLyU6-0003RE-00 for nemo@ietf.org; Fri, 07 May 2004 02:05:23 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1BLySn-0002qr-00 for nemo@ietf.org; Fri, 07 May 2004 02:04:01 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id ECD195D190; Fri, 7 May 2004 15:03:30 +0900 (JST) Date: Fri, 7 May 2004 15:03:31 +0900 From: Thierry Ernst To: Benjamin Koh Tien-Ming Cc: nemo@ietf.org Subject: Re: [nemo] Question on MR - CN Message-Id: <20040507150331.02f8f363.ernst@sfc.wide.ad.jp> In-Reply-To: <408F1019.9020908@psl.com.sg> References: <408F1019.9020908@psl.com.sg> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, For security reasons, we decided to use a bidirectional tunnel, so encapsulation between MR and HA in both directions. This was decided before the actual set up of the NEMO WG. I don't know if there is a particular thread to recommend you, but probably that would be on the monet ML archives, not the nemo ML archives. Thierry. On Wed, 28 Apr 2004 09:59:53 +0800 Benjamin Koh Tien-Ming wrote: > Hi! > > I have a question on MR operation that I'm hoping someone can help clarify. > > In the case when the MR is away from home, a LFN sends a packet to a CN. > Can the MR encapsulate the original packet and forward it directly to > the CN using it's current CoA (Care-of-Address)? Are there any reasons > against or problems with using such a method? > > Please direct me to a relevant thread if this question had been > previously raised. > > Thanks! > > Regards, > Benjamin > > From exim@www1.ietf.org Fri May 7 02:24:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29223 for ; Fri, 7 May 2004 02:24:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyeF-00024R-2Z for nemo-archive@odin.ietf.org; Fri, 07 May 2004 02:15:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i476FpSH007953 for nemo-archive@odin.ietf.org; Fri, 7 May 2004 02:15:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLya1-000800-Md for nemo-web-archive@optimus.ietf.org; Fri, 07 May 2004 02:11:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25882 for ; Fri, 7 May 2004 02:11:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLyZy-0006Sf-63 for nemo-web-archive@ietf.org; Fri, 07 May 2004 02:11:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLyZ6-00064I-00 for nemo-web-archive@ietf.org; Fri, 07 May 2004 02:10:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLyYf-0005fM-00 for nemo-web-archive@ietf.org; Fri, 07 May 2004 02:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyTo-0004AI-Ny; Fri, 07 May 2004 02:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyRO-0002SV-1a for nemo@optimus.ietf.org; Fri, 07 May 2004 02:02:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17034 for ; Fri, 7 May 2004 02:02:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLyRK-0002Qg-Fv for nemo@ietf.org; Fri, 07 May 2004 02:02:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLyQX-00021X-00 for nemo@ietf.org; Fri, 07 May 2004 02:01:41 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1BLyPu-0001ZL-00 for nemo@ietf.org; Fri, 07 May 2004 02:01:02 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 0D6805D3C0; Fri, 7 May 2004 15:00:20 +0900 (JST) Date: Fri, 7 May 2004 15:00:20 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: "Jongkeun Na" , Christophe.Janneteau@motorola.com Message-Id: <20040507150020.4b67a179.ernst@sfc.wide.ad.jp> In-Reply-To: <200405030637.i436bb1u006471@popeye.snu.ac.kr> References: <40925CA9.6000101@motorola.com> <200405030637.i436bb1u006471@popeye.snu.ac.kr> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] About new drafts Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 To all draft authors, Note that individually submitted drafts don't get announced on the nemo WG list if you don't **EXPLICITLY** ask the secretariat to do so. Thierry. On Mon, 3 May 2004 15:43:00 +0900 "Jongkeun Na" wrote: > Hi all, > > Just to inform you that we've submitted a new draft on the route > optimization. I don't know why that draft was not appeared in this mailing > list. Anyway, any feedback from you all is welcomed. Thanks. > http://www.ietf.org/internet-drafts/draft-na-nemo-path-control-header-00.txt > > /Jongkeun > From exim@www1.ietf.org Fri May 7 02:25:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29383 for ; Fri, 7 May 2004 02:25:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLylr-0006Zs-8b for nemo-archive@odin.ietf.org; Fri, 07 May 2004 02:23:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i476NhEm025145 for nemo-archive@odin.ietf.org; Fri, 7 May 2004 02:23:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLygs-0003ee-Fi for nemo-web-archive@optimus.ietf.org; Fri, 07 May 2004 02:18:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28622 for ; Fri, 7 May 2004 02:18:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLygp-0001Zp-15 for nemo-web-archive@ietf.org; Fri, 07 May 2004 02:18:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLygA-0001AR-00 for nemo-web-archive@ietf.org; Fri, 07 May 2004 02:17:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLyf9-0000k2-00 for nemo-web-archive@ietf.org; Fri, 07 May 2004 02:16:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyae-0008Lw-Og; Fri, 07 May 2004 02:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyVz-0005UH-36 for nemo@optimus.ietf.org; Fri, 07 May 2004 02:07:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21682 for ; Fri, 7 May 2004 02:07:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLyVv-0004RC-AL for nemo@ietf.org; Fri, 07 May 2004 02:07:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLyU6-0003RE-00 for nemo@ietf.org; Fri, 07 May 2004 02:05:23 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1BLySn-0002qr-00 for nemo@ietf.org; Fri, 07 May 2004 02:04:01 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id ECD195D190; Fri, 7 May 2004 15:03:30 +0900 (JST) Date: Fri, 7 May 2004 15:03:31 +0900 From: Thierry Ernst To: Benjamin Koh Tien-Ming Cc: nemo@ietf.org Subject: Re: [nemo] Question on MR - CN Message-Id: <20040507150331.02f8f363.ernst@sfc.wide.ad.jp> In-Reply-To: <408F1019.9020908@psl.com.sg> References: <408F1019.9020908@psl.com.sg> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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, For security reasons, we decided to use a bidirectional tunnel, so encapsulation between MR and HA in both directions. This was decided before the actual set up of the NEMO WG. I don't know if there is a particular thread to recommend you, but probably that would be on the monet ML archives, not the nemo ML archives. Thierry. On Wed, 28 Apr 2004 09:59:53 +0800 Benjamin Koh Tien-Ming wrote: > Hi! > > I have a question on MR operation that I'm hoping someone can help clarify. > > In the case when the MR is away from home, a LFN sends a packet to a CN. > Can the MR encapsulate the original packet and forward it directly to > the CN using it's current CoA (Care-of-Address)? Are there any reasons > against or problems with using such a method? > > Please direct me to a relevant thread if this question had been > previously raised. > > Thanks! > > Regards, > Benjamin > > From nemo-admin@ietf.org Fri May 7 10:28:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25727 for ; Fri, 7 May 2004 10:28:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5va-0000sz-24; Fri, 07 May 2004 10:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCNH-0005BY-Qq for nemo@optimus.ietf.org; Tue, 04 May 2004 22:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16476 for ; Tue, 4 May 2004 22:43:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLCNE-0004X8-CD for nemo@ietf.org; Tue, 04 May 2004 22:43:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCMK-0004Pm-00 for nemo@ietf.org; Tue, 04 May 2004 22:42:09 -0400 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BLCLb-0004AP-00 for nemo@ietf.org; Tue, 04 May 2004 22:41:23 -0400 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-white.research.att.com (Postfix) with ESMTP id B41E2664037; Tue, 4 May 2004 22:40:54 -0400 (EDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-green.research.att.com (Postfix) with ESMTP id A0CF5F3A8F; Tue, 4 May 2004 22:40:54 -0400 (EDT) Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i452eqZ12351; Tue, 4 May 2004 22:40:52 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id B18717B44; Tue, 4 May 2004 22:40:51 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Vijay Devarapalli Cc: margaret@thingmagic.com, nemo@ietf.org In-Reply-To: Your message of "Mon, 05 Apr 2004 14:48:21 PDT." <4071D425.7060502@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 May 2004 22:40:51 -0400 Message-Id: <20040505024051.B18717B44@berkshire.research.att.com> 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 Subject: [nemo] Re: your comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , In message <4071D425.7060502@iprg.nokia.com>, Vijay Devarapalli writes: >hi Steve, > >I am trying to address your comments on draft-ietf-nemo-basic-support > >> 3: What good does it to to check the source address of the >> outer IPv6 header? Spoofing that is far too easy. > >when the Mobile Router (MR) receives a tunneled packet >from the Home Agent (HA), it looks like the following > >IPv6 hdr (src=HA, dst=MR_CoA) >IPv6 hdr (src=CN, dst=MNN) >Payload > >MNN (Mobile network node) is one of the nodes inside the >Mobile Network. > >when the MR decapsulates the above packet and forwards the >inner packet, it has to perform a few tunnel checks. it has >to verify that the source address on the outer IPv6 header >is the Home Agent and the destination address in the inner >packet is one of the nodes in the Mobile Network. such >checks need to be performed always, right? > >this check however only needs to be done if there is no >IPsec protection (in tunnel mode) for the packets. OK. Should the above sentence be added as a clarification? > >> >> 6.1.2: why is the prefix table check only a SHOULD and not a MUST? > >well, the mobile router and the HA most of the time share >some kind of subscriber/provider relationship. the prefix >table is needed only if you expect the mobile routers to >misbehave. this was the concensus in the WG when this was >discussed earlier. > >> >> 8: This text is unclear: >> >> When the Mobile Router and the Home Agent exchange routes >> through a dynamic routing protocol, the Mobile Router >> should be careful in including the same Mobile Network >> Prefixes in the Binding Update to the Home Agent and in >> the routing protocol updates. The Home Agent depending >> on its configuration might not add routes based on the >> prefix information in the Binding Updates at all, and >> might use only the routing protocol updates. Moreover, >> including the same prefix information in both the Binding >> Update and the routing protocol update is redundant. >> >> Do you mean "be careful to include the same information in >> both places" -- redunancy is sometimes good. Or do you >> mean "be careful to avoid doing this"? Personally, I think >> the former is more appropriate, because it allows a check >> on the validity of the routing information. Note that the >> prefixes announced via binding updates are checked for >> authorization; routing data generally is not. I would thus >> suggest that routing advertisements MUST NOT contain any >> prefixes not known to the home agent by either implicit >> mode configuration or explicit mode announcement. I don't see any response here. Or is the response to 9 intended to cover this? I think the language needs fixing no matter what. >> >> 9: When discussing Home Agent routing protocol processing, must >> the HA check the authorization for routing messages in general, >> or for the prefixes actually being announced? >> > >we actually wanted to avoid any kind of coupling between >running an IGP and the NEMO basic support protocol. > >when a routing protocol is used between the mobile router >and the HA, the bi-directional tunnel between the MR and >the HA actually extends the IGP domain to include the MR. >thats all. NEMO basic support protocol only creates the >bi-directional tunnel (and few more things). we dont want >NEMO to do the verification for routing protocol updates. > >if there is enough trust between the MR and the HA and >they are configured to run an IGP, they do it. otherwise >the MR and the HA should not run an IGP when the MR is >not at home. we can make this more explicit if needed. > I'd appreciate that, especially since 8 does talk about some linkage. --Steve Bellovin, http://www.research.att.com/~smb From exim@www1.ietf.org Fri May 7 11:08:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29619 for ; Fri, 7 May 2004 11:08:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6b4-00051u-85 for nemo-archive@odin.ietf.org; Fri, 07 May 2004 10:45:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Ej6ia019334 for nemo-archive@odin.ietf.org; Fri, 7 May 2004 10:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6Mo-0007jB-0S for nemo-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:30:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25910 for ; Fri, 7 May 2004 10:30:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6Ml-00062T-Me for nemo-web-archive@ietf.org; Fri, 07 May 2004 10:30:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6Ll-0005YW-00 for nemo-web-archive@ietf.org; Fri, 07 May 2004 10:29:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6Ky-00054Y-00 for nemo-web-archive@ietf.org; Fri, 07 May 2004 10:28:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5va-0000sz-24; Fri, 07 May 2004 10:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCNH-0005BY-Qq for nemo@optimus.ietf.org; Tue, 04 May 2004 22:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16476 for ; Tue, 4 May 2004 22:43:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLCNE-0004X8-CD for nemo@ietf.org; Tue, 04 May 2004 22:43:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCMK-0004Pm-00 for nemo@ietf.org; Tue, 04 May 2004 22:42:09 -0400 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BLCLb-0004AP-00 for nemo@ietf.org; Tue, 04 May 2004 22:41:23 -0400 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-white.research.att.com (Postfix) with ESMTP id B41E2664037; Tue, 4 May 2004 22:40:54 -0400 (EDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-green.research.att.com (Postfix) with ESMTP id A0CF5F3A8F; Tue, 4 May 2004 22:40:54 -0400 (EDT) Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i452eqZ12351; Tue, 4 May 2004 22:40:52 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id B18717B44; Tue, 4 May 2004 22:40:51 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Vijay Devarapalli Cc: margaret@thingmagic.com, nemo@ietf.org In-Reply-To: Your message of "Mon, 05 Apr 2004 14:48:21 PDT." <4071D425.7060502@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 May 2004 22:40:51 -0400 Message-Id: <20040505024051.B18717B44@berkshire.research.att.com> Subject: [nemo] Re: your comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 message <4071D425.7060502@iprg.nokia.com>, Vijay Devarapalli writes: >hi Steve, > >I am trying to address your comments on draft-ietf-nemo-basic-support > >> 3: What good does it to to check the source address of the >> outer IPv6 header? Spoofing that is far too easy. > >when the Mobile Router (MR) receives a tunneled packet >from the Home Agent (HA), it looks like the following > >IPv6 hdr (src=HA, dst=MR_CoA) >IPv6 hdr (src=CN, dst=MNN) >Payload > >MNN (Mobile network node) is one of the nodes inside the >Mobile Network. > >when the MR decapsulates the above packet and forwards the >inner packet, it has to perform a few tunnel checks. it has >to verify that the source address on the outer IPv6 header >is the Home Agent and the destination address in the inner >packet is one of the nodes in the Mobile Network. such >checks need to be performed always, right? > >this check however only needs to be done if there is no >IPsec protection (in tunnel mode) for the packets. OK. Should the above sentence be added as a clarification? > >> >> 6.1.2: why is the prefix table check only a SHOULD and not a MUST? > >well, the mobile router and the HA most of the time share >some kind of subscriber/provider relationship. the prefix >table is needed only if you expect the mobile routers to >misbehave. this was the concensus in the WG when this was >discussed earlier. > >> >> 8: This text is unclear: >> >> When the Mobile Router and the Home Agent exchange routes >> through a dynamic routing protocol, the Mobile Router >> should be careful in including the same Mobile Network >> Prefixes in the Binding Update to the Home Agent and in >> the routing protocol updates. The Home Agent depending >> on its configuration might not add routes based on the >> prefix information in the Binding Updates at all, and >> might use only the routing protocol updates. Moreover, >> including the same prefix information in both the Binding >> Update and the routing protocol update is redundant. >> >> Do you mean "be careful to include the same information in >> both places" -- redunancy is sometimes good. Or do you >> mean "be careful to avoid doing this"? Personally, I think >> the former is more appropriate, because it allows a check >> on the validity of the routing information. Note that the >> prefixes announced via binding updates are checked for >> authorization; routing data generally is not. I would thus >> suggest that routing advertisements MUST NOT contain any >> prefixes not known to the home agent by either implicit >> mode configuration or explicit mode announcement. I don't see any response here. Or is the response to 9 intended to cover this? I think the language needs fixing no matter what. >> >> 9: When discussing Home Agent routing protocol processing, must >> the HA check the authorization for routing messages in general, >> or for the prefixes actually being announced? >> > >we actually wanted to avoid any kind of coupling between >running an IGP and the NEMO basic support protocol. > >when a routing protocol is used between the mobile router >and the HA, the bi-directional tunnel between the MR and >the HA actually extends the IGP domain to include the MR. >thats all. NEMO basic support protocol only creates the >bi-directional tunnel (and few more things). we dont want >NEMO to do the verification for routing protocol updates. > >if there is enough trust between the MR and the HA and >they are configured to run an IGP, they do it. otherwise >the MR and the HA should not run an IGP when the MR is >not at home. we can make this more explicit if needed. > I'd appreciate that, especially since 8 does talk about some linkage. --Steve Bellovin, http://www.research.att.com/~smb From nemo-admin@ietf.org Sat May 8 22:45: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 WAA11129 for ; Sat, 8 May 2004 22:45:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMeFQ-0005jY-OZ; Sat, 08 May 2004 22:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMeDq-0005VL-IW for nemo@optimus.ietf.org; Sat, 08 May 2004 22:39:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10934 for ; Sat, 8 May 2004 22:39:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMeDn-0006Gn-7G for nemo@ietf.org; Sat, 08 May 2004 22:39:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMeCj-0005ti-00 for nemo@ietf.org; Sat, 08 May 2004 22:38:14 -0400 Received: from [192.103.16.30] (helo=iio.multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1BMeBj-0004Pf-00 for nemo@ietf.org; Sat, 08 May 2004 22:37:11 -0400 Received: from kniveton.com (deimos.tehama.multihop.net [64.36.73.242]) (authenticated bits=0) by iio.multihop.net (8.12.11/8.12.11) with ESMTP id i492YLNk059745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 May 2004 19:34:22 -0700 (PDT) (envelope-from tj@kniveton.com) Message-ID: <409D98A7.5020501@kniveton.com> Date: Sat, 08 May 2004 19:34:15 -0700 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benjamin Koh Tien-Ming CC: nemo@ietf.org Subject: Re: [nemo] Question on MR - CN References: <408F1019.9020908@psl.com.sg> <20040507150331.02f8f363.ernst@sfc.wide.ad.jp> In-Reply-To: <20040507150331.02f8f363.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >Hi, > >For security reasons, we decided to use a bidirectional tunnel, so >encapsulation between MR and HA in both directions. This was decided >before the actual set up of the NEMO WG. I don't know if there is a >particular thread to recommend you, but probably that would be on the >monet ML archives, not the nemo ML archives. > > I looked through my monet archives and didn't come up with much on this subject. Most of the discussion happened between authors of requirements/solution specs at the time. The first thread I find with a quick search is from a year ago: On May 27, 2003, Greg Daley wrote: > Routers in the visited fixed network will Ingress filter > to prevent address spoofing. > Reverse tunnels are required, so that MNNs have an > address on the NEMO which is topologically correct. > > Greg Daley. > > atq atiq wrote: > >> Dear all, >> As a new customer, i don't understand the need for tunnelling for the >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> HAofMR ---> CN >> >> to send packets from VMN to CN [assume that CN already sent some to >> VMN]. >> >> if there is no tunnelling from FAofMR --[tunnelling here]--> HAofMR, >> what is the prob. or otherwise what's the benefits? >> >> Pls. let me know. >> >> Thanks in advance. >> >> >> aa >> >> >> __________________________________ >> Do you Yahoo!? >> Yahoo! Calendar - Free online calendar with sync to Outlook(TM). >> http://calendar.yahoo.com > From exim@www1.ietf.org Sat May 8 22:48: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 WAA11338 for ; Sat, 8 May 2004 22:48:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMeLb-0006Rp-3c for nemo-archive@odin.ietf.org; Sat, 08 May 2004 22:47:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i492lN5l024785 for nemo-archive@odin.ietf.org; Sat, 8 May 2004 22:47:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMeKd-0006Hb-LF for nemo-web-archive@optimus.ietf.org; Sat, 08 May 2004 22:46:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11199 for ; Sat, 8 May 2004 22:46:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMeKa-00018c-8y for nemo-web-archive@ietf.org; Sat, 08 May 2004 22:46:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMeJc-0000lJ-00 for nemo-web-archive@ietf.org; Sat, 08 May 2004 22:45:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMeIp-0000Oi-00 for nemo-web-archive@ietf.org; Sat, 08 May 2004 22:44:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMeFQ-0005jY-OZ; Sat, 08 May 2004 22:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMeDq-0005VL-IW for nemo@optimus.ietf.org; Sat, 08 May 2004 22:39:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10934 for ; Sat, 8 May 2004 22:39:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMeDn-0006Gn-7G for nemo@ietf.org; Sat, 08 May 2004 22:39:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMeCj-0005ti-00 for nemo@ietf.org; Sat, 08 May 2004 22:38:14 -0400 Received: from [192.103.16.30] (helo=iio.multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1BMeBj-0004Pf-00 for nemo@ietf.org; Sat, 08 May 2004 22:37:11 -0400 Received: from kniveton.com (deimos.tehama.multihop.net [64.36.73.242]) (authenticated bits=0) by iio.multihop.net (8.12.11/8.12.11) with ESMTP id i492YLNk059745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 May 2004 19:34:22 -0700 (PDT) (envelope-from tj@kniveton.com) Message-ID: <409D98A7.5020501@kniveton.com> Date: Sat, 08 May 2004 19:34:15 -0700 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benjamin Koh Tien-Ming CC: nemo@ietf.org Subject: Re: [nemo] Question on MR - CN References: <408F1019.9020908@psl.com.sg> <20040507150331.02f8f363.ernst@sfc.wide.ad.jp> In-Reply-To: <20040507150331.02f8f363.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Thierry Ernst wrote: >Hi, > >For security reasons, we decided to use a bidirectional tunnel, so >encapsulation between MR and HA in both directions. This was decided >before the actual set up of the NEMO WG. I don't know if there is a >particular thread to recommend you, but probably that would be on the >monet ML archives, not the nemo ML archives. > > I looked through my monet archives and didn't come up with much on this subject. Most of the discussion happened between authors of requirements/solution specs at the time. The first thread I find with a quick search is from a year ago: On May 27, 2003, Greg Daley wrote: > Routers in the visited fixed network will Ingress filter > to prevent address spoofing. > Reverse tunnels are required, so that MNNs have an > address on the NEMO which is topologically correct. > > Greg Daley. > > atq atiq wrote: > >> Dear all, >> As a new customer, i don't understand the need for tunnelling for the >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> HAofMR ---> CN >> >> to send packets from VMN to CN [assume that CN already sent some to >> VMN]. >> >> if there is no tunnelling from FAofMR --[tunnelling here]--> HAofMR, >> what is the prob. or otherwise what's the benefits? >> >> Pls. let me know. >> >> Thanks in advance. >> >> >> aa >> >> >> __________________________________ >> Do you Yahoo!? >> Yahoo! Calendar - Free online calendar with sync to Outlook(TM). >> http://calendar.yahoo.com > From nemo-admin@ietf.org Sat May 8 23:31:50 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12571 for ; Sat, 8 May 2004 23:31:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMf0r-0002Ho-Cd; Sat, 08 May 2004 23:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMezE-0002A9-04 for nemo@optimus.ietf.org; Sat, 08 May 2004 23:28:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12494 for ; Sat, 8 May 2004 23:28:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMezC-0001OG-0V for nemo@ietf.org; Sat, 08 May 2004 23:28:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMeyH-00011X-00 for nemo@ietf.org; Sat, 08 May 2004 23:27:22 -0400 Received: from bb220-255-90-171.singnet.com.sg ([220.255.90.171] helo=fox.magix.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1BMexP-0000fE-00 for nemo@ietf.org; Sat, 08 May 2004 23:26:27 -0400 Received: by fox.magix.com.sg (Postfix, from userid 1000) id 0053A193BDD; Sun, 9 May 2004 11:26:38 +0800 (SGT) Subject: Re: [nemo] Question on MR - CN From: Chan-Wah NG To: IETF NEMO WG In-Reply-To: <409D98A7.5020501@kniveton.com> References: <408F1019.9020908@psl.com.sg> <20040507150331.02f8f363.ernst@sfc.wide.ad.jp> <409D98A7.5020501@kniveton.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1084073198.16081.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 09 May 2004 11:26:38 +0800 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is interesting, there is no concrete explanation on what the "security threats" are. I guess most of us just assumed that direct tunneling to CN is "somehow insecure", at least I do, without giving it serious thought. According to the "Generic IPv6 Tunneling" RFC 2473, a tunnel exit node should just discard the outer packet and process the inner packet as though it has been delivered through a network interface. Perhaps we should ask what is the "security threat" here? The ingress filtering problem shouldn't be a concern, since we would assume the outer packet bears the CoA of MR as the src. The only issue I can think of is, not related to security, is the CN is implemented not to accept tunnel from any nodes. For that, I consulted the IPv6 Node (or Host) requirements draft, but there was no mention on tunnel handling requirement. Any thoughts on this from others? /rgds /cwng On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > Thierry Ernst wrote: > > >Hi, > > > >For security reasons, we decided to use a bidirectional tunnel, so > >encapsulation between MR and HA in both directions. This was decided > >before the actual set up of the NEMO WG. I don't know if there is a > >particular thread to recommend you, but probably that would be on the > >monet ML archives, not the nemo ML archives. > > > > > I looked through my monet archives and didn't come up with much on this > subject. Most of the discussion happened between authors of > requirements/solution specs at the time. The first thread I find with a > quick search is from a year ago: > > On May 27, 2003, Greg Daley wrote: > > > Routers in the visited fixed network will Ingress filter > > to prevent address spoofing. > > Reverse tunnels are required, so that MNNs have an > > address on the NEMO which is topologically correct. > > > > Greg Daley. > > > > atq atiq wrote: > > > >> Dear all, > >> As a new customer, i don't understand the need for tunnelling for the > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> HAofMR ---> CN > >> > >> to send packets from VMN to CN [assume that CN already sent some to > >> VMN]. > >> > >> if there is no tunnelling from FAofMR --[tunnelling here]--> HAofMR, > >> what is the prob. or otherwise what's the benefits? > >> > >> Pls. let me know. > >> > >> Thanks in advance. > >> > >> > >> aa > >> > >> > >> __________________________________ > >> Do you Yahoo!? > >> Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > >> http://calendar.yahoo.com > > > > > From exim@www1.ietf.org Sat May 8 23:36:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12857 for ; Sat, 8 May 2004 23:36:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMf65-0002rg-A5 for nemo-archive@odin.ietf.org; Sat, 08 May 2004 23:35:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i493ZPAv011009 for nemo-archive@odin.ietf.org; Sat, 8 May 2004 23:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMf47-0002g8-Om for nemo-web-archive@optimus.ietf.org; Sat, 08 May 2004 23:33:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12687 for ; Sat, 8 May 2004 23:33:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMf45-0003FC-Px for nemo-web-archive@ietf.org; Sat, 08 May 2004 23:33:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMf38-0002rm-00 for nemo-web-archive@ietf.org; Sat, 08 May 2004 23:32:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMf29-0002Ub-00 for nemo-web-archive@ietf.org; Sat, 08 May 2004 23:31:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMf0r-0002Ho-Cd; Sat, 08 May 2004 23:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMezE-0002A9-04 for nemo@optimus.ietf.org; Sat, 08 May 2004 23:28:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12494 for ; Sat, 8 May 2004 23:28:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMezC-0001OG-0V for nemo@ietf.org; Sat, 08 May 2004 23:28:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMeyH-00011X-00 for nemo@ietf.org; Sat, 08 May 2004 23:27:22 -0400 Received: from bb220-255-90-171.singnet.com.sg ([220.255.90.171] helo=fox.magix.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1BMexP-0000fE-00 for nemo@ietf.org; Sat, 08 May 2004 23:26:27 -0400 Received: by fox.magix.com.sg (Postfix, from userid 1000) id 0053A193BDD; Sun, 9 May 2004 11:26:38 +0800 (SGT) Subject: Re: [nemo] Question on MR - CN From: Chan-Wah NG To: IETF NEMO WG In-Reply-To: <409D98A7.5020501@kniveton.com> References: <408F1019.9020908@psl.com.sg> <20040507150331.02f8f363.ernst@sfc.wide.ad.jp> <409D98A7.5020501@kniveton.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1084073198.16081.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 09 May 2004 11:26:38 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 This is interesting, there is no concrete explanation on what the "security threats" are. I guess most of us just assumed that direct tunneling to CN is "somehow insecure", at least I do, without giving it serious thought. According to the "Generic IPv6 Tunneling" RFC 2473, a tunnel exit node should just discard the outer packet and process the inner packet as though it has been delivered through a network interface. Perhaps we should ask what is the "security threat" here? The ingress filtering problem shouldn't be a concern, since we would assume the outer packet bears the CoA of MR as the src. The only issue I can think of is, not related to security, is the CN is implemented not to accept tunnel from any nodes. For that, I consulted the IPv6 Node (or Host) requirements draft, but there was no mention on tunnel handling requirement. Any thoughts on this from others? /rgds /cwng On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > Thierry Ernst wrote: > > >Hi, > > > >For security reasons, we decided to use a bidirectional tunnel, so > >encapsulation between MR and HA in both directions. This was decided > >before the actual set up of the NEMO WG. I don't know if there is a > >particular thread to recommend you, but probably that would be on the > >monet ML archives, not the nemo ML archives. > > > > > I looked through my monet archives and didn't come up with much on this > subject. Most of the discussion happened between authors of > requirements/solution specs at the time. The first thread I find with a > quick search is from a year ago: > > On May 27, 2003, Greg Daley wrote: > > > Routers in the visited fixed network will Ingress filter > > to prevent address spoofing. > > Reverse tunnels are required, so that MNNs have an > > address on the NEMO which is topologically correct. > > > > Greg Daley. > > > > atq atiq wrote: > > > >> Dear all, > >> As a new customer, i don't understand the need for tunnelling for the > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> HAofMR ---> CN > >> > >> to send packets from VMN to CN [assume that CN already sent some to > >> VMN]. > >> > >> if there is no tunnelling from FAofMR --[tunnelling here]--> HAofMR, > >> what is the prob. or otherwise what's the benefits? > >> > >> Pls. let me know. > >> > >> Thanks in advance. > >> > >> > >> aa > >> > >> > >> __________________________________ > >> Do you Yahoo!? > >> Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > >> http://calendar.yahoo.com > > > > > From nemo-admin@ietf.org Mon May 10 07:24:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25454 for ; Mon, 10 May 2004 07:24:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8lS-0005JJ-LZ; Mon, 10 May 2004 07:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8kB-000563-IN for nemo@optimus.ietf.org; Mon, 10 May 2004 07:14:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24958 for ; Mon, 10 May 2004 07:14:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN8kA-0004tc-UJ for nemo@ietf.org; Mon, 10 May 2004 07:14:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN8jJ-0004bR-00 for nemo@ietf.org; Mon, 10 May 2004 07:13:54 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BN8ij-0004HD-00 for nemo@ietf.org; Mon, 10 May 2004 07:13:17 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4256926299; Mon, 10 May 2004 13:12:46 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 25A6B26287; Mon, 10 May 2004 13:12:46 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Seongho Cho" , Subject: RE: [nemo] Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Date: Mon, 10 May 2004 13:08:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040427104127.B9862@popeye.snu.ac.kr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Seongho, I have some questions about this draft. 1. In section 5.1 Neighbor MRs Discovery is stated that neighbors discovery is based in RA messages. My question is how does the solution works when the multiple MRs are not all connected to the same link, but there are routers between them? This implies that MR1 cannot hear RA messages from MR2. For instance: | | MR MR | | ----------Router------- 2. In the same section it is stated that from the neighbor discovery process, MR1 can discover all the required data from MR2, such as HoA, CoA and MNP. My question is how does MR1 discovers the CoA of MR2? i mean, as i understand it, RA messages does not contain such information, since the egress interface belongs to another link. 3. About the usage of RR to authenticate a MR presented in section 5.2 First of all, i am not sure that i understand why the RR procedure is suitable to perform this particular authentication. I mean, the RR check verifies the collocation of a HoA and a CoA (or two addresses if you would). But in this case, i would say that you need to verify more than just that. I mean, using only the RR check, any device with both an ingress and egress interface can claim to be a MR of the NEMO and the RR check will succeed. For instance an attacker can simply join the nemo and if he has a wireless interface connecting to the internet, it can claim to be a MR. Wouldn't be necessary additional verifications, like an list of authorized MR?, and once that you have that list, what do you need to perform the RR check for? Additionally, using the RR check may have some issues, since for instance the BCE lifetime of binding validated using RR check are limited to 7 minutes. This implies that you have to perform the RR check every 7 minutes. But what happens if the MR is no longer available (which as far as i understand i one of your goals) 4. Finally, once that the HA is using an alternative MR, how do you manage to exchange signaling between them? I mean, BU messages and other signaling must be authenticated using IPSec, but the HA and the new MR don't have an IPSec SA between them, so i don't see how the will be able to exchange signaling, for instance when there is a movement and a new CoA has to be announced from the MR to the HA. Regards, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Seongho > Cho > Enviado el: martes, 27 de abril de 2004 3:41 > Para: nemo@ietf.org > Asunto: [nemo] Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt > > > Hi forks, > > To inform you that we have submitted a new I-D on neighbor MR > authentication > & registration mechanism for multihomed mobile networks. > We propose a dynamic MR registration solution without extra > signaling message, > and hope that this I-D will initiate some discussions on this topic. > > Thanks. > > Bests, > Seongho > > ----- Forwarded message from Internet-Drafts@ietf.org ----- > > To: i-d-announce@ietf.org > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-cho-nemo-mr-registration-00.txt > Date: Mon, 26 Apr 2004 15:26:20 -0400 > Errors-To: i-d-announce-admin@ietf.org > X-BeenThere: i-d-announce@ietf.org > X-Mailman-Version: 2.0.12 > Precedence: bulk > Reply-To: internet-drafts@ietf.org > List-Unsubscribe: , > > List-Id: > List-Post: > List-Help: > List-Subscribe: , > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Neighbor MR Authentication and > Registration Mechanism > in Multihomed Mobile Networks > Author(s) : S. Cho, et al. > Filename : draft-cho-nemo-mr-registration-00.txt > Pages : 12 > Date : 2004-4-26 > > In multihomed mobile networks, multiple Mobile Routers can be > deployed to provide fault recovery or load sharing. Also, each Mobile > Router (MR) can have a bi-directional tunnel with its own Home Agent > (HA). In this multihomed mobile network scenario, the neighbor root > MR can replace or share the operation of another MR. Therefore, MRs > should cooperate with each other to provide session continuity or > load sharing. We present an authentication and registration mechanism > without introducing extra signaling messages. Using the Return > Routability procedure of Mobile IPv6 and the Binding Update message > with the neighbor MR registration option, the MR can authenticate and > register the neighbor MR to its own HA. And the HA can use this > registered neighbor MR information to provide fault recovery or load > sharing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cho-nemo-mr-registration-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the > body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-cho-nemo-mr-registration-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-cho-nemo-mr-registration-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. > > > > ----- End forwarded message ----- > > From exim@www1.ietf.org Mon May 10 07:32:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26170 for ; Mon, 10 May 2004 07:32:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8z5-0007AV-AT for nemo-archive@odin.ietf.org; Mon, 10 May 2004 07:30:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ABUB9R027555 for nemo-archive@odin.ietf.org; Mon, 10 May 2004 07:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8x2-0006jK-De for nemo-web-archive@optimus.ietf.org; Mon, 10 May 2004 07:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25940 for ; Mon, 10 May 2004 07:28:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN8x1-00018Z-S6 for nemo-web-archive@ietf.org; Mon, 10 May 2004 07:28:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN8vM-0000kb-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 07:26:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN8tP-00001c-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 07:24:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8lS-0005JJ-LZ; Mon, 10 May 2004 07:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8kB-000563-IN for nemo@optimus.ietf.org; Mon, 10 May 2004 07:14:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24958 for ; Mon, 10 May 2004 07:14:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN8kA-0004tc-UJ for nemo@ietf.org; Mon, 10 May 2004 07:14:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN8jJ-0004bR-00 for nemo@ietf.org; Mon, 10 May 2004 07:13:54 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BN8ij-0004HD-00 for nemo@ietf.org; Mon, 10 May 2004 07:13:17 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4256926299; Mon, 10 May 2004 13:12:46 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 25A6B26287; Mon, 10 May 2004 13:12:46 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Seongho Cho" , Subject: RE: [nemo] Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Date: Mon, 10 May 2004 13:08:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040427104127.B9862@popeye.snu.ac.kr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Seongho, I have some questions about this draft. 1. In section 5.1 Neighbor MRs Discovery is stated that neighbors discovery is based in RA messages. My question is how does the solution works when the multiple MRs are not all connected to the same link, but there are routers between them? This implies that MR1 cannot hear RA messages from MR2. For instance: | | MR MR | | ----------Router------- 2. In the same section it is stated that from the neighbor discovery process, MR1 can discover all the required data from MR2, such as HoA, CoA and MNP. My question is how does MR1 discovers the CoA of MR2? i mean, as i understand it, RA messages does not contain such information, since the egress interface belongs to another link. 3. About the usage of RR to authenticate a MR presented in section 5.2 First of all, i am not sure that i understand why the RR procedure is suitable to perform this particular authentication. I mean, the RR check verifies the collocation of a HoA and a CoA (or two addresses if you would). But in this case, i would say that you need to verify more than just that. I mean, using only the RR check, any device with both an ingress and egress interface can claim to be a MR of the NEMO and the RR check will succeed. For instance an attacker can simply join the nemo and if he has a wireless interface connecting to the internet, it can claim to be a MR. Wouldn't be necessary additional verifications, like an list of authorized MR?, and once that you have that list, what do you need to perform the RR check for? Additionally, using the RR check may have some issues, since for instance the BCE lifetime of binding validated using RR check are limited to 7 minutes. This implies that you have to perform the RR check every 7 minutes. But what happens if the MR is no longer available (which as far as i understand i one of your goals) 4. Finally, once that the HA is using an alternative MR, how do you manage to exchange signaling between them? I mean, BU messages and other signaling must be authenticated using IPSec, but the HA and the new MR don't have an IPSec SA between them, so i don't see how the will be able to exchange signaling, for instance when there is a movement and a new CoA has to be announced from the MR to the HA. Regards, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Seongho > Cho > Enviado el: martes, 27 de abril de 2004 3:41 > Para: nemo@ietf.org > Asunto: [nemo] Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt > > > Hi forks, > > To inform you that we have submitted a new I-D on neighbor MR > authentication > & registration mechanism for multihomed mobile networks. > We propose a dynamic MR registration solution without extra > signaling message, > and hope that this I-D will initiate some discussions on this topic. > > Thanks. > > Bests, > Seongho > > ----- Forwarded message from Internet-Drafts@ietf.org ----- > > To: i-d-announce@ietf.org > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-cho-nemo-mr-registration-00.txt > Date: Mon, 26 Apr 2004 15:26:20 -0400 > Errors-To: i-d-announce-admin@ietf.org > X-BeenThere: i-d-announce@ietf.org > X-Mailman-Version: 2.0.12 > Precedence: bulk > Reply-To: internet-drafts@ietf.org > List-Unsubscribe: , > > List-Id: > List-Post: > List-Help: > List-Subscribe: , > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Neighbor MR Authentication and > Registration Mechanism > in Multihomed Mobile Networks > Author(s) : S. Cho, et al. > Filename : draft-cho-nemo-mr-registration-00.txt > Pages : 12 > Date : 2004-4-26 > > In multihomed mobile networks, multiple Mobile Routers can be > deployed to provide fault recovery or load sharing. Also, each Mobile > Router (MR) can have a bi-directional tunnel with its own Home Agent > (HA). In this multihomed mobile network scenario, the neighbor root > MR can replace or share the operation of another MR. Therefore, MRs > should cooperate with each other to provide session continuity or > load sharing. We present an authentication and registration mechanism > without introducing extra signaling messages. Using the Return > Routability procedure of Mobile IPv6 and the Binding Update message > with the neighbor MR registration option, the MR can authenticate and > register the neighbor MR to its own HA. And the HA can use this > registered neighbor MR information to provide fault recovery or load > sharing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cho-nemo-mr-registration-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the > body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-cho-nemo-mr-registration-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-cho-nemo-mr-registration-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. > > > > ----- End forwarded message ----- > > From nemo-admin@ietf.org Mon May 10 07:52:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27287 for ; Mon, 10 May 2004 07:52:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9FN-00018m-29; Mon, 10 May 2004 07:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9E7-00011v-28 for nemo@optimus.ietf.org; Mon, 10 May 2004 07:45:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26953 for ; Mon, 10 May 2004 07:45:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9E6-00072y-Ch for nemo@ietf.org; Mon, 10 May 2004 07:45:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9DI-0006kh-00 for nemo@ietf.org; Mon, 10 May 2004 07:44:53 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BN9CM-00069x-00 for nemo@ietf.org; Mon, 10 May 2004 07:43:54 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6A5F4261FE; Mon, 10 May 2004 13:43:23 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 3B406261FA; Mon, 10 May 2004 13:43:23 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Chan-Wah NG" , "IETF NEMO WG" Subject: RE: [nemo] Question on MR - CN Date: Mon, 10 May 2004 13:39:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1084073198.16081.17.camel@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have also been wondering about this issue for a while now. RFC 2003, states that a host should accept encapsulated packets if both inner and outer addresses belong to the host. However, MIPv6, states that a HoA option cannot be processed if a valid (authenticated) BCE exists in the host. Moreover, the transition mechanisms IPv4-IPv6 state that the only encapsutaled packets that are accepted are those thay belong to exsiting tunnels, toher shoudl be discarded. Finaly, 6to4 accepts all encapsulated packet, and a threats document is being discussed in v6ops. I guess that the main risk that this introduces is that source address spoofing is much more simpler thant today. I also guess that current implementations don't really accept encapsulated packets by defualt. So, in brief, older specs state that encpasulated packets may be accepted but newer ones are moving from that and only packets belonging to existent tunnels are accepted. Regards, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de > Chan-Wah NG > Enviado el: domingo, 09 de mayo de 2004 5:27 > Para: IETF NEMO WG > Asunto: Re: [nemo] Question on MR - CN > > > This is interesting, there is no concrete explanation on what the > "security threats" are. I guess most of us just assumed that direct > tunneling to CN is "somehow insecure", at least I do, without giving it > serious thought. > > According to the "Generic IPv6 Tunneling" RFC 2473, a tunnel exit node > should just discard the outer packet and process the inner packet as > though it has been delivered through a network interface. > > Perhaps we should ask what is the "security threat" here? The ingress > filtering problem shouldn't be a concern, since we would assume the > outer packet bears the CoA of MR as the src. > > The only issue I can think of is, not related to security, is the CN is > implemented not to accept tunnel from any nodes. For that, I consulted > the IPv6 Node (or Host) requirements draft, but there was no mention on > tunnel handling requirement. > > Any thoughts on this from others? > > /rgds > /cwng > > On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > > Thierry Ernst wrote: > > > > >Hi, > > > > > >For security reasons, we decided to use a bidirectional tunnel, so > > >encapsulation between MR and HA in both directions. This was decided > > >before the actual set up of the NEMO WG. I don't know if there is a > > >particular thread to recommend you, but probably that would be on the > > >monet ML archives, not the nemo ML archives. > > > > > > > > I looked through my monet archives and didn't come up with much on this > > subject. Most of the discussion happened between authors of > > requirements/solution specs at the time. The first thread I find with a > > quick search is from a year ago: > > > > On May 27, 2003, Greg Daley wrote: > > > > > Routers in the visited fixed network will Ingress filter > > > to prevent address spoofing. > > > Reverse tunnels are required, so that MNNs have an > > > address on the NEMO which is topologically correct. > > > > > > Greg Daley. > > > > > > atq atiq wrote: > > > > > >> Dear all, > > >> As a new customer, i don't understand the need for tunnelling for the > > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> > HAofMR ---> CN > > >> > > >> to send packets from VMN to CN [assume that CN already sent some to > > >> VMN]. > > >> > > >> if there is no tunnelling from FAofMR --[tunnelling here]--> HAofMR, > > >> what is the prob. or otherwise what's the benefits? > > >> > > >> Pls. let me know. > > >> > > >> Thanks in advance. > > >> > > >> > > >> aa > > >> > > >> > > >> __________________________________ > > >> Do you Yahoo!? > > >> Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > > >> http://calendar.yahoo.com > > > > > > > > > > From exim@www1.ietf.org Mon May 10 08:00:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27622 for ; Mon, 10 May 2004 08:00:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9PQ-0002Bd-SJ for nemo-archive@odin.ietf.org; Mon, 10 May 2004 07:57:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ABvOPu008400 for nemo-archive@odin.ietf.org; Mon, 10 May 2004 07:57:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9Ly-0001od-Mc for nemo-web-archive@optimus.ietf.org; Mon, 10 May 2004 07:53:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27340 for ; Mon, 10 May 2004 07:53:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9Lx-0001hf-Q1 for nemo-web-archive@ietf.org; Mon, 10 May 2004 07:53:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9L3-0001Pb-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 07:52:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN9KT-00016l-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 07:52:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9FN-00018m-29; Mon, 10 May 2004 07:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9E7-00011v-28 for nemo@optimus.ietf.org; Mon, 10 May 2004 07:45:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26953 for ; Mon, 10 May 2004 07:45:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9E6-00072y-Ch for nemo@ietf.org; Mon, 10 May 2004 07:45:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9DI-0006kh-00 for nemo@ietf.org; Mon, 10 May 2004 07:44:53 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BN9CM-00069x-00 for nemo@ietf.org; Mon, 10 May 2004 07:43:54 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6A5F4261FE; Mon, 10 May 2004 13:43:23 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 3B406261FA; Mon, 10 May 2004 13:43:23 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Chan-Wah NG" , "IETF NEMO WG" Subject: RE: [nemo] Question on MR - CN Date: Mon, 10 May 2004 13:39:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1084073198.16081.17.camel@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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, I have also been wondering about this issue for a while now. RFC 2003, states that a host should accept encapsulated packets if both inner and outer addresses belong to the host. However, MIPv6, states that a HoA option cannot be processed if a valid (authenticated) BCE exists in the host. Moreover, the transition mechanisms IPv4-IPv6 state that the only encapsutaled packets that are accepted are those thay belong to exsiting tunnels, toher shoudl be discarded. Finaly, 6to4 accepts all encapsulated packet, and a threats document is being discussed in v6ops. I guess that the main risk that this introduces is that source address spoofing is much more simpler thant today. I also guess that current implementations don't really accept encapsulated packets by defualt. So, in brief, older specs state that encpasulated packets may be accepted but newer ones are moving from that and only packets belonging to existent tunnels are accepted. Regards, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de > Chan-Wah NG > Enviado el: domingo, 09 de mayo de 2004 5:27 > Para: IETF NEMO WG > Asunto: Re: [nemo] Question on MR - CN > > > This is interesting, there is no concrete explanation on what the > "security threats" are. I guess most of us just assumed that direct > tunneling to CN is "somehow insecure", at least I do, without giving it > serious thought. > > According to the "Generic IPv6 Tunneling" RFC 2473, a tunnel exit node > should just discard the outer packet and process the inner packet as > though it has been delivered through a network interface. > > Perhaps we should ask what is the "security threat" here? The ingress > filtering problem shouldn't be a concern, since we would assume the > outer packet bears the CoA of MR as the src. > > The only issue I can think of is, not related to security, is the CN is > implemented not to accept tunnel from any nodes. For that, I consulted > the IPv6 Node (or Host) requirements draft, but there was no mention on > tunnel handling requirement. > > Any thoughts on this from others? > > /rgds > /cwng > > On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > > Thierry Ernst wrote: > > > > >Hi, > > > > > >For security reasons, we decided to use a bidirectional tunnel, so > > >encapsulation between MR and HA in both directions. This was decided > > >before the actual set up of the NEMO WG. I don't know if there is a > > >particular thread to recommend you, but probably that would be on the > > >monet ML archives, not the nemo ML archives. > > > > > > > > I looked through my monet archives and didn't come up with much on this > > subject. Most of the discussion happened between authors of > > requirements/solution specs at the time. The first thread I find with a > > quick search is from a year ago: > > > > On May 27, 2003, Greg Daley wrote: > > > > > Routers in the visited fixed network will Ingress filter > > > to prevent address spoofing. > > > Reverse tunnels are required, so that MNNs have an > > > address on the NEMO which is topologically correct. > > > > > > Greg Daley. > > > > > > atq atiq wrote: > > > > > >> Dear all, > > >> As a new customer, i don't understand the need for tunnelling for the > > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> > HAofMR ---> CN > > >> > > >> to send packets from VMN to CN [assume that CN already sent some to > > >> VMN]. > > >> > > >> if there is no tunnelling from FAofMR --[tunnelling here]--> HAofMR, > > >> what is the prob. or otherwise what's the benefits? > > >> > > >> Pls. let me know. > > >> > > >> Thanks in advance. > > >> > > >> > > >> aa > > >> > > >> > > >> __________________________________ > > >> Do you Yahoo!? > > >> Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > > >> http://calendar.yahoo.com > > > > > > > > > > From nemo-admin@ietf.org Mon May 10 08:49:37 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00590 for ; Mon, 10 May 2004 08:49:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNA9V-0001ri-GW; Mon, 10 May 2004 08:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9sn-0005mp-RY for nemo@optimus.ietf.org; Mon, 10 May 2004 08:27:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29001 for ; Mon, 10 May 2004 08:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9sm-0004aL-Lm for nemo@ietf.org; Mon, 10 May 2004 08:27:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9rp-0004IF-00 for nemo@ietf.org; Mon, 10 May 2004 08:26:46 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BN9rM-0003zs-00 for nemo@ietf.org; Mon, 10 May 2004 08:26:16 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 May 2004 08:25:40 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: [nemo] Question on MR - CN Date: Mon, 10 May 2004 08:25:39 -0400 Message-ID: Thread-Topic: [nemo] Question on MR - CN Thread-Index: AcQ2hTxmKBYy2tNER66qLbibjxHtBQAAjMTA From: "Soliman Hesham" To: , "Chan-Wah NG" , "IETF NEMO WG" X-OriginalArrivalTime: 10 May 2004 12:25:40.0014 (UTC) FILETIME=[E7C5DCE0:01C43689] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi,=20 I found it difficult to understand the original question. But tunnelling to the HA was included in the charter as a working assumption. At the time this was the best wording we could come up with to satisfy IESG, IAB...etc without explicitly naming the solution.=20 Tunnelling to the CN has the same security problems as the HAO. RO in MIPv6 is essentially the same as tunnelling. The reason tunnelling to any random CN is not being suggested is that no implementation today accepts an unauthorised tunnel.=20 Of course the reason is reflection attacks.=20 So unless the tunnel is secure (which is effectively what=20 return routability does in MIPv6, or IPsec in case of=20 the HA) it won't be accepted.=20 FWIW, MIPv6 could have used IP in IP tunnelling instead of the HAO and routing header, but the WG decided against this. Google draft-nordmark-hindsight ... for details. Hesham > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of > marcelo bagnulo > Sent: Monday, May 10, 2004 7:40 AM > To: Chan-Wah NG; IETF NEMO WG > Subject: RE: [nemo] Question on MR - CN >=20 >=20 > Hi, >=20 > I have also been wondering about this issue for a while now. >=20 > RFC 2003, states that a host should accept encapsulated=20 > packets if both > inner and outer addresses belong to the host. >=20 > However, MIPv6, states that a HoA option cannot be processed=20 > if a valid > (authenticated) BCE exists in the host. >=20 > Moreover, the transition mechanisms IPv4-IPv6 state that the only > encapsutaled packets that are accepted are those thay belong=20 > to exsiting > tunnels, toher shoudl be discarded. >=20 > Finaly, 6to4 accepts all encapsulated packet, and a threats=20 > document is > being discussed in v6ops. >=20 > I guess that the main risk that this introduces is that=20 > source address > spoofing is much more simpler thant today. I also guess that current > implementations don't really accept encapsulated packets by defualt. >=20 > So, in brief, older specs state that encpasulated packets=20 > may be accepted > but newer ones are moving from that and only packets=20 > belonging to existent > tunnels are accepted. >=20 > Regards, marcelo >=20 > > -----Mensaje original----- > > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de > > Chan-Wah NG > > Enviado el: domingo, 09 de mayo de 2004 5:27 > > Para: IETF NEMO WG > > Asunto: Re: [nemo] Question on MR - CN > > > > > > This is interesting, there is no concrete explanation on what the > > "security threats" are. I guess most of us just assumed=20 > that direct > > tunneling to CN is "somehow insecure", at least I do,=20 > without giving it > > serious thought. > > > > According to the "Generic IPv6 Tunneling" RFC 2473, a=20 > tunnel exit node > > should just discard the outer packet and process the inner=20 > packet as > > though it has been delivered through a network interface. > > > > Perhaps we should ask what is the "security threat" here? =20 > The ingress > > filtering problem shouldn't be a concern, since we would assume the > > outer packet bears the CoA of MR as the src. > > > > The only issue I can think of is, not related to security,=20 > is the CN is > > implemented not to accept tunnel from any nodes. For=20 > that, I consulted > > the IPv6 Node (or Host) requirements draft, but there was=20 > no mention on > > tunnel handling requirement. > > > > Any thoughts on this from others? > > > > /rgds > > /cwng > > > > On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > > > Thierry Ernst wrote: > > > > > > >Hi, > > > > > > > >For security reasons, we decided to use a bidirectional=20 > tunnel, so > > > >encapsulation between MR and HA in both directions.=20 > This was decided > > > >before the actual set up of the NEMO WG. I don't know=20 > if there is a > > > >particular thread to recommend you, but probably that=20 > would be on the > > > >monet ML archives, not the nemo ML archives. > > > > > > > > > > > I looked through my monet archives and didn't come up=20 > with much on this > > > subject. Most of the discussion happened between authors of > > > requirements/solution specs at the time. The first=20 > thread I find with a > > > quick search is from a year ago: > > > > > > On May 27, 2003, Greg Daley wrote: > > > > > > > Routers in the visited fixed network will Ingress filter > > > > to prevent address spoofing. > > > > Reverse tunnels are required, so that MNNs have an > > > > address on the NEMO which is topologically correct. > > > > > > > > Greg Daley. > > > > > > > > atq atiq wrote: > > > > > > > >> Dear all, > > > >> As a new customer, i don't understand the need for=20 > tunnelling for the > > > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> > > HAofMR ---> CN > > > >> > > > >> to send packets from VMN to CN [assume that CN=20 > already sent some to > > > >> VMN]. > > > >> > > > >> if there is no tunnelling from FAofMR --[tunnelling=20 > here]--> HAofMR, > > > >> what is the prob. or otherwise what's the benefits? > > > >> > > > >> Pls. let me know. > > > >> > > > >> Thanks in advance. > > > >> > > > >> > > > >> aa > > > >> > > > >> > > > >> __________________________________ > > > >> Do you Yahoo!? > > > >> Yahoo! Calendar - Free online calendar with sync to=20 > Outlook(TM). > > > >> http://calendar.yahoo.com > > > > > > > > > > > > > > > >=20 >=20 >=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 This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From exim@www1.ietf.org Mon May 10 09:10:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01765 for ; Mon, 10 May 2004 09:10:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNANa-0004jB-FN for nemo-archive@odin.ietf.org; Mon, 10 May 2004 08:59:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ACxYdA018169 for nemo-archive@odin.ietf.org; Mon, 10 May 2004 08:59:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAFK-0003KA-4k for nemo-web-archive@optimus.ietf.org; Mon, 10 May 2004 08:51:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00714 for ; Mon, 10 May 2004 08:50:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNAFI-0004m0-On for nemo-web-archive@ietf.org; Mon, 10 May 2004 08:51:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNAEP-0004Pu-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 08:50:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNADV-00044d-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 08:49:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNA9V-0001ri-GW; Mon, 10 May 2004 08:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9sn-0005mp-RY for nemo@optimus.ietf.org; Mon, 10 May 2004 08:27:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29001 for ; Mon, 10 May 2004 08:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9sm-0004aL-Lm for nemo@ietf.org; Mon, 10 May 2004 08:27:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9rp-0004IF-00 for nemo@ietf.org; Mon, 10 May 2004 08:26:46 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BN9rM-0003zs-00 for nemo@ietf.org; Mon, 10 May 2004 08:26:16 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 May 2004 08:25:40 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: [nemo] Question on MR - CN Date: Mon, 10 May 2004 08:25:39 -0400 Message-ID: Thread-Topic: [nemo] Question on MR - CN Thread-Index: AcQ2hTxmKBYy2tNER66qLbibjxHtBQAAjMTA From: "Soliman Hesham" To: , "Chan-Wah NG" , "IETF NEMO WG" X-OriginalArrivalTime: 10 May 2004 12:25:40.0014 (UTC) FILETIME=[E7C5DCE0:01C43689] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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,=20 I found it difficult to understand the original question. But tunnelling to the HA was included in the charter as a working assumption. At the time this was the best wording we could come up with to satisfy IESG, IAB...etc without explicitly naming the solution.=20 Tunnelling to the CN has the same security problems as the HAO. RO in MIPv6 is essentially the same as tunnelling. The reason tunnelling to any random CN is not being suggested is that no implementation today accepts an unauthorised tunnel.=20 Of course the reason is reflection attacks.=20 So unless the tunnel is secure (which is effectively what=20 return routability does in MIPv6, or IPsec in case of=20 the HA) it won't be accepted.=20 FWIW, MIPv6 could have used IP in IP tunnelling instead of the HAO and routing header, but the WG decided against this. Google draft-nordmark-hindsight ... for details. Hesham > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of > marcelo bagnulo > Sent: Monday, May 10, 2004 7:40 AM > To: Chan-Wah NG; IETF NEMO WG > Subject: RE: [nemo] Question on MR - CN >=20 >=20 > Hi, >=20 > I have also been wondering about this issue for a while now. >=20 > RFC 2003, states that a host should accept encapsulated=20 > packets if both > inner and outer addresses belong to the host. >=20 > However, MIPv6, states that a HoA option cannot be processed=20 > if a valid > (authenticated) BCE exists in the host. >=20 > Moreover, the transition mechanisms IPv4-IPv6 state that the only > encapsutaled packets that are accepted are those thay belong=20 > to exsiting > tunnels, toher shoudl be discarded. >=20 > Finaly, 6to4 accepts all encapsulated packet, and a threats=20 > document is > being discussed in v6ops. >=20 > I guess that the main risk that this introduces is that=20 > source address > spoofing is much more simpler thant today. I also guess that current > implementations don't really accept encapsulated packets by defualt. >=20 > So, in brief, older specs state that encpasulated packets=20 > may be accepted > but newer ones are moving from that and only packets=20 > belonging to existent > tunnels are accepted. >=20 > Regards, marcelo >=20 > > -----Mensaje original----- > > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de > > Chan-Wah NG > > Enviado el: domingo, 09 de mayo de 2004 5:27 > > Para: IETF NEMO WG > > Asunto: Re: [nemo] Question on MR - CN > > > > > > This is interesting, there is no concrete explanation on what the > > "security threats" are. I guess most of us just assumed=20 > that direct > > tunneling to CN is "somehow insecure", at least I do,=20 > without giving it > > serious thought. > > > > According to the "Generic IPv6 Tunneling" RFC 2473, a=20 > tunnel exit node > > should just discard the outer packet and process the inner=20 > packet as > > though it has been delivered through a network interface. > > > > Perhaps we should ask what is the "security threat" here? =20 > The ingress > > filtering problem shouldn't be a concern, since we would assume the > > outer packet bears the CoA of MR as the src. > > > > The only issue I can think of is, not related to security,=20 > is the CN is > > implemented not to accept tunnel from any nodes. For=20 > that, I consulted > > the IPv6 Node (or Host) requirements draft, but there was=20 > no mention on > > tunnel handling requirement. > > > > Any thoughts on this from others? > > > > /rgds > > /cwng > > > > On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > > > Thierry Ernst wrote: > > > > > > >Hi, > > > > > > > >For security reasons, we decided to use a bidirectional=20 > tunnel, so > > > >encapsulation between MR and HA in both directions.=20 > This was decided > > > >before the actual set up of the NEMO WG. I don't know=20 > if there is a > > > >particular thread to recommend you, but probably that=20 > would be on the > > > >monet ML archives, not the nemo ML archives. > > > > > > > > > > > I looked through my monet archives and didn't come up=20 > with much on this > > > subject. Most of the discussion happened between authors of > > > requirements/solution specs at the time. The first=20 > thread I find with a > > > quick search is from a year ago: > > > > > > On May 27, 2003, Greg Daley wrote: > > > > > > > Routers in the visited fixed network will Ingress filter > > > > to prevent address spoofing. > > > > Reverse tunnels are required, so that MNNs have an > > > > address on the NEMO which is topologically correct. > > > > > > > > Greg Daley. > > > > > > > > atq atiq wrote: > > > > > > > >> Dear all, > > > >> As a new customer, i don't understand the need for=20 > tunnelling for the > > > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> > > HAofMR ---> CN > > > >> > > > >> to send packets from VMN to CN [assume that CN=20 > already sent some to > > > >> VMN]. > > > >> > > > >> if there is no tunnelling from FAofMR --[tunnelling=20 > here]--> HAofMR, > > > >> what is the prob. or otherwise what's the benefits? > > > >> > > > >> Pls. let me know. > > > >> > > > >> Thanks in advance. > > > >> > > > >> > > > >> aa > > > >> > > > >> > > > >> __________________________________ > > > >> Do you Yahoo!? > > > >> Yahoo! Calendar - Free online calendar with sync to=20 > Outlook(TM). > > > >> http://calendar.yahoo.com > > > > > > > > > > > > > > > >=20 >=20 >=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 This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From nemo-admin@ietf.org Mon May 10 10:00:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04532 for ; Mon, 10 May 2004 10:00:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBFI-00072m-CY; Mon, 10 May 2004 09:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNB8S-0005wY-2Z for nemo@optimus.ietf.org; Mon, 10 May 2004 09:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03759 for ; Mon, 10 May 2004 09:47:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNB8Q-0000Gj-6j for nemo@ietf.org; Mon, 10 May 2004 09:47:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNB7N-0007gE-00 for nemo@ietf.org; Mon, 10 May 2004 09:46:53 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BNB6L-0006xt-00 for nemo@ietf.org; Mon, 10 May 2004 09:45:49 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 1343C26044; Mon, 10 May 2004 15:45:19 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 418D726067; Mon, 10 May 2004 15:45:16 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , , "Chan-Wah NG" , "IETF NEMO WG" Subject: RE: [nemo] Question on MR - CN Date: Mon, 10 May 2004 15:41:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hesham, In my case, the question was generated by RFC 2003, since it states that "Host implementations that are capable of receiving encapsulated IP datagrams SHOULD admit only those datagrams fitting into one or more of the following categories: [...] - The encapsulated (inner) datagram is addressed to a network interface belonging to the decapsulator" This behavior is not coherent with the processing of MIPv6 HoA destination option and what you are describing i guess. IMHO, the proper approach is to discard the encapsulated packets that don't belong to an existent tunnel or that have been validated somehow, as you mention, but RFC 2003 seems to state otherwise. Summarizing, I agree that CN shouldn't accept encapsulated packets that don't belong to an existing tunnel, but that it is not what it is stated in RFC 2003 (and AFAIK, most implementations don't accept them, as you mention) The other question raised was why the CN shouldn't accept those packets, and the reason for this is that it would even easier to spoof source addresses. Regards, marcelo > -----Mensaje original----- > De: Soliman Hesham [mailto:H.Soliman@flarion.com] > Enviado el: lunes, 10 de mayo de 2004 14:26 > Para: mbagnulo@ing.uc3m.es; Chan-Wah NG; IETF NEMO WG > Asunto: RE: [nemo] Question on MR - CN > > > Hi, > > I found it difficult to understand the original question. > But tunnelling to the HA was included in the charter > as a working assumption. At the time this was the best > wording we could come up with to satisfy IESG, IAB...etc > without explicitly naming the solution. > > Tunnelling to the CN has the same security problems > as the HAO. RO in MIPv6 is essentially the same as tunnelling. > > The reason tunnelling to any random CN is not being suggested > is that no implementation today accepts an unauthorised tunnel. > Of course the reason is reflection attacks. > > So unless the tunnel is secure (which is effectively what > return routability does in MIPv6, or IPsec in case of > the HA) it won't be accepted. > > FWIW, MIPv6 could have used IP in IP tunnelling instead > of the HAO and routing header, but the WG decided against > this. Google draft-nordmark-hindsight ... for details. > > Hesham > > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of > > marcelo bagnulo > > Sent: Monday, May 10, 2004 7:40 AM > > To: Chan-Wah NG; IETF NEMO WG > > Subject: RE: [nemo] Question on MR - CN > > > > > > Hi, > > > > I have also been wondering about this issue for a while now. > > > > RFC 2003, states that a host should accept encapsulated > > packets if both > > inner and outer addresses belong to the host. > > > > However, MIPv6, states that a HoA option cannot be processed > > if a valid > > (authenticated) BCE exists in the host. > > > > Moreover, the transition mechanisms IPv4-IPv6 state that the only > > encapsutaled packets that are accepted are those thay belong > > to exsiting > > tunnels, toher shoudl be discarded. > > > > Finaly, 6to4 accepts all encapsulated packet, and a threats > > document is > > being discussed in v6ops. > > > > I guess that the main risk that this introduces is that > > source address > > spoofing is much more simpler thant today. I also guess that current > > implementations don't really accept encapsulated packets by defualt. > > > > So, in brief, older specs state that encpasulated packets > > may be accepted > > but newer ones are moving from that and only packets > > belonging to existent > > tunnels are accepted. > > > > Regards, marcelo > > > > > -----Mensaje original----- > > > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de > > > Chan-Wah NG > > > Enviado el: domingo, 09 de mayo de 2004 5:27 > > > Para: IETF NEMO WG > > > Asunto: Re: [nemo] Question on MR - CN > > > > > > > > > This is interesting, there is no concrete explanation on what the > > > "security threats" are. I guess most of us just assumed > > that direct > > > tunneling to CN is "somehow insecure", at least I do, > > without giving it > > > serious thought. > > > > > > According to the "Generic IPv6 Tunneling" RFC 2473, a > > tunnel exit node > > > should just discard the outer packet and process the inner > > packet as > > > though it has been delivered through a network interface. > > > > > > Perhaps we should ask what is the "security threat" here? > > The ingress > > > filtering problem shouldn't be a concern, since we would assume the > > > outer packet bears the CoA of MR as the src. > > > > > > The only issue I can think of is, not related to security, > > is the CN is > > > implemented not to accept tunnel from any nodes. For > > that, I consulted > > > the IPv6 Node (or Host) requirements draft, but there was > > no mention on > > > tunnel handling requirement. > > > > > > Any thoughts on this from others? > > > > > > /rgds > > > /cwng > > > > > > On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > > > > Thierry Ernst wrote: > > > > > > > > >Hi, > > > > > > > > > >For security reasons, we decided to use a bidirectional > > tunnel, so > > > > >encapsulation between MR and HA in both directions. > > This was decided > > > > >before the actual set up of the NEMO WG. I don't know > > if there is a > > > > >particular thread to recommend you, but probably that > > would be on the > > > > >monet ML archives, not the nemo ML archives. > > > > > > > > > > > > > > I looked through my monet archives and didn't come up > > with much on this > > > > subject. Most of the discussion happened between authors of > > > > requirements/solution specs at the time. The first > > thread I find with a > > > > quick search is from a year ago: > > > > > > > > On May 27, 2003, Greg Daley wrote: > > > > > > > > > Routers in the visited fixed network will Ingress filter > > > > > to prevent address spoofing. > > > > > Reverse tunnels are required, so that MNNs have an > > > > > address on the NEMO which is topologically correct. > > > > > > > > > > Greg Daley. > > > > > > > > > > atq atiq wrote: > > > > > > > > > >> Dear all, > > > > >> As a new customer, i don't understand the need for > > tunnelling for the > > > > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> > > > HAofMR ---> CN > > > > >> > > > > >> to send packets from VMN to CN [assume that CN > > already sent some to > > > > >> VMN]. > > > > >> > > > > >> if there is no tunnelling from FAofMR --[tunnelling > > here]--> HAofMR, > > > > >> what is the prob. or otherwise what's the benefits? > > > > >> > > > > >> Pls. let me know. > > > > >> > > > > >> Thanks in advance. > > > > >> > > > > >> > > > > >> aa > > > > >> > > > > >> > > > > >> __________________________________ > > > > >> Do you Yahoo!? > > > > >> Yahoo! Calendar - Free online calendar with sync to > > Outlook(TM). > > > > >> http://calendar.yahoo.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > ======================================================== > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review or distribution by others is > strictly prohibited. If you are not the intended recipient please contact > the sender and delete all copies. > ======================================================== > From exim@www1.ietf.org Mon May 10 10:10:37 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06012 for ; Mon, 10 May 2004 10:10:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBRS-0003wU-5R for nemo-archive@odin.ietf.org; Mon, 10 May 2004 10:07:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AE7cCP015152 for nemo-archive@odin.ietf.org; Mon, 10 May 2004 10:07:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBMh-0001hC-2Y for nemo-web-archive@optimus.ietf.org; Mon, 10 May 2004 10:02:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04610 for ; Mon, 10 May 2004 10:02:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNBMf-00050s-1M for nemo-web-archive@ietf.org; Mon, 10 May 2004 10:02:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNBL2-0004Z7-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 10:01:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNBKS-0004E2-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 10:00:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBFI-00072m-CY; Mon, 10 May 2004 09:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNB8S-0005wY-2Z for nemo@optimus.ietf.org; Mon, 10 May 2004 09:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03759 for ; Mon, 10 May 2004 09:47:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNB8Q-0000Gj-6j for nemo@ietf.org; Mon, 10 May 2004 09:47:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNB7N-0007gE-00 for nemo@ietf.org; Mon, 10 May 2004 09:46:53 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BNB6L-0006xt-00 for nemo@ietf.org; Mon, 10 May 2004 09:45:49 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 1343C26044; Mon, 10 May 2004 15:45:19 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 418D726067; Mon, 10 May 2004 15:45:16 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , , "Chan-Wah NG" , "IETF NEMO WG" Subject: RE: [nemo] Question on MR - CN Date: Mon, 10 May 2004 15:41:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Hesham, In my case, the question was generated by RFC 2003, since it states that "Host implementations that are capable of receiving encapsulated IP datagrams SHOULD admit only those datagrams fitting into one or more of the following categories: [...] - The encapsulated (inner) datagram is addressed to a network interface belonging to the decapsulator" This behavior is not coherent with the processing of MIPv6 HoA destination option and what you are describing i guess. IMHO, the proper approach is to discard the encapsulated packets that don't belong to an existent tunnel or that have been validated somehow, as you mention, but RFC 2003 seems to state otherwise. Summarizing, I agree that CN shouldn't accept encapsulated packets that don't belong to an existing tunnel, but that it is not what it is stated in RFC 2003 (and AFAIK, most implementations don't accept them, as you mention) The other question raised was why the CN shouldn't accept those packets, and the reason for this is that it would even easier to spoof source addresses. Regards, marcelo > -----Mensaje original----- > De: Soliman Hesham [mailto:H.Soliman@flarion.com] > Enviado el: lunes, 10 de mayo de 2004 14:26 > Para: mbagnulo@ing.uc3m.es; Chan-Wah NG; IETF NEMO WG > Asunto: RE: [nemo] Question on MR - CN > > > Hi, > > I found it difficult to understand the original question. > But tunnelling to the HA was included in the charter > as a working assumption. At the time this was the best > wording we could come up with to satisfy IESG, IAB...etc > without explicitly naming the solution. > > Tunnelling to the CN has the same security problems > as the HAO. RO in MIPv6 is essentially the same as tunnelling. > > The reason tunnelling to any random CN is not being suggested > is that no implementation today accepts an unauthorised tunnel. > Of course the reason is reflection attacks. > > So unless the tunnel is secure (which is effectively what > return routability does in MIPv6, or IPsec in case of > the HA) it won't be accepted. > > FWIW, MIPv6 could have used IP in IP tunnelling instead > of the HAO and routing header, but the WG decided against > this. Google draft-nordmark-hindsight ... for details. > > Hesham > > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of > > marcelo bagnulo > > Sent: Monday, May 10, 2004 7:40 AM > > To: Chan-Wah NG; IETF NEMO WG > > Subject: RE: [nemo] Question on MR - CN > > > > > > Hi, > > > > I have also been wondering about this issue for a while now. > > > > RFC 2003, states that a host should accept encapsulated > > packets if both > > inner and outer addresses belong to the host. > > > > However, MIPv6, states that a HoA option cannot be processed > > if a valid > > (authenticated) BCE exists in the host. > > > > Moreover, the transition mechanisms IPv4-IPv6 state that the only > > encapsutaled packets that are accepted are those thay belong > > to exsiting > > tunnels, toher shoudl be discarded. > > > > Finaly, 6to4 accepts all encapsulated packet, and a threats > > document is > > being discussed in v6ops. > > > > I guess that the main risk that this introduces is that > > source address > > spoofing is much more simpler thant today. I also guess that current > > implementations don't really accept encapsulated packets by defualt. > > > > So, in brief, older specs state that encpasulated packets > > may be accepted > > but newer ones are moving from that and only packets > > belonging to existent > > tunnels are accepted. > > > > Regards, marcelo > > > > > -----Mensaje original----- > > > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de > > > Chan-Wah NG > > > Enviado el: domingo, 09 de mayo de 2004 5:27 > > > Para: IETF NEMO WG > > > Asunto: Re: [nemo] Question on MR - CN > > > > > > > > > This is interesting, there is no concrete explanation on what the > > > "security threats" are. I guess most of us just assumed > > that direct > > > tunneling to CN is "somehow insecure", at least I do, > > without giving it > > > serious thought. > > > > > > According to the "Generic IPv6 Tunneling" RFC 2473, a > > tunnel exit node > > > should just discard the outer packet and process the inner > > packet as > > > though it has been delivered through a network interface. > > > > > > Perhaps we should ask what is the "security threat" here? > > The ingress > > > filtering problem shouldn't be a concern, since we would assume the > > > outer packet bears the CoA of MR as the src. > > > > > > The only issue I can think of is, not related to security, > > is the CN is > > > implemented not to accept tunnel from any nodes. For > > that, I consulted > > > the IPv6 Node (or Host) requirements draft, but there was > > no mention on > > > tunnel handling requirement. > > > > > > Any thoughts on this from others? > > > > > > /rgds > > > /cwng > > > > > > On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > > > > Thierry Ernst wrote: > > > > > > > > >Hi, > > > > > > > > > >For security reasons, we decided to use a bidirectional > > tunnel, so > > > > >encapsulation between MR and HA in both directions. > > This was decided > > > > >before the actual set up of the NEMO WG. I don't know > > if there is a > > > > >particular thread to recommend you, but probably that > > would be on the > > > > >monet ML archives, not the nemo ML archives. > > > > > > > > > > > > > > I looked through my monet archives and didn't come up > > with much on this > > > > subject. Most of the discussion happened between authors of > > > > requirements/solution specs at the time. The first > > thread I find with a > > > > quick search is from a year ago: > > > > > > > > On May 27, 2003, Greg Daley wrote: > > > > > > > > > Routers in the visited fixed network will Ingress filter > > > > > to prevent address spoofing. > > > > > Reverse tunnels are required, so that MNNs have an > > > > > address on the NEMO which is topologically correct. > > > > > > > > > > Greg Daley. > > > > > > > > > > atq atiq wrote: > > > > > > > > > >> Dear all, > > > > >> As a new customer, i don't understand the need for > > tunnelling for the > > > > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> > > > HAofMR ---> CN > > > > >> > > > > >> to send packets from VMN to CN [assume that CN > > already sent some to > > > > >> VMN]. > > > > >> > > > > >> if there is no tunnelling from FAofMR --[tunnelling > > here]--> HAofMR, > > > > >> what is the prob. or otherwise what's the benefits? > > > > >> > > > > >> Pls. let me know. > > > > >> > > > > >> Thanks in advance. > > > > >> > > > > >> > > > > >> aa > > > > >> > > > > >> > > > > >> __________________________________ > > > > >> Do you Yahoo!? > > > > >> Yahoo! Calendar - Free online calendar with sync to > > Outlook(TM). > > > > >> http://calendar.yahoo.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > ======================================================== > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review or distribution by others is > strictly prohibited. If you are not the intended recipient please contact > the sender and delete all copies. > ======================================================== > From nemo-admin@ietf.org Mon May 10 10:18:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06913 for ; Mon, 10 May 2004 10:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBT0-0004s5-Eq; Mon, 10 May 2004 10:09:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBPk-0002qK-N3 for nemo@optimus.ietf.org; Mon, 10 May 2004 10:05:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05359 for ; Mon, 10 May 2004 10:05:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNBPi-0006Tg-MI for nemo@ietf.org; Mon, 10 May 2004 10:05:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNBOh-00063a-00 for nemo@ietf.org; Mon, 10 May 2004 10:04:49 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BNBNC-00052A-00 for nemo@ietf.org; Mon, 10 May 2004 10:03:15 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 May 2004 10:01:32 -0400 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: [nemo] Question on MR - CN Date: Mon, 10 May 2004 10:01:32 -0400 Message-ID: Thread-Topic: [nemo] Question on MR - CN Thread-Index: AcQ2lQkhvub9MGl2RE2w8leCHVsKewAAGncA From: "Soliman Hesham" To: , "Chan-Wah NG" , "IETF NEMO WG" X-OriginalArrivalTime: 10 May 2004 14:01:32.0639 (UTC) FILETIME=[4C9AC6F0:01C43697] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Marcelo, > In my case, the question was generated by RFC 2003, since it=20 > states that >=20 > "Host implementations that are capable of receiving encapsulated IP > datagrams SHOULD admit only those datagrams fitting into one or more > of the following categories: >=20 > [...] > - The encapsulated (inner) datagram is addressed to a network > interface belonging to the decapsulator" >=20 > This behavior is not coherent with the processing of MIPv6=20 > HoA destination > option and what you are describing i guess. =3D> Well, 2003 is not even applicable to IPv6. Also the HAO is not considered part of IP in IP tunnelling, Although it's effectivley the same thing. >=20 > IMHO, the proper approach is to discard the encapsulated=20 > packets that don't > belong to an existent tunnel or that have been validated=20 > somehow, as you > mention, but RFC 2003 seems to state otherwise. =3D> Agreed.=20 >=20 > Summarizing, I agree that CN shouldn't accept encapsulated=20 > packets that > don't belong to an existing tunnel, but that it is not what=20 > it is stated in > RFC 2003 (and AFAIK, most implementations don't accept them,=20 > as you mention) =3D> Right. but I wouldn't worry about 2003 for IPv6. A more relevant one is 2473. >=20 > The other question raised was why the CN shouldn't accept=20 > those packets, and > the reason for this is that it would even easier to spoof=20 > source addresses. =3D> Yes. Hesham >=20 > Regards, marcelo >=20 >=20 > > -----Mensaje original----- > > De: Soliman Hesham [mailto:H.Soliman@flarion.com] > > Enviado el: lunes, 10 de mayo de 2004 14:26 > > Para: mbagnulo@ing.uc3m.es; Chan-Wah NG; IETF NEMO WG > > Asunto: RE: [nemo] Question on MR - CN > > > > > > Hi, > > > > I found it difficult to understand the original question. > > But tunnelling to the HA was included in the charter > > as a working assumption. At the time this was the best > > wording we could come up with to satisfy IESG, IAB...etc > > without explicitly naming the solution. > > > > Tunnelling to the CN has the same security problems > > as the HAO. RO in MIPv6 is essentially the same as tunnelling. > > > > The reason tunnelling to any random CN is not being suggested > > is that no implementation today accepts an unauthorised tunnel. > > Of course the reason is reflection attacks. > > > > So unless the tunnel is secure (which is effectively what > > return routability does in MIPv6, or IPsec in case of > > the HA) it won't be accepted. > > > > FWIW, MIPv6 could have used IP in IP tunnelling instead > > of the HAO and routing header, but the WG decided against > > this. Google draft-nordmark-hindsight ... for details. > > > > Hesham > > > > > -----Original Message----- > > > From: nemo-admin@ietf.org=20 > [mailto:nemo-admin@ietf.org]On Behalf Of > > > marcelo bagnulo > > > Sent: Monday, May 10, 2004 7:40 AM > > > To: Chan-Wah NG; IETF NEMO WG > > > Subject: RE: [nemo] Question on MR - CN > > > > > > > > > Hi, > > > > > > I have also been wondering about this issue for a while now. > > > > > > RFC 2003, states that a host should accept encapsulated > > > packets if both > > > inner and outer addresses belong to the host. > > > > > > However, MIPv6, states that a HoA option cannot be processed > > > if a valid > > > (authenticated) BCE exists in the host. > > > > > > Moreover, the transition mechanisms IPv4-IPv6 state=20 > that the only > > > encapsutaled packets that are accepted are those thay belong > > > to exsiting > > > tunnels, toher shoudl be discarded. > > > > > > Finaly, 6to4 accepts all encapsulated packet, and a threats > > > document is > > > being discussed in v6ops. > > > > > > I guess that the main risk that this introduces is that > > > source address > > > spoofing is much more simpler thant today. I also guess=20 > that current > > > implementations don't really accept encapsulated=20 > packets by defualt. > > > > > > So, in brief, older specs state that encpasulated packets > > > may be accepted > > > but newer ones are moving from that and only packets > > > belonging to existent > > > tunnels are accepted. > > > > > > Regards, marcelo > > > > > > > -----Mensaje original----- > > > > De: nemo-admin@ietf.org=20 > [mailto:nemo-admin@ietf.org]En nombre de > > > > Chan-Wah NG > > > > Enviado el: domingo, 09 de mayo de 2004 5:27 > > > > Para: IETF NEMO WG > > > > Asunto: Re: [nemo] Question on MR - CN > > > > > > > > > > > > This is interesting, there is no concrete explanation=20 > on what the > > > > "security threats" are. I guess most of us just assumed > > > that direct > > > > tunneling to CN is "somehow insecure", at least I do, > > > without giving it > > > > serious thought. > > > > > > > > According to the "Generic IPv6 Tunneling" RFC 2473, a > > > tunnel exit node > > > > should just discard the outer packet and process the inner > > > packet as > > > > though it has been delivered through a network interface. > > > > > > > > Perhaps we should ask what is the "security threat" here? > > > The ingress > > > > filtering problem shouldn't be a concern, since we=20 > would assume the > > > > outer packet bears the CoA of MR as the src. > > > > > > > > The only issue I can think of is, not related to security, > > > is the CN is > > > > implemented not to accept tunnel from any nodes. For > > > that, I consulted > > > > the IPv6 Node (or Host) requirements draft, but there was > > > no mention on > > > > tunnel handling requirement. > > > > > > > > Any thoughts on this from others? > > > > > > > > /rgds > > > > /cwng > > > > > > > > On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > > > > > Thierry Ernst wrote: > > > > > > > > > > >Hi, > > > > > > > > > > > >For security reasons, we decided to use a bidirectional > > > tunnel, so > > > > > >encapsulation between MR and HA in both directions. > > > This was decided > > > > > >before the actual set up of the NEMO WG. I don't know > > > if there is a > > > > > >particular thread to recommend you, but probably that > > > would be on the > > > > > >monet ML archives, not the nemo ML archives. > > > > > > > > > > > > > > > > > I looked through my monet archives and didn't come up > > > with much on this > > > > > subject. Most of the discussion happened between authors of > > > > > requirements/solution specs at the time. The first > > > thread I find with a > > > > > quick search is from a year ago: > > > > > > > > > > On May 27, 2003, Greg Daley wrote: > > > > > > > > > > > Routers in the visited fixed network will Ingress filter > > > > > > to prevent address spoofing. > > > > > > Reverse tunnels are required, so that MNNs have an > > > > > > address on the NEMO which is topologically correct. > > > > > > > > > > > > Greg Daley. > > > > > > > > > > > > atq atiq wrote: > > > > > > > > > > > >> Dear all, > > > > > >> As a new customer, i don't understand the need for > > > tunnelling for the > > > > > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> > > > > HAofMR ---> CN > > > > > >> > > > > > >> to send packets from VMN to CN [assume that CN > > > already sent some to > > > > > >> VMN]. > > > > > >> > > > > > >> if there is no tunnelling from FAofMR --[tunnelling > > > here]--> HAofMR, > > > > > >> what is the prob. or otherwise what's the benefits? > > > > > >> > > > > > >> Pls. let me know. > > > > > >> > > > > > >> Thanks in advance. > > > > > >> > > > > > >> > > > > > >> aa > > > > > >> > > > > > >> > > > > > >> __________________________________ > > > > > >> Do you Yahoo!? > > > > > >> Yahoo! Calendar - Free online calendar with sync to > > > Outlook(TM). > > > > > >> http://calendar.yahoo.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged=20 > material for the sole > > use of the intended recipient. Any review or distribution=20 > by others is > > strictly prohibited. If you are not the intended=20 > recipient please contact > > the sender and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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 >=20 >=20 From exim@www1.ietf.org Mon May 10 10:29:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07885 for ; Mon, 10 May 2004 10:29:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBjm-0001dl-1j for nemo-archive@odin.ietf.org; Mon, 10 May 2004 10:26:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AEQYXR006291 for nemo-archive@odin.ietf.org; Mon, 10 May 2004 10:26:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBee-0000Ye-Rx for nemo-web-archive@optimus.ietf.org; Mon, 10 May 2004 10:21:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07370 for ; Mon, 10 May 2004 10:21:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNBec-0004DU-ME for nemo-web-archive@ietf.org; Mon, 10 May 2004 10:21:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNBdQ-0003ht-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 10:20:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNBbY-0002vM-00 for nemo-web-archive@ietf.org; Mon, 10 May 2004 10:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBT0-0004s5-Eq; Mon, 10 May 2004 10:09:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBPk-0002qK-N3 for nemo@optimus.ietf.org; Mon, 10 May 2004 10:05:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05359 for ; Mon, 10 May 2004 10:05:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNBPi-0006Tg-MI for nemo@ietf.org; Mon, 10 May 2004 10:05:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNBOh-00063a-00 for nemo@ietf.org; Mon, 10 May 2004 10:04:49 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BNBNC-00052A-00 for nemo@ietf.org; Mon, 10 May 2004 10:03:15 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 May 2004 10:01:32 -0400 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: [nemo] Question on MR - CN Date: Mon, 10 May 2004 10:01:32 -0400 Message-ID: Thread-Topic: [nemo] Question on MR - CN Thread-Index: AcQ2lQkhvub9MGl2RE2w8leCHVsKewAAGncA From: "Soliman Hesham" To: , "Chan-Wah NG" , "IETF NEMO WG" X-OriginalArrivalTime: 10 May 2004 14:01:32.0639 (UTC) FILETIME=[4C9AC6F0:01C43697] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Marcelo, > In my case, the question was generated by RFC 2003, since it=20 > states that >=20 > "Host implementations that are capable of receiving encapsulated IP > datagrams SHOULD admit only those datagrams fitting into one or more > of the following categories: >=20 > [...] > - The encapsulated (inner) datagram is addressed to a network > interface belonging to the decapsulator" >=20 > This behavior is not coherent with the processing of MIPv6=20 > HoA destination > option and what you are describing i guess. =3D> Well, 2003 is not even applicable to IPv6. Also the HAO is not considered part of IP in IP tunnelling, Although it's effectivley the same thing. >=20 > IMHO, the proper approach is to discard the encapsulated=20 > packets that don't > belong to an existent tunnel or that have been validated=20 > somehow, as you > mention, but RFC 2003 seems to state otherwise. =3D> Agreed.=20 >=20 > Summarizing, I agree that CN shouldn't accept encapsulated=20 > packets that > don't belong to an existing tunnel, but that it is not what=20 > it is stated in > RFC 2003 (and AFAIK, most implementations don't accept them,=20 > as you mention) =3D> Right. but I wouldn't worry about 2003 for IPv6. A more relevant one is 2473. >=20 > The other question raised was why the CN shouldn't accept=20 > those packets, and > the reason for this is that it would even easier to spoof=20 > source addresses. =3D> Yes. Hesham >=20 > Regards, marcelo >=20 >=20 > > -----Mensaje original----- > > De: Soliman Hesham [mailto:H.Soliman@flarion.com] > > Enviado el: lunes, 10 de mayo de 2004 14:26 > > Para: mbagnulo@ing.uc3m.es; Chan-Wah NG; IETF NEMO WG > > Asunto: RE: [nemo] Question on MR - CN > > > > > > Hi, > > > > I found it difficult to understand the original question. > > But tunnelling to the HA was included in the charter > > as a working assumption. At the time this was the best > > wording we could come up with to satisfy IESG, IAB...etc > > without explicitly naming the solution. > > > > Tunnelling to the CN has the same security problems > > as the HAO. RO in MIPv6 is essentially the same as tunnelling. > > > > The reason tunnelling to any random CN is not being suggested > > is that no implementation today accepts an unauthorised tunnel. > > Of course the reason is reflection attacks. > > > > So unless the tunnel is secure (which is effectively what > > return routability does in MIPv6, or IPsec in case of > > the HA) it won't be accepted. > > > > FWIW, MIPv6 could have used IP in IP tunnelling instead > > of the HAO and routing header, but the WG decided against > > this. Google draft-nordmark-hindsight ... for details. > > > > Hesham > > > > > -----Original Message----- > > > From: nemo-admin@ietf.org=20 > [mailto:nemo-admin@ietf.org]On Behalf Of > > > marcelo bagnulo > > > Sent: Monday, May 10, 2004 7:40 AM > > > To: Chan-Wah NG; IETF NEMO WG > > > Subject: RE: [nemo] Question on MR - CN > > > > > > > > > Hi, > > > > > > I have also been wondering about this issue for a while now. > > > > > > RFC 2003, states that a host should accept encapsulated > > > packets if both > > > inner and outer addresses belong to the host. > > > > > > However, MIPv6, states that a HoA option cannot be processed > > > if a valid > > > (authenticated) BCE exists in the host. > > > > > > Moreover, the transition mechanisms IPv4-IPv6 state=20 > that the only > > > encapsutaled packets that are accepted are those thay belong > > > to exsiting > > > tunnels, toher shoudl be discarded. > > > > > > Finaly, 6to4 accepts all encapsulated packet, and a threats > > > document is > > > being discussed in v6ops. > > > > > > I guess that the main risk that this introduces is that > > > source address > > > spoofing is much more simpler thant today. I also guess=20 > that current > > > implementations don't really accept encapsulated=20 > packets by defualt. > > > > > > So, in brief, older specs state that encpasulated packets > > > may be accepted > > > but newer ones are moving from that and only packets > > > belonging to existent > > > tunnels are accepted. > > > > > > Regards, marcelo > > > > > > > -----Mensaje original----- > > > > De: nemo-admin@ietf.org=20 > [mailto:nemo-admin@ietf.org]En nombre de > > > > Chan-Wah NG > > > > Enviado el: domingo, 09 de mayo de 2004 5:27 > > > > Para: IETF NEMO WG > > > > Asunto: Re: [nemo] Question on MR - CN > > > > > > > > > > > > This is interesting, there is no concrete explanation=20 > on what the > > > > "security threats" are. I guess most of us just assumed > > > that direct > > > > tunneling to CN is "somehow insecure", at least I do, > > > without giving it > > > > serious thought. > > > > > > > > According to the "Generic IPv6 Tunneling" RFC 2473, a > > > tunnel exit node > > > > should just discard the outer packet and process the inner > > > packet as > > > > though it has been delivered through a network interface. > > > > > > > > Perhaps we should ask what is the "security threat" here? > > > The ingress > > > > filtering problem shouldn't be a concern, since we=20 > would assume the > > > > outer packet bears the CoA of MR as the src. > > > > > > > > The only issue I can think of is, not related to security, > > > is the CN is > > > > implemented not to accept tunnel from any nodes. For > > > that, I consulted > > > > the IPv6 Node (or Host) requirements draft, but there was > > > no mention on > > > > tunnel handling requirement. > > > > > > > > Any thoughts on this from others? > > > > > > > > /rgds > > > > /cwng > > > > > > > > On Sun, 2004-05-09 at 10:34, T.J. Kniveton wrote: > > > > > Thierry Ernst wrote: > > > > > > > > > > >Hi, > > > > > > > > > > > >For security reasons, we decided to use a bidirectional > > > tunnel, so > > > > > >encapsulation between MR and HA in both directions. > > > This was decided > > > > > >before the actual set up of the NEMO WG. I don't know > > > if there is a > > > > > >particular thread to recommend you, but probably that > > > would be on the > > > > > >monet ML archives, not the nemo ML archives. > > > > > > > > > > > > > > > > > I looked through my monet archives and didn't come up > > > with much on this > > > > > subject. Most of the discussion happened between authors of > > > > > requirements/solution specs at the time. The first > > > thread I find with a > > > > > quick search is from a year ago: > > > > > > > > > > On May 27, 2003, Greg Daley wrote: > > > > > > > > > > > Routers in the visited fixed network will Ingress filter > > > > > > to prevent address spoofing. > > > > > > Reverse tunnels are required, so that MNNs have an > > > > > > address on the NEMO which is topologically correct. > > > > > > > > > > > > Greg Daley. > > > > > > > > > > > > atq atiq wrote: > > > > > > > > > > > >> Dear all, > > > > > >> As a new customer, i don't understand the need for > > > tunnelling for the > > > > > >> case VMN[say, laptop] ---> FAofMR --[tunnelling here]--> > > > > HAofMR ---> CN > > > > > >> > > > > > >> to send packets from VMN to CN [assume that CN > > > already sent some to > > > > > >> VMN]. > > > > > >> > > > > > >> if there is no tunnelling from FAofMR --[tunnelling > > > here]--> HAofMR, > > > > > >> what is the prob. or otherwise what's the benefits? > > > > > >> > > > > > >> Pls. let me know. > > > > > >> > > > > > >> Thanks in advance. > > > > > >> > > > > > >> > > > > > >> aa > > > > > >> > > > > > >> > > > > > >> __________________________________ > > > > > >> Do you Yahoo!? > > > > > >> Yahoo! Calendar - Free online calendar with sync to > > > Outlook(TM). > > > > > >> http://calendar.yahoo.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged=20 > material for the sole > > use of the intended recipient. Any review or distribution=20 > by others is > > strictly prohibited. If you are not the intended=20 > recipient please contact > > the sender and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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 >=20 >=20 From nemo-admin@ietf.org Tue May 11 09:13:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24481 for ; Tue, 11 May 2004 09:13:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWwa-0007zp-Gd; Tue, 11 May 2004 09:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWqM-0006Tz-8D for nemo@optimus.ietf.org; Tue, 11 May 2004 08:58:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23912 for ; Tue, 11 May 2004 08:58:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNWqK-0000Fg-TA for nemo@ietf.org; Tue, 11 May 2004 08:58:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNWpM-0007em-00 for nemo@ietf.org; Tue, 11 May 2004 08:57:44 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BNWoE-0006tq-00 for nemo@ietf.org; Tue, 11 May 2004 08:56:35 -0400 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i4BCp41u029605; Tue, 11 May 2004 21:51:04 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i4BCp3No029604; Tue, 11 May 2004 21:51:03 +0900 Date: Tue, 11 May 2004 21:51:03 +0900 From: Seongho Cho To: marcelo bagnulo Cc: nemo@ietf.org Message-ID: <20040511215103.A29170@popeye.snu.ac.kr> References: <20040427104127.B9862@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mbagnulo@ing.uc3m.es on Mon, May 10, 2004 at 01:08:54PM +0200 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 Subject: [nemo] Re: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello Marcelo, Thanks for some very good comments. On Mon, May 10, 2004 at 01:08:54PM +0200, marcelo bagnulo wrote: > Hi Seongho, > > I have some questions about this draft. > > 1. In section 5.1 Neighbor MRs Discovery is stated that neighbors discovery > is based in RA messages. My question is how does the solution works when the > multiple MRs are not all connected to the same link, but there are routers > between them? This implies that MR1 cannot hear RA messages from MR2. > > For instance: > > | | > MR MR > | | > ----------Router------- Right. Actually, I also think about this situation. However, I think this problem can be solved from the HMRA (Hierarchical Mobile Router Advertisement) which is proposed by H. Cho. And the similar problem happens also in case of the nested MR scenario. I'll include this point to the next version. > 2. In the same section it is stated that from the neighbor discovery > process, MR1 can discover all the required data from MR2, such as HoA, CoA > and MNP. My question is how does MR1 discovers the CoA of MR2? i mean, as i > understand it, RA messages does not contain such information, since the > egress interface belongs to another link. I miss this point in my draft. However, the CoA of the root MR can be included as an option of RA. IMO, this option is simple, but usuful for other solution, like the route optimization. > 3. About the usage of RR to authenticate a MR presented in section 5.2 > First of all, i am not sure that i understand why the RR procedure is > suitable to perform this particular authentication. I mean, the RR check > verifies the collocation of a HoA and a CoA (or two addresses if you would). > But in this case, i would say that you need to verify more than just that. I > mean, using only the RR check, any device with both an ingress and egress > interface can claim to be a MR of the NEMO and the RR check will succeed. > For instance an attacker can simply join the nemo and if he has a wireless > interface connecting to the internet, it can claim to be a MR. Wouldn't be > necessary additional verifications, like an list of authorized MR?, and once > that you have that list, what do you need to perform the RR check for? > Additionally, using the RR check may have some issues, since for instance > the BCE lifetime of binding validated using RR check are limited to 7 > minutes. This implies that you have to perform the RR check every 7 minutes. > But what happens if the MR is no longer available (which as far as i > understand i one of your goals) First, I assume that the MR has a secure association with its HA and the wired node, including HA, can be verifiable using PKIX or other mechanism. This assumption is general. And the virtue of RR is the neighbor MR can confirm the mapping of a HoA and a CoA using HA's information. From this procedure, we can get the valid mapping of a HoA and a CoA. And this security issues have been treated in Mobile IP version 6 Route Optimization Security Design Background . Second, I think your example attacker can be prevented and our mechanism can provide non-repudiation from the SA between HA and MR. Finally, the BCE lifetime would not be the dominant factor for the leaving MR. The periodic RA message can be the factor for leaving or unavailable neighbor MR. I just use the RR procedure as an authentification mechansim. > 4. Finally, once that the HA is using an alternative MR, how do you manage > to exchange signaling between them? I mean, BU messages and other signaling > must be authenticated using IPSec, but the HA and the new MR don't have an > IPSec SA between them, so i don't see how the will be able to exchange > signaling, for instance when there is a movement and a new CoA has to be > announced from the MR to the HA. I assumed no signalling message between the HA and the new (neighbor) MR. The only required operation is de-capsulation for HA-(old)MR tunneled packets. But, the new MR can acquire the MNP from the RA, so this de-capsulation can be done after authentication using RR. Thank you for your comments. Regards, Seongho From exim@www1.ietf.org Tue May 11 09:23:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24990 for ; Tue, 11 May 2004 09:23:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXAC-0002Or-Lo for nemo-archive@odin.ietf.org; Tue, 11 May 2004 09:19:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BDJG9L009224 for nemo-archive@odin.ietf.org; Tue, 11 May 2004 09:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNX5w-0001S1-A0 for nemo-web-archive@optimus.ietf.org; Tue, 11 May 2004 09:14:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24586 for ; Tue, 11 May 2004 09:14:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNX5u-0006Zc-Pn for nemo-web-archive@ietf.org; Tue, 11 May 2004 09:14:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNX53-0006B4-00 for nemo-web-archive@ietf.org; Tue, 11 May 2004 09:13:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNX4D-0005lP-00 for nemo-web-archive@ietf.org; Tue, 11 May 2004 09:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWwa-0007zp-Gd; Tue, 11 May 2004 09:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWqM-0006Tz-8D for nemo@optimus.ietf.org; Tue, 11 May 2004 08:58:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23912 for ; Tue, 11 May 2004 08:58:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNWqK-0000Fg-TA for nemo@ietf.org; Tue, 11 May 2004 08:58:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNWpM-0007em-00 for nemo@ietf.org; Tue, 11 May 2004 08:57:44 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BNWoE-0006tq-00 for nemo@ietf.org; Tue, 11 May 2004 08:56:35 -0400 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i4BCp41u029605; Tue, 11 May 2004 21:51:04 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i4BCp3No029604; Tue, 11 May 2004 21:51:03 +0900 Date: Tue, 11 May 2004 21:51:03 +0900 From: Seongho Cho To: marcelo bagnulo Cc: nemo@ietf.org Message-ID: <20040511215103.A29170@popeye.snu.ac.kr> References: <20040427104127.B9862@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mbagnulo@ing.uc3m.es on Mon, May 10, 2004 at 01:08:54PM +0200 Subject: [nemo] Re: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Hello Marcelo, Thanks for some very good comments. On Mon, May 10, 2004 at 01:08:54PM +0200, marcelo bagnulo wrote: > Hi Seongho, > > I have some questions about this draft. > > 1. In section 5.1 Neighbor MRs Discovery is stated that neighbors discovery > is based in RA messages. My question is how does the solution works when the > multiple MRs are not all connected to the same link, but there are routers > between them? This implies that MR1 cannot hear RA messages from MR2. > > For instance: > > | | > MR MR > | | > ----------Router------- Right. Actually, I also think about this situation. However, I think this problem can be solved from the HMRA (Hierarchical Mobile Router Advertisement) which is proposed by H. Cho. And the similar problem happens also in case of the nested MR scenario. I'll include this point to the next version. > 2. In the same section it is stated that from the neighbor discovery > process, MR1 can discover all the required data from MR2, such as HoA, CoA > and MNP. My question is how does MR1 discovers the CoA of MR2? i mean, as i > understand it, RA messages does not contain such information, since the > egress interface belongs to another link. I miss this point in my draft. However, the CoA of the root MR can be included as an option of RA. IMO, this option is simple, but usuful for other solution, like the route optimization. > 3. About the usage of RR to authenticate a MR presented in section 5.2 > First of all, i am not sure that i understand why the RR procedure is > suitable to perform this particular authentication. I mean, the RR check > verifies the collocation of a HoA and a CoA (or two addresses if you would). > But in this case, i would say that you need to verify more than just that. I > mean, using only the RR check, any device with both an ingress and egress > interface can claim to be a MR of the NEMO and the RR check will succeed. > For instance an attacker can simply join the nemo and if he has a wireless > interface connecting to the internet, it can claim to be a MR. Wouldn't be > necessary additional verifications, like an list of authorized MR?, and once > that you have that list, what do you need to perform the RR check for? > Additionally, using the RR check may have some issues, since for instance > the BCE lifetime of binding validated using RR check are limited to 7 > minutes. This implies that you have to perform the RR check every 7 minutes. > But what happens if the MR is no longer available (which as far as i > understand i one of your goals) First, I assume that the MR has a secure association with its HA and the wired node, including HA, can be verifiable using PKIX or other mechanism. This assumption is general. And the virtue of RR is the neighbor MR can confirm the mapping of a HoA and a CoA using HA's information. From this procedure, we can get the valid mapping of a HoA and a CoA. And this security issues have been treated in Mobile IP version 6 Route Optimization Security Design Background . Second, I think your example attacker can be prevented and our mechanism can provide non-repudiation from the SA between HA and MR. Finally, the BCE lifetime would not be the dominant factor for the leaving MR. The periodic RA message can be the factor for leaving or unavailable neighbor MR. I just use the RR procedure as an authentification mechansim. > 4. Finally, once that the HA is using an alternative MR, how do you manage > to exchange signaling between them? I mean, BU messages and other signaling > must be authenticated using IPSec, but the HA and the new MR don't have an > IPSec SA between them, so i don't see how the will be able to exchange > signaling, for instance when there is a movement and a new CoA has to be > announced from the MR to the HA. I assumed no signalling message between the HA and the new (neighbor) MR. The only required operation is de-capsulation for HA-(old)MR tunneled packets. But, the new MR can acquire the MNP from the RA, so this de-capsulation can be done after authentication using RR. Thank you for your comments. Regards, Seongho From nemo-admin@ietf.org Tue May 11 10:26:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29301 for ; Tue, 11 May 2004 10:26:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNY8y-0004t4-ME; Tue, 11 May 2004 10:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXuP-0005l7-Mt for nemo@optimus.ietf.org; Tue, 11 May 2004 10:07:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27347 for ; Tue, 11 May 2004 10:06:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNXuN-0003rb-N0 for nemo@ietf.org; Tue, 11 May 2004 10:06:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNXtS-0003Tf-00 for nemo@ietf.org; Tue, 11 May 2004 10:06:03 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BNXsj-00032h-00 for nemo@ietf.org; Tue, 11 May 2004 10:05:18 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 1150C263F9; Tue, 11 May 2004 16:04:47 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 8AA0A263F9; Tue, 11 May 2004 16:04:46 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Seongho Cho" , "marcelo bagnulo" Cc: Date: Tue, 11 May 2004 16:00:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040511215103.A29170@popeye.snu.ac.kr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Subject: [nemo] RE: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > First, I assume that the MR has a secure association with its HA and the > wired node, including HA, can be verifiable using PKIX or other > mechanism. Ok, let's define the considered a bit more. LEt's suppose that the nemo has two MR: MR1 and MR2 There are also two HA: HA1 and HA2. Additioanlly let's suppose that the MR1 uses HA1 and that MR2 uses HA2. So i guess you are assuming that HA1 has a SA with MR1 and that HA2 has a SA with MR2, right? IMHO this is what can be assumed by default. Now you are using the RR so that MR1 can verify the collocation of the CoA and the HoA of MR2 and conversely i.e. the MR2 can verify the collocation of the HoA and the CoA of MR1. > This assumption is general. And the virtue of RR is the neighbor MR can > confirm the mapping of a HoA and a CoA using HA's information. What HA's information? i mean this procedure is between the MR1 and MR2, so what HA are you considering here? From this > procedure, we can get the valid mapping of a HoA and a CoA. And > this security > issues have been treated in Mobile IP version 6 Route Optimization > Security Design Background . Yes, but i guess that the RR check is usefull when you want to verify the collocation of two addresses of a CN that you don't have previous contact and you are contcting it over the internet, This scenario is quite different, since the two MRs probably know each other, they are using the nemo to communicate and you probably want some sort of authorization information to valiudate that using another MR is safe, Again, i think that MR1 should be aware of the existance of MR2 through a preconfigured list. I mean, not all nodes in the nemo are suitable to act as MR. > > Second, I think your example attacker can be prevented and our mechanism > can provide non-repudiation from the SA between HA and MR. How? PErhaps you would care to expand on how you can prevent any node with two addresses to become a MR using RR check? > > Finally, the BCE lifetime would not be the dominant factor for > the leaving MR. > The periodic RA message can be the factor for leaving or > unavailable neighbor > MR. I just use the RR procedure as an authentification mechansim. YEs but the authentication information is valid only for 7 minutes, after that, the BCE will disapear and if the other MR is down, you won't be able to renew it becuase the RR check will fail ( i mean, the router is down, so it won't be able to reply RR packets) > > > 4. Finally, once that the HA is using an alternative MR, how do > you manage > > to exchange signaling between them? I mean, BU messages and > other signaling > > must be authenticated using IPSec, but the HA and the new MR > don't have an > > IPSec SA between them, so i don't see how the will be able to exchange > > signaling, for instance when there is a movement and a new CoA has to be > > announced from the MR to the HA. > > I assumed no signalling message between the HA and the new > (neighbor) MR. > The only required operation is de-capsulation for HA-(old)MR > tunneled packets. > But, the new MR can acquire the MNP from the RA, so this > de-capsulation can > be done after authentication using RR. Again, suppose that one of the routers is down. If you want to preserve the communications that are being carried through its HA you will need to update the binding information in both HAs as the nemo moves and changes its CoA, and since one MR is down, the remaining MR will have to update the binding information on both HAs. With one of the HA it will have a IPSec SA so no problem, but with the other, it doesn't have an IPSec SA so it won't be able to update the binding. This essentially means that if MR2 is down, then the HA2 will send packets to the MR1, so far so good. Now the nemo moves, so MR1 changes its CoA, now how do you update the HA1 with the new CoA of MR1? Regards, marcelo > > Thank you for your comments. > > Regards, > Seongho From exim@www1.ietf.org Tue May 11 10:46:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00615 for ; Tue, 11 May 2004 10:46:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYSL-00017X-Dw for nemo-archive@odin.ietf.org; Tue, 11 May 2004 10:42:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BEg5Zn004302 for nemo-archive@odin.ietf.org; Tue, 11 May 2004 10:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYEg-0006Mb-6f for nemo-web-archive@optimus.ietf.org; Tue, 11 May 2004 10:27:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29390 for ; Tue, 11 May 2004 10:27:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNYEd-0004cv-WC for nemo-web-archive@ietf.org; Tue, 11 May 2004 10:27:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNYDg-0004EJ-00 for nemo-web-archive@ietf.org; Tue, 11 May 2004 10:26:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNYCz-0003om-00 for nemo-web-archive@ietf.org; Tue, 11 May 2004 10:26:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNY8y-0004t4-ME; Tue, 11 May 2004 10:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXuP-0005l7-Mt for nemo@optimus.ietf.org; Tue, 11 May 2004 10:07:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27347 for ; Tue, 11 May 2004 10:06:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNXuN-0003rb-N0 for nemo@ietf.org; Tue, 11 May 2004 10:06:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNXtS-0003Tf-00 for nemo@ietf.org; Tue, 11 May 2004 10:06:03 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BNXsj-00032h-00 for nemo@ietf.org; Tue, 11 May 2004 10:05:18 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 1150C263F9; Tue, 11 May 2004 16:04:47 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 8AA0A263F9; Tue, 11 May 2004 16:04:46 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Seongho Cho" , "marcelo bagnulo" Cc: Date: Tue, 11 May 2004 16:00:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040511215103.A29170@popeye.snu.ac.kr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [nemo] RE: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 > > First, I assume that the MR has a secure association with its HA and the > wired node, including HA, can be verifiable using PKIX or other > mechanism. Ok, let's define the considered a bit more. LEt's suppose that the nemo has two MR: MR1 and MR2 There are also two HA: HA1 and HA2. Additioanlly let's suppose that the MR1 uses HA1 and that MR2 uses HA2. So i guess you are assuming that HA1 has a SA with MR1 and that HA2 has a SA with MR2, right? IMHO this is what can be assumed by default. Now you are using the RR so that MR1 can verify the collocation of the CoA and the HoA of MR2 and conversely i.e. the MR2 can verify the collocation of the HoA and the CoA of MR1. > This assumption is general. And the virtue of RR is the neighbor MR can > confirm the mapping of a HoA and a CoA using HA's information. What HA's information? i mean this procedure is between the MR1 and MR2, so what HA are you considering here? From this > procedure, we can get the valid mapping of a HoA and a CoA. And > this security > issues have been treated in Mobile IP version 6 Route Optimization > Security Design Background . Yes, but i guess that the RR check is usefull when you want to verify the collocation of two addresses of a CN that you don't have previous contact and you are contcting it over the internet, This scenario is quite different, since the two MRs probably know each other, they are using the nemo to communicate and you probably want some sort of authorization information to valiudate that using another MR is safe, Again, i think that MR1 should be aware of the existance of MR2 through a preconfigured list. I mean, not all nodes in the nemo are suitable to act as MR. > > Second, I think your example attacker can be prevented and our mechanism > can provide non-repudiation from the SA between HA and MR. How? PErhaps you would care to expand on how you can prevent any node with two addresses to become a MR using RR check? > > Finally, the BCE lifetime would not be the dominant factor for > the leaving MR. > The periodic RA message can be the factor for leaving or > unavailable neighbor > MR. I just use the RR procedure as an authentification mechansim. YEs but the authentication information is valid only for 7 minutes, after that, the BCE will disapear and if the other MR is down, you won't be able to renew it becuase the RR check will fail ( i mean, the router is down, so it won't be able to reply RR packets) > > > 4. Finally, once that the HA is using an alternative MR, how do > you manage > > to exchange signaling between them? I mean, BU messages and > other signaling > > must be authenticated using IPSec, but the HA and the new MR > don't have an > > IPSec SA between them, so i don't see how the will be able to exchange > > signaling, for instance when there is a movement and a new CoA has to be > > announced from the MR to the HA. > > I assumed no signalling message between the HA and the new > (neighbor) MR. > The only required operation is de-capsulation for HA-(old)MR > tunneled packets. > But, the new MR can acquire the MNP from the RA, so this > de-capsulation can > be done after authentication using RR. Again, suppose that one of the routers is down. If you want to preserve the communications that are being carried through its HA you will need to update the binding information in both HAs as the nemo moves and changes its CoA, and since one MR is down, the remaining MR will have to update the binding information on both HAs. With one of the HA it will have a IPSec SA so no problem, but with the other, it doesn't have an IPSec SA so it won't be able to update the binding. This essentially means that if MR2 is down, then the HA2 will send packets to the MR1, so far so good. Now the nemo moves, so MR1 changes its CoA, now how do you update the HA1 with the new CoA of MR1? Regards, marcelo > > Thank you for your comments. > > Regards, > Seongho From nemo-admin@ietf.org Tue May 11 11:28:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03792 for ; Tue, 11 May 2004 11:28:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNZ4J-0001wJ-6A; Tue, 11 May 2004 11:21:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYuM-0007o4-Dp for nemo@optimus.ietf.org; Tue, 11 May 2004 11:11:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02623 for ; Tue, 11 May 2004 11:10:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNYuJ-0007G9-Nt for nemo@ietf.org; Tue, 11 May 2004 11:10:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNYtS-0006qc-00 for nemo@ietf.org; Tue, 11 May 2004 11:10:07 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BNYsc-0006Qy-00 for nemo@ietf.org; Tue, 11 May 2004 11:09:15 -0400 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i4BF3i1u029998; Wed, 12 May 2004 00:03:44 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i4BF3irJ029997; Wed, 12 May 2004 00:03:44 +0900 Date: Wed, 12 May 2004 00:03:44 +0900 From: Seongho Cho To: marcelo bagnulo Cc: nemo@ietf.org Message-ID: <20040512000344.A29872@popeye.snu.ac.kr> References: <20040511215103.A29170@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mbagnulo@ing.uc3m.es on Tue, May 11, 2004 at 04:00:50PM +0200 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 Subject: [nemo] Re: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > > > First, I assume that the MR has a secure association with its HA and the > > wired node, including HA, can be verifiable using PKIX or other > > mechanism. > > Ok, let's define the considered a bit more. > LEt's suppose that the nemo has two MR: MR1 and MR2 > There are also two HA: HA1 and HA2. > Additioanlly let's suppose that the MR1 uses HA1 and that MR2 uses HA2. > > So i guess you are assuming that HA1 has a SA with MR1 and that HA2 has a SA > with MR2, right? > IMHO this is what can be assumed by default. Yes. > Now you are using the RR so that MR1 can verify the collocation of the CoA > and the HoA of MR2 and conversely i.e. the MR2 can verify the collocation > of the HoA and the CoA of MR1. Correct. > > > This assumption is general. And the virtue of RR is the neighbor MR can > > confirm the mapping of a HoA and a CoA using HA's information. > > What HA's information? i mean this procedure is between the MR1 and MR2, so > what HA are you considering here? The RR procedure consists of Home Test and Care-of Test. So, what I want to mention was HA's Binding Cache information of it's MR. I assume that each MR and HA pair has correct binding information. From Home Test, MR can verify packets are correctly tunneled to the neighbor MR through its HA. And the CoA which is updated to the HA would be correct through this test. > From this > > procedure, we can get the valid mapping of a HoA and a CoA. And > > this security > > issues have been treated in Mobile IP version 6 Route Optimization > > Security Design Background . > > Yes, but i guess that the RR check is usefull when you want to verify the > collocation of two addresses of a CN that you don't have previous contact > and you are contcting it over the internet, This scenario is quite > different, since the two MRs probably know each other, they are using the > nemo to communicate and you probably want some sort of authorization > information to valiudate that using another MR is safe, Again, i think that > MR1 should be aware of the existance of MR2 through a preconfigured list. I > mean, not all nodes in the nemo are suitable to act as MR. IMO, the preconfigured list is not always possible in some cases. Each MR can move dynamically in the mobile networks. Practical situation can be the European train. Each train consists of several wagons. And the wagon can flock and depart by their destination. Each wagon can join and leave dynamically. Like this example, some situations need dynamic MR authentication and registration. And this dynamic mechanism would be prefered for convenient network management. My assumption is MR1 could not be aware of the existance of MR2 before receiving MR2's RA message. And, like you said, not all nodes in the nemo are suitable to act as root MR. MR1 and MR2 should be root MRs which have a connection to the wired network. > > Second, I think your example attacker can be prevented and our mechanism > > can provide non-repudiation from the SA between HA and MR. > > How? > PErhaps you would care to expand on how you can prevent any node with two > addresses to become a MR using RR check? My assumption is each MR has its own HA. The single HA case is trivial. My scope is each MR has the different HA. If we refer the HA, we can acquire valid CoA, HoA, and MNP of MR. What I want to verify using RR is the neighbor MR's CoA, HoA, and MNP is correct or not. And if the neighbor MR do malicious thing, then we can refer MR's HA. That can be the non- repudiation. > > Finally, the BCE lifetime would not be the dominant factor for > > the leaving MR. > > The periodic RA message can be the factor for leaving or > > unavailable neighbor > > MR. I just use the RR procedure as an authentification mechansim. > > YEs but the authentication information is valid only for 7 minutes, after > that, the BCE will disapear and if the other MR is down, you won't be able > to renew it becuase the RR check will fail ( i mean, the router is down, so > it won't be able to reply RR packets) Correct. What is the problem in that router failure? Periodic RR test? or RR test overhead? > > > 4. Finally, once that the HA is using an alternative MR, how do > > you manage > > > to exchange signaling between them? I mean, BU messages and > > other signaling > > > must be authenticated using IPSec, but the HA and the new MR > > don't have an > > > IPSec SA between them, so i don't see how the will be able to exchange > > > signaling, for instance when there is a movement and a new CoA has to be > > > announced from the MR to the HA. > > > > I assumed no signalling message between the HA and the new > > (neighbor) MR. > > The only required operation is de-capsulation for HA-(old)MR > > tunneled packets. > > But, the new MR can acquire the MNP from the RA, so this > > de-capsulation can > > be done after authentication using RR. > > Again, suppose that one of the routers is down. > If you want to preserve the communications that are being carried through > its HA you will need to update the binding information in both HAs as the > nemo moves and changes its CoA, and since one MR is down, the remaining MR > will have to update the binding information on both HAs. With one of the HA > it will have a IPSec SA so no problem, but with the other, it doesn't have > an IPSec SA so it won't be able to update the binding. > This essentially means that if MR2 is down, then the HA2 will send packets > to the MR1, so far so good. > Now the nemo moves, so MR1 changes its CoA, now how do you update the HA1 > with the new CoA of MR1? As you said, MR1 doesn't have a IPSec SA with HA2. So, all packets from HA2 should be tunnelled though the MR1-HA1 tunnel. And the movement of MR1 is another problem. In that case, there exists no alternative MR for failed MR2. So, the service cease for MR2-HA2 would be correct. Regards, Seongho From exim@www1.ietf.org Tue May 11 11:41:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04469 for ; Tue, 11 May 2004 11:41:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNZEu-0004SQ-60 for nemo-archive@odin.ietf.org; Tue, 11 May 2004 11:32:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BFWGZn017132 for nemo-archive@odin.ietf.org; Tue, 11 May 2004 11:32:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNZBv-0003ho-UR for nemo-web-archive@optimus.ietf.org; Tue, 11 May 2004 11:29:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03876 for ; Tue, 11 May 2004 11:29:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNZBv-0007Sr-1F for nemo-web-archive@ietf.org; Tue, 11 May 2004 11:29:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNZAt-00072J-00 for nemo-web-archive@ietf.org; Tue, 11 May 2004 11:28:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNZAN-0006cC-00 for nemo-web-archive@ietf.org; Tue, 11 May 2004 11:27:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNZ4J-0001wJ-6A; Tue, 11 May 2004 11:21:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYuM-0007o4-Dp for nemo@optimus.ietf.org; Tue, 11 May 2004 11:11:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02623 for ; Tue, 11 May 2004 11:10:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNYuJ-0007G9-Nt for nemo@ietf.org; Tue, 11 May 2004 11:10:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNYtS-0006qc-00 for nemo@ietf.org; Tue, 11 May 2004 11:10:07 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BNYsc-0006Qy-00 for nemo@ietf.org; Tue, 11 May 2004 11:09:15 -0400 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i4BF3i1u029998; Wed, 12 May 2004 00:03:44 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i4BF3irJ029997; Wed, 12 May 2004 00:03:44 +0900 Date: Wed, 12 May 2004 00:03:44 +0900 From: Seongho Cho To: marcelo bagnulo Cc: nemo@ietf.org Message-ID: <20040512000344.A29872@popeye.snu.ac.kr> References: <20040511215103.A29170@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mbagnulo@ing.uc3m.es on Tue, May 11, 2004 at 04:00:50PM +0200 Subject: [nemo] Re: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 > > > > First, I assume that the MR has a secure association with its HA and the > > wired node, including HA, can be verifiable using PKIX or other > > mechanism. > > Ok, let's define the considered a bit more. > LEt's suppose that the nemo has two MR: MR1 and MR2 > There are also two HA: HA1 and HA2. > Additioanlly let's suppose that the MR1 uses HA1 and that MR2 uses HA2. > > So i guess you are assuming that HA1 has a SA with MR1 and that HA2 has a SA > with MR2, right? > IMHO this is what can be assumed by default. Yes. > Now you are using the RR so that MR1 can verify the collocation of the CoA > and the HoA of MR2 and conversely i.e. the MR2 can verify the collocation > of the HoA and the CoA of MR1. Correct. > > > This assumption is general. And the virtue of RR is the neighbor MR can > > confirm the mapping of a HoA and a CoA using HA's information. > > What HA's information? i mean this procedure is between the MR1 and MR2, so > what HA are you considering here? The RR procedure consists of Home Test and Care-of Test. So, what I want to mention was HA's Binding Cache information of it's MR. I assume that each MR and HA pair has correct binding information. From Home Test, MR can verify packets are correctly tunneled to the neighbor MR through its HA. And the CoA which is updated to the HA would be correct through this test. > From this > > procedure, we can get the valid mapping of a HoA and a CoA. And > > this security > > issues have been treated in Mobile IP version 6 Route Optimization > > Security Design Background . > > Yes, but i guess that the RR check is usefull when you want to verify the > collocation of two addresses of a CN that you don't have previous contact > and you are contcting it over the internet, This scenario is quite > different, since the two MRs probably know each other, they are using the > nemo to communicate and you probably want some sort of authorization > information to valiudate that using another MR is safe, Again, i think that > MR1 should be aware of the existance of MR2 through a preconfigured list. I > mean, not all nodes in the nemo are suitable to act as MR. IMO, the preconfigured list is not always possible in some cases. Each MR can move dynamically in the mobile networks. Practical situation can be the European train. Each train consists of several wagons. And the wagon can flock and depart by their destination. Each wagon can join and leave dynamically. Like this example, some situations need dynamic MR authentication and registration. And this dynamic mechanism would be prefered for convenient network management. My assumption is MR1 could not be aware of the existance of MR2 before receiving MR2's RA message. And, like you said, not all nodes in the nemo are suitable to act as root MR. MR1 and MR2 should be root MRs which have a connection to the wired network. > > Second, I think your example attacker can be prevented and our mechanism > > can provide non-repudiation from the SA between HA and MR. > > How? > PErhaps you would care to expand on how you can prevent any node with two > addresses to become a MR using RR check? My assumption is each MR has its own HA. The single HA case is trivial. My scope is each MR has the different HA. If we refer the HA, we can acquire valid CoA, HoA, and MNP of MR. What I want to verify using RR is the neighbor MR's CoA, HoA, and MNP is correct or not. And if the neighbor MR do malicious thing, then we can refer MR's HA. That can be the non- repudiation. > > Finally, the BCE lifetime would not be the dominant factor for > > the leaving MR. > > The periodic RA message can be the factor for leaving or > > unavailable neighbor > > MR. I just use the RR procedure as an authentification mechansim. > > YEs but the authentication information is valid only for 7 minutes, after > that, the BCE will disapear and if the other MR is down, you won't be able > to renew it becuase the RR check will fail ( i mean, the router is down, so > it won't be able to reply RR packets) Correct. What is the problem in that router failure? Periodic RR test? or RR test overhead? > > > 4. Finally, once that the HA is using an alternative MR, how do > > you manage > > > to exchange signaling between them? I mean, BU messages and > > other signaling > > > must be authenticated using IPSec, but the HA and the new MR > > don't have an > > > IPSec SA between them, so i don't see how the will be able to exchange > > > signaling, for instance when there is a movement and a new CoA has to be > > > announced from the MR to the HA. > > > > I assumed no signalling message between the HA and the new > > (neighbor) MR. > > The only required operation is de-capsulation for HA-(old)MR > > tunneled packets. > > But, the new MR can acquire the MNP from the RA, so this > > de-capsulation can > > be done after authentication using RR. > > Again, suppose that one of the routers is down. > If you want to preserve the communications that are being carried through > its HA you will need to update the binding information in both HAs as the > nemo moves and changes its CoA, and since one MR is down, the remaining MR > will have to update the binding information on both HAs. With one of the HA > it will have a IPSec SA so no problem, but with the other, it doesn't have > an IPSec SA so it won't be able to update the binding. > This essentially means that if MR2 is down, then the HA2 will send packets > to the MR1, so far so good. > Now the nemo moves, so MR1 changes its CoA, now how do you update the HA1 > with the new CoA of MR1? As you said, MR1 doesn't have a IPSec SA with HA2. So, all packets from HA2 should be tunnelled though the MR1-HA1 tunnel. And the movement of MR1 is another problem. In that case, there exists no alternative MR for failed MR2. So, the service cease for MR2-HA2 would be correct. Regards, Seongho From nemo-admin@ietf.org Wed May 12 06:09:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21141 for ; Wed, 12 May 2004 06:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqcj-0003PH-8C; Wed, 12 May 2004 06:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqaY-0002aG-8A for nemo@optimus.ietf.org; Wed, 12 May 2004 06:03:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20923 for ; Wed, 12 May 2004 06:03:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNqaU-0001aV-IR for nemo@ietf.org; Wed, 12 May 2004 06:03:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNqZV-00015Q-00 for nemo@ietf.org; Wed, 12 May 2004 06:02:42 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BNqYK-00008s-00 for nemo@ietf.org; Wed, 12 May 2004 06:01:28 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id A6273269DD; Wed, 12 May 2004 12:00:58 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 1EDF1269BB; Wed, 12 May 2004 12:00:56 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Seongho Cho" , "marcelo bagnulo" Cc: Subject: RE: [nemo] Re: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Date: Wed, 12 May 2004 11:56:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040512000344.A29872@popeye.snu.ac.kr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > The RR procedure consists of Home Test and Care-of Test. So, > what I want to > mention was HA's Binding Cache information of it's MR. I assume that each > MR and HA pair has correct binding information. From Home Test, MR can > verify packets are correctly tunneled to the neighbor MR through its HA. > And the CoA which is updated to the HA would be correct through > this test. I think i am not following this... I mean, the two MR are on the same nemo, and you assume that each one of them can listen to the RAdv from each other. This basically means that MR1 can reach the HoA of MR2 through the nemo, and it will not use the HA. For accesing the CoA of MR2, normal routing will be used so, i guess you don't need the HA of MR2 neither. So what binding information are you using? [...] > IMO, the preconfigured list is not always possible in some > cases. Each MR > can move dynamically in the mobile networks. Practical situation can be > the European train. Each train consists of several wagons. And the wagon > can flock and depart by their destination. Each wagon can join and leave > dynamically. Like this example, some situations need dynamic MR > authentication and registration. And this dynamic mechanism > would be prefered for convenient > network management. My assumption is MR1 could not be aware of > the existance > of MR2 before receiving MR2's RA message. I like your example, thanks. I think that we should distinguish two issues here. I agree that the MR in wagon 1 will need to discover the other MRs in other wagons, since the arrangement of wagons can vary. However, i think that that doesn't mean that they cannot have a list of authorized MR that are acceptable. I mean, alll the wagons will belong to the train company, so the can have a preconfigured key. So you need a mechanism to discover which MR are available from those that are authorized. But this is not really the point. The point is about whether the RR check provides valid security. In the example of the train, i guess that it is not acceptable that i put my laptop there, with a WLAN and a GPRS connection and start pretending that i am a valid MR (who knows why i would want to do that, for instance in order to try to redirect all the traffic to a key cracking device somewhere else or divert the traffic to do a mitm attack) So, how the RR check can prevent me from doing this? If this is not the attack that the RR can prevent, please describe an attack that the RR check can prevent Regards, marcelo From exim@www1.ietf.org Wed May 12 06:21:00 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21755 for ; Wed, 12 May 2004 06:21:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqli-0006OG-MA for nemo-archive@odin.ietf.org; Wed, 12 May 2004 06:15:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CAFIoD024564 for nemo-archive@odin.ietf.org; Wed, 12 May 2004 06:15:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqhl-00054L-4f for nemo-web-archive@optimus.ietf.org; Wed, 12 May 2004 06:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21309 for ; Wed, 12 May 2004 06:11:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNqhh-00058H-Gi for nemo-web-archive@ietf.org; Wed, 12 May 2004 06:11:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNqgo-0004cr-00 for nemo-web-archive@ietf.org; Wed, 12 May 2004 06:10:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNqfd-00045X-00 for nemo-web-archive@ietf.org; Wed, 12 May 2004 06:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqcj-0003PH-8C; Wed, 12 May 2004 06:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqaY-0002aG-8A for nemo@optimus.ietf.org; Wed, 12 May 2004 06:03:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20923 for ; Wed, 12 May 2004 06:03:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNqaU-0001aV-IR for nemo@ietf.org; Wed, 12 May 2004 06:03:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNqZV-00015Q-00 for nemo@ietf.org; Wed, 12 May 2004 06:02:42 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1BNqYK-00008s-00 for nemo@ietf.org; Wed, 12 May 2004 06:01:28 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id A6273269DD; Wed, 12 May 2004 12:00:58 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp02.uc3m.es (Postfix) with SMTP id 1EDF1269BB; Wed, 12 May 2004 12:00:56 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Seongho Cho" , "marcelo bagnulo" Cc: Subject: RE: [nemo] Re: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Date: Wed, 12 May 2004 11:56:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040512000344.A29872@popeye.snu.ac.kr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 > The RR procedure consists of Home Test and Care-of Test. So, > what I want to > mention was HA's Binding Cache information of it's MR. I assume that each > MR and HA pair has correct binding information. From Home Test, MR can > verify packets are correctly tunneled to the neighbor MR through its HA. > And the CoA which is updated to the HA would be correct through > this test. I think i am not following this... I mean, the two MR are on the same nemo, and you assume that each one of them can listen to the RAdv from each other. This basically means that MR1 can reach the HoA of MR2 through the nemo, and it will not use the HA. For accesing the CoA of MR2, normal routing will be used so, i guess you don't need the HA of MR2 neither. So what binding information are you using? [...] > IMO, the preconfigured list is not always possible in some > cases. Each MR > can move dynamically in the mobile networks. Practical situation can be > the European train. Each train consists of several wagons. And the wagon > can flock and depart by their destination. Each wagon can join and leave > dynamically. Like this example, some situations need dynamic MR > authentication and registration. And this dynamic mechanism > would be prefered for convenient > network management. My assumption is MR1 could not be aware of > the existance > of MR2 before receiving MR2's RA message. I like your example, thanks. I think that we should distinguish two issues here. I agree that the MR in wagon 1 will need to discover the other MRs in other wagons, since the arrangement of wagons can vary. However, i think that that doesn't mean that they cannot have a list of authorized MR that are acceptable. I mean, alll the wagons will belong to the train company, so the can have a preconfigured key. So you need a mechanism to discover which MR are available from those that are authorized. But this is not really the point. The point is about whether the RR check provides valid security. In the example of the train, i guess that it is not acceptable that i put my laptop there, with a WLAN and a GPRS connection and start pretending that i am a valid MR (who knows why i would want to do that, for instance in order to try to redirect all the traffic to a key cracking device somewhere else or divert the traffic to do a mitm attack) So, how the RR check can prevent me from doing this? If this is not the attack that the RR can prevent, please describe an attack that the RR check can prevent Regards, marcelo From nemo-admin@ietf.org Wed May 12 21:52:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25887 for ; Wed, 12 May 2004 21:52:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO5GS-00052W-SU; Wed, 12 May 2004 21:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO5BF-0003sC-P5 for nemo@optimus.ietf.org; Wed, 12 May 2004 21:38:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25347 for ; Wed, 12 May 2004 21:38:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO5BD-0003oR-2V for nemo@ietf.org; Wed, 12 May 2004 21:38:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO5A7-0003Gd-00 for nemo@ietf.org; Wed, 12 May 2004 21:37:28 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BO59J-0002k3-00 for nemo@ietf.org; Wed, 12 May 2004 21:36:37 -0400 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i4D1V61u005219; Thu, 13 May 2004 10:31:06 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i4D1V5er005218; Thu, 13 May 2004 10:31:05 +0900 Date: Thu, 13 May 2004 10:31:05 +0900 From: Seongho Cho To: marcelo bagnulo Cc: nemo@ietf.org Subject: Re: [nemo] Re: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Message-ID: <20040513103105.A2420@popeye.snu.ac.kr> References: <20040512000344.A29872@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mbagnulo@ing.uc3m.es on Wed, May 12, 2004 at 11:56:57AM +0200 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , On Wed, May 12, 2004 at 11:56:57AM +0200, marcelo bagnulo wrote: > > The RR procedure consists of Home Test and Care-of Test. So, > > what I want to > > mention was HA's Binding Cache information of it's MR. I assume that each > > MR and HA pair has correct binding information. From Home Test, MR can > > verify packets are correctly tunneled to the neighbor MR through its HA. > > And the CoA which is updated to the HA would be correct through > > this test. > > I think i am not following this... > > I mean, the two MR are on the same nemo, and you assume that each one of > them can listen to the RAdv from each other. This basically means that MR1 > can reach the HoA of MR2 through the nemo, and it will not use the HA. For > accesing the CoA of MR2, normal routing will be used so, i guess you don't > need the HA of MR2 neither. So what binding information are you using? Even two MRs are on the same nemo, each MR can have different HA. In the multihoming issues draft, draft-ng-nemo-multihoming-issues-03, there is no assumption in case of (N, N, N) cases. And, this situation can be possible in my European train example. Each wagon has own MR and each MR has its own HA. And some MR can be part of different administrative domain. In this case, Each MR can have different HoA (I mean the different prefix). And each MR can be reachable, because most of MRs would have wireless intereface. So, even there exist no bridging router, different MR can access each other with different MNPs. > [...] > > > IMO, the preconfigured list is not always possible in some > > cases. Each MR > > can move dynamically in the mobile networks. Practical situation can be > > the European train. Each train consists of several wagons. And the wagon > > can flock and depart by their destination. Each wagon can join and leave > > dynamically. Like this example, some situations need dynamic MR > > authentication and registration. And this dynamic mechanism > > would be prefered for convenient > > network management. My assumption is MR1 could not be aware of > > the existance > > of MR2 before receiving MR2's RA message. > > I like your example, thanks. > I think that we should distinguish two issues here. I agree that the MR in > wagon 1 will need to discover the other MRs in other wagons, since the > arrangement of wagons can vary. However, i think that that doesn't mean that > they cannot have a list of authorized MR that are acceptable. I mean, alll > the wagons will belong to the train company, so the can have a preconfigured > key. > So you need a mechanism to discover which MR are available from those that > are authorized. > But this is not really the point. The point is about whether the RR check > provides valid security. I think your assumption is not always possible and it needs lots of assumption and predefined condition. And this case is not the point, as you said. > But this is not really the point. The point is about whether the RR check > provides valid security. > In the example of the train, i guess that it is not acceptable that i put my > laptop there, with a WLAN and a GPRS connection and start pretending that i > am a valid MR (who knows why i would want to do that, for instance in order > to try to redirect all the traffic to a key cracking device somewhere else > or divert the traffic to do a mitm attack) > So, how the RR check can prevent me from doing this? > If this is not the attack that the RR can prevent, please describe an attack > that the RR check can prevent > My point is your laptop also has your own HA. From the RR procedure, your CoA and HoA can be verified. These verified addresses are registered by your labtop. And your laptop can be tracable by refering its own HA. So, this process can provide non-repudiation. And our process can protect from the MR which advertises the wrong CoA like RR can protect wrong BU from MN in MIPv6. Regards, Seongho From exim@www1.ietf.org Wed May 12 21:59:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26236 for ; Wed, 12 May 2004 21:59:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO5Sr-0007hz-1h for nemo-archive@odin.ietf.org; Wed, 12 May 2004 21:56:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D1un3j029626 for nemo-archive@odin.ietf.org; Wed, 12 May 2004 21:56:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO5Pd-0006wx-TL for nemo-web-archive@optimus.ietf.org; Wed, 12 May 2004 21:53:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25947 for ; Wed, 12 May 2004 21:53:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO5Pb-0003dX-1n for nemo-web-archive@ietf.org; Wed, 12 May 2004 21:53:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO5Ol-00039H-00 for nemo-web-archive@ietf.org; Wed, 12 May 2004 21:52:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO5Np-0002eW-00 for nemo-web-archive@ietf.org; Wed, 12 May 2004 21:51:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO5GS-00052W-SU; Wed, 12 May 2004 21:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO5BF-0003sC-P5 for nemo@optimus.ietf.org; Wed, 12 May 2004 21:38:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25347 for ; Wed, 12 May 2004 21:38:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO5BD-0003oR-2V for nemo@ietf.org; Wed, 12 May 2004 21:38:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO5A7-0003Gd-00 for nemo@ietf.org; Wed, 12 May 2004 21:37:28 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BO59J-0002k3-00 for nemo@ietf.org; Wed, 12 May 2004 21:36:37 -0400 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i4D1V61u005219; Thu, 13 May 2004 10:31:06 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i4D1V5er005218; Thu, 13 May 2004 10:31:05 +0900 Date: Thu, 13 May 2004 10:31:05 +0900 From: Seongho Cho To: marcelo bagnulo Cc: nemo@ietf.org Subject: Re: [nemo] Re: Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Message-ID: <20040513103105.A2420@popeye.snu.ac.kr> References: <20040512000344.A29872@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mbagnulo@ing.uc3m.es on Wed, May 12, 2004 at 11:56:57AM +0200 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 On Wed, May 12, 2004 at 11:56:57AM +0200, marcelo bagnulo wrote: > > The RR procedure consists of Home Test and Care-of Test. So, > > what I want to > > mention was HA's Binding Cache information of it's MR. I assume that each > > MR and HA pair has correct binding information. From Home Test, MR can > > verify packets are correctly tunneled to the neighbor MR through its HA. > > And the CoA which is updated to the HA would be correct through > > this test. > > I think i am not following this... > > I mean, the two MR are on the same nemo, and you assume that each one of > them can listen to the RAdv from each other. This basically means that MR1 > can reach the HoA of MR2 through the nemo, and it will not use the HA. For > accesing the CoA of MR2, normal routing will be used so, i guess you don't > need the HA of MR2 neither. So what binding information are you using? Even two MRs are on the same nemo, each MR can have different HA. In the multihoming issues draft, draft-ng-nemo-multihoming-issues-03, there is no assumption in case of (N, N, N) cases. And, this situation can be possible in my European train example. Each wagon has own MR and each MR has its own HA. And some MR can be part of different administrative domain. In this case, Each MR can have different HoA (I mean the different prefix). And each MR can be reachable, because most of MRs would have wireless intereface. So, even there exist no bridging router, different MR can access each other with different MNPs. > [...] > > > IMO, the preconfigured list is not always possible in some > > cases. Each MR > > can move dynamically in the mobile networks. Practical situation can be > > the European train. Each train consists of several wagons. And the wagon > > can flock and depart by their destination. Each wagon can join and leave > > dynamically. Like this example, some situations need dynamic MR > > authentication and registration. And this dynamic mechanism > > would be prefered for convenient > > network management. My assumption is MR1 could not be aware of > > the existance > > of MR2 before receiving MR2's RA message. > > I like your example, thanks. > I think that we should distinguish two issues here. I agree that the MR in > wagon 1 will need to discover the other MRs in other wagons, since the > arrangement of wagons can vary. However, i think that that doesn't mean that > they cannot have a list of authorized MR that are acceptable. I mean, alll > the wagons will belong to the train company, so the can have a preconfigured > key. > So you need a mechanism to discover which MR are available from those that > are authorized. > But this is not really the point. The point is about whether the RR check > provides valid security. I think your assumption is not always possible and it needs lots of assumption and predefined condition. And this case is not the point, as you said. > But this is not really the point. The point is about whether the RR check > provides valid security. > In the example of the train, i guess that it is not acceptable that i put my > laptop there, with a WLAN and a GPRS connection and start pretending that i > am a valid MR (who knows why i would want to do that, for instance in order > to try to redirect all the traffic to a key cracking device somewhere else > or divert the traffic to do a mitm attack) > So, how the RR check can prevent me from doing this? > If this is not the attack that the RR can prevent, please describe an attack > that the RR check can prevent > My point is your laptop also has your own HA. From the RR procedure, your CoA and HoA can be verified. These verified addresses are registered by your labtop. And your laptop can be tracable by refering its own HA. So, this process can provide non-repudiation. And our process can protect from the MR which advertises the wrong CoA like RR can protect wrong BU from MN in MIPv6. Regards, Seongho From nemo-admin@ietf.org Mon May 17 09:22: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 JAA21197 for ; Mon, 17 May 2004 09:22:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi1G-0003nU-DN; Mon, 17 May 2004 09:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhsm-0002de-Vq for nemo@optimus.ietf.org; Mon, 17 May 2004 09:10:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20564 for ; Mon, 17 May 2004 09:10:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPhsl-0001qa-ED for nemo@ietf.org; Mon, 17 May 2004 09:10:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhrb-0001SP-00 for nemo@ietf.org; Mon, 17 May 2004 09:09:04 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BPhqV-0000m9-00 for nemo@ietf.org; Mon, 17 May 2004 09:07:55 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 17 May 2004 15:11:10 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4HD7Lbj009059; Mon, 17 May 2004 15:07:21 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 May 2004 14:07:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 May 2004 14:07:49 +0100 Message-ID: Thread-Topic: Announcing Tree Discovery Thread-Index: AcQ8D9dPrTMDAb5QRmiHHKJ5yGenSQ== From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 17 May 2004 13:07:50.0988 (UTC) FILETIME=[F53E18C0:01C43C0F] 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 Subject: [nemo] Announcing Tree Discovery Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi: Please note that a new draft has been published: http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-00.txt Summary: The purpose of this paper is to describe a minimum set of features that extends the Nemo basic support in order to avoid loops in the nested Nemo case. As a result, Mobile Routers assemble into a tree that can be optimized based on various metrics. NEMO basic support does not address the formation of loops as MRs attach to other MRs indiscriminately. This draft proposes a solution to that problem, primarily as a complement for NEMO basic support, as opposed to an RO solution. Nevertheless, shaping the tree optimally is critical for the forthcoming RO solution. Pascal From exim@www1.ietf.org Mon May 17 09:28: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 JAA21447 for ; Mon, 17 May 2004 09:28:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi7x-0004fy-Em for nemo-archive@odin.ietf.org; Mon, 17 May 2004 09:25:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HDPvS4017975 for nemo-archive@odin.ietf.org; Mon, 17 May 2004 09:25:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi61-0004R6-UD for nemo-web-archive@optimus.ietf.org; Mon, 17 May 2004 09:23:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21259 for ; Mon, 17 May 2004 09:23:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPi60-0006SC-9w for nemo-web-archive@ietf.org; Mon, 17 May 2004 09:23:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPi56-00067s-00 for nemo-web-archive@ietf.org; Mon, 17 May 2004 09:23:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPi42-0005mN-00 for nemo-web-archive@ietf.org; Mon, 17 May 2004 09:21:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi1G-0003nU-DN; Mon, 17 May 2004 09:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhsm-0002de-Vq for nemo@optimus.ietf.org; Mon, 17 May 2004 09:10:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20564 for ; Mon, 17 May 2004 09:10:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPhsl-0001qa-ED for nemo@ietf.org; Mon, 17 May 2004 09:10:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhrb-0001SP-00 for nemo@ietf.org; Mon, 17 May 2004 09:09:04 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BPhqV-0000m9-00 for nemo@ietf.org; Mon, 17 May 2004 09:07:55 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 17 May 2004 15:11:10 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4HD7Lbj009059; Mon, 17 May 2004 15:07:21 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 May 2004 14:07:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 May 2004 14:07:49 +0100 Message-ID: Thread-Topic: Announcing Tree Discovery Thread-Index: AcQ8D9dPrTMDAb5QRmiHHKJ5yGenSQ== From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 17 May 2004 13:07:50.0988 (UTC) FILETIME=[F53E18C0:01C43C0F] Content-Transfer-Encoding: quoted-printable Subject: [nemo] Announcing Tree Discovery Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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: Please note that a new draft has been published: http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-00.txt Summary: The purpose of this paper is to describe a minimum set of features that extends the Nemo basic support in order to avoid loops in the nested Nemo case. As a result, Mobile Routers assemble into a tree that can be optimized based on various metrics. NEMO basic support does not address the formation of loops as MRs attach to other MRs indiscriminately. This draft proposes a solution to that problem, primarily as a complement for NEMO basic support, as opposed to an RO solution. Nevertheless, shaping the tree optimally is critical for the forthcoming RO solution. Pascal From nemo-admin@ietf.org Mon May 17 10:25:03 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25223 for ; Mon, 17 May 2004 10:25:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPixL-0002ok-2V; Mon, 17 May 2004 10:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPirw-00016E-44 for nemo@optimus.ietf.org; Mon, 17 May 2004 10:13:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24273 for ; Mon, 17 May 2004 10:13:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPirt-0006mI-Sa for nemo@ietf.org; Mon, 17 May 2004 10:13:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPiqF-0006Nm-00 for nemo@ietf.org; Mon, 17 May 2004 10:11:44 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BPinr-0005Gv-00 for nemo@ietf.org; Mon, 17 May 2004 10:09:15 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4C91438035; Mon, 17 May 2004 16:08:44 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp01.uc3m.es (Postfix) with SMTP id 359D03802D; Mon, 17 May 2004 16:08:44 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Pascal Thubert (pthubert)" , Subject: RE: [nemo] Announcing Tree Discovery Date: Mon, 17 May 2004 16:04:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pascal, i have been reading the draft and i have some questions about it. Here they go... - about the clusterhead: why is it useful to include the fixed AR as the clusterhead when it is possible. I mean, this would imply that every time the nemo moves, you have to rebuild the tree. OTOH, if the clustehead is the root MR, the tree could be preserved through movement. After all, the sub MR are just MNN of the parent nemo, so they shouldn't be aware of the parent movement, right? - about the nodes and leafs of the tree. It is stated in the draft that: " The nodes of the tree are Mobile Routers, the root is either a fixed or a Mobile Router, called in the latter case the root Mobile Router in NEMO terminology [6]. The leaves are mobile or fixed hosts, called Local Fixed Nodes, Local Mobile Nodes and Visiting Mobile Nodes in the NEMO terminology." My first point here is that there is an IMHO important difference between fixed hosts and Local Fixed Nodes (and also between mobile hosts and LMN and VMN) and that is that AFAIU, MNN can be routers while fixed and mobile hosts can only be hosts (i guess) IMHO this is important in this case, because i clearly see that MR are nodes of the tree and that hosts are leaves of the tree, but what about MNN that are routers, that is a fixed router within the nemo, is this a node or a leaf of the tree? This is also relevant in the case that for instance the access router of a nemo is not a MR, for instance. If fixed router within the nemo are not part of the tree, then i am not sure how useful is this approach to fulfill the first goal stated in the draft: " One of the usage of the new option introduced in this document is to distribute information on the hierarchy of MRs. This information can be distributed to ARs, MRs and MNNs as well in order to allow better route selection and to increase the knowledge of the Nemo topology on each node." I mean the tree will not contain all the hops in the path, but only the MR in the path, so, the shortest path according the tree may not be the shortest path in terms of hops, for instance. - about the support of non-MR. I guess that by non-MR you mean fixed routers within the nemo, right? The proposed solution that uses an extension of the RA, requires that all the routers within the nemo are upgraded, right? i mean, MR are part of the tree so they need to build it, so they need to be upgraded, but non-MR also need to be upgraded, since the need to copy the option, right? Wouldn't it be possible to use other ICMP message with a broader scope so that you don't need support from non-MR? this would, IMHO, simplify adoption but it would also provide a more robust solution, since in the present proposal, if one of the router within the nemo doesn't support the protocol, this would mean that the tree information is lost and the loop prevention mechanism can fail, right? - Finally, there are several fields in the proposed TIO format that i am not sure what they are used for: The G and the H bits, the Path digest. And what is the difference of the Boottime random and the treeid? i mean why cannot be the treeid be used instead of the boottiemrandom Thanks, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Pascal > Thubert (pthubert) > Enviado el: lunes, 17 de mayo de 2004 15:08 > Para: nemo@ietf.org > Asunto: [nemo] Announcing Tree Discovery > > > Hi: > > Please note that a new draft has been published: > http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-00.txt > > Summary: > The purpose of this paper is to describe a minimum set of features > that extends the Nemo basic support in order to avoid loops in the > nested Nemo case. As a result, Mobile Routers assemble into a tree > that can be optimized based on various metrics. > > NEMO basic support does not address the formation of loops as MRs attach > to other MRs indiscriminately. This draft proposes a solution to that > problem, primarily as a complement for NEMO basic support, as opposed to > an RO solution. Nevertheless, shaping the tree optimally is critical for > the forthcoming RO solution. > > Pascal > > From exim@www1.ietf.org Mon May 17 10:36:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25859 for ; Mon, 17 May 2004 10:36:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPj8S-00053n-8n for nemo-archive@odin.ietf.org; Mon, 17 May 2004 10:30:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HEUWnL019452 for nemo-archive@odin.ietf.org; Mon, 17 May 2004 10:30:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPj4I-0004Qd-25 for nemo-web-archive@optimus.ietf.org; Mon, 17 May 2004 10:26:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25309 for ; Mon, 17 May 2004 10:26:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPj4F-0003Al-QE for nemo-web-archive@ietf.org; Mon, 17 May 2004 10:26:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPj3J-0002qh-00 for nemo-web-archive@ietf.org; Mon, 17 May 2004 10:25:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPj2g-0002Na-00 for nemo-web-archive@ietf.org; Mon, 17 May 2004 10:24:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPixL-0002ok-2V; Mon, 17 May 2004 10:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPirw-00016E-44 for nemo@optimus.ietf.org; Mon, 17 May 2004 10:13:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24273 for ; Mon, 17 May 2004 10:13:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPirt-0006mI-Sa for nemo@ietf.org; Mon, 17 May 2004 10:13:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPiqF-0006Nm-00 for nemo@ietf.org; Mon, 17 May 2004 10:11:44 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BPinr-0005Gv-00 for nemo@ietf.org; Mon, 17 May 2004 10:09:15 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4C91438035; Mon, 17 May 2004 16:08:44 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp01.uc3m.es (Postfix) with SMTP id 359D03802D; Mon, 17 May 2004 16:08:44 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Pascal Thubert (pthubert)" , Subject: RE: [nemo] Announcing Tree Discovery Date: Mon, 17 May 2004 16:04:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Pascal, i have been reading the draft and i have some questions about it. Here they go... - about the clusterhead: why is it useful to include the fixed AR as the clusterhead when it is possible. I mean, this would imply that every time the nemo moves, you have to rebuild the tree. OTOH, if the clustehead is the root MR, the tree could be preserved through movement. After all, the sub MR are just MNN of the parent nemo, so they shouldn't be aware of the parent movement, right? - about the nodes and leafs of the tree. It is stated in the draft that: " The nodes of the tree are Mobile Routers, the root is either a fixed or a Mobile Router, called in the latter case the root Mobile Router in NEMO terminology [6]. The leaves are mobile or fixed hosts, called Local Fixed Nodes, Local Mobile Nodes and Visiting Mobile Nodes in the NEMO terminology." My first point here is that there is an IMHO important difference between fixed hosts and Local Fixed Nodes (and also between mobile hosts and LMN and VMN) and that is that AFAIU, MNN can be routers while fixed and mobile hosts can only be hosts (i guess) IMHO this is important in this case, because i clearly see that MR are nodes of the tree and that hosts are leaves of the tree, but what about MNN that are routers, that is a fixed router within the nemo, is this a node or a leaf of the tree? This is also relevant in the case that for instance the access router of a nemo is not a MR, for instance. If fixed router within the nemo are not part of the tree, then i am not sure how useful is this approach to fulfill the first goal stated in the draft: " One of the usage of the new option introduced in this document is to distribute information on the hierarchy of MRs. This information can be distributed to ARs, MRs and MNNs as well in order to allow better route selection and to increase the knowledge of the Nemo topology on each node." I mean the tree will not contain all the hops in the path, but only the MR in the path, so, the shortest path according the tree may not be the shortest path in terms of hops, for instance. - about the support of non-MR. I guess that by non-MR you mean fixed routers within the nemo, right? The proposed solution that uses an extension of the RA, requires that all the routers within the nemo are upgraded, right? i mean, MR are part of the tree so they need to build it, so they need to be upgraded, but non-MR also need to be upgraded, since the need to copy the option, right? Wouldn't it be possible to use other ICMP message with a broader scope so that you don't need support from non-MR? this would, IMHO, simplify adoption but it would also provide a more robust solution, since in the present proposal, if one of the router within the nemo doesn't support the protocol, this would mean that the tree information is lost and the loop prevention mechanism can fail, right? - Finally, there are several fields in the proposed TIO format that i am not sure what they are used for: The G and the H bits, the Path digest. And what is the difference of the Boottime random and the treeid? i mean why cannot be the treeid be used instead of the boottiemrandom Thanks, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Pascal > Thubert (pthubert) > Enviado el: lunes, 17 de mayo de 2004 15:08 > Para: nemo@ietf.org > Asunto: [nemo] Announcing Tree Discovery > > > Hi: > > Please note that a new draft has been published: > http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-00.txt > > Summary: > The purpose of this paper is to describe a minimum set of features > that extends the Nemo basic support in order to avoid loops in the > nested Nemo case. As a result, Mobile Routers assemble into a tree > that can be optimized based on various metrics. > > NEMO basic support does not address the formation of loops as MRs attach > to other MRs indiscriminately. This draft proposes a solution to that > problem, primarily as a complement for NEMO basic support, as opposed to > an RO solution. Nevertheless, shaping the tree optimally is critical for > the forthcoming RO solution. > > Pascal > > From nemo-admin@ietf.org Mon May 17 11:24: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 LAA28190 for ; Mon, 17 May 2004 11:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjtM-0002dJ-Jg; Mon, 17 May 2004 11:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjq7-0002D2-CE for nemo@optimus.ietf.org; Mon, 17 May 2004 11:15:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27641 for ; Mon, 17 May 2004 11:15:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPjq6-0003zY-I2 for nemo@ietf.org; Mon, 17 May 2004 11:15:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPjof-0003fo-00 for nemo@ietf.org; Mon, 17 May 2004 11:14:10 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BPjng-00032d-00 for nemo@ietf.org; Mon, 17 May 2004 11:13:08 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 17 May 2004 17:16:24 +0200 X-BrightmailFiltered: true Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4HFBecL001417; Mon, 17 May 2004 17:12:34 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 May 2004 16:12:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Announcing Tree Discovery Date: Mon, 17 May 2004 16:12:50 +0100 Message-ID: Thread-Topic: [nemo] Announcing Tree Discovery Thread-Index: AcQ8GJ+vu+S1LGbcS3CK/VfacLer8QABBtaA From: "Pascal Thubert \(pthubert\)" To: , X-OriginalArrivalTime: 17 May 2004 15:12:51.0154 (UTC) FILETIME=[6BB09B20:01C43C21] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Marcelo=20 >=20 > - about the clusterhead: why is it useful to include the fixed AR as the > clusterhead when it is possible. I mean, this would imply that every time > the nemo moves, you have to rebuild the tree. OTOH, if the clustehead is the > root MR, the tree could be preserved through movement. After all, the sub MR > are just MNN of the parent nemo, so they shouldn't be aware of the parent > movement, right? >=20 Seems you are assuming the specific case of group mobility. If this happens, I expect that the TIO will carry a GID and that the members of the group will prefer a tree sourced at GID as one metric. In that case, the root MR may omit forwarding the TIO from AR and set itself clusterhead. This policy is allowed by the draft.=20 =20 On the other hand, it may happen that MRs move arbitrarily regarding each other, e.g. cars in a city. In that case, you may want the clusterhead to be a fixed antenna. > - about the nodes and leafs of the tree. It is stated in the draft that: > " The nodes of the tree are Mobile Routers, the root is > either a fixed or a Mobile Router, called in the latter case the root > Mobile Router in NEMO terminology [6]. The leaves are mobile or fixed > hosts, called Local Fixed Nodes, Local Mobile Nodes and Visiting > Mobile Nodes in the NEMO terminology." >=20 > My first point here is that there is an IMHO important difference between > fixed hosts and Local Fixed Nodes (and also between mobile hosts and LMN and > VMN) and that is that AFAIU, MNN can be routers while fixed and mobile hosts > can only be hosts (i guess) > IMHO this is important in this case, because i clearly see that MR are nodes > of the tree and that hosts are leaves of the tree, but what about MNN that > are routers, that is a fixed router within the nemo, is this a node or a > leaf of the tree? > This is also relevant in the case that for instance the access router of a > nemo is not a MR, for instance. >=20 > If fixed router within the nemo are not part of the tree, then i am not sure > how useful is this approach to fulfill the first goal stated in the draft: >=20 > " One of the usage of the new option introduced in this document is to > distribute information on the hierarchy of MRs. This information can > be distributed to ARs, MRs and MNNs as well in order to allow better > route selection and to increase the knowledge of the Nemo topology on > each node." >=20 > I mean the tree will not contain all the hops in the path, but only the MR > in the path, so, the shortest path according the tree may not be the > shortest path in terms of hops, for instance. >=20 Right, we have to discuss the role of local fixed nodes that are routers. A plain router like that will not know about the TIO and will drop it. In turn, it may be mistaken for a fixed AR by a roaming MR. So I guess this limits the role of such routers as stubs. This is the assumption in the draft, they are leaves. But maybe we could devise a new class of lfn routers, that would propagate TIOs... To be discussed.=20 This is not core I believe. I expect that the most desired situation is a MR attaching to an other MR, not a MR attaching to a LFN-router that is attached to an MR. > - about the support of non-MR. I guess that by non-MR you mean fixed routers > within the nemo, right? > The proposed solution that uses an extension of the RA, requires that all > the routers within the nemo are upgraded, right? i mean, MR are part of the > tree so they need to build it, so they need to be upgraded, but non-MR also > need to be upgraded, since the need to copy the option, right? Yes > Wouldn't it be possible to use other ICMP message with a broader scope so > that you don't need support from non-MR? this would, IMHO, simplify adoption > but it would also provide a more robust solution, since in the present > proposal, if one of the router within the nemo doesn't support the protocol, > this would mean that the tree information is lost and the loop prevention > mechanism can fail, right? Sure. I'm not sure how your proposal really fixes any of this but I'm interested in discussing it. As of now, LFN routers are leaves. I'm missing a use case where there's value doing otherwise. > - Finally, there are several fields in the proposed TIO format that i am not > sure what they are used for: > The G and the H bits, the Path digest. And what is the difference of the > Boottime random and the treeid? i mean why cannot be the treeid be used > instead of the boottiemrandom Boot time random is used for collision avoidance but can not be used to identify a root MR. On the other hand, the tree id is a constant so other routers may be configured to prefer that tree, referenced by ID. Path digest changes if the list above you has changed, even if the depth and tree id did not. This is useful to trigger a BU for instance. The G bit guarantees the connectivity to the infrastructure. An Algorithm that requires internet connectivity will prioritize a G bit on in AR selection. Now what the infrastructure is context dependent. Same context as that allowing the L2 access, hopefully.=20 The H bit is informational for the time being. We have to discuss if a MR with H on actually incremements the depth. But there's no practical use for it for the time being... Thanks for your comments :) Pascal=20 From exim@www1.ietf.org Mon May 17 11:39: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 LAA28952 for ; Mon, 17 May 2004 11:39:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkBo-0005HI-M0 for nemo-archive@odin.ietf.org; Mon, 17 May 2004 11:38:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HFc41E020283 for nemo-archive@odin.ietf.org; Mon, 17 May 2004 11:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPk0B-0003Nf-Mg for nemo-web-archive@optimus.ietf.org; Mon, 17 May 2004 11:26:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28259 for ; Mon, 17 May 2004 11:26:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPk0A-0007dO-QN for nemo-web-archive@ietf.org; Mon, 17 May 2004 11:26:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPjzC-0007IO-00 for nemo-web-archive@ietf.org; Mon, 17 May 2004 11:25:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPjy7-0006nL-00 for nemo-web-archive@ietf.org; Mon, 17 May 2004 11:23:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjtM-0002dJ-Jg; Mon, 17 May 2004 11:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjq7-0002D2-CE for nemo@optimus.ietf.org; Mon, 17 May 2004 11:15:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27641 for ; Mon, 17 May 2004 11:15:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPjq6-0003zY-I2 for nemo@ietf.org; Mon, 17 May 2004 11:15:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPjof-0003fo-00 for nemo@ietf.org; Mon, 17 May 2004 11:14:10 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BPjng-00032d-00 for nemo@ietf.org; Mon, 17 May 2004 11:13:08 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 17 May 2004 17:16:24 +0200 X-BrightmailFiltered: true Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4HFBecL001417; Mon, 17 May 2004 17:12:34 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 May 2004 16:12:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Announcing Tree Discovery Date: Mon, 17 May 2004 16:12:50 +0100 Message-ID: Thread-Topic: [nemo] Announcing Tree Discovery Thread-Index: AcQ8GJ+vu+S1LGbcS3CK/VfacLer8QABBtaA From: "Pascal Thubert \(pthubert\)" To: , X-OriginalArrivalTime: 17 May 2004 15:12:51.0154 (UTC) FILETIME=[6BB09B20:01C43C21] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Marcelo=20 >=20 > - about the clusterhead: why is it useful to include the fixed AR as the > clusterhead when it is possible. I mean, this would imply that every time > the nemo moves, you have to rebuild the tree. OTOH, if the clustehead is the > root MR, the tree could be preserved through movement. After all, the sub MR > are just MNN of the parent nemo, so they shouldn't be aware of the parent > movement, right? >=20 Seems you are assuming the specific case of group mobility. If this happens, I expect that the TIO will carry a GID and that the members of the group will prefer a tree sourced at GID as one metric. In that case, the root MR may omit forwarding the TIO from AR and set itself clusterhead. This policy is allowed by the draft.=20 =20 On the other hand, it may happen that MRs move arbitrarily regarding each other, e.g. cars in a city. In that case, you may want the clusterhead to be a fixed antenna. > - about the nodes and leafs of the tree. It is stated in the draft that: > " The nodes of the tree are Mobile Routers, the root is > either a fixed or a Mobile Router, called in the latter case the root > Mobile Router in NEMO terminology [6]. The leaves are mobile or fixed > hosts, called Local Fixed Nodes, Local Mobile Nodes and Visiting > Mobile Nodes in the NEMO terminology." >=20 > My first point here is that there is an IMHO important difference between > fixed hosts and Local Fixed Nodes (and also between mobile hosts and LMN and > VMN) and that is that AFAIU, MNN can be routers while fixed and mobile hosts > can only be hosts (i guess) > IMHO this is important in this case, because i clearly see that MR are nodes > of the tree and that hosts are leaves of the tree, but what about MNN that > are routers, that is a fixed router within the nemo, is this a node or a > leaf of the tree? > This is also relevant in the case that for instance the access router of a > nemo is not a MR, for instance. >=20 > If fixed router within the nemo are not part of the tree, then i am not sure > how useful is this approach to fulfill the first goal stated in the draft: >=20 > " One of the usage of the new option introduced in this document is to > distribute information on the hierarchy of MRs. This information can > be distributed to ARs, MRs and MNNs as well in order to allow better > route selection and to increase the knowledge of the Nemo topology on > each node." >=20 > I mean the tree will not contain all the hops in the path, but only the MR > in the path, so, the shortest path according the tree may not be the > shortest path in terms of hops, for instance. >=20 Right, we have to discuss the role of local fixed nodes that are routers. A plain router like that will not know about the TIO and will drop it. In turn, it may be mistaken for a fixed AR by a roaming MR. So I guess this limits the role of such routers as stubs. This is the assumption in the draft, they are leaves. But maybe we could devise a new class of lfn routers, that would propagate TIOs... To be discussed.=20 This is not core I believe. I expect that the most desired situation is a MR attaching to an other MR, not a MR attaching to a LFN-router that is attached to an MR. > - about the support of non-MR. I guess that by non-MR you mean fixed routers > within the nemo, right? > The proposed solution that uses an extension of the RA, requires that all > the routers within the nemo are upgraded, right? i mean, MR are part of the > tree so they need to build it, so they need to be upgraded, but non-MR also > need to be upgraded, since the need to copy the option, right? Yes > Wouldn't it be possible to use other ICMP message with a broader scope so > that you don't need support from non-MR? this would, IMHO, simplify adoption > but it would also provide a more robust solution, since in the present > proposal, if one of the router within the nemo doesn't support the protocol, > this would mean that the tree information is lost and the loop prevention > mechanism can fail, right? Sure. I'm not sure how your proposal really fixes any of this but I'm interested in discussing it. As of now, LFN routers are leaves. I'm missing a use case where there's value doing otherwise. > - Finally, there are several fields in the proposed TIO format that i am not > sure what they are used for: > The G and the H bits, the Path digest. And what is the difference of the > Boottime random and the treeid? i mean why cannot be the treeid be used > instead of the boottiemrandom Boot time random is used for collision avoidance but can not be used to identify a root MR. On the other hand, the tree id is a constant so other routers may be configured to prefer that tree, referenced by ID. Path digest changes if the list above you has changed, even if the depth and tree id did not. This is useful to trigger a BU for instance. The G bit guarantees the connectivity to the infrastructure. An Algorithm that requires internet connectivity will prioritize a G bit on in AR selection. Now what the infrastructure is context dependent. Same context as that allowing the L2 access, hopefully.=20 The H bit is informational for the time being. We have to discuss if a MR with H on actually incremements the depth. But there's no practical use for it for the time being... Thanks for your comments :) Pascal=20 From nemo-admin@ietf.org Mon May 17 12:20: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 MAA02345 for ; Mon, 17 May 2004 12:20:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkYz-0008Sp-8Y; Mon, 17 May 2004 12:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkTQ-0007m2-Sq for nemo@optimus.ietf.org; Mon, 17 May 2004 11:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00420 for ; Mon, 17 May 2004 11:56:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPkTP-0002Ka-KP for nemo@ietf.org; Mon, 17 May 2004 11:56:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkSM-0001zi-00 for nemo@ietf.org; Mon, 17 May 2004 11:55:11 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BPkRO-0001Lt-00 for nemo@ietf.org; Mon, 17 May 2004 11:54:10 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 4318937F01; Mon, 17 May 2004 17:53:39 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp01.uc3m.es (Postfix) with SMTP id 1B78837CA9; Mon, 17 May 2004 17:53:36 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Pascal Thubert (pthubert)" , , Subject: RE: [nemo] Announcing Tree Discovery Date: Mon, 17 May 2004 17:49:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Seems you are assuming the specific case of group mobility. If this > happens, I expect that the TIO will carry a GID and that the members of > the group will prefer a tree sourced at GID as one metric. In that case, > the root MR may omit forwarding the TIO from AR and set itself > clusterhead. This policy is allowed by the draft. Ok, i didn't read the draft that way... > > On the other hand, it may happen that MRs move arbitrarily regarding > each other, e.g. cars in a city. In that case, you may want the > clusterhead to be a fixed antenna. This is the case that i don't understand why would you want that? I mean, if the clusterhead is a fixed AR then when the nemo moves it has rebuild the tree, right? So what is the benefit of doing so? I am not saying that the draft should prevent this situation, but it seems to me that you may have considered some scenario where this configuration may be useful and provide some benefits, if this is so, could you describe it? > [...] > Right, we have to discuss the role of local fixed nodes that are > routers. A plain router like that will not know about the TIO and will > drop it. In turn, it may be mistaken for a fixed AR by a roaming MR. I an not parsing the last sentence, sorry... > So > I guess this limits the role of such routers as stubs. This is the > assumption in the draft, they are leaves. But maybe we could devise a > new class of lfn routers, that would propagate TIOs I understood that this is what it is required in order the mechanism to work, as described in section 4.2 when talking about non-MR... So just to clarify the discussion what do you mean by a non-MR in section 4.2? My concer regarding this point and the next one is how does the TD works when a router LFN exists in the nemo IMHO I guess that there are two cases here: - when a router LFN doesn't support the TD in any form - When a router LFN supports the TD According to the draft the TD has two goals,: - Loop prevention - enhanced route selection IMHO the loop prevetnion is critical, while the enhanced route selection is one of those nice-to-have features. IMHO the support when there are router LFN in the nemo would be that: - the loop prevention doesn't breaks - get as much as possible of the enhanced route selection as possible As far as is understand in its current form, the proposed TD mechanisms breaks if a router LFN that doesn't supports TD exists in the nemo, right? This is beacuse, the the non upgraded router LFN won't forward the TIO opction so, the tree discovery mechanism will be broken, right? I guess that it would be better to have a more robust TD mechanism that supports non upgraded router LFN in the nemo. This would require using some other signaling instead of using a RA option. The new signaling message shouldn't be link scoped but its scope should be the nemo. But before discusin options about how to do this, do you agree that it would be intersting that the TD mechanism can support non upgraded routers LFN? The other issue is about enahnced route selection. I am not sure that we can do much when we have to deal with non upgraded router LFN in this case, but i guess that including upgraded router LFN in the tree topology would provide more information about intermediate hosts, so the selection would be improved. So i guess that all the routers that support the TD mechanisms could be included in the tree as a form to provide more detailed information for route selection support. [...] > Boot time random is used for collision avoidance but can not be used to > identify a root MR. On the other hand, the tree id is a constant so > other routers may be configured to prefer that tree, referenced by ID. > > Path digest changes if the list above you has changed, even if the depth > and tree id did not. This is useful to trigger a BU for instance. > > The G bit guarantees the connectivity to the infrastructure. An > Algorithm that requires internet connectivity will prioritize a G bit on > in AR selection. Now what the infrastructure is context dependent. Same > context as that allowing the L2 access, hopefully. > > The H bit is informational for the time being. We have to discuss if a > MR with H on actually incremements the depth. But there's no practical > use for it for the time being... I may have missed some of this stuff, but if they are not in the draft, including them would provide clearer view of the mechanisms. > > Thanks for your comments :) My pleasure, nice draft. Regards,marcelo > > Pascal > From exim@www1.ietf.org Mon May 17 12:45:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04236 for ; Mon, 17 May 2004 12:45:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPl0F-0006Vc-Rd for nemo-archive@odin.ietf.org; Mon, 17 May 2004 12:30:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HGUBSD025021 for nemo-archive@odin.ietf.org; Mon, 17 May 2004 12:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPktE-000583-KQ for nemo-web-archive@optimus.ietf.org; Mon, 17 May 2004 12:22:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02510 for ; Mon, 17 May 2004 12:22:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPktD-0003yN-5N for nemo-web-archive@ietf.org; Mon, 17 May 2004 12:22:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkrf-0003Tk-00 for nemo-web-archive@ietf.org; Mon, 17 May 2004 12:21:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPkqc-00033a-00 for nemo-web-archive@ietf.org; Mon, 17 May 2004 12:20:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkYz-0008Sp-8Y; Mon, 17 May 2004 12:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkTQ-0007m2-Sq for nemo@optimus.ietf.org; Mon, 17 May 2004 11:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00420 for ; Mon, 17 May 2004 11:56:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPkTP-0002Ka-KP for nemo@ietf.org; Mon, 17 May 2004 11:56:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkSM-0001zi-00 for nemo@ietf.org; Mon, 17 May 2004 11:55:11 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BPkRO-0001Lt-00 for nemo@ietf.org; Mon, 17 May 2004 11:54:10 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 4318937F01; Mon, 17 May 2004 17:53:39 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.58]) by smtp01.uc3m.es (Postfix) with SMTP id 1B78837CA9; Mon, 17 May 2004 17:53:36 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Pascal Thubert (pthubert)" , , Subject: RE: [nemo] Announcing Tree Discovery Date: Mon, 17 May 2004 17:49:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 > Seems you are assuming the specific case of group mobility. If this > happens, I expect that the TIO will carry a GID and that the members of > the group will prefer a tree sourced at GID as one metric. In that case, > the root MR may omit forwarding the TIO from AR and set itself > clusterhead. This policy is allowed by the draft. Ok, i didn't read the draft that way... > > On the other hand, it may happen that MRs move arbitrarily regarding > each other, e.g. cars in a city. In that case, you may want the > clusterhead to be a fixed antenna. This is the case that i don't understand why would you want that? I mean, if the clusterhead is a fixed AR then when the nemo moves it has rebuild the tree, right? So what is the benefit of doing so? I am not saying that the draft should prevent this situation, but it seems to me that you may have considered some scenario where this configuration may be useful and provide some benefits, if this is so, could you describe it? > [...] > Right, we have to discuss the role of local fixed nodes that are > routers. A plain router like that will not know about the TIO and will > drop it. In turn, it may be mistaken for a fixed AR by a roaming MR. I an not parsing the last sentence, sorry... > So > I guess this limits the role of such routers as stubs. This is the > assumption in the draft, they are leaves. But maybe we could devise a > new class of lfn routers, that would propagate TIOs I understood that this is what it is required in order the mechanism to work, as described in section 4.2 when talking about non-MR... So just to clarify the discussion what do you mean by a non-MR in section 4.2? My concer regarding this point and the next one is how does the TD works when a router LFN exists in the nemo IMHO I guess that there are two cases here: - when a router LFN doesn't support the TD in any form - When a router LFN supports the TD According to the draft the TD has two goals,: - Loop prevention - enhanced route selection IMHO the loop prevetnion is critical, while the enhanced route selection is one of those nice-to-have features. IMHO the support when there are router LFN in the nemo would be that: - the loop prevention doesn't breaks - get as much as possible of the enhanced route selection as possible As far as is understand in its current form, the proposed TD mechanisms breaks if a router LFN that doesn't supports TD exists in the nemo, right? This is beacuse, the the non upgraded router LFN won't forward the TIO opction so, the tree discovery mechanism will be broken, right? I guess that it would be better to have a more robust TD mechanism that supports non upgraded router LFN in the nemo. This would require using some other signaling instead of using a RA option. The new signaling message shouldn't be link scoped but its scope should be the nemo. But before discusin options about how to do this, do you agree that it would be intersting that the TD mechanism can support non upgraded routers LFN? The other issue is about enahnced route selection. I am not sure that we can do much when we have to deal with non upgraded router LFN in this case, but i guess that including upgraded router LFN in the tree topology would provide more information about intermediate hosts, so the selection would be improved. So i guess that all the routers that support the TD mechanisms could be included in the tree as a form to provide more detailed information for route selection support. [...] > Boot time random is used for collision avoidance but can not be used to > identify a root MR. On the other hand, the tree id is a constant so > other routers may be configured to prefer that tree, referenced by ID. > > Path digest changes if the list above you has changed, even if the depth > and tree id did not. This is useful to trigger a BU for instance. > > The G bit guarantees the connectivity to the infrastructure. An > Algorithm that requires internet connectivity will prioritize a G bit on > in AR selection. Now what the infrastructure is context dependent. Same > context as that allowing the L2 access, hopefully. > > The H bit is informational for the time being. We have to discuss if a > MR with H on actually incremements the depth. But there's no practical > use for it for the time being... I may have missed some of this stuff, but if they are not in the draft, including them would provide clearer view of the mechanisms. > > Thanks for your comments :) My pleasure, nice draft. Regards,marcelo > > Pascal > From nemo-admin@ietf.org Tue May 18 03:57:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22188 for ; Tue, 18 May 2004 03:57:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzON-0002yz-1b; Tue, 18 May 2004 03:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzLc-0002gn-0L for nemo@optimus.ietf.org; Tue, 18 May 2004 03:49:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21806 for ; Tue, 18 May 2004 03:49:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzLZ-0005Ba-GG for nemo@ietf.org; Tue, 18 May 2004 03:49:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzKW-0004lk-00 for nemo@ietf.org; Tue, 18 May 2004 03:48:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BPzJp-0004LX-00 for nemo@ietf.org; Tue, 18 May 2004 03:47:22 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 May 2004 09:50:52 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4I7klbl029908; Tue, 18 May 2004 09:46:49 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 May 2004 08:47:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Announcing Tree Discovery Date: Tue, 18 May 2004 08:47:18 +0100 Message-ID: Thread-Topic: [nemo] Announcing Tree Discovery Thread-Index: AcQ8J0XyZyB7RRhwQ2uKJti2HfJq0wAfHwNg From: "Pascal Thubert \(pthubert\)" To: , X-OriginalArrivalTime: 18 May 2004 07:47:19.0520 (UTC) FILETIME=[58CEB600:01C43CAC] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] > Sent: lundi 17 mai 2004 17:49 > To: Pascal Thubert (pthubert); mbagnulo@ing.uc3m.es; nemo@ietf.org > Subject: RE: [nemo] Announcing Tree Discovery >=20 >=20 > > Seems you are assuming the specific case of group mobility. If this > > happens, I expect that the TIO will carry a GID and that the members of > > the group will prefer a tree sourced at GID as one metric. In that case, > > the root MR may omit forwarding the TIO from AR and set itself > > clusterhead. This policy is allowed by the draft. >=20 > Ok, i didn't read the draft that way... Actually you're right,=20 the draft is not too clear about that. I have to fix it. Any router can be clusterhead if it finds that the available clusters are not good enough. And if a root MR has internet connectivity to an AR, it can forward packets to the infrastructure. I hope that this much is clear enough. But you are right that a MR can not be clusterhead and then attach anywhere in a tree without joining that tree, otherwise it would create loops. The only case where it's valid for sure is when the clusterhead attaches to a fixed AR, whether that fixed AR advertises itself as clusterhead or not. This needs additional wording. Thanks :) >=20 > > > > On the other hand, it may happen that MRs move arbitrarily regarding > > each other, e.g. cars in a city. In that case, you may want the > > clusterhead to be a fixed antenna. >=20 > This is the case that i don't understand why would you want that? > I mean, if the clusterhead is a fixed AR then when the nemo moves it has > rebuild the tree, right? > So what is the benefit of doing so? I am not saying that the draft should > prevent this situation, but it seems to me that you may have considered some > scenario where this configuration may be useful and provide some benefits, > if this is so, could you describe it? >=20 In fact, yes, very much so. Some is related to RO but I do not want such discussions to cloud tree discovery and make it look like it's an RO feature, since it's required for nemo basic, imho. The classical use case is cars in a city. Cars do not move as a group, so if a car drags a tree, the other (not necessarily moving) cars will have to jump all the time. Having a fixed AR as clusterhead stabilizes the situation and enables parked cars to relay for moving ones. As for RO, once a tree is built around a fixed antenna, you may use the antenna for Local mobility management. For instance, a fixed clusterhead is ideally placed to be the DHCP-PD + Home Agent in our nemo LMM draft http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt . Finally, a car may stay for a while in a radius around a few blocks, even if the immediate vicinity with other cars changes rapidly. So a car may be able to stay within the same tree if that tree is based on a fixed antenna; this enables all sorts of routing, within the tree and between clusterheads. In fact, this is why I call these clusterheads in the first . > > > [...] >=20 > > Right, we have to discuss the role of local fixed nodes that are > > routers. A plain router like that will not know about the TIO and will > > drop it. In turn, it may be mistaken for a fixed AR by a roaming MR. >=20 > I an not parsing the last sentence, sorry... Just acknowledging your words. A legacy router will be mistaken for a fixed router even if it is permanently attached to a MR and moving with it. So I guess a roaming MR should always prefer an Attachment Router with TIO, be it fixed or mobile. But in order to prevent loops, it is also recommended that legacy MR be configured not to accept roaming MRs, what can we do, right? >=20 > > So > > I guess this limits the role of such routers as stubs. This is the > > assumption in the draft, they are leaves. But maybe we could devise a > > new class of lfn routers, that would propagate TIOs >=20 > I understood that this is what it is required in order the mechanism to > work, as described in section 4.2 when talking about non-MR... So just to > clarify the discussion what do you mean by a non-MR in section 4.2? >=20 > My concer regarding this point and the next one is how does the TD works > when a router LFN exists in the nemo Understood and agreed with the concern, though I saw it as secondary for the lack of use cases. This is one discussion where help from the group would be appreciated. We already simulated that draft, and actually that was a concern. We ended up moving the TIO support from a MR feature to a ND optional feature for all routers. It may be harder to move it to IETF that way, though. =20 The same question arises for a MR that is at home in a tree. Should it propagate TIO? Should it increase the depth? We started with no for both and ended up with yes for both. Really we have to weight this as a group and make a decision. >=20 > IMHO I guess that there are two cases here: >=20 > - when a router LFN doesn't support the TD in any form > - When a router LFN supports the TD >=20 and when a MR is at home in a tree (mobile home stuff) as a third > According to the draft the TD has two goals,: > - Loop prevention > - enhanced route selection >=20 > IMHO the loop prevetnion is critical, while the enhanced route selection is > one of those nice-to-have features. Yes Actually we try to avoid the enhanced thing. We intend to present just the mere common part, not a specific route selection. We have a number of algorithms for various use cases. One is cars (again) where all you want is minimizing the depth with optionally some stickiness to a given antenna, one is the fleet where the infrastructure connectivity is secondary, but you want a managed tree (thus the preference), an other one is a group of tourist where a group ID is critical... But all those need to share the core presented in the draft. >=20 > IMHO the support when there are router LFN in the nemo would be that: >=20 > - the loop prevention doesn't breaks > - get as much as possible of the enhanced route selection as possible cool > As far as is understand in its current form, the proposed TD mechanisms > breaks if a router LFN that doesn't supports TD exists in the nemo, right?=20 > This is beacuse, the the non upgraded router LFN won't forward the TIO > opction so, the tree discovery mechanism will be broken, right? Well, they are supposed to reject visitors (eg no RA or M bit), otherwise yes, exactly. >=20 > I guess that it would be better to have a more robust TD mechanism that > supports non upgraded router LFN in the nemo. This would require using some > other signaling instead of using a RA option. The new signaling message > shouldn't be link scoped but its scope should be the nemo. Not too easy to do. And remember you want to be damn quick and efficient. Sometimes, an apparent beauty results in a living nightmare. My proposal is to leave those as leaves and see what we can do for case 2 (LFN Router with TD) and 3 (MR at home within tree). > But before discusin options about how to do this, do you agree that it would > be intersting that the TD mechanism can support non upgraded routers LFN? Not really. Being a MR is pretty cool. Can add features like RO to the picture. Again I need a convincing use case. TD builds the tree dynamically and is you support RRH, you can source route down that tree. TD on MRs (even more with an RO solution like RRH in place) results in a pretty efficient feature and I would definitely enable MR on all boxes in a roaming cloud. >=20 > The other issue is about enahnced route selection. > I am not sure that we can do much when we have to deal with non upgraded > router LFN in this case, but i guess that including upgraded router LFN in > the tree topology would provide more information about intermediate hosts, > so the selection would be improved. So i guess that all the routers that > support the TD mechanisms could be included in the tree as a form to provide > more detailed information for route selection support. Yes, this seems reasonable and we have to figure that out. I believe we should concentrate on that case as opposed to legacy LFN routers. If we do so, again, this impacts all routers, making it harder to move forward at IETF... >=20 > [...] >=20 > > Boot time random is used for collision avoidance but can not be used to > > identify a root MR. On the other hand, the tree id is a constant so > > other routers may be configured to prefer that tree, referenced by ID. > > > > Path digest changes if the list above you has changed, even if the depth > > and tree id did not. This is useful to trigger a BU for instance. > > > > The G bit guarantees the connectivity to the infrastructure. An > > Algorithm that requires internet connectivity will prioritize a G bit on > > in AR selection. Now what the infrastructure is context dependent. Same > > context as that allowing the L2 access, hopefully. > > > > The H bit is informational for the time being. We have to discuss if a > > MR with H on actually incremements the depth. But there's no practical > > use for it for the time being... >=20 > I may have missed some of this stuff, but if they are not in the draft, > including them would provide clearer view of the mechanisms. Well, chapter 5 explains the collision stuff. In particular 5.3.3 gives you the extended preference stuff based on the Boot time random. This seems almost impossible in real life but it is the first thing you get in a simulation :) > My pleasure, nice draft. :) Pascal From exim@www1.ietf.org Tue May 18 04:16:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22899 for ; Tue, 18 May 2004 04:16:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzay-0005wg-Rs for nemo-archive@odin.ietf.org; Tue, 18 May 2004 04:05:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I8548P022851 for nemo-archive@odin.ietf.org; Tue, 18 May 2004 04:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzV3-0004if-CO for nemo-web-archive@optimus.ietf.org; Tue, 18 May 2004 03:58:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22285 for ; Tue, 18 May 2004 03:58:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzV0-0001NL-RE for nemo-web-archive@ietf.org; Tue, 18 May 2004 03:58:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzU4-0000zM-00 for nemo-web-archive@ietf.org; Tue, 18 May 2004 03:57:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPzTM-0000ba-00 for nemo-web-archive@ietf.org; Tue, 18 May 2004 03:57:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzON-0002yz-1b; Tue, 18 May 2004 03:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzLc-0002gn-0L for nemo@optimus.ietf.org; Tue, 18 May 2004 03:49:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21806 for ; Tue, 18 May 2004 03:49:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzLZ-0005Ba-GG for nemo@ietf.org; Tue, 18 May 2004 03:49:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzKW-0004lk-00 for nemo@ietf.org; Tue, 18 May 2004 03:48:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BPzJp-0004LX-00 for nemo@ietf.org; Tue, 18 May 2004 03:47:22 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 May 2004 09:50:52 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4I7klbl029908; Tue, 18 May 2004 09:46:49 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 May 2004 08:47:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Announcing Tree Discovery Date: Tue, 18 May 2004 08:47:18 +0100 Message-ID: Thread-Topic: [nemo] Announcing Tree Discovery Thread-Index: AcQ8J0XyZyB7RRhwQ2uKJti2HfJq0wAfHwNg From: "Pascal Thubert \(pthubert\)" To: , X-OriginalArrivalTime: 18 May 2004 07:47:19.0520 (UTC) FILETIME=[58CEB600:01C43CAC] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 > -----Original Message----- > From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] > Sent: lundi 17 mai 2004 17:49 > To: Pascal Thubert (pthubert); mbagnulo@ing.uc3m.es; nemo@ietf.org > Subject: RE: [nemo] Announcing Tree Discovery >=20 >=20 > > Seems you are assuming the specific case of group mobility. If this > > happens, I expect that the TIO will carry a GID and that the members of > > the group will prefer a tree sourced at GID as one metric. In that case, > > the root MR may omit forwarding the TIO from AR and set itself > > clusterhead. This policy is allowed by the draft. >=20 > Ok, i didn't read the draft that way... Actually you're right,=20 the draft is not too clear about that. I have to fix it. Any router can be clusterhead if it finds that the available clusters are not good enough. And if a root MR has internet connectivity to an AR, it can forward packets to the infrastructure. I hope that this much is clear enough. But you are right that a MR can not be clusterhead and then attach anywhere in a tree without joining that tree, otherwise it would create loops. The only case where it's valid for sure is when the clusterhead attaches to a fixed AR, whether that fixed AR advertises itself as clusterhead or not. This needs additional wording. Thanks :) >=20 > > > > On the other hand, it may happen that MRs move arbitrarily regarding > > each other, e.g. cars in a city. In that case, you may want the > > clusterhead to be a fixed antenna. >=20 > This is the case that i don't understand why would you want that? > I mean, if the clusterhead is a fixed AR then when the nemo moves it has > rebuild the tree, right? > So what is the benefit of doing so? I am not saying that the draft should > prevent this situation, but it seems to me that you may have considered some > scenario where this configuration may be useful and provide some benefits, > if this is so, could you describe it? >=20 In fact, yes, very much so. Some is related to RO but I do not want such discussions to cloud tree discovery and make it look like it's an RO feature, since it's required for nemo basic, imho. The classical use case is cars in a city. Cars do not move as a group, so if a car drags a tree, the other (not necessarily moving) cars will have to jump all the time. Having a fixed AR as clusterhead stabilizes the situation and enables parked cars to relay for moving ones. As for RO, once a tree is built around a fixed antenna, you may use the antenna for Local mobility management. For instance, a fixed clusterhead is ideally placed to be the DHCP-PD + Home Agent in our nemo LMM draft http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt . Finally, a car may stay for a while in a radius around a few blocks, even if the immediate vicinity with other cars changes rapidly. So a car may be able to stay within the same tree if that tree is based on a fixed antenna; this enables all sorts of routing, within the tree and between clusterheads. In fact, this is why I call these clusterheads in the first . > > > [...] >=20 > > Right, we have to discuss the role of local fixed nodes that are > > routers. A plain router like that will not know about the TIO and will > > drop it. In turn, it may be mistaken for a fixed AR by a roaming MR. >=20 > I an not parsing the last sentence, sorry... Just acknowledging your words. A legacy router will be mistaken for a fixed router even if it is permanently attached to a MR and moving with it. So I guess a roaming MR should always prefer an Attachment Router with TIO, be it fixed or mobile. But in order to prevent loops, it is also recommended that legacy MR be configured not to accept roaming MRs, what can we do, right? >=20 > > So > > I guess this limits the role of such routers as stubs. This is the > > assumption in the draft, they are leaves. But maybe we could devise a > > new class of lfn routers, that would propagate TIOs >=20 > I understood that this is what it is required in order the mechanism to > work, as described in section 4.2 when talking about non-MR... So just to > clarify the discussion what do you mean by a non-MR in section 4.2? >=20 > My concer regarding this point and the next one is how does the TD works > when a router LFN exists in the nemo Understood and agreed with the concern, though I saw it as secondary for the lack of use cases. This is one discussion where help from the group would be appreciated. We already simulated that draft, and actually that was a concern. We ended up moving the TIO support from a MR feature to a ND optional feature for all routers. It may be harder to move it to IETF that way, though. =20 The same question arises for a MR that is at home in a tree. Should it propagate TIO? Should it increase the depth? We started with no for both and ended up with yes for both. Really we have to weight this as a group and make a decision. >=20 > IMHO I guess that there are two cases here: >=20 > - when a router LFN doesn't support the TD in any form > - When a router LFN supports the TD >=20 and when a MR is at home in a tree (mobile home stuff) as a third > According to the draft the TD has two goals,: > - Loop prevention > - enhanced route selection >=20 > IMHO the loop prevetnion is critical, while the enhanced route selection is > one of those nice-to-have features. Yes Actually we try to avoid the enhanced thing. We intend to present just the mere common part, not a specific route selection. We have a number of algorithms for various use cases. One is cars (again) where all you want is minimizing the depth with optionally some stickiness to a given antenna, one is the fleet where the infrastructure connectivity is secondary, but you want a managed tree (thus the preference), an other one is a group of tourist where a group ID is critical... But all those need to share the core presented in the draft. >=20 > IMHO the support when there are router LFN in the nemo would be that: >=20 > - the loop prevention doesn't breaks > - get as much as possible of the enhanced route selection as possible cool > As far as is understand in its current form, the proposed TD mechanisms > breaks if a router LFN that doesn't supports TD exists in the nemo, right?=20 > This is beacuse, the the non upgraded router LFN won't forward the TIO > opction so, the tree discovery mechanism will be broken, right? Well, they are supposed to reject visitors (eg no RA or M bit), otherwise yes, exactly. >=20 > I guess that it would be better to have a more robust TD mechanism that > supports non upgraded router LFN in the nemo. This would require using some > other signaling instead of using a RA option. The new signaling message > shouldn't be link scoped but its scope should be the nemo. Not too easy to do. And remember you want to be damn quick and efficient. Sometimes, an apparent beauty results in a living nightmare. My proposal is to leave those as leaves and see what we can do for case 2 (LFN Router with TD) and 3 (MR at home within tree). > But before discusin options about how to do this, do you agree that it would > be intersting that the TD mechanism can support non upgraded routers LFN? Not really. Being a MR is pretty cool. Can add features like RO to the picture. Again I need a convincing use case. TD builds the tree dynamically and is you support RRH, you can source route down that tree. TD on MRs (even more with an RO solution like RRH in place) results in a pretty efficient feature and I would definitely enable MR on all boxes in a roaming cloud. >=20 > The other issue is about enahnced route selection. > I am not sure that we can do much when we have to deal with non upgraded > router LFN in this case, but i guess that including upgraded router LFN in > the tree topology would provide more information about intermediate hosts, > so the selection would be improved. So i guess that all the routers that > support the TD mechanisms could be included in the tree as a form to provide > more detailed information for route selection support. Yes, this seems reasonable and we have to figure that out. I believe we should concentrate on that case as opposed to legacy LFN routers. If we do so, again, this impacts all routers, making it harder to move forward at IETF... >=20 > [...] >=20 > > Boot time random is used for collision avoidance but can not be used to > > identify a root MR. On the other hand, the tree id is a constant so > > other routers may be configured to prefer that tree, referenced by ID. > > > > Path digest changes if the list above you has changed, even if the depth > > and tree id did not. This is useful to trigger a BU for instance. > > > > The G bit guarantees the connectivity to the infrastructure. An > > Algorithm that requires internet connectivity will prioritize a G bit on > > in AR selection. Now what the infrastructure is context dependent. Same > > context as that allowing the L2 access, hopefully. > > > > The H bit is informational for the time being. We have to discuss if a > > MR with H on actually incremements the depth. But there's no practical > > use for it for the time being... >=20 > I may have missed some of this stuff, but if they are not in the draft, > including them would provide clearer view of the mechanisms. Well, chapter 5 explains the collision stuff. In particular 5.3.3 gives you the extended preference stuff based on the Boot time random. This seems almost impossible in real life but it is the first thing you get in a simulation :) > My pleasure, nice draft. :) Pascal From nemo-admin@ietf.org Tue May 18 13:20: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 NAA28593 for ; Tue, 18 May 2004 13:20:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ80Y-0006FH-Hs; Tue, 18 May 2004 13:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7wh-00057x-DY for nemo@optimus.ietf.org; Tue, 18 May 2004 13:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27384 for ; Tue, 18 May 2004 13:00:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ7wf-0007Cr-NX for nemo@ietf.org; Tue, 18 May 2004 13:00:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ7vr-0007AX-00 for nemo@ietf.org; Tue, 18 May 2004 12:59:12 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BQ7vD-000758-00 for nemo@ietf.org; Tue, 18 May 2004 12:58:31 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 58E79381A8; Tue, 18 May 2004 18:58:00 +0200 (CEST) Received: from [163.117.139.233] (dummyhost0.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 2934138181; Tue, 18 May 2004 18:58:00 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <820FC54B-A8EC-11D8-B001-000D93ACD0FE@ing.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: From: marcelo bagnulo braun Subject: Re: [nemo] Announcing Tree Discovery Date: Tue, 18 May 2004 18:57:55 +0200 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.613) 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable El 18/05/2004, a las 9:47, Pascal Thubert (pthubert) escribi=F3: [...] > In fact, yes, very much so. Some is related to RO but I do not want=20 > such > discussions to cloud tree discovery and make it look like it's an RO > feature, since it's required for nemo basic, imho. > > The classical use case is cars in a city. Cars do not move as a group, > so if a car drags a tree, the other (not necessarily moving) cars will > have to jump all the time. Having a fixed AR as clusterhead stabilizes > the situation and enables parked cars to relay for moving ones. > > As for RO, once a tree is built around a fixed antenna, you may use = the > antenna for Local mobility management. For instance, a fixed=20 > clusterhead > is ideally placed to be the DHCP-PD + Home Agent in our nemo LMM draft > http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt = . > > Finally, a car may stay for a while in a radius around a few blocks, > even if the immediate vicinity with other cars changes rapidly. So a=20= > car > may be able to stay within the same tree if that tree is based on a > fixed antenna; this enables all sorts of routing, within the tree and > between clusterheads. In fact, this is why I call these clusterheads = in > the first . > Ok, in this case about cars, you are assuming that car A and car B have=20= nemos within them and that car A is sort of providing transit for Car=20 B=B4s nemo, i.e. the car A=B4s nemo is the parent nemo and car B=B4s = nemo is=20 the sub nemo, so car B=B4s nemo attaches to car A=B4s nemo. If this is = so,=20 my question is why do you consider that this is a possible scenario, i=20= mean why car A would accept car B as a sub nemo? this would be a sort=20 of mobile ISP, but i fail to see why this would be possible... >>> >> [...] >> >>> Right, we have to discuss the role of local fixed nodes that are >>> routers. A plain router like that will not know about the TIO and > will >>> drop it. In turn, it may be mistaken for a fixed AR by a roaming MR. >> >> I an not parsing the last sentence, sorry... > Just acknowledging your words. A legacy router will be mistaken for a > fixed router even if it is permanently attached to a MR and moving = with > it. So I guess a roaming MR should always prefer an Attachment Router > with TIO, be it fixed or mobile. But in order to prevent loops, it is > also recommended that legacy MR be configured not to accept roaming=20 > MRs, > what can we do, right? IMHO it would be reasonable to assume that all MR support the TD=20 mechanism, and also that AR within the nemo also support the TD=20 mechanism. However, i am not so sure that it would be reasonable to assume that=20 all the router LFN support the the TD mechanism. IMHO, both the MR and the AR within the nemo are devices closely=20 related with mobility support so i guess that it is reasonable to=20 assume that the have proper mobility support. OTOH, router LFN may not=20= even be aware of movement. An example of this case for me would be a=20 train. In this case, i would say that a possible configuration is that=20= there is one MR in the train and then there are some router LFNs inside=20= the train between different links inside the train. I guess that it=20 would be beneficial if those routers could be just regular routers and=20= that the special support is only required in the MR and possible AR. [...] >> My concer regarding this point and the next one is how does the TD > works >> when a router LFN exists in the nemo > > Understood and agreed with the concern, though I saw it as secondary=20= > for > the lack of use cases. > > This is one discussion where help from the group would be appreciated. > We already simulated that draft, and actually that was a concern. We > ended up moving the TIO support from a MR feature to a ND optional > feature for all routers. It may be harder to move it to IETF that way, > though. > > The same question arises for a MR that is at home in a tree. Should it > propagate TIO? nice question... IMHO when the nemo is at home, the AR within that nemo are AR belonging=20= to the fixed infrastructure, so according to this rule this would imply=20= that each AR of the nemo that is at home should be a clusterhead on its=20= own, right? But what happens when the nemo moves? in this case, the MR of the nemo=20= will become the clusterhead, and the AR within the nemo should announce=20= the tree of the mr and not their own, which is reasonable since they=20 are no longer a AR of the fixed infrastructure. I would say that i prefer the first option, since the AR within a nemo=20= probably is not as good as a fixed AR in any case, so this is reflected=20= in the tree depth in the TIO [...] >> According to the draft the TD has two goals,: >> - Loop prevention >> - enhanced route selection >> >> IMHO the loop prevetnion is critical, while the enhanced route > selection is >> one of those nice-to-have features. > Yes > > Actually we try to avoid the enhanced thing. I agree with you. the critical stuff is the loop prevention. However, IMHO this is not really reflected in the draft considering=20 that the first point in the motivation section is related to route=20 selection and the loop detection is the second one. I would suggest that you put the loop prevention as the first=20 motivation and then explicitly state that route selection is just a=20 plus, nice to have feature (perhaps put it in a separate section?) [...] >> >> I guess that it would be better to have a more robust TD mechanism > that >> supports non upgraded router LFN in the nemo. This would require = using > some >> other signaling instead of using a RA option. The new signaling > message >> shouldn't be link scoped but its scope should be the nemo. > Not too easy to do. agree > And remember you want to be damn quick and > efficient. Sometimes, an apparent beauty results in a living = nightmare. > My proposal is to leave those as leaves and see what we can do for = case > 2 (LFN Router with TD) and 3 (MR at home within tree). > Well, basically what is needed here is a mechanism to communicate with=20= all the MR of a nemo. I would assume, as i mentioned earlier that all the MR and all the AR=20 within the nemo support the TD mechanism. The problem then is how to=20 allow a communication between all those devices when maybe there are=20 some devices between that don=B4t support the TD mechanism. Using RAdv doesn=B4t solve this problem since the non upgraded=20 intermediate router will not propagate the TIO. I guess that an option could be to use site scoped multicast for this=20 i.e. use messages that are sent to the all router multicast address=20 with a site scope. In this way, if multicast is supported in the site,=20= it would work even if intermediate routers don't understand the TD=20 mechanism. Note that this option would at least work as good as the RAdv option,=20 since, at least all the routers directly connected in the link will=20 receive the message, and if multicast routing is available, routers in=20= other links will also receive it. Upgraded routers would also forward=20 the messages. Moreover, there is no need of upgrading the routers LFN,=20= just turn on multicast routing for this multicast group. since it is assumed that MR and AR within the nemo support the TD,=20 intra nemo multicast routing is required, and not inter nemo multicast=20= routing is required. >> But before discusin options about how to do this, do you agree that = it > would >> be intersting that the TD mechanism can support non upgraded routers > LFN? > Not really. Being a MR is pretty cool. Can add features like RO to the > picture. MR and AR within the nemo are required to support it, agree. My concern is about the robustness of the TD mechanism, w.r.t. non=20 upgraded devices in the path > Again I need a convincing use case. Do you think it is reasonable that nemos may have legacy routers within=20= or you assume that all routers within the nemo will be upgraded? > TD builds the tree > dynamically and is you support RRH, you can source route down that=20 > tree. > TD on MRs (even more with an RO solution like RRH in place) results in=20= > a > pretty efficient feature and I would definitely enable MR on all boxes > in a roaming cloud. Yes but you are assuming that will be able to do so, what about legacy=20= routers? you just won't be able to use them within a nemo? > >> >> The other issue is about enahnced route selection. >> I am not sure that we can do much when we have to deal with non > upgraded >> router LFN in this case, but i guess that including upgraded router > LFN in >> the tree topology would provide more information about intermediate > hosts, >> so the selection would be improved. So i guess that all the routers > that >> support the TD mechanisms could be included in the tree as a form to > provide >> more detailed information for route selection support. > Yes, this seems reasonable and we have to figure that out. I believe = we > should concentrate on that case as opposed to legacy LFN routers. If = we > do so, again, this impacts all routers, making it harder to move=20 > forward > at IETF... > Well, adding all the routers that support the TD to the tree shouldn't=20= be a problem, i guess regards, marcelo > > Pascal > From exim@www1.ietf.org Tue May 18 13:36:22 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 NAA29653 for ; Tue, 18 May 2004 13:36:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8Qv-0004mk-SQ for nemo-archive@odin.ietf.org; Tue, 18 May 2004 13:31:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IHVHpK018394 for nemo-archive@odin.ietf.org; Tue, 18 May 2004 13:31:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8HF-0002cI-Ty for nemo-web-archive@optimus.ietf.org; Tue, 18 May 2004 13:21:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28739 for ; Tue, 18 May 2004 13:21:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8HD-0000ot-Vq for nemo-web-archive@ietf.org; Tue, 18 May 2004 13:21:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8GL-0000l1-00 for nemo-web-archive@ietf.org; Tue, 18 May 2004 13:20:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ8Fo-0000gt-00 for nemo-web-archive@ietf.org; Tue, 18 May 2004 13:19:48 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQ8Fo-0008RD-8m for nemo-web-archive@ietf.org; Tue, 18 May 2004 13:19:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ80Y-0006FH-Hs; Tue, 18 May 2004 13:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7wh-00057x-DY for nemo@optimus.ietf.org; Tue, 18 May 2004 13:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27384 for ; Tue, 18 May 2004 13:00:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ7wf-0007Cr-NX for nemo@ietf.org; Tue, 18 May 2004 13:00:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ7vr-0007AX-00 for nemo@ietf.org; Tue, 18 May 2004 12:59:12 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BQ7vD-000758-00 for nemo@ietf.org; Tue, 18 May 2004 12:58:31 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 58E79381A8; Tue, 18 May 2004 18:58:00 +0200 (CEST) Received: from [163.117.139.233] (dummyhost0.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 2934138181; Tue, 18 May 2004 18:58:00 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <820FC54B-A8EC-11D8-B001-000D93ACD0FE@ing.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: From: marcelo bagnulo braun Subject: Re: [nemo] Announcing Tree Discovery Date: Tue, 18 May 2004 18:57:55 +0200 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 El 18/05/2004, a las 9:47, Pascal Thubert (pthubert) escribi=F3: [...] > In fact, yes, very much so. Some is related to RO but I do not want=20 > such > discussions to cloud tree discovery and make it look like it's an RO > feature, since it's required for nemo basic, imho. > > The classical use case is cars in a city. Cars do not move as a group, > so if a car drags a tree, the other (not necessarily moving) cars will > have to jump all the time. Having a fixed AR as clusterhead stabilizes > the situation and enables parked cars to relay for moving ones. > > As for RO, once a tree is built around a fixed antenna, you may use = the > antenna for Local mobility management. For instance, a fixed=20 > clusterhead > is ideally placed to be the DHCP-PD + Home Agent in our nemo LMM draft > http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt = . > > Finally, a car may stay for a while in a radius around a few blocks, > even if the immediate vicinity with other cars changes rapidly. So a=20= > car > may be able to stay within the same tree if that tree is based on a > fixed antenna; this enables all sorts of routing, within the tree and > between clusterheads. In fact, this is why I call these clusterheads = in > the first . > Ok, in this case about cars, you are assuming that car A and car B have=20= nemos within them and that car A is sort of providing transit for Car=20 B=B4s nemo, i.e. the car A=B4s nemo is the parent nemo and car B=B4s = nemo is=20 the sub nemo, so car B=B4s nemo attaches to car A=B4s nemo. If this is = so,=20 my question is why do you consider that this is a possible scenario, i=20= mean why car A would accept car B as a sub nemo? this would be a sort=20 of mobile ISP, but i fail to see why this would be possible... >>> >> [...] >> >>> Right, we have to discuss the role of local fixed nodes that are >>> routers. A plain router like that will not know about the TIO and > will >>> drop it. In turn, it may be mistaken for a fixed AR by a roaming MR. >> >> I an not parsing the last sentence, sorry... > Just acknowledging your words. A legacy router will be mistaken for a > fixed router even if it is permanently attached to a MR and moving = with > it. So I guess a roaming MR should always prefer an Attachment Router > with TIO, be it fixed or mobile. But in order to prevent loops, it is > also recommended that legacy MR be configured not to accept roaming=20 > MRs, > what can we do, right? IMHO it would be reasonable to assume that all MR support the TD=20 mechanism, and also that AR within the nemo also support the TD=20 mechanism. However, i am not so sure that it would be reasonable to assume that=20 all the router LFN support the the TD mechanism. IMHO, both the MR and the AR within the nemo are devices closely=20 related with mobility support so i guess that it is reasonable to=20 assume that the have proper mobility support. OTOH, router LFN may not=20= even be aware of movement. An example of this case for me would be a=20 train. In this case, i would say that a possible configuration is that=20= there is one MR in the train and then there are some router LFNs inside=20= the train between different links inside the train. I guess that it=20 would be beneficial if those routers could be just regular routers and=20= that the special support is only required in the MR and possible AR. [...] >> My concer regarding this point and the next one is how does the TD > works >> when a router LFN exists in the nemo > > Understood and agreed with the concern, though I saw it as secondary=20= > for > the lack of use cases. > > This is one discussion where help from the group would be appreciated. > We already simulated that draft, and actually that was a concern. We > ended up moving the TIO support from a MR feature to a ND optional > feature for all routers. It may be harder to move it to IETF that way, > though. > > The same question arises for a MR that is at home in a tree. Should it > propagate TIO? nice question... IMHO when the nemo is at home, the AR within that nemo are AR belonging=20= to the fixed infrastructure, so according to this rule this would imply=20= that each AR of the nemo that is at home should be a clusterhead on its=20= own, right? But what happens when the nemo moves? in this case, the MR of the nemo=20= will become the clusterhead, and the AR within the nemo should announce=20= the tree of the mr and not their own, which is reasonable since they=20 are no longer a AR of the fixed infrastructure. I would say that i prefer the first option, since the AR within a nemo=20= probably is not as good as a fixed AR in any case, so this is reflected=20= in the tree depth in the TIO [...] >> According to the draft the TD has two goals,: >> - Loop prevention >> - enhanced route selection >> >> IMHO the loop prevetnion is critical, while the enhanced route > selection is >> one of those nice-to-have features. > Yes > > Actually we try to avoid the enhanced thing. I agree with you. the critical stuff is the loop prevention. However, IMHO this is not really reflected in the draft considering=20 that the first point in the motivation section is related to route=20 selection and the loop detection is the second one. I would suggest that you put the loop prevention as the first=20 motivation and then explicitly state that route selection is just a=20 plus, nice to have feature (perhaps put it in a separate section?) [...] >> >> I guess that it would be better to have a more robust TD mechanism > that >> supports non upgraded router LFN in the nemo. This would require = using > some >> other signaling instead of using a RA option. The new signaling > message >> shouldn't be link scoped but its scope should be the nemo. > Not too easy to do. agree > And remember you want to be damn quick and > efficient. Sometimes, an apparent beauty results in a living = nightmare. > My proposal is to leave those as leaves and see what we can do for = case > 2 (LFN Router with TD) and 3 (MR at home within tree). > Well, basically what is needed here is a mechanism to communicate with=20= all the MR of a nemo. I would assume, as i mentioned earlier that all the MR and all the AR=20 within the nemo support the TD mechanism. The problem then is how to=20 allow a communication between all those devices when maybe there are=20 some devices between that don=B4t support the TD mechanism. Using RAdv doesn=B4t solve this problem since the non upgraded=20 intermediate router will not propagate the TIO. I guess that an option could be to use site scoped multicast for this=20 i.e. use messages that are sent to the all router multicast address=20 with a site scope. In this way, if multicast is supported in the site,=20= it would work even if intermediate routers don't understand the TD=20 mechanism. Note that this option would at least work as good as the RAdv option,=20 since, at least all the routers directly connected in the link will=20 receive the message, and if multicast routing is available, routers in=20= other links will also receive it. Upgraded routers would also forward=20 the messages. Moreover, there is no need of upgrading the routers LFN,=20= just turn on multicast routing for this multicast group. since it is assumed that MR and AR within the nemo support the TD,=20 intra nemo multicast routing is required, and not inter nemo multicast=20= routing is required. >> But before discusin options about how to do this, do you agree that = it > would >> be intersting that the TD mechanism can support non upgraded routers > LFN? > Not really. Being a MR is pretty cool. Can add features like RO to the > picture. MR and AR within the nemo are required to support it, agree. My concern is about the robustness of the TD mechanism, w.r.t. non=20 upgraded devices in the path > Again I need a convincing use case. Do you think it is reasonable that nemos may have legacy routers within=20= or you assume that all routers within the nemo will be upgraded? > TD builds the tree > dynamically and is you support RRH, you can source route down that=20 > tree. > TD on MRs (even more with an RO solution like RRH in place) results in=20= > a > pretty efficient feature and I would definitely enable MR on all boxes > in a roaming cloud. Yes but you are assuming that will be able to do so, what about legacy=20= routers? you just won't be able to use them within a nemo? > >> >> The other issue is about enahnced route selection. >> I am not sure that we can do much when we have to deal with non > upgraded >> router LFN in this case, but i guess that including upgraded router > LFN in >> the tree topology would provide more information about intermediate > hosts, >> so the selection would be improved. So i guess that all the routers > that >> support the TD mechanisms could be included in the tree as a form to > provide >> more detailed information for route selection support. > Yes, this seems reasonable and we have to figure that out. I believe = we > should concentrate on that case as opposed to legacy LFN routers. If = we > do so, again, this impacts all routers, making it harder to move=20 > forward > at IETF... > Well, adding all the routers that support the TD to the tree shouldn't=20= be a problem, i guess regards, marcelo > > Pascal > From nemo-admin@ietf.org Fri May 21 20:27:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15530 for ; Fri, 21 May 2004 20:27:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRKI1-0007j6-OO; Fri, 21 May 2004 20:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRKG1-0007RA-4g for nemo@optimus.ietf.org; Fri, 21 May 2004 20:20:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15205 for ; Fri, 21 May 2004 20:20:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRKFy-0007YB-UC for nemo@ietf.org; Fri, 21 May 2004 20:20:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRKFB-0007SX-00 for nemo@ietf.org; Fri, 21 May 2004 20:20:06 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BRKEe-0007L0-00 for nemo@ietf.org; Fri, 21 May 2004 20:19:32 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4M0Itd06111; Fri, 21 May 2004 17:18:55 -0700 X-mProtect: <200405220018> 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 smtpdinF9FR; Fri, 21 May 2004 17:18:53 PDT Message-ID: <40AE9CED.8060704@iprg.nokia.com> Date: Fri, 21 May 2004 17:21:01 -0700 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: "Steven M. Bellovin" CC: margaret@thingmagic.com, nemo@ietf.org Subject: Re: [nemo] Re: your comments on NEMO spec References: <20040505024051.B18717B44@berkshire.research.att.com> In-Reply-To: <20040505024051.B18717B44@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Steve, sorry for the delay in getting back to you. Steven M. Bellovin wrote: >> >>>3: What good does it to to check the source address of the >>> outer IPv6 header? Spoofing that is far too easy. >> >>when the Mobile Router (MR) receives a tunneled packet > >>from the Home Agent (HA), it looks like the following > >>IPv6 hdr (src=HA, dst=MR_CoA) >>IPv6 hdr (src=CN, dst=MNN) >>Payload >> >>MNN (Mobile network node) is one of the nodes inside the >>Mobile Network. >> >>when the MR decapsulates the above packet and forwards the >>inner packet, it has to perform a few tunnel checks. it has >>to verify that the source address on the outer IPv6 header >>is the Home Agent and the destination address in the inner >>packet is one of the nodes in the Mobile Network. such >>checks need to be performed always, right? >> >>this check however only needs to be done if there is no >>IPsec protection (in tunnel mode) for the packets. > > > OK. Should the above sentence be added as a clarification? I added the following to section 3 However, this check is not necessary if the packet is protected by IPsec in tunnel mode. > >>>6.1.2: why is the prefix table check only a SHOULD and not a MUST? >> >>well, the mobile router and the HA most of the time share >>some kind of subscriber/provider relationship. the prefix >>table is needed only if you expect the mobile routers to >>misbehave. this was the concensus in the WG when this was >>discussed earlier. >> >> >>>8: This text is unclear: >>> >>> When the Mobile Router and the Home Agent exchange routes >>> through a dynamic routing protocol, the Mobile Router >>> should be careful in including the same Mobile Network >>> Prefixes in the Binding Update to the Home Agent and in >>> the routing protocol updates. The Home Agent depending >>> on its configuration might not add routes based on the >>> prefix information in the Binding Updates at all, and >>> might use only the routing protocol updates. Moreover, >>> including the same prefix information in both the Binding >>> Update and the routing protocol update is redundant. >>> >>> Do you mean "be careful to include the same information in >>> both places" -- redunancy is sometimes good. Or do you >>> mean "be careful to avoid doing this"? Personally, I think >>> the former is more appropriate, because it allows a check >>> on the validity of the routing information. Note that the >>> prefixes announced via binding updates are checked for >>> authorization; routing data generally is not. I would thus >>> suggest that routing advertisements MUST NOT contain any >>> prefixes not known to the home agent by either implicit >>> mode configuration or explicit mode announcement. > > > I don't see any response here. Or is the response to 9 intended to > cover this? yes. we would like to keep the routing protocol operation and explicit mode separate. > I think the language needs fixing no matter what. I modified the text to say that when using a dynamic routing protocol, the Mobile Router SHOULD NOT include anything in the binding updates. When the Mobile Router and the Home Agent exchange routes through a dynamic routing protocol, the Mobile Router SHOULD NOT include the same Mobile Network Prefixes in the Binding Update to the Home Agent and in the routing protocol updates. > > >>>9: When discussing Home Agent routing protocol processing, must >>> the HA check the authorization for routing messages in general, >>> or for the prefixes actually being announced? >>> >> >>we actually wanted to avoid any kind of coupling between >>running an IGP and the NEMO basic support protocol. >> >>when a routing protocol is used between the mobile router >>and the HA, the bi-directional tunnel between the MR and >>the HA actually extends the IGP domain to include the MR. >>thats all. NEMO basic support protocol only creates the >>bi-directional tunnel (and few more things). we dont want >>NEMO to do the verification for routing protocol updates. >> >>if there is enough trust between the MR and the HA and >>they are configured to run an IGP, they do it. otherwise >>the MR and the HA should not run an IGP when the MR is >>not at home. we can make this more explicit if needed. >> > > I'd appreciate that, especially since 8 does talk about some linkage. I added some text to the Security Considerations section. this is the new text. The Home Agent MUST verify that the Mobile Router is authorized to send routing updates before processing the messages and propagating the routing information. If there is not enough trust, that is required for two routers to exchange routing updates in a domain, the Home Agent MUST reject routing updates from the Mobile Router. Since the routing protocol message could contain information about the internal routing structure of the home network, these messages require authentication and confidentiality protection. Confidentiality protection through IPsec ESP [4] SHOULD be used. let me know if this addresses your concerns. Vijay From exim@www1.ietf.org Fri May 21 20:38:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15794 for ; Fri, 21 May 2004 20:38:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRKVN-0001SR-SX for nemo-archive@odin.ietf.org; Fri, 21 May 2004 20:36:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M0antC005604 for nemo-archive@odin.ietf.org; Fri, 21 May 2004 20:36:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRKNc-0000Lx-E4 for nemo-web-archive@optimus.ietf.org; Fri, 21 May 2004 20:28:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15560 for ; Fri, 21 May 2004 20:28:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRKNa-0000Uu-42 for nemo-web-archive@ietf.org; Fri, 21 May 2004 20:28:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRKMe-0000QK-00 for nemo-web-archive@ietf.org; Fri, 21 May 2004 20:27:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRKMA-0000M4-00 for nemo-web-archive@ietf.org; Fri, 21 May 2004 20:27:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRKI1-0007j6-OO; Fri, 21 May 2004 20:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRKG1-0007RA-4g for nemo@optimus.ietf.org; Fri, 21 May 2004 20:20:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15205 for ; Fri, 21 May 2004 20:20:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRKFy-0007YB-UC for nemo@ietf.org; Fri, 21 May 2004 20:20:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRKFB-0007SX-00 for nemo@ietf.org; Fri, 21 May 2004 20:20:06 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BRKEe-0007L0-00 for nemo@ietf.org; Fri, 21 May 2004 20:19:32 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4M0Itd06111; Fri, 21 May 2004 17:18:55 -0700 X-mProtect: <200405220018> 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 smtpdinF9FR; Fri, 21 May 2004 17:18:53 PDT Message-ID: <40AE9CED.8060704@iprg.nokia.com> Date: Fri, 21 May 2004 17:21:01 -0700 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: "Steven M. Bellovin" CC: margaret@thingmagic.com, nemo@ietf.org Subject: Re: [nemo] Re: your comments on NEMO spec References: <20040505024051.B18717B44@berkshire.research.att.com> In-Reply-To: <20040505024051.B18717B44@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Steve, sorry for the delay in getting back to you. Steven M. Bellovin wrote: >> >>>3: What good does it to to check the source address of the >>> outer IPv6 header? Spoofing that is far too easy. >> >>when the Mobile Router (MR) receives a tunneled packet > >>from the Home Agent (HA), it looks like the following > >>IPv6 hdr (src=HA, dst=MR_CoA) >>IPv6 hdr (src=CN, dst=MNN) >>Payload >> >>MNN (Mobile network node) is one of the nodes inside the >>Mobile Network. >> >>when the MR decapsulates the above packet and forwards the >>inner packet, it has to perform a few tunnel checks. it has >>to verify that the source address on the outer IPv6 header >>is the Home Agent and the destination address in the inner >>packet is one of the nodes in the Mobile Network. such >>checks need to be performed always, right? >> >>this check however only needs to be done if there is no >>IPsec protection (in tunnel mode) for the packets. > > > OK. Should the above sentence be added as a clarification? I added the following to section 3 However, this check is not necessary if the packet is protected by IPsec in tunnel mode. > >>>6.1.2: why is the prefix table check only a SHOULD and not a MUST? >> >>well, the mobile router and the HA most of the time share >>some kind of subscriber/provider relationship. the prefix >>table is needed only if you expect the mobile routers to >>misbehave. this was the concensus in the WG when this was >>discussed earlier. >> >> >>>8: This text is unclear: >>> >>> When the Mobile Router and the Home Agent exchange routes >>> through a dynamic routing protocol, the Mobile Router >>> should be careful in including the same Mobile Network >>> Prefixes in the Binding Update to the Home Agent and in >>> the routing protocol updates. The Home Agent depending >>> on its configuration might not add routes based on the >>> prefix information in the Binding Updates at all, and >>> might use only the routing protocol updates. Moreover, >>> including the same prefix information in both the Binding >>> Update and the routing protocol update is redundant. >>> >>> Do you mean "be careful to include the same information in >>> both places" -- redunancy is sometimes good. Or do you >>> mean "be careful to avoid doing this"? Personally, I think >>> the former is more appropriate, because it allows a check >>> on the validity of the routing information. Note that the >>> prefixes announced via binding updates are checked for >>> authorization; routing data generally is not. I would thus >>> suggest that routing advertisements MUST NOT contain any >>> prefixes not known to the home agent by either implicit >>> mode configuration or explicit mode announcement. > > > I don't see any response here. Or is the response to 9 intended to > cover this? yes. we would like to keep the routing protocol operation and explicit mode separate. > I think the language needs fixing no matter what. I modified the text to say that when using a dynamic routing protocol, the Mobile Router SHOULD NOT include anything in the binding updates. When the Mobile Router and the Home Agent exchange routes through a dynamic routing protocol, the Mobile Router SHOULD NOT include the same Mobile Network Prefixes in the Binding Update to the Home Agent and in the routing protocol updates. > > >>>9: When discussing Home Agent routing protocol processing, must >>> the HA check the authorization for routing messages in general, >>> or for the prefixes actually being announced? >>> >> >>we actually wanted to avoid any kind of coupling between >>running an IGP and the NEMO basic support protocol. >> >>when a routing protocol is used between the mobile router >>and the HA, the bi-directional tunnel between the MR and >>the HA actually extends the IGP domain to include the MR. >>thats all. NEMO basic support protocol only creates the >>bi-directional tunnel (and few more things). we dont want >>NEMO to do the verification for routing protocol updates. >> >>if there is enough trust between the MR and the HA and >>they are configured to run an IGP, they do it. otherwise >>the MR and the HA should not run an IGP when the MR is >>not at home. we can make this more explicit if needed. >> > > I'd appreciate that, especially since 8 does talk about some linkage. I added some text to the Security Considerations section. this is the new text. The Home Agent MUST verify that the Mobile Router is authorized to send routing updates before processing the messages and propagating the routing information. If there is not enough trust, that is required for two routers to exchange routing updates in a domain, the Home Agent MUST reject routing updates from the Mobile Router. Since the routing protocol message could contain information about the internal routing structure of the home network, these messages require authentication and confidentiality protection. Confidentiality protection through IPsec ESP [4] SHOULD be used. let me know if this addresses your concerns. Vijay From nemo-admin@ietf.org Sat May 22 04:57: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 EAA21379 for ; Sat, 22 May 2004 04:57:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRS7r-0004y9-BT; Sat, 22 May 2004 04:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRS51-0004Q9-Ts for nemo@optimus.ietf.org; Sat, 22 May 2004 04:42:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20924 for ; Sat, 22 May 2004 04:42:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRS4y-0005Hd-5a for nemo@ietf.org; Sat, 22 May 2004 04:42:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRS4A-0005Ak-00 for nemo@ietf.org; Sat, 22 May 2004 04:41:14 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BRS3f-00052Z-00 for nemo@ietf.org; Sat, 22 May 2004 04:40:43 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i4M8cbOj026944; Sat, 22 May 2004 08:38:37 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004052216400015557 ; Sat, 22 May 2004 16:40:00 +0800 Received: from pgsmsx401.gar.corp.intel.com ([172.30.190.29]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 22 May 2004 16:40:00 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43FD8.5EEE8AD1" Date: Sat, 22 May 2004 16:39:59 +0800 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <777DEAB49FEBEA4D8A3DABE83697355B0519FE@pgsmsx401.gar.corp.intel.com> Thread-Topic: Nemo Tree Discovery Thread-Index: AcQ/2F4IoYSGuP/vRAOLYuD5tygeYw== From: "Tan, Tat Kin" To: "Pascal Thubert \(pthubert\)" Cc: X-OriginalArrivalTime: 22 May 2004 08:40:00.0955 (UTC) FILETIME=[5ED268B0:01C43FD8] 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,HTML_MESSAGE autolearn=no version=2.60 Subject: [nemo] Nemo Tree Discovery Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C43FD8.5EEE8AD1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Pascal, Would like to post some questions to you regarding to "Nested Nemo Tree Discovery". I very much agree with a statement at pg4 3.1 where it says "Each level of a Nemo implies the usage of a new tunnel between the MR and its home agent. Thus if a MNN connects to a sub-nemo which is also a sub-nemo, packets from the MNN will be encapsulated three times." I see the processing overheads here. :-) When the MRs are chained in tree fashion, say, MR1 as the clusterhead that connects to a particular AR, MR3 connects to MR2; MR4 connects to MR3 and so on....., When a MNN that resides in, say MR6 that wish to communicate, isnt this the same level of encapsulation and routing overheads introduced when packets traverse via the chain, compared to the above statement? Of cource the Tree-Balancing method could be employed to potentially reduce the level of nested routing? Secondly, what happen if a "branch" of the Tree is broken say, MR4 in the chain is down? While the restructuring of Tree should be made transparent, MNNs under MR4 and below simply would loose connections. If such circumstance is possible, would MR5 (that connects to MR4) declare "independent" and attempt to connect to other AR that is available and hence form another sub-tree? How will your proposed Nemo-Tree resolved routing potential conflicts? What's your view on these scenarios? :) I may not be right....... Cheers, Tatkin ------_=_NextPart_001_01C43FD8.5EEE8AD1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nemo Tree Discovery

Hello Pascal,

Would like to post some questions to = you regarding to "Nested Nemo Tree Discovery".

I very much agree with a statement at = pg4 3.1 where it says "Each level of a Nemo implies the usage of a = new tunnel between the MR and its home agent. Thus if a MNN connects to = a sub-nemo which is also a sub-nemo, packets from the MNN will be = encapsulated three times." I see the processing overheads here. = :-)

When the MRs are chained in tree = fashion, say, MR1 as the clusterhead that connects to a particular AR, = MR3 connects to MR2; MR4 connects to MR3 and so on….., When a MNN = that resides in, say MR6 that wish to communicate, isnt this the same = level of encapsulation and routing overheads introduced when packets = traverse via the chain, compared to the above statement? Of cource the = Tree-Balancing method could be employed to potentially reduce the level = of nested routing?

Secondly, what happen if a = "branch" of the Tree is broken say, MR4 in the chain is down? = While the restructuring of Tree should be made transparent, MNNs under = MR4 and below simply would loose connections. If such circumstance is = possible, would MR5 (that connects to MR4) declare = "independent" and attempt to connect to other AR that is = available and hence form another sub-tree? How will your proposed = Nemo-Tree resolved routing potential conflicts?

What's your view on these scenarios? :) = I may not be right…….

Cheers,
Tatkin

------_=_NextPart_001_01C43FD8.5EEE8AD1-- From exim@www1.ietf.org Sat May 22 05:04: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 FAA21706 for ; Sat, 22 May 2004 05:04:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSOE-0007Tn-Ax for nemo-archive@odin.ietf.org; Sat, 22 May 2004 05:01:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M91w9t028751 for nemo-archive@odin.ietf.org; Sat, 22 May 2004 05:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSLZ-0006je-B4 for nemo-web-archive@optimus.ietf.org; Sat, 22 May 2004 04:59:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21425 for ; Sat, 22 May 2004 04:59:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRSLW-0007VJ-4J for nemo-web-archive@ietf.org; Sat, 22 May 2004 04:59:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRSKW-0007Mn-00 for nemo-web-archive@ietf.org; Sat, 22 May 2004 04:58:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRSJp-0007FJ-00 for nemo-web-archive@ietf.org; Sat, 22 May 2004 04:57:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRS7r-0004y9-BT; Sat, 22 May 2004 04:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRS51-0004Q9-Ts for nemo@optimus.ietf.org; Sat, 22 May 2004 04:42:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20924 for ; Sat, 22 May 2004 04:42:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRS4y-0005Hd-5a for nemo@ietf.org; Sat, 22 May 2004 04:42:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRS4A-0005Ak-00 for nemo@ietf.org; Sat, 22 May 2004 04:41:14 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BRS3f-00052Z-00 for nemo@ietf.org; Sat, 22 May 2004 04:40:43 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i4M8cbOj026944; Sat, 22 May 2004 08:38:37 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004052216400015557 ; Sat, 22 May 2004 16:40:00 +0800 Received: from pgsmsx401.gar.corp.intel.com ([172.30.190.29]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 22 May 2004 16:40:00 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43FD8.5EEE8AD1" Date: Sat, 22 May 2004 16:39:59 +0800 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <777DEAB49FEBEA4D8A3DABE83697355B0519FE@pgsmsx401.gar.corp.intel.com> Thread-Topic: Nemo Tree Discovery Thread-Index: AcQ/2F4IoYSGuP/vRAOLYuD5tygeYw== From: "Tan, Tat Kin" To: "Pascal Thubert \(pthubert\)" Cc: X-OriginalArrivalTime: 22 May 2004 08:40:00.0955 (UTC) FILETIME=[5ED268B0:01C43FD8] Subject: [nemo] Nemo Tree Discovery Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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_001_01C43FD8.5EEE8AD1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Pascal, Would like to post some questions to you regarding to "Nested Nemo Tree Discovery". I very much agree with a statement at pg4 3.1 where it says "Each level of a Nemo implies the usage of a new tunnel between the MR and its home agent. Thus if a MNN connects to a sub-nemo which is also a sub-nemo, packets from the MNN will be encapsulated three times." I see the processing overheads here. :-) When the MRs are chained in tree fashion, say, MR1 as the clusterhead that connects to a particular AR, MR3 connects to MR2; MR4 connects to MR3 and so on....., When a MNN that resides in, say MR6 that wish to communicate, isnt this the same level of encapsulation and routing overheads introduced when packets traverse via the chain, compared to the above statement? Of cource the Tree-Balancing method could be employed to potentially reduce the level of nested routing? Secondly, what happen if a "branch" of the Tree is broken say, MR4 in the chain is down? While the restructuring of Tree should be made transparent, MNNs under MR4 and below simply would loose connections. If such circumstance is possible, would MR5 (that connects to MR4) declare "independent" and attempt to connect to other AR that is available and hence form another sub-tree? How will your proposed Nemo-Tree resolved routing potential conflicts? What's your view on these scenarios? :) I may not be right....... Cheers, Tatkin ------_=_NextPart_001_01C43FD8.5EEE8AD1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nemo Tree Discovery

Hello Pascal,

Would like to post some questions to = you regarding to "Nested Nemo Tree Discovery".

I very much agree with a statement at = pg4 3.1 where it says "Each level of a Nemo implies the usage of a = new tunnel between the MR and its home agent. Thus if a MNN connects to = a sub-nemo which is also a sub-nemo, packets from the MNN will be = encapsulated three times." I see the processing overheads here. = :-)

When the MRs are chained in tree = fashion, say, MR1 as the clusterhead that connects to a particular AR, = MR3 connects to MR2; MR4 connects to MR3 and so on….., When a MNN = that resides in, say MR6 that wish to communicate, isnt this the same = level of encapsulation and routing overheads introduced when packets = traverse via the chain, compared to the above statement? Of cource the = Tree-Balancing method could be employed to potentially reduce the level = of nested routing?

Secondly, what happen if a = "branch" of the Tree is broken say, MR4 in the chain is down? = While the restructuring of Tree should be made transparent, MNNs under = MR4 and below simply would loose connections. If such circumstance is = possible, would MR5 (that connects to MR4) declare = "independent" and attempt to connect to other AR that is = available and hence form another sub-tree? How will your proposed = Nemo-Tree resolved routing potential conflicts?

What's your view on these scenarios? :) = I may not be right…….

Cheers,
Tatkin

------_=_NextPart_001_01C43FD8.5EEE8AD1-- From nemo-admin@ietf.org Mon May 24 03:18:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16443 for ; Mon, 24 May 2004 03:18:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9es-0000C0-4T; Mon, 24 May 2004 03:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9d8-0008OV-9b for nemo@optimus.ietf.org; Mon, 24 May 2004 03:12:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16200 for ; Mon, 24 May 2004 03:12:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS9d6-0006pC-28 for nemo@ietf.org; Mon, 24 May 2004 03:12:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS9c9-0006Xn-00 for nemo@ietf.org; Mon, 24 May 2004 03:11:14 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BS9bQ-00060V-00 for nemo@ietf.org; Mon, 24 May 2004 03:10:28 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 May 2004 09:15:48 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4O79s3v019083; Mon, 24 May 2004 09:09:55 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 May 2004 08:10:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 May 2004 08:10:28 +0100 Message-ID: Thread-Topic: Nemo Tree Discovery Thread-Index: AcQ/2F4IoYSGuP/vRAOLYuD5tygeYwBgioVQ From: "Pascal Thubert \(pthubert\)" To: "Tan, Tat Kin" Cc: X-OriginalArrivalTime: 24 May 2004 07:10:29.0079 (UTC) FILETIME=[31C2AE70:01C4415E] 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 Subject: [nemo] RE: Nemo Tree Discovery Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Tatkin >> When the MRs are chained in tree fashion, say, MR1 as the clusterhead that connects to a particular AR, MR3 connects to MR2; MR4 connects to MR3 and so on....., When a MNN that resides in, say MR6 that wish to communicate, isnt this the same level of encapsulation and routing overheads introduced when packets traverse via the chain, compared to the above statement? Of course the Tree-Balancing method could be employed to potentially reduce the level of nested routing? =3D> You got it right, one major aspect of TD is that the tree depth is minimized. The depth is the key both to avoid loops and to limit the level of reencapsulation. TD is not an RO solution, rather a precursor. Many RO techniques can be applied on top of TD, for example Reverse Routing Header :) >> Secondly, what happen if a "branch" of the Tree is broken say, MR4 in the chain is down? While the restructuring of Tree should be made transparent, MNNs under MR4 and below simply would loose connections. If such circumstance is possible, would MR5 (that connects to MR4) declare "independent" and attempt to connect to other AR that is available and hence form another sub-tree? How will your proposed Nemo-Tree resolved routing potential conflicts? What's your view on these scenarios? :) I may not be right.......=20 =3D> I think this is the core of TD. MR5 maintains a conceptual ordered Default Router List that contains all the routers that MR5 may jump to. MR4 must have been the best from MR5 standpoint since MR5 decided to attach to MR4. The DR List contains virtually all the routers in MR5's line of sight but those in the same tree as MR5 but deeper. Those unacceptable routers may be kept in a conceptually separate list, or flagged with a state.=20 =3D> When MR5 looses MR4 (MIP movement detection, DNA, 802.21 etc...) = MR5 selects the next in the DRL and attaches to it - MRA say. In order to save time, MR5 may have proactively allocated an address from MRA, or may use optimistic DAD, whatever. If the DRL was empty then MR5 becomes clusterhead of its own tree, and after some time, MR5 may reattach deeper in the original tree since now it's a different tree. In both cases MR5 informs attached MR of the new topology using RATIO. =3D> there is more to it, see the tree hop timer and the few states that smoothen tree migrations and merging, and the give a precise meaning to 'after some time'... Pascal From exim@www1.ietf.org Mon May 24 03:25:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16694 for ; Mon, 24 May 2004 03:25:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9o3-0001K2-Rb for nemo-archive@odin.ietf.org; Mon, 24 May 2004 03:23:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O7NVjO005077 for nemo-archive@odin.ietf.org; Mon, 24 May 2004 03:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9jr-0000iu-Eh for nemo-web-archive@optimus.ietf.org; Mon, 24 May 2004 03:19:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16493 for ; Mon, 24 May 2004 03:19:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS9jp-00012G-5u for nemo-web-archive@ietf.org; Mon, 24 May 2004 03:19:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS9iq-0000l4-00 for nemo-web-archive@ietf.org; Mon, 24 May 2004 03:18:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS9iE-0000Ub-00 for nemo-web-archive@ietf.org; Mon, 24 May 2004 03:17:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9es-0000C0-4T; Mon, 24 May 2004 03:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9d8-0008OV-9b for nemo@optimus.ietf.org; Mon, 24 May 2004 03:12:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16200 for ; Mon, 24 May 2004 03:12:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS9d6-0006pC-28 for nemo@ietf.org; Mon, 24 May 2004 03:12:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS9c9-0006Xn-00 for nemo@ietf.org; Mon, 24 May 2004 03:11:14 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BS9bQ-00060V-00 for nemo@ietf.org; Mon, 24 May 2004 03:10:28 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 May 2004 09:15:48 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4O79s3v019083; Mon, 24 May 2004 09:09:55 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 May 2004 08:10:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 May 2004 08:10:28 +0100 Message-ID: Thread-Topic: Nemo Tree Discovery Thread-Index: AcQ/2F4IoYSGuP/vRAOLYuD5tygeYwBgioVQ From: "Pascal Thubert \(pthubert\)" To: "Tan, Tat Kin" Cc: X-OriginalArrivalTime: 24 May 2004 07:10:29.0079 (UTC) FILETIME=[31C2AE70:01C4415E] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Nemo Tree Discovery Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group 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 Hello Tatkin >> When the MRs are chained in tree fashion, say, MR1 as the clusterhead that connects to a particular AR, MR3 connects to MR2; MR4 connects to MR3 and so on....., When a MNN that resides in, say MR6 that wish to communicate, isnt this the same level of encapsulation and routing overheads introduced when packets traverse via the chain, compared to the above statement? Of course the Tree-Balancing method could be employed to potentially reduce the level of nested routing? =3D> You got it right, one major aspect of TD is that the tree depth is minimized. The depth is the key both to avoid loops and to limit the level of reencapsulation. TD is not an RO solution, rather a precursor. Many RO techniques can be applied on top of TD, for example Reverse Routing Header :) >> Secondly, what happen if a "branch" of the Tree is broken say, MR4 in the chain is down? While the restructuring of Tree should be made transparent, MNNs under MR4 and below simply would loose connections. If such circumstance is possible, would MR5 (that connects to MR4) declare "independent" and attempt to connect to other AR that is available and hence form another sub-tree? How will your proposed Nemo-Tree resolved routing potential conflicts? What's your view on these scenarios? :) I may not be right.......=20 =3D> I think this is the core of TD. MR5 maintains a conceptual ordered Default Router List that contains all the routers that MR5 may jump to. MR4 must have been the best from MR5 standpoint since MR5 decided to attach to MR4. The DR List contains virtually all the routers in MR5's line of sight but those in the same tree as MR5 but deeper. Those unacceptable routers may be kept in a conceptually separate list, or flagged with a state.=20 =3D> When MR5 looses MR4 (MIP movement detection, DNA, 802.21 etc...) = MR5 selects the next in the DRL and attaches to it - MRA say. In order to save time, MR5 may have proactively allocated an address from MRA, or may use optimistic DAD, whatever. If the DRL was empty then MR5 becomes clusterhead of its own tree, and after some time, MR5 may reattach deeper in the original tree since now it's a different tree. In both cases MR5 informs attached MR of the new topology using RATIO. =3D> there is more to it, see the tree hop timer and the few states that smoothen tree migrations and merging, and the give a precise meaning to 'after some time'... Pascal From nemo-bounces@ietf.org Thu May 27 21:55:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11583 for ; Thu, 27 May 2004 21:55:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTWW7-0006bj-Cn; Thu, 27 May 2004 21:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTW5f-0001Gn-DQ for nemo@megatron.ietf.org; Thu, 27 May 2004 21:23:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10086 for ; Thu, 27 May 2004 21:23:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTW5Y-0007Yx-J7 for nemo@ietf.org; Thu, 27 May 2004 21:23:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTW4V-0007FJ-00 for nemo@ietf.org; Thu, 27 May 2004 21:22:07 -0400 Received: from [168.188.129.51] (helo=cclab.cclab.cnu.ac.kr ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BTW3Q-0006go-00 for nemo@ietf.org; Thu, 27 May 2004 21:21:00 -0400 Received: from cclabShine ([168.188.129.67]) by cclab.cclab.cnu.ac.kr (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4S1Kqca000728 for ; Fri, 28 May 2004 10:20:52 +0900 Message-Id: <200405280120.i4S1Kqca000728@cclab.cclab.cnu.ac.kr> From: "Shine Choi" To: Subject: [nemo] Questions about .. Date: Fri, 28 May 2004 10:20:54 +0900 Organization: CNU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcREUgTmIJoqpOMiQ3yWVde/G1SC0Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello! everybody concerned with the draft, or interested in my question. I'm Shine who's been studying multihoming in NEMO. By the way, something in the draft has made me feel wonder. If there's someone who can help me understand it clearly, please help me. My question is... In brief, I don't understand why there must be "the number of HAs" as one of the 3-tuple in the multihoming classification. To let me understand why~, I need to know these things first... 1) Are there some cases or scenarios that show an ISP has multiple HAs? 2) If so, could you give me the examples of those..? I would like someone, who made the number of HAs as one of the 3-tuple in the classification, to show me why there could be multiple HAs with examples. 3) I think, such multiple HAs could be logically viewed as the one HA in the ISP even if they are physically many in there. The "logically" term means multiple HAs would act like one HA. Even though there were multiple HAs in an ISP, the HAs would be like only distributed system. If that's right, bidirectional tunnel between HAs in the ISP and a MR would be also made on the same route. In addition, I think, MRs and CNs outside the ISP cannot help regarding the HAs as just one HA acting. I'm waiting someone to reply for my questions asap. Cheers, Shine From nemo-bounces@ietf.org Thu May 27 22:24:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12812 for ; Thu, 27 May 2004 22:24:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTWwY-0003Wp-5g; Thu, 27 May 2004 22:17:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTWcS-0008Qr-LM for nemo@megatron.ietf.org; Thu, 27 May 2004 21:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11668 for ; Thu, 27 May 2004 21:57:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTWcQ-0002Da-Ur for nemo@ietf.org; Thu, 27 May 2004 21:57:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTWbU-0001uM-00 for nemo@ietf.org; Thu, 27 May 2004 21:56:12 -0400 Received: from [168.188.129.51] (helo=cclab.cclab.cnu.ac.kr ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BTWaX-0001an-00 for nemo@ietf.org; Thu, 27 May 2004 21:55:14 -0400 Received: from cclabShine ([168.188.129.67]) by cclab.cclab.cnu.ac.kr (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4S1tCca000929 for ; Fri, 28 May 2004 10:55:12 +0900 Message-Id: <200405280155.i4S1tCca000929@cclab.cclab.cnu.ac.kr> From: "Shine Choi" To: Subject: [nemo] Questions about .. Date: Fri, 28 May 2004 10:55:14 +0900 Organization: CNU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcREVtEQLiGNRQeiTxK/LbQSg2VmpA== 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=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello! everybody concerned with the draft, or interested in my question. I'm Shine who's been studying multihoming in NEMO. By the way, something in the draft has made me feel wonder. If there's someone who can help me understand it clearly, please help me. My question is... In brief, I don't understand why there must be "the number of HAs" as one of the 3-tuple in the multihoming classification. To let me understand why~, I need to know these things first... 1) Are there some cases or scenarios that show an ISP has multiple HAs? 2) If so, could you give me the examples of those..? I would like someone, who made the number of HAs as one of the 3-tuple in the classification, to show me why there could be multiple HAs with examples. 3) I think, such multiple HAs could be logically viewed as the one HA in the ISP even if they are physically many in there. The "logically" term means multiple HAs would act like one HA. Even though there were multiple HAs in an ISP, the HAs would be like only distributed system. If that's right, bidirectional tunnel between HAs in the ISP and a MR would be also made on the same route. In addition, I think, MRs and CNs outside the ISP cannot help regarding the HAs as just one HA acting. I'm waiting someone to reply for my questions asap. Cheers, Shine From nemo-bounces@ietf.org Thu May 27 23:26:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14908 for ; Thu, 27 May 2004 23:26:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTXhR-00051d-N4; Thu, 27 May 2004 23:06:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTXYg-0003DA-51 for nemo@megatron.ietf.org; Thu, 27 May 2004 22:57:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13939 for ; Thu, 27 May 2004 22:57:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTXYe-0004fJ-72 for nemo@ietf.org; Thu, 27 May 2004 22:57:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTXXe-0004NW-00 for nemo@ietf.org; Thu, 27 May 2004 22:56:19 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BTXWo-0003nL-00 for nemo@ietf.org; Thu, 27 May 2004 22:55:26 -0400 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i4S2qpNG018343; Fri, 28 May 2004 10:52:51 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 2A499B240D4; Fri, 28 May 2004 11:04:09 +0800 (SGT) Subject: Re: [nemo] Questions about .. From: Chan-Wah Ng To: Shine Choi In-Reply-To: <200405280120.i4S1Kqca000728@cclab.cclab.cnu.ac.kr> References: <200405280120.i4S1Kqca000728@cclab.cclab.cnu.ac.kr> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1085713447.9072.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 28 May 2004 11:04:08 +0800 Content-Transfer-Encoding: 7bit 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 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Shine, The deployment scenarios has been illustrated in previous versions, however, due to the introduction of multihoming-goals-and-benefits draft, to reduce duplication, deployment scenarios has been removed. Anyway, consider a multi-mode mobile router. When it subscribe to Wi-Fi, GPRS or even satellite through different service providers, it is likely for each service provider assign different HA to the mobile router. If all HA are assigned to a single ISP, I agree with your statement that they can be "logically viewed as one". /rgds /cwng On Fri, 2004-05-28 at 09:20, Shine Choi wrote: > Hello! everybody concerned with the draft, > or interested in my question. > > I'm Shine who's been studying multihoming in NEMO. > By the way, something in the draft has made me feel wonder. > If there's someone who can help me understand it clearly, please help me. > My question is... > > In brief, I don't understand why there must be "the number of HAs" > as one of the 3-tuple in the multihoming classification. > > To let me understand why~, I need to know these things first... > > 1) Are there some cases or scenarios that show an ISP has multiple HAs? > 2) If so, could you give me the examples of those..? > I would like someone, who made the number of HAs as one of the 3-tuple in > the classification, to show me why there could be multiple HAs with > examples. > 3) I think, such multiple HAs could be logically viewed as the one HA in the > ISP > even if they are physically many in there. > > The "logically" term means multiple HAs would act like one HA. > Even though there were multiple HAs in an ISP, the HAs would be like only > distributed system. > If that's right, bidirectional tunnel between HAs in the ISP and a MR would > be also made on the same route. > In addition, I think, MRs and CNs outside the ISP cannot help regarding the > HAs as just one HA acting. > > I'm waiting someone to reply for my questions asap. > > Cheers, > Shine > > > From nemo-bounces@ietf.org Thu May 27 23:33:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15297 for ; Thu, 27 May 2004 23:33:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTY0x-0001Lw-Uu; Thu, 27 May 2004 23:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTXot-0006ZD-2i for nemo@megatron.ietf.org; Thu, 27 May 2004 23:14:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14420 for ; Thu, 27 May 2004 23:14:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTXoq-0000sz-Q9 for nemo@ietf.org; Thu, 27 May 2004 23:14:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTXlw-0000H5-00 for nemo@ietf.org; Thu, 27 May 2004 23:11:07 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1BTXjd-0007Sy-00 for nemo@ietf.org; Thu, 27 May 2004 23:08:41 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4D0155D2A5; Fri, 28 May 2004 12:08:11 +0900 (JST) Date: Fri, 28 May 2004 12:07:46 +0900 From: Thierry Ernst To: "Shine Choi" Subject: Re: [nemo] Questions about .. Message-Id: <20040528120746.76707c60.ernst@sfc.wide.ad.jp> In-Reply-To: <200405280120.i4S1Kqca000728@cclab.cclab.cnu.ac.kr> References: <200405280120.i4S1Kqca000728@cclab.cclab.cnu.ac.kr> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, On Fri, 28 May 2004 10:20:54 +0900 "Shine Choi" wrote: > Hello! everybody concerned with the draft, > or interested in my question. > > I'm Shine who's been studying multihoming in NEMO. > By the way, something in the draft has made me feel wonder. > If there's someone who can help me understand it clearly, please help me. > My question is... > > In brief, I don't understand why there must be "the number of HAs" > as one of the 3-tuple in the multihoming classification. > > To let me understand why~, I need to know these things first... > > 1) Are there some cases or scenarios that show an ISP has multiple HAs? > 2) If so, could you give me the examples of those..? This has been discussed at length on the mailing list. First, HAs may not belong to the same ISPs. Take a PAN-like scenario. My NEMO-PAN has sevelal egress interfaces. One is a WLAN 802.11b, the HA is at my office. The second one is a cellular link, the HA is in my cellular provided's network. > I would like someone, who made the number of HAs as one of the 3-tuple in > the classification, to show me why there could be multiple HAs with > examples. > 3) I think, such multiple HAs could be logically viewed as the one HA in the > ISP > even if they are physically many in there. Not valid if HAs belong to distinct ISPs. > The "logically" term means multiple HAs would act like one HA. > Even though there were multiple HAs in an ISP, the HAs would be like only > distributed system. > If that's right, bidirectional tunnel between HAs in the ISP and a MR would > be also made on the same route. > In addition, I think, MRs and CNs outside the ISP cannot help regarding the > HAs as just one HA acting. > > I'm waiting someone to reply for my questions asap. Thierry. From nemo-bounces@ietf.org Thu May 27 23:57:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16165 for ; Thu, 27 May 2004 23:57:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTYNY-000626-CC; Thu, 27 May 2004 23:49:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTYEG-0003Vt-3b for nemo@megatron.ietf.org; Thu, 27 May 2004 23:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15503 for ; Thu, 27 May 2004 23:40:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTYED-0001GE-UW for nemo@ietf.org; Thu, 27 May 2004 23:40:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTYDB-0000xf-00 for nemo@ietf.org; Thu, 27 May 2004 23:39:14 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1BTYC4-0000P0-00 for nemo@ietf.org; Thu, 27 May 2004 23:38:04 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4D4395D1B3 for ; Fri, 28 May 2004 12:36:07 +0900 (JST) Date: Fri, 28 May 2004 12:35:42 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Questions about .. Message-Id: <20040528123542.188c568a.ernst@sfc.wide.ad.jp> In-Reply-To: <1085713447.9072.6.camel@localhost> References: <200405280120.i4S1Kqca000728@cclab.cclab.cnu.ac.kr> <1085713447.9072.6.camel@localhost> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit > The deployment scenarios has been illustrated in previous versions, > however, due to the introduction of multihoming-goals-and-benefits > draft, to reduce duplication, deployment scenarios has been removed. Well, indeed, the idea was to remove what ever was general, but to keep NEMO-specific **configurations** in the draft (like one example with multple HAs, and multiple MRs.). We shall consider this for next revision (which should be a WG document draft-ietf-nemo0-multihoming-problem-statement.txt). Also, the draft will have to discuss the configurations that are useful to handle. > Anyway, consider a multi-mode mobile router. When it subscribe to > Wi-Fi, GPRS or even satellite through different service providers, it is > likely for each service provider assign different HA to the mobile > router. > > If all HA are assigned to a single ISP, I agree with your statement that > they can be "logically viewed as one". Thierry.