From nemo-admin@nal.motlabs.com Tue Dec 3 01:29:13 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29160 for ; Tue, 3 Dec 2002 01:29:12 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB36U6S30892; Tue, 3 Dec 2002 07:30:06 +0100 Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB36TpS30876 for ; Tue, 3 Dec 2002 07:29:51 +0100 Received: by bulls.mei.co.jp (8.12.5/3.7W/jazz) with ESMTP id gB36Tbjd006630; Tue, 3 Dec 2002 15:29:37 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx1) with ESMTP id gB36TbD10582; Tue, 3 Dec 2002 15:29:37 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id gB36TaS22609; Tue, 3 Dec 2002 15:29:36 +0900 (JST) Received: from yrpgw1.yrp.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:02091217) id gB36Ta518726; Tue, 3 Dec 2002 15:29:36 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by yrpgw1.yrp.mci.mei.co.jp (8.11.3/3.7W-GW1) with ESMTP id gB36TZ107560; Tue, 3 Dec 2002 15:29:35 +0900 (JST) Received: from [133.183.211.78] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7W-TELECOM) with ESMTP id gB36TYH14644; Tue, 3 Dec 2002 15:29:34 +0900 (JST) From: Takeshi TANAKA To: Thierry Ernst , IETF NEMO Subject: Re: [nemo] Requirements List Cc: Chan-Wah Ng , "Pascal Thubert (pthubert)" In-Reply-To: <20021125.142935.98599736.ernst@sfc.wide.ad.jp> References: <3DE13EA5.8020505@alcatel.com> <20021125.142935.98599736.ernst@sfc.wide.ad.jp> Message-Id: <20021203150558.F58F.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 03 Dec 2002 15:30:46 +0900 Content-Transfer-Encoding: 7bit Hi, At Mon, 25 Nov 2002 14:29:35 +0900 (JST) Thierry Ernst wrote : > Dear all, > > This is exactly what I'm saying, there will be a single NEMO WG draft > based on the agreed requirements listed by TJ; and we will clarify the > understanding of the requirements once this draft is published. The > purpose of the discussion at Atlanta's meeting was to make sure people > agree with this list before we move forward. Since the chairs have an > idea how the NEMO document should be completed and probably also have > a good idea how to make best use of a meeting, the purpose of the > discussion at Atlanta's meeting was to make sure people agree with > this list before we move forward, and also to assess people's opinion > on the AAA draft and on the terminology draft. > > Thierry Yes, and I think we did get people's opinion on the AAA draft. I could re-explain the motivation and approach on our presentations (NEMO AAA requirements by ChanWah, RO problem space by Pascal) so that attendances at the meeting who might not be familiar with NEMO and our background can understand. Note that this is not the conclusion of the presentations, just background behind our presentations. AAA(Access control in NEMO) Our motivation is to consider about AAA on NEMO for commercial deployment. Then we divided these requirements into 1.requirements for NEMO solution, 2. requirements for AAA solution. We considered 1. will be requirements for basic support in order for basic solution not to preclude the requirements. Also, 2. will be requirements for AAA related WG. RO(including partical RO) In the presentation, we classified the so that people can understand RO scope and approaches in NEMO. Our motivation is to note that basic support(bidirectional tunneling) has issues as follows and people who thinks of deploying NEMO in large scale will have to note them. We well knew that WG works on basic support first and provide the solution. Regards, Takeshi From nemo-admin@nal.motlabs.com Thu Dec 5 13:21:19 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22324 for ; Thu, 5 Dec 2002 13:21:18 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB5IH5S04589; Thu, 5 Dec 2002 19:17:05 +0100 Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB5IGWS04579 for ; Thu, 5 Dec 2002 19:16:33 +0100 Received: from [192.168.1.10] (reflection.kniveton.com [192.168.1.10]) by multihop.net (8.12.6/8.11.1) with ESMTP id gB5IGmTg066952 for ; Thu, 5 Dec 2002 10:16:48 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 From: "T.J. Kniveton" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [nemo] Meeting minutes from IETF55 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 05 Dec 2002 10:16:24 -0800 Content-Transfer-Encoding: 7bit Hi folks, The meeting minutes have been posted to the web page at: http://www.nal.motlabs.com/nemo/ietf55/nemo-ietf55-minutes.txt Special thanks to everyone who contributed, including Greg Daley, Pascal Thubert, JinHyeock Choi, Ryuji Wakikawa and Thierry. These minutes are very complete. -TJ From nemo-admin@nal.motlabs.com Thu Dec 5 14:59:16 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25746 for ; Thu, 5 Dec 2002 14:59:15 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB5Jq2S05715; Thu, 5 Dec 2002 20:52:02 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB5JpRS05695 for ; Thu, 5 Dec 2002 20:51:28 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gB5JpNXL012851; Thu, 5 Dec 2002 12:51:23 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA09580; Thu, 5 Dec 2002 12:46:42 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/il06exr01) with ESMTP id gB5JpCc04529; Thu, 5 Dec 2002 13:51:13 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1BDDE2EC8B; Thu, 5 Dec 2002 20:51:13 +0100 (CET) To: "T.J. Kniveton" Cc: References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 69 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [nemo] reqs again (Was: Meeting minutes from IETF55) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 05 Dec 2002 20:51:13 +0100 "T.J. Kniveton" writes: > The meeting minutes have been posted to the web page at: Thanks all for compiling the minutes. Allow me to bring forth item #6 "MIPv6 MNs can use link as home or visited link." I understand this requirement as a scenario where a mobile network moves around and has an HA internal in the mobile network. As such, a host that is normally fixed in the mobile network and moves as a unit together the mobile network, it could at a certain moment detach from the mobile network and become itself mobile. Once that host (a pure MIPv6 MN?) is out of the mobille network it will send BUs to the HA that is in the mobile network and everything is required to work just fine. Is this the requirement #6? If yes, then I would like to mention one other scenario that could be turned into a requirement: Consider two MRs at home, having a unique HA. Then, the first MR stays at home but the second MR moves away from home and towards under the first MR. That could be seen as a kind of nested mobility I believe. A more generic question stemming from this could be whether two MRs of the same HA are required to be able to nest one under the other or not. Or maybe this is already covered by another requirement? Another requirement question that I have is whether the ARs that accept the visits of various MRs are required to advertise themselves as default routers; this has implications on whether the MR uses its routes from its "default router list" or it must use routes from its "routing table". E.g., if AR doesn't advertise itself as a default router, then MR should have an entry in its routing table pointing towards HA through the AR (that is HA->AR but not ::->AR). Of course, this is probably not reasonable to ask from ARs because ARs are normally far away from the DFZ. Alex > #1 continuous internet connection while MR moving. > > #2 basic support mobile IP and reverse tunnel > > #3 transparency, nodes in NEMO can be unaware of movement. Simple IPv6 > node continues to work. > > #4 CN's do not need to be aware of MIPv6 MNN being in NEMO. > > #5 Fixed Nodes and Mobile IP mobile nodes. > > #6 MIPv6 MNs can use link as home or visited link > > #7 Multihoming works : incorporate EN's ideas on distinctions between > these. > > #8 Co-operate with other groups doing AAA&etc. > > #9 Scalability: support large number of mobile networks, > > #10 Support roaming in different domains of control: one reason for > mobile IP (since supports). > > #11 NEMO is a stub network, not asked to carry traffic for nodes which > aren't part of the mobile Net. > > #12 MNN's Above IP layer shouldn't be affected by the mobility. From nemo-admin@nal.motlabs.com Thu Dec 5 17:42:41 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03499 for ; Thu, 5 Dec 2002 17:42:34 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB5Mb3S07891; Thu, 5 Dec 2002 23:37:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB5Ma7S07864 for ; Thu, 5 Dec 2002 23:36:07 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA29316; Thu, 5 Dec 2002 14:36:01 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gB5MZwT12481; Thu, 5 Dec 2002 14:35:58 -0800 X-mProtect: <200212052235> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrQr7db; Thu, 05 Dec 2002 14:35:56 PST Message-ID: <3DEFD4CD.646334D@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "T.J. Kniveton" CC: nemo@nal.motlabs.com Subject: Re: [nemo] Meeting minutes from IETF55 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 05 Dec 2002 14:35:57 -0800 Content-Transfer-Encoding: 7bit > #6 MIPv6 MNs can use link as home or visited link where can I find more details on this? Vijay From nemo-admin@nal.motlabs.com Thu Dec 5 18:21:13 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04689 for ; Thu, 5 Dec 2002 18:21:07 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB5NJ2S08410; Fri, 6 Dec 2002 00:19:02 +0100 Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB5NIFS08383 for ; Fri, 6 Dec 2002 00:18:16 +0100 Received: from [192.168.1.10] (reflection.kniveton.com [192.168.1.10]) by multihop.net (8.12.6/8.11.1) with ESMTP id gB5NIUTg067327 for ; Thu, 5 Dec 2002 15:18:33 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 From: "T.J. Kniveton" To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [nemo] Re: reqs again (Was: Meeting minutes from IETF55) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 05 Dec 2002 15:18:05 -0800 Content-Transfer-Encoding: 7bit On 12/5/02 11:51 AM, "Alexandru Petrescu" wrote: > If yes, then I would like to mention one other scenario that could be > turned into a requirement: > > Consider two MRs at home, having a unique HA. Then, the first MR > stays at home but the second MR moves away from home and towards under > the first MR. That could be seen as a kind of nested mobility I > believe. A more generic question stemming from this could be whether > two MRs of the same HA are required to be able to nest one under the > other or not. Or maybe this is already covered by another > requirement? How would this be different than a MN nesting under a MR? The second MR that attaches to the first MR's mobile network will just look like an MN to the MR and HA, right? Or is there some detail that makes it a different case? From nemo-admin@nal.motlabs.com Fri Dec 6 01:05:33 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15909 for ; Fri, 6 Dec 2002 01:05:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB6654S13459; Fri, 6 Dec 2002 07:05:04 +0100 Received: from web.plov.omega.bg (web.plov.omega.bg [212.50.0.221]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB664HS13445 for ; Fri, 6 Dec 2002 07:04:17 +0100 Received: from server.plov.omega.bg ([212.91.164.67]) by web.plov.omega.bg with esmtp (Exim 3.35 #1 (Debian)) id 18KBQu-0006HE-00; Fri, 06 Dec 2002 07:53:52 +0200 Received: from dialup492.plovdiv.spnet.net ([213.169.37.236] helo=sender) by server.plov.omega.bg with smtp (Exim 3.12 #1 (Debian)) id 18KBQn-0001Tb-00; Fri, 06 Dec 2002 07:53:45 +0200 From: Toni Stoev To: NeMo Discussion Subscribers , NeMo Discussion Subscribers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: X-Scanner: exiscan *18KBQn-0001Tb-00*wsMkdWE9zzE* http://duncanthrax.net/exiscan/ Subject: [nemo] Term word change Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 06 Dec 2002 07:53:45 +0200 Hi, everybody. I propose a term word change: Mobile Gateway instead of Mobile Router Is it too late? From nemo-admin@nal.motlabs.com Fri Dec 6 01:36:29 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16626 for ; Fri, 6 Dec 2002 01:36:26 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB66S1S13705; Fri, 6 Dec 2002 07:28:01 +0100 Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB66RlS13694 for ; Fri, 6 Dec 2002 07:27:48 +0100 Received: from [192.168.1.10] (reflection.kniveton.com [192.168.1.10]) by multihop.net (8.12.6/8.11.1) with ESMTP id gB66SATg067933 for ; Thu, 5 Dec 2002 22:28:10 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [nemo] Term word change From: "T.J. Kniveton" To: NeMo Discussion Subscribers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 05 Dec 2002 22:27:45 -0800 Content-Transfer-Encoding: 7bit On 12/5/02 9:53 PM, "Toni Stoev" wrote: > > Hi, everybody. > > I propose a term word change: > Mobile Gateway instead of Mobile Router Do you have any reason to justify this proposal? > > Is it too late? > (Probably..) From nemo-admin@nal.motlabs.com Fri Dec 6 05:09:06 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00745 for ; Fri, 6 Dec 2002 05:09:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB6A68S16255; Fri, 6 Dec 2002 11:06:08 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB6A5pS16239 for ; Fri, 6 Dec 2002 11:05:52 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6A4B99022622; Fri, 6 Dec 2002 11:04:16 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 6 Dec 2002 11:05:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [nemo] Term word change Message-ID: Thread-Topic: [nemo] Term word change Thread-Index: AcKc7qzXwSA7H4KsROS5j7gPth4PfgAH7shg From: "Pascal Thubert (pthubert)" To: "Toni Stoev" , "NeMo Discussion Subscribers" , "NeMo Discussion Subscribers" X-OriginalArrivalTime: 06 Dec 2002 10:05:36.0401 (UTC) FILETIME=[059C8810:01C29D0F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gB6A5pS16239 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 6 Dec 2002 10:05:35 -0000 Content-Transfer-Encoding: 8bit Hi Toni: Routers used to be referred to as gateways, and so they are, L3 gateways. But these days, people in groups such as AMIC refer to a mobile gateway meaning a multilayer gateway (L2 to L5). In Nemo, at the mment we only consider L3 mobility, so router fits better in my view. Pascal > -----Original Message----- > From: Toni Stoev [mailto:nemo@toni.powerdns.org] > Sent: vendredi 6 décembre 2002 06:54 > To: NeMo Discussion Subscribers; NeMo Discussion Subscribers > Subject: [nemo] Term word change > > > > Hi, everybody. > > I propose a term word change: > Mobile Gateway instead of Mobile Router > > Is it too late? > From nemo-admin@nal.motlabs.com Fri Dec 6 05:56:04 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01635 for ; Fri, 6 Dec 2002 05:56:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB6Av1S17013; Fri, 6 Dec 2002 11:57:01 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB6AuMS16977 for ; Fri, 6 Dec 2002 11:56:22 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gB6AuIY8021717; Fri, 6 Dec 2002 03:56:18 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id DAA03129; Fri, 6 Dec 2002 03:56:17 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/az33exr01) with ESMTP id gB6AuDE00787; Fri, 6 Dec 2002 04:56:14 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id AC5D02EC86; Fri, 6 Dec 2002 11:56:11 +0100 (CET) To: "T.J. Kniveton" Cc: Subject: Re: [nemo] Re: reqs again (Was: Meeting minutes from IETF55) References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 06 Dec 2002 11:56:11 +0100 "T.J. Kniveton" writes: > On 12/5/02 11:51 AM, "Alexandru Petrescu" wrote: > > > If yes, then I would like to mention one other scenario that could be > > turned into a requirement: > > > > Consider two MRs at home, having a unique HA. Then, the first MR > > stays at home but the second MR moves away from home and towards under > > the first MR. That could be seen as a kind of nested mobility I > > believe. A more generic question stemming from this could be whether > > two MRs of the same HA are required to be able to nest one under the > > other or not. Or maybe this is already covered by another > > requirement? > > How would this be different than a MN nesting under a MR? The second > MR that attaches to the first MR's mobile network will just look > like an MN to the MR and HA, right? Or is there some detail that > makes it a different case? Indeed it's not much different. There are some "nitty-gritty" details we noticed in practice about MR2 when is at home (neighbouring MR1 and HA) has ND entries that MUST be invaldated when the MR2 goes nesting under MR1. Additional detail is when several MRs have the same HA and are nesting one under the other the tunnel headers they built they all have the same destination address, the HA. So if three nested MRs then the three tunnels will contain redundant information (3 times the same destination address). Maybe in a first step we could require arbitrary number of MRs of same HA to be able to nest under each other and in later steps we could require a sort of optimization of "nested MRs same HA" case with sort of Deering-Zill tunnels. Or maybe this has already been discussed. Alex From nemo-admin@nal.motlabs.com Fri Dec 6 05:59:16 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01733 for ; Fri, 6 Dec 2002 05:59:15 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB6Ax1S17057; Fri, 6 Dec 2002 11:59:01 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB6AwWS17036 for ; Fri, 6 Dec 2002 11:58:33 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gB6AwYNC018932; Fri, 6 Dec 2002 03:58:35 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id DAA26790; Fri, 6 Dec 2002 03:58:27 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/il06exr06) with ESMTP id gB6AwP320746; Fri, 6 Dec 2002 04:58:26 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 752F62EC86; Fri, 6 Dec 2002 11:58:23 +0100 (CET) To: Toni Stoev Cc: NeMo Discussion Subscribers Subject: Re: [nemo] Term word change References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 06 Dec 2002 11:58:23 +0100 Toni Stoev writes: > I propose a term word change: > Mobile Gateway instead of Mobile Router Yes Toni please post why you would like so. We're experts in terminology and changing it, we adapt. To me, Gateway is so much like a bigger machine than a router. Alex From nemo-admin@nal.motlabs.com Fri Dec 6 11:16:58 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12363 for ; Fri, 6 Dec 2002 11:16:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB6GG7S23087; Fri, 6 Dec 2002 17:16:07 +0100 Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB6GFRS23077 for ; Fri, 6 Dec 2002 17:15:28 +0100 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id gB6GFLiv008493; Fri, 6 Dec 2002 10:15:21 -0600 (CST) Message-ID: <3DF0CD57.5070604@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: "T.J. Kniveton" , nemo@nal.motlabs.com Subject: Re: [nemo] Meeting minutes from IETF55 References: <3DEFD4CD.646334D@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------020802080709020405050400" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 06 Dec 2002 10:16:23 -0600 --------------020802080709020405050400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay, What this simply means that we may have two kinds of MNs in nemo, LMNs and VMNs. In MIPv6 there are home and visited link concepts. So for VMNs the link connected to NEMO becomes a visited link. For LMNs, the link could be their home link. Regards, Vijay Devarapalli wrote: >>#6 MIPv6 MNs can use link as home or visited link >> >> > >where can I find more details on this? > >Vijay > > > -- Behcet --------------020802080709020405050400 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Vijay,
  What this simply means that we may have two kinds of MNs in nemo,
LMNs and
VMNs.
In MIPv6 there are home and visited link concepts. So for VMNs  the link connected to NEMO becomes a visited link. For LMNs, the link could be their home link.

Regards,

Vijay Devarapalli wrote:
#6 MIPv6 MNs can use link as home or visited link
    

where can I find more details on this?

Vijay

  

-- 
Behcet

--------------020802080709020405050400-- From nemo-admin@nal.motlabs.com Fri Dec 6 19:24:28 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02712 for ; Fri, 6 Dec 2002 19:24:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB70N5S29939; Sat, 7 Dec 2002 01:23:06 +0100 Received: from web.plov.omega.bg (web.plov.omega.bg [212.50.0.221]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB70MBS29929 for ; Sat, 7 Dec 2002 01:22:12 +0100 Received: from server.plov.omega.bg ([212.91.164.67]) by web.plov.omega.bg with esmtp (Exim 3.35 #1 (Debian)) id 18KSTm-0006aD-00; Sat, 07 Dec 2002 02:05:58 +0200 Received: from dialup403.plovdiv.spnet.net ([213.169.37.147] helo=sender) by server.plov.omega.bg with smtp (Exim 3.12 #1 (Debian)) id 18KSTc-0008Ef-00; Sat, 07 Dec 2002 02:05:48 +0200 From: Toni Stoev To: "T.J. Kniveton" , Pascal Thubert , Alexandru Petrescu CC: NeMo Discussion Subscribers Subject: Re: [nemo] Term word change: Reason Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: X-Scanner: exiscan *18KSTc-0008Ef-00*7RBnl2GEuaM* http://duncanthrax.net/exiscan/ Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 07 Dec 2002 02:05:48 +0200 | > I propose a term word change: | > Mobile Gateway instead of Mobile Router | | Do you have any reason to justify this proposal? A mobile network node, which is a Router and also a Mobile Node through its own external link, may forward packets through the external link but not be used for reaching the mobile network through that link. This makes the node a mobile Router and not a gateway between the mobile network and other networks. From nemo-admin@nal.motlabs.com Mon Dec 9 08:36:31 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08613 for ; Mon, 9 Dec 2002 08:36:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB9DZ8S18051; Mon, 9 Dec 2002 14:35:08 +0100 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB9AqNS16983 for ; Mon, 9 Dec 2002 11:52:23 +0100 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.9.3/8.9.3) with ESMTP id MAA21183 for ; Mon, 9 Dec 2002 12:52:20 +0200 (EET) Received: from ele4114 (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with SMTP id MAA04433 for ; Mon, 9 Dec 2002 12:52:20 +0200 (EET) Message-ID: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> From: "=?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?=" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C29F81.CDFDB8F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [nemo] MR definition Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 9 Dec 2002 12:52:17 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C29F81.CDFDB8F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Please correct me if I have understood the definition of MR wrong. MR is : A router as defined in RFC 2460 : "a node that forwards IPv6 packets not = explicitly addressed to itself." In addition to this MR's relation to Neighbor Discovery (ND) is (RFC = 2461): - MR has host specific Neighbor Discovery behaviour in one or more = interfaces as defined in RFC 2461. (MR's egress interfaces) - MR has router specific Neighbor Discovery behaviour in one or more = interfaces as defined in RFC 2461. (MR's ingress interfaces) This would mean that MR would have different ND behaviour depending on = the=20 interface.=20 ------=_NextPart_000_0039_01C29F81.CDFDB8F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Please correct me if I have understood the = definition of MR=20 wrong.
 
MR is :
 
A router as defined in RFC 2460 : = "a node that forwards IPv6 packets not explicitly = addressed to itself."
 
In addition to this MR's relation to Neighbor = Discovery=20 (ND) is (RFC 2461):
 
- MR has host specific Neighbor Discovery behaviour = in one or=20 more interfaces as defined in RFC 2461. (MR's egress = interfaces)
- MR has router specific Neighbor Discovery = behaviour in one=20 or more interfaces as defined in RFC 2461. (MR's ingress=20 interfaces)
 
This would mean that MR would have different ND = behaviour=20 depending on the
interface.
 

------=_NextPart_000_0039_01C29F81.CDFDB8F0-- From nemo-admin@nal.motlabs.com Mon Dec 9 09:43:30 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11306 for ; Mon, 9 Dec 2002 09:43:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB9Eg3S18698; Mon, 9 Dec 2002 15:42:05 +0100 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB9EfLS18687 for ; Mon, 9 Dec 2002 15:41:22 +0100 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB9EfDQ1027163; Mon, 9 Dec 2002 15:41:13 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YCDZ79KZ; Mon, 9 Dec 2002 15:41:13 +0100 Message-ID: <3DF4AA9B.A6658FEE@era.ericsson.se> X-Sybari-Trust: b8c8cc14 ca231590 64e43b73 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka =?iso-8859-1?Q?P=E4=E4kk=F6nen?= CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 09 Dec 2002 15:37:15 +0100 Content-Transfer-Encoding: 8bit Hi Pekka, Pekka Pääkkönen wrote: > > Hi all, > This would mean that MR would have different ND behaviour depending on > the interface. Yes. Cf. with a multilink-subnet router, it has a proxy-mode interface and router-mode interfaces. /Mattias From nemo-admin@nal.motlabs.com Mon Dec 9 15:11:06 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28925 for ; Mon, 9 Dec 2002 15:11:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB9KB3S28142; Mon, 9 Dec 2002 21:11:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB9KAES28131 for ; Mon, 9 Dec 2002 21:10:14 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA28288; Mon, 9 Dec 2002 12:10:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gB9KA5525871; Mon, 9 Dec 2002 12:10:05 -0800 X-mProtect: <200212092010> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpd2PVro5; Mon, 09 Dec 2002 12:10:03 PST Message-ID: <3DF4F89C.B3C59542@kniveton.com> From: "T.J. Kniveton" Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka =?iso-8859-1?Q?P=E4=E4kk=F6nen?= CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 09 Dec 2002 12:10:04 -0800 Content-Transfer-Encoding: 8bit > Pekka Pddkkvnen wrote: > > Hi all, > > Please correct me if I have understood the definition of MR wrong. > > MR is : > > A router as defined in RFC 2460 : "a node that forwards IPv6 packets not > explicitly addressed to itself." Yes, this is the strict definition. There is a very fine line between a router and host when you look at it this way -- by changing one bit in my kernel sysctl variables, I can change my "host" into a "router". Most people also consider other factors, such as whether the node runs routing protocols, whether it is administratively responsible for certain prefixes, whether it is considered by other routers as the next hop to get to a prefix, etc. > In addition to this MR's relation to Neighbor Discovery (ND) is (RFC 2461): > > - MR has host specific Neighbor Discovery behaviour in one or more interfaces > as defined in RFC 2461. (MR's egress interfaces) > - MR has router specific Neighbor Discovery behaviour in one or more > interfaces as defined in RFC 2461. (MR's ingress interfaces) The second statement is certainly true. The first statement may or may not be true. In the Tunneled Mobile Router draft (draft-kniveton-mobrtr), there are two cases defined: Consumer and Fully-Enabled. In the consumer case, the MR may not be a trusted entity in the visited domain. In that case, it has no choice but to act like a host (lowest common denominator) in the visited domain to cooperate with the policies there, and use its COA to create a virtual link to its Home Agent, so that it can have the privelege of routing "upstream" through its home network. In the Fully-Enabled case, the MR is considered as a full-fledged router (beyond the ability to simply forward packets from one interface to another), and thus it would behave just like any other router in most respects, including neighbor discovery. > > This would mean that MR would have different ND behaviour depending on the > interface. May be true. A MR has to be versatile enough to use Mobile IP, and tunneling, to create a virtual link to its home network. That intelligence might include using host-like ND procedures. -TJ From nemo-admin@nal.motlabs.com Tue Dec 10 05:28:56 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03247 for ; Tue, 10 Dec 2002 05:28:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBAAR9S03430; Tue, 10 Dec 2002 11:27:10 +0100 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBAAQIS03420 for ; Tue, 10 Dec 2002 11:26:19 +0100 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.9.3/8.9.3) with ESMTP id MAA16822 for ; Tue, 10 Dec 2002 12:26:10 +0200 (EET) Received: from ele4114 (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with SMTP id MAA15095 for ; Tue, 10 Dec 2002 12:26:03 +0200 (EET) Message-ID: <017001c2a036$8deb2030$725ebc82@ele4114.ad.vtt.fi> From: "=?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?=" To: Subject: Re: [nemo] MR definition MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 10 Dec 2002 12:26:07 +0200 Content-Transfer-Encoding: 8bit -----Original Message----- From: T.J. Kniveton To: Pekka Pääkkönen Cc: nemo@nal.motlabs.com Date: 9. joulukuuta 2002 22:10 Subject: Re: [nemo] MR definition >> Pekka Pddkkvnen wrote: >> >> Hi all, >> >> Please correct me if I have understood the definition of MR wrong. >> >> MR is : >> >> A router as defined in RFC 2460 : "a node that forwards IPv6 packets not >> explicitly addressed to itself." > >Yes, this is the strict definition. There is a very fine line between a router >and host when you look at it this way -- by changing one bit in my kernel >sysctl variables, I can change my "host" into a "router". > >Most people also consider other factors, such as whether the node runs routing >protocols, whether it is administratively responsible for certain prefixes, >whether it is considered by other routers as the next hop to get to a prefix, >etc. > > >> In addition to this MR's relation to Neighbor Discovery (ND) is (RFC 2461): >> >> - MR has host specific Neighbor Discovery behaviour in one or more interfaces >> as defined in RFC 2461. (MR's egress interfaces) >> - MR has router specific Neighbor Discovery behaviour in one or more >> interfaces as defined in RFC 2461. (MR's ingress interfaces) > >The second statement is certainly true. > >The first statement may or may not be true. In the Tunneled Mobile Router draft >(draft-kniveton-mobrtr), there are two cases defined: Consumer and >Fully-Enabled. In the consumer case, the MR may not be a trusted entity in the >visited domain. In that case, it has no choice but to act like a host (lowest >common denominator) in the visited domain to cooperate with the policies there, >and use its COA to create a virtual link to its Home Agent, so that it can have >the privelege of routing "upstream" through its home network. > >In the Fully-Enabled case, the MR is considered as a full-fledged router >(beyond the ability to simply forward packets from one interface to another), >and thus it would behave just like any other router in most respects, including >neighbor discovery. > Doesn't the MR also need a global COA in the Fully-Enabled mode in order to create a bidirectional tunnel with its HA? To create a COA, MR has to have host-like ND procedures in order to create a COA on the egress interface, because router-like ND procedures on the egress interface do not create a COA based on received Router Advertisements. >> >> This would mean that MR would have different ND behaviour depending on the >> interface. > >May be true. A MR has to be versatile enough to use Mobile IP, and tunneling, >to create a virtual link to its home network. That intelligence might include >using host-like ND procedures. > >-TJ > From nemo-admin@nal.motlabs.com Tue Dec 10 07:20:01 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04692 for ; Tue, 10 Dec 2002 07:20:00 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBACK2S04350; Tue, 10 Dec 2002 13:20:02 +0100 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBACJiS04336 for ; Tue, 10 Dec 2002 13:19:44 +0100 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBACJhQ1017145; Tue, 10 Dec 2002 13:19:43 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YCD5DP9B; Tue, 10 Dec 2002 13:19:42 +0100 Message-ID: <3DF5DAF1.4B8BC409@era.ericsson.se> X-Sybari-Trust: ff2e5420 ca231590 9555c2c6 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka =?iso-8859-1?Q?P=E4=E4kk=F6nen?= CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 10 Dec 2002 13:15:45 +0100 Content-Transfer-Encoding: 8bit Hi again, Pekka Pääkkönen wrote: > > Hi all, > > Please correct me if I have understood the definition of MR wrong. > > MR is : > > A router as defined in RFC 2460 : "a node that forwards IPv6 packets > not explicitly addressed to itself." > > In addition to this MR's relation to Neighbor Discovery (ND) is (RFC > 2461): > > - MR has host specific Neighbor Discovery behaviour in one or more > interfaces as defined in RFC 2461. (MR's egress interfaces) > - MR has router specific Neighbor Discovery behaviour in one or more > interfaces as defined in RFC 2461. (MR's ingress interfaces) > > This would mean that MR would have different ND behaviour depending on > the > interface. I thought about this a little more. The MR may change its behaviour on its egress interface depending on where it is attached. For instance, if MR is at home the egress interface can be in router mode, but when MR is away the egress interface can be in host mode (and the router-mode functionality is moved to the bi-dir tunnel interface MRHA). Is the changing of behaviour on a particular interface something we desire? /Mattias From nemo-admin@nal.motlabs.com Tue Dec 10 08:23:40 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05736 for ; Tue, 10 Dec 2002 08:23:39 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBADO2S04816; Tue, 10 Dec 2002 14:24:02 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBADNuS04806 for ; Tue, 10 Dec 2002 14:23:56 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gBADNsCn021287; Tue, 10 Dec 2002 06:23:55 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id GAA04146; Tue, 10 Dec 2002 06:23:54 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/il06exr02) with ESMTP id gBADNlr05768; Tue, 10 Dec 2002 07:23:48 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 099382EC86; Tue, 10 Dec 2002 14:23:48 +0100 (CET) To: Mattias Pettersson Cc: Pekka =?iso-8859-1?q?P=E4=E4kk=F6nen?=, Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> <3DF5DAF1.4B8BC409@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: <3DF5DAF1.4B8BC409@era.ericsson.se> Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 10 Dec 2002 14:23:48 +0100 Mattias Pettersson writes: > I thought about this a little more. The MR may change its behaviour on > its egress interface depending on where it is attached. For instance, if > MR is at home the egress interface can be in router mode, but when MR is > away the egress interface can be in host mode (and the router-mode > functionality is moved to the bi-dir tunnel interface MRHA). So the description would work fine with many things, and less fine with other things: If we exemplify with "routing on the egress interface": when the MR is at home, it is in "router mode" and routes through the egress interface (it has entries in the routing table that point to the egress interace); when MR is not at home, it's in host mode and doesn't route through the egress interface (it has _not_ entries in the routing table pointing to the egress interface). But, if exemplify the above with the RA behaviour. When MR is at home, it sends RAs on the egress interface. When the MR is not at home, it is in "host mode", it sends RAs on the bi-dir tunnel interface MRHA. Maybe the home link doesn't need those RAs when the MR is not at home? > Is the changing of behaviour on a particular interface something we > desire? I would say yes, but it's only one oppinion. Alex From nemo-admin@nal.motlabs.com Tue Dec 10 13:05:22 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16128 for ; Tue, 10 Dec 2002 13:05:11 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBAHvNS15179; Tue, 10 Dec 2002 18:57:28 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBAHuYS15095 for ; Tue, 10 Dec 2002 18:56:37 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA19804; Tue, 10 Dec 2002 09:56:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBAHu5917632; Tue, 10 Dec 2002 09:56:05 -0800 X-mProtect: <200212101756> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdP1eFmx; Tue, 10 Dec 2002 09:56:04 PST Message-ID: <3DF62AB4.B4DDC34F@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Mattias Pettersson , "Pekka =?iso-8859-1?Q?P=E4=E4kk=F6nen?=" , nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> <3DF5DAF1.4B8BC409@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 10 Dec 2002 09:56:04 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > When the MR is not at > home, it is in "host mode", it sends RAs on the bi-dir tunnel > interface MRHA. Maybe the home link doesn't need those RAs when the > MR is not at home? the home link does not need the RAs from the MR, when the MR is not at home. the MR shouldnt tunnel the RAs through the bi-directional tunnel. Vijay From nemo-admin@nal.motlabs.com Tue Dec 10 15:03:09 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19375 for ; Tue, 10 Dec 2002 15:02:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBAJpES23005; Tue, 10 Dec 2002 20:51:20 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBAJo9S22992 for ; Tue, 10 Dec 2002 20:50:23 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gBAJna7r008991; Tue, 10 Dec 2002 12:49:37 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA25444; Tue, 10 Dec 2002 12:49:36 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (8.11.6/az33exr04) with ESMTP id gBAJkDY25629; Tue, 10 Dec 2002 13:46:14 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id DD4552EC86; Tue, 10 Dec 2002 20:46:20 +0100 (CET) To: Vijay Devarapalli Cc: Mattias Pettersson, "Pekka =?iso-8859-1?q?P=E4=E4kk=F6nen?=", Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> <3DF5DAF1.4B8BC409@era.ericsson.se> <3DF62AB4.B4DDC34F@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DF62AB4.B4DDC34F@iprg.nokia.com> Message-ID: Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 10 Dec 2002 20:46:20 +0100 Vijay Devarapalli writes: > > When the MR is not at > > home, it is in "host mode", it sends RAs on the bi-dir tunnel > > interface MRHA. Maybe the home link doesn't need those RAs when the > > MR is not at home? > > the home link does not need the RAs from the MR, when the MR is > not at home. the MR shouldnt tunnel the RAs through the > bi-directional tunnel. Yes, that is reasonable. Should the MR send ICMP redirects when it is not at home, and through the MRHA tunnel, towards the home link? Probably not. If a host on the home link sends an RS on the home link towards the all-routers multicast address, and the MR is not at home, should the MR obtain that RS throught the MRHA tunnel? Should MR respond to that RS with an RA? If MR is at home and is subscribed to the all-routers multicast address with link scope, should this subscription continue when the MR is not at home? If MR is at home and is subscribed to the all-routers multicast address with scope other than link, should this subscription continue when the MR is not at home? Should it be possible for the MR to be renumbered when it is not at home, as if it were at home? Alex From nemo-admin@nal.motlabs.com Tue Dec 10 22:20:11 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29750 for ; Tue, 10 Dec 2002 22:20:00 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBB3E6S25545; Wed, 11 Dec 2002 04:14:06 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBB3DiS25535 for ; Wed, 11 Dec 2002 04:13:44 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA13698; Tue, 10 Dec 2002 19:13:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBB3DZh24378; Tue, 10 Dec 2002 19:13:35 -0800 X-mProtect: <200212110313> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzTHm9W; Tue, 10 Dec 2002 19:13:33 PST Message-ID: <3DF6AD5D.4FABF6E2@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Mattias Pettersson , "Pekka =?iso-8859-1?Q?P=E4=E4kk=F6nen?=" , nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> <3DF5DAF1.4B8BC409@era.ericsson.se> <3DF62AB4.B4DDC34F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 10 Dec 2002 19:13:33 -0800 Content-Transfer-Encoding: 7bit hi Alex, before tunneling a packet through the bi-directional tunnel, we have to see if the packet serves any purpose. for example it makes no sense for the MR to send a router advert through the bi-directional tunnel in response to a router solicitation when it is away from the home. the tunneled router advert is of no use to anyone. the HA shouldnt have tunneled the router solicitation to the MR in the first place. Alexandru Petrescu wrote: > If a host on the home link sends an RS on the home link towards the > all-routers multicast address, and the MR is not at home, should the > MR obtain that RS throught the MRHA tunnel? no. > Should MR respond to that > RS with an RA? no. > If MR is at home and is subscribed to the all-routers multicast > address with link scope, should this subscription continue when the MR > is not at home? no. if it is useful then maybe yes. do you have a scenario where it would be useful? > If MR is at home and is subscribed to the all-routers multicast > address with scope other than link, should this subscription continue what is this multicast address used for? > Should it be possible for the MR to be renumbered when it is not at > home, as if it were at home? maybe yes. it can be done if we tunnel Router Renumbering Command/Result messages through the bi-directional tunnel. but I see your point. it can get quite complicated if the HA has to inspect every packet before tunneling it to the MR. Vijay From nemo-admin@nal.motlabs.com Wed Dec 11 04:42:45 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29705 for ; Wed, 11 Dec 2002 04:42:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBB9h3S28532; Wed, 11 Dec 2002 10:43:04 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBB9g6S28522 for ; Wed, 11 Dec 2002 10:42:06 +0100 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBB9g5KV007205; Wed, 11 Dec 2002 10:42:05 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Y3GZLQ27; Wed, 11 Dec 2002 10:42:04 +0100 Message-ID: <3DF7077F.F7FEFCF0@era.ericsson.se> X-Sybari-Trust: ac679971 ca231590 9555c2c6 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> <3DF5DAF1.4B8BC409@era.ericsson.se> <3DF62AB4.B4DDC34F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 11 Dec 2002 10:38:07 +0100 Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > > Alexandru Petrescu wrote: > > > > When the MR is not at > > home, it is in "host mode", it sends RAs on the bi-dir tunnel > > interface MRHA. Maybe the home link doesn't need those RAs when the > > MR is not at home? > > the home link does not need the RAs from the MR, when the MR is > not at home. the MR shouldnt tunnel the RAs through the > bi-directional tunnel. I agree. I also would ask: why should MR send RAs when at home? It is not a default router of the home link, as it will not be able to route towards the Internet. The only other network MR is connected to is a leaf network (the mobile network). /Mattias From nemo-admin@nal.motlabs.com Wed Dec 11 05:14:24 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00221 for ; Wed, 11 Dec 2002 05:14:22 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBBAF2S28657; Wed, 11 Dec 2002 11:15:02 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBBAEGS28645 for ; Wed, 11 Dec 2002 11:14:17 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gBBAELlD020637; Wed, 11 Dec 2002 03:14:22 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id DAA24337; Wed, 11 Dec 2002 03:09:27 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/il06exr02) with ESMTP id gBBAE5r05704; Wed, 11 Dec 2002 04:14:06 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 08FEA2EC86; Wed, 11 Dec 2002 11:14:05 +0100 (CET) To: Mattias Pettersson Cc: Vijay Devarapalli, Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> <3DF5DAF1.4B8BC409@era.ericsson.se> <3DF62AB4.B4DDC34F@iprg.nokia.com> <3DF7077F.F7FEFCF0@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: <3DF7077F.F7FEFCF0@era.ericsson.se> Message-ID: Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Dec 2002 11:14:05 +0100 Mattias Pettersson writes: > Vijay Devarapalli wrote: > > > > Alexandru Petrescu wrote: > > > > > > When the MR is not at > > > home, it is in "host mode", it sends RAs on the bi-dir tunnel > > > interface MRHA. Maybe the home link doesn't need those RAs when the > > > MR is not at home? > > > > the home link does not need the RAs from the MR, when the MR is > > not at home. the MR shouldnt tunnel the RAs through the > > bi-directional tunnel. > > I agree. I also would ask: why should MR send RAs when at home? It is > not a default router of the home link, as it will not be able to route > towards the Internet. The only other network MR is connected to is a > leaf network (the mobile network). RAs help setting a default route, and it is probably not necessary for MRs to advertise themselves as default routers on the home link. But RAs also advertise the prefixes of the home link, in the home link, and this is be helpful for address autoconfiguration. For example, if several MRs are at home and advertising RAs (w/ exponential backoff or something to avoid peak sudden network loads) then another MR coming back home will have more chances to identify it is back home based on info from those RAs. If it's only the BR/HA that sends these RAs then maybe an MR coming back home will take more time to realize it is back home. So, maybe useful, or maybe not. So, "MR MAY advertise RAs when at home"? Or, "MRs SHOULD NOT advertise RAs when at home because they are not default routers at home"? Alex From nemo-admin@nal.motlabs.com Wed Dec 11 08:32:55 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04337 for ; Wed, 11 Dec 2002 08:32:53 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBBDXCS29437; Wed, 11 Dec 2002 14:33:12 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBBDWES29422 for ; Wed, 11 Dec 2002 14:32:14 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gBBDWBvT017746; Wed, 11 Dec 2002 06:32:11 -0700 (MST) Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA16177; Wed, 11 Dec 2002 06:32:10 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/az33exr03) with ESMTP id gBBDVcp20450; Wed, 11 Dec 2002 07:31:38 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 9586C2EC86; Wed, 11 Dec 2002 14:28:55 +0100 (CET) To: Vijay Devarapalli Cc: Mattias Pettersson, "Pekka =?iso-8859-1?q?P=E4=E4kk=F6nen?=", Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> <3DF5DAF1.4B8BC409@era.ericsson.se> <3DF62AB4.B4DDC34F@iprg.nokia.com> <3DF6AD5D.4FABF6E2@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DF6AD5D.4FABF6E2@iprg.nokia.com> Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Dec 2002 14:28:55 +0100 Vijay Devarapalli writes: > > If MR is at home and is subscribed to the all-routers multicast > > address with scope other than link, should this subscription continue > > what is this multicast address used for? For example router renumbering? For example a central administration point in the home domain decides to renumber all routers belonging to that home and thus sends a message to all-routers multicast address within that domain. Alex From nemo-admin@nal.motlabs.com Wed Dec 11 12:58:51 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14703 for ; Wed, 11 Dec 2002 12:58:50 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBBHw4S32265; Wed, 11 Dec 2002 18:58:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBBHv9S32213 for ; Wed, 11 Dec 2002 18:57:09 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA13275; Wed, 11 Dec 2002 09:57:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBBHv0U13301; Wed, 11 Dec 2002 09:57:00 -0800 X-mProtect: <200212111757> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhYARVr; Wed, 11 Dec 2002 09:56:58 PST Message-ID: <3DF77C6B.B4CC8E6F@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Mattias Pettersson , nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> <3DF5DAF1.4B8BC409@era.ericsson.se> <3DF62AB4.B4DDC34F@iprg.nokia.com> <3DF7077F.F7FEFCF0@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 11 Dec 2002 09:56:59 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > > RAs help setting a default route, and it is probably not necessary for > MRs to advertise themselves as default routers on the home link. But > RAs also advertise the prefixes of the home link, in the home link, > and this is be helpful for address autoconfiguration. For example, if > several MRs are at home and advertising RAs (w/ exponential backoff or > something to avoid peak sudden network loads) then another MR coming > back home will have more chances to identify it is back home based on > info from those RAs. If it's only the BR/HA that sends these RAs then > maybe an MR coming back home will take more time to realize it is back > home. this is a wrong mechanism for an MR to figure out that it is home. configure your HA or any router on the home link to send out more frequent router advertisements. or better still have some triggers on MR which sends out a router solicitation as soon as it detects a link up. > Or, "MRs SHOULD NOT advertise RAs when at home because they > are not default routers at home"? on the egress interface, yes. Vijay From nemo-admin@nal.motlabs.com Wed Dec 11 13:29:35 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15635 for ; Wed, 11 Dec 2002 13:29:34 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBBIT2S00840; Wed, 11 Dec 2002 19:29:02 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBBISqS00828 for ; Wed, 11 Dec 2002 19:28:52 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gBBISml1001974; Wed, 11 Dec 2002 11:28:48 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA20529; Wed, 11 Dec 2002 11:28:47 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/il06exr01) with ESMTP id gBBISec21233; Wed, 11 Dec 2002 12:28:41 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 474182EC86; Wed, 11 Dec 2002 19:28:41 +0100 (CET) To: Vijay Devarapalli Cc: Mattias Pettersson, Subject: Re: [nemo] MR definition References: <003c01c29f71$0b53fe50$725ebc82@ele4114.ad.vtt.fi> <3DF5DAF1.4B8BC409@era.ericsson.se> <3DF62AB4.B4DDC34F@iprg.nokia.com> <3DF7077F.F7FEFCF0@era.ericsson.se> <3DF77C6B.B4CC8E6F@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DF77C6B.B4CC8E6F@iprg.nokia.com> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Dec 2002 19:28:41 +0100 Vijay Devarapalli writes: > this is a wrong mechanism for an MR to figure out that it is > home. configure your HA or any router on the home link to > send out more frequent router advertisements. or better still > have some triggers on MR which sends out a router solicitation > as soon as it detects a link up. Yes, these are two more performant alternatives. With respect to the first approach, one can argue that same machine sending frequent RAs is higher load than same task performed by a set of routers sending RAs less frequently. But you're right that this might be an configurational issue only. In the second approach, the high constant load is eliminated and offers an RA only when needed, thus looks very interesting. Unfortunately, routers do not send RSs. An MR (its egress) can send RSs only if it acts like a router, and it logically does so only if it is at home. Following this, maybe we can suggest text where MR always acts like a host, always sends RSs. Except when it knows it is at home, it no longer sends RSs. If on the other hand MR would use "RA listening" to detect it is at home, the above suggestion is worthless (we can get away without the above text), because both hosts and routers listen to RAs. Right? Alex From nemo-admin@nal.motlabs.com Thu Dec 12 02:38:08 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15613 for ; Thu, 12 Dec 2002 02:38:06 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBC7c3S04206; Thu, 12 Dec 2002 08:38:04 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBC7bsS04196 for ; Thu, 12 Dec 2002 08:37:54 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBC7aNLi010826; Thu, 12 Dec 2002 08:36:25 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 12 Dec 2002 08:37:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A1B1.57E53D14" Subject: RE: [nemo] MR definition Message-ID: Thread-Topic: [nemo] MR definition Thread-Index: AcKfiXLRoN5KWsdbTauRKAPEgvXVmgCI/F3g From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?= , X-OriginalArrivalTime: 12 Dec 2002 07:37:38.0084 (UTC) FILETIME=[58335E40:01C2A1B1] Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 12 Dec 2002 07:37:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2A1B1.57E53D14 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is that fair from all this discussion to consider that for basic = support, Pekka's summary is correct? For one, this seems to work fine, = and second this saves a lot of text in basic support doc by simple = inheritence from knell-known models.=20 =20 Still for basic support, I suppose we need to extend Pekka for some = MIPv6 support as well. On the egress interface the basic support for = Nemo would include Mobile Node (RO and CN excluded). And MIPv6 support = by all routers should be present on all ingress interfaces, correct? =20 Pascal -----Original Message----- From: Pekka P=E4=E4kk=F6nen [mailto:Pekka.Paakkonen@vtt.fi]=20 Sent: lundi 9 d=E9cembre 2002 11:52 To: nemo@nal.motlabs.com Subject: [nemo] MR definition Hi all, =20 Please correct me if I have understood the definition of MR wrong. =20 MR is : =20 A router as defined in RFC 2460 : "a node that forwards IPv6 packets not = explicitly addressed to itself." =20 In addition to this MR's relation to Neighbor Discovery (ND) is (RFC = 2461): =20 - MR has host specific Neighbor Discovery behaviour in one or more = interfaces as defined in RFC 2461. (MR's egress interfaces) - MR has router specific Neighbor Discovery behaviour in one or more = interfaces as defined in RFC 2461. (MR's ingress interfaces) =20 This would mean that MR would have different ND behaviour depending on = the=20 interface.=20 =20 ------_=_NextPart_001_01C2A1B1.57E53D14 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Is that fair from all this discussion to = consider that=20 for basic support, Pekka's summary is correct? For one, this seems to = work fine,=20 and second this saves a lot of text in basic support doc by simple = inheritence=20 from knell-known models. 
 
Still=20 for basic support, I suppose we need to extend Pekka for some MIPv6 = support=20 as well. On the egress interface the basic support = for=20 Nemo would include Mobile Node (RO and CN excluded). And = MIPv6=20 support by all routers should be present on all ingress interfaces,=20 correct?
 
Pascal
-----Original Message-----
From: = Pekka P=E4=E4kk=F6nen=20 [mailto:Pekka.Paakkonen@vtt.fi]
Sent: lundi 9 d=E9cembre = 2002=20 11:52
To: nemo@nal.motlabs.com
Subject: [nemo] MR=20 definition

Hi all,
 
Please correct me if I have understood the = definition of MR=20 wrong.
 
MR is :
 
A router as defined in RFC 2460 : = "a node that forwards IPv6 packets not explicitly = addressed to itself."
 
In addition to this MR's relation to Neighbor = Discovery=20 (ND) is (RFC 2461):
 
- MR has host specific Neighbor Discovery = behaviour in one=20 or more interfaces as defined in RFC 2461. (MR's egress=20 interfaces)
- MR has router specific Neighbor Discovery = behaviour in one=20 or more interfaces as defined in RFC 2461. (MR's ingress=20 interfaces)
 
This would mean that MR would have different ND = behaviour=20 depending on the
interface.
 

------_=_NextPart_001_01C2A1B1.57E53D14-- From nemo-admin@nal.motlabs.com Fri Dec 13 03:49:43 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18349 for ; Fri, 13 Dec 2002 03:49:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBD8p4S11677; Fri, 13 Dec 2002 09:51:04 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBD8oXS11667 for ; Fri, 13 Dec 2002 09:50:33 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gBD8oVCT028515; Fri, 13 Dec 2002 01:50:31 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id BAA28511; Fri, 13 Dec 2002 01:45:43 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/il06exr04) with ESMTP id gBD8oPg08412; Fri, 13 Dec 2002 02:50:26 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 9052C2EC86; Fri, 13 Dec 2002 09:50:25 +0100 (CET) To: "Pascal Thubert (pthubert)" Cc: Pekka =?iso-8859-1?q?P=E4=E4kk=F6nen?=, Subject: Re: [nemo] MR definition References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Dec 2002 09:50:24 +0100 "Pascal Thubert (pthubert)" writes: > Is that fair from all this discussion to consider that for basic > support, Pekka's summary is correct? For one, this seems to work > fine, and second this saves a lot of text in basic support doc by > simple inheritence from knell-known models. YEs, I see PEkka's summary as correct and good paragraph beginning. > Still for basic support, I suppose we need to extend Pekka for some > MIPv6 support as well. On the egress interface the basic support for > Nemo would include Mobile Node (RO and CN excluded). And MIPv6 > support by all routers should be present on all ingress interfaces, > correct? I do not understand what you mean? Not all routers will need to support NEMO, only the mobile routers and the HAs, right? Alex From nemo-admin@nal.motlabs.com Fri Dec 13 04:55:20 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19174 for ; Fri, 13 Dec 2002 04:55:19 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBD9v2S12381; Fri, 13 Dec 2002 10:57:02 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBD9ukS12371 for ; Fri, 13 Dec 2002 10:56:46 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBD9tB7I011192; Fri, 13 Dec 2002 10:55:12 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 13 Dec 2002 10:55:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [nemo] MR definition Message-ID: Thread-Topic: [nemo] MR definition Thread-Index: AcKihL18H/2O3a4lTkGM0fyVs7XIQgAAyAwA From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 13 Dec 2002 09:55:40.0878 (UTC) FILETIME=[CB8B2EE0:01C2A28D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gBD9ukS12371 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 13 Dec 2002 09:55:40 -0000 Content-Transfer-Encoding: 8bit >> MIPv6 support by all routers should be present on all ingress interfaces, correct? > > I do not understand what you mean? Not all routers will need > to support NEMO, only the mobile routers and the HAs, right? Sorry for being unclear. I meant requirements 8.1 (easy) and 8.3 page 62 in MIPv6 draft 19 should be part of Nemo basic support for MRs on all ingress interfaces. The MIPv6 support on egress interface is the tricky thing that we'll have to define. I guess basic support does not need RO as a MN or CN at all, does it? The way I see it, we'd need a subset of 8.5, excluding the RR procedure, and we should not need section 9. What do you think? Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@crm.mot.com] > Sent: vendredi 13 décembre 2002 09:50 > To: Pascal Thubert (pthubert) > Cc: Pekka Pääkkönen; nemo@nal.motlabs.com > Subject: Re: [nemo] MR definition > > > "Pascal Thubert (pthubert)" writes: > > Is that fair from all this discussion to consider that for basic > > support, Pekka's summary is correct? For one, this seems to > work fine, > > and second this saves a lot of text in basic support doc by simple > > inheritence from knell-known models. > > YEs, I see PEkka's summary as correct and good paragraph beginning. > > > Still for basic support, I suppose we need to extend Pekka for some > > MIPv6 support as well. On the egress interface the basic > support for > > Nemo would include Mobile Node (RO and CN excluded). And > MIPv6 support > > by all routers should be present on all ingress interfaces, correct? > > I do not understand what you mean? Not all routers will need > to support NEMO, only the mobile routers and the HAs, right? > > Alex > > From nemo-admin@nal.motlabs.com Fri Dec 13 07:01:48 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21334 for ; Fri, 13 Dec 2002 07:01:47 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDC23S12977; Fri, 13 Dec 2002 13:02:03 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDC1ZS12967 for ; Fri, 13 Dec 2002 13:01:35 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gBDC1XCT018783 for ; Fri, 13 Dec 2002 05:01:33 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA18906 for ; Fri, 13 Dec 2002 05:01:33 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/il06exr03) with ESMTP id gBDBwIY14671; Fri, 13 Dec 2002 05:58:18 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 961252EC86; Fri, 13 Dec 2002 12:58:19 +0100 (CET) To: "Pascal Thubert (pthubert)" Cc: Subject: Re: [nemo] MR definition References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 113 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Dec 2002 12:58:19 +0100 "Pascal Thubert (pthubert)" writes: > >> MIPv6 support by all routers should be present on all ingress > >> interfaces, correct? > > > > I do not understand what you mean? Not all routers will need > > to support NEMO, only the mobile routers and the HAs, right? > > Sorry for being unclear. I meant requirements 8.1 (easy) and 8.3 > page 62 in MIPv6 draft 19 should be part of Nemo basic support for > MRs on all ingress interfaces. Ah yes, I see. Let me give it a try at fitting Mobile IP HA requirements with NEMO HA requirements. From draft-mobileip: "8.1. All IPv6 Nodes Any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node. There are no Mobile IPv6 specific requirements for such nodes, and standard IPv6 techniques are sufficient." Is indeed easy, it's same for MR, as you say. "- Every home agent MUST be able to maintain an entry in its Binding Cache for each mobile node for which it is serving as the home agent (Sections 10.1 and 10.3.1)." Same. "- Every home agent MUST be able to intercept packets (using proxy Neighbor Discovery [12]) addressed to a mobile node for which it is currently serving as the home agent, on that mobile node's home link, while the mobile node is away from home (Section 10.4.1)." Same. "- Every home agent MUST be able to encapsulate [15] such intercepted packets in order to tunnel them to the primary care-of address for the mobile node indicated in its binding in the home agent's Binding Cache (Section 10.4.2)." Same. "- Every home agent MUST support decapsulating [15] reverse tunneled packets sent to it from a mobile node's home address. Every home agent MUST also check that the source address in the tunneled packets corresponds to the currently registered location of the mobile node (Section 10.4.3)." In the MR case, the src address of the encapsulated packet is not MR's CoA, but it is the fixed address of an LFN or the address of a visiting MH that derives its CoA from the MNP. This is probably a security threat. "- The node MUST be able to process Mobility Headers as described in Section 10.2." Same. "- Every home agent MUST be able to return a Binding Acknowledgement in response to a Binding Update (Section 10.3.1)." Same. "- Every home agent MUST maintain a separate Home Agents List for each link on which it is serving as a home agent, as described in Sections 10.1 and 10.5.1." Same. "- Every home agent MUST be able to accept packets addressed to the Mobile IPv6 Home-Agents anycast address for the subnet on which it is serving as a home agent [16], and MUST be able to participate in dynamic home agent address discovery (Section 10.5)." Same. "- Every home agent SHOULD support a configuration mechanism to allow a system administrator to manually set the value to be sent by this home agent in the Home Agent Preference field of the Home Agent Information Option in Router Advertisements that it sends (Section 7.4)." Same. "- Every home agent SHOULD support sending ICMP Mobile Prefix Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix Solicitations (Section 6.7). This behavior MUST be configurable, so that home agents can be configured to avoid sending such Prefix Advertisements according to the needs of the network administration in the home domain." In the NEMO case, this SHOULD could be a MAY. MR will probably not need Mobile Prefix Advertisements from its home link. We were saying previously that MR will probably not need to receive RAs from the home link, so neither will it need Mobile Prefix Advertisements. "- Every home agent MUST support IPsec ESP for protection of packets belonging to the return routability procedure (Section 10.4.4)." Depends on RO issues in NEMO. In addition to the above requirements, if MRTP with MRHA uses dynamic routing protocols between MR and HA then "HA MUST subscribe to the all-routers mc address with link scope". What do you think? Alex From nemo-admin@nal.motlabs.com Fri Dec 13 07:41:27 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21968 for ; Fri, 13 Dec 2002 07:41:26 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDCd1S13211; Fri, 13 Dec 2002 13:39:01 +0100 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDCcoS13201 for ; Fri, 13 Dec 2002 13:38:50 +0100 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBDCcnQ1006950; Fri, 13 Dec 2002 13:38:49 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YV61V80H; Fri, 13 Dec 2002 13:38:48 +0100 Message-ID: <3DF9D3DC.1DA2184A@era.ericsson.se> X-Sybari-Trust: 70196233 ca231590 8cae28c9 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 13 Dec 2002 13:34:37 +0100 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > "- Every home agent MUST support decapsulating [15] reverse tunneled > packets sent to it from a mobile node's home address. Every home > agent MUST also check that the source address in the tunneled > packets corresponds to the currently registered location of the > mobile node (Section 10.4.3)." > > In the MR case, the src address of the encapsulated packet is not MR's > CoA, but it is the fixed address of an LFN or the address of a > visiting MH that derives its CoA from the MNP. This is probably a > security threat. I don't know what you mean. I think the I-D talks about the source address of the outer packet. It should be equal to the current CoA of MR. Nothing new. /Mattias From nemo-admin@nal.motlabs.com Fri Dec 13 07:52:55 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22222 for ; Fri, 13 Dec 2002 07:52:54 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDCt3S13294; Fri, 13 Dec 2002 13:55:03 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDCsTS13282 for ; Fri, 13 Dec 2002 13:54:29 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gBDCsRgn002084 for ; Fri, 13 Dec 2002 05:54:27 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id FAA08424 for ; Fri, 13 Dec 2002 05:49:40 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/il06exr02) with ESMTP id gBDCsLr24575; Fri, 13 Dec 2002 06:54:21 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 7C32A2EC86; Fri, 13 Dec 2002 13:54:21 +0100 (CET) To: Mattias Pettersson Cc: Subject: Re: [nemo] MR definition References: <3DF9D3DC.1DA2184A@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: <3DF9D3DC.1DA2184A@era.ericsson.se> Message-ID: Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Dec 2002 13:54:21 +0100 Mattias Pettersson writes: > Alexandru Petrescu wrote: > > > > "- Every home agent MUST support decapsulating [15] reverse tunneled > > packets sent to it from a mobile node's home address. Every home > > agent MUST also check that the source address in the tunneled > > packets corresponds to the currently registered location of the > > mobile node (Section 10.4.3)." > > > > In the MR case, the src address of the encapsulated packet is not MR's > > CoA, but it is the fixed address of an LFN or the address of a > > visiting MH that derives its CoA from the MNP. This is probably a > > security threat. > > I don't know what you mean. > > I think the I-D talks about the source address of the outer packet. It > should be equal to the current CoA of MR. Nothing new. I don't know what they mean. I thought that they wanted that, in the MH case (MH: mobile host), the HA checks the source address of the packet that is tunnelled (inner packet's src) and ensure that that src address equals the home address corresponding to the CoA that is registered in the binding cache. That's how I interpreted the above paragraph. If that interpretation is correct, and in the MR case, then that check would fail because the inner packet's src address does not equal the outer packet's CoA in the binding cache entry. Thus there would be a need for HA to act differently for MRs than for MHs. And if that check was considered to be useful for MH to prevent security attacks, and we eliminate that check in NEMO, we validate the security attacks. Of course, if my interpretation of the MIPv6 paragraph is wrong, and the HA only checks for the src address of the received outer packet, then that src address is indeed MR's CoA, and then indeed there's nothing new for NEMO. The only suggestion would be to change to - Every home agent MUST support decapsulating [15] reverse tunneled packets sent to it from a mobile node's home address. Every home agent MUST also check that the source address in the outer header corresponds to the currently registered location of the mobile node (Section 10.4.3). Note change "the source address in the tunneled packets" to "the source address in the outer header" Alex From nemo-admin@nal.motlabs.com Fri Dec 13 08:18:13 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22647 for ; Fri, 13 Dec 2002 08:18:12 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDDF3S13531; Fri, 13 Dec 2002 14:15:03 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDDEHS13519 for ; Fri, 13 Dec 2002 14:14:17 +0100 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBDDECKV008823; Fri, 13 Dec 2002 14:14:13 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YV61W2CQ; Fri, 13 Dec 2002 14:14:12 +0100 Message-ID: <3DF9DC22.FDC62DED@era.ericsson.se> X-Sybari-Trust: db62136f ca231590 8cae28c9 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <3DF9D3DC.1DA2184A@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 13 Dec 2002 14:09:54 +0100 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Mattias Pettersson writes: > > Alexandru Petrescu wrote: > > > > > > "- Every home agent MUST support decapsulating [15] reverse tunneled > > > packets sent to it from a mobile node's home address. Every home > > > agent MUST also check that the source address in the tunneled > > > packets corresponds to the currently registered location of the > > > mobile node (Section 10.4.3)." > > > > > > In the MR case, the src address of the encapsulated packet is not MR's > > > CoA, but it is the fixed address of an LFN or the address of a > > > visiting MH that derives its CoA from the MNP. This is probably a > > > security threat. > > > > I don't know what you mean. > > > > I think the I-D talks about the source address of the outer packet. It > > should be equal to the current CoA of MR. Nothing new. > > I don't know what they mean. > > I thought that they wanted that, in the MH case (MH: mobile host), the > HA checks the source address of the packet that is tunnelled (inner > packet's src) and ensure that that src address equals the home address > corresponding to the CoA that is registered in the binding cache. > That's how I interpreted the above paragraph. If that interpretation > is correct, and in the MR case, then that check would fail because the > inner packet's src address does not equal the outer packet's CoA in > the binding cache entry. Thus there would be a need for HA to act > differently for MRs than for MHs. And if that check was considered to > be useful for MH to prevent security attacks, and we eliminate that > check in NEMO, we validate the security attacks. Ok, I can see your concern. I don't know if such a thing has ever been discussed in Mobile IP, although it may be a very reasonable thing to do. In general, checking the source address of packets would certainly help for various reasons. Maybe we can add a recommendation that a Home Agent supporting NEMOs should perform ingress filtering, so that only topologically correct packets leave the HA. > > Of course, if my interpretation of the MIPv6 paragraph is wrong, and > the HA only checks for the src address of the received outer packet, > then that src address is indeed MR's CoA, and then indeed there's > nothing new for NEMO. The only suggestion would be to change to > > - Every home agent MUST support decapsulating [15] reverse tunneled > packets sent to it from a mobile node's home address. Every home > agent MUST also check that the source address in the outer header > corresponds to the currently registered location of the mobile node > (Section 10.4.3). > > Note change "the source address in the tunneled packets" to > "the source address in the outer header" Sounds better. /Mattias From nemo-admin@nal.motlabs.com Fri Dec 13 08:40:26 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22959 for ; Fri, 13 Dec 2002 08:40:25 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDDf1S13678; Fri, 13 Dec 2002 14:41:01 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDDeIS13668 for ; Fri, 13 Dec 2002 14:40:18 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gBDDeFCT010657; Fri, 13 Dec 2002 06:40:15 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id GAA01363; Fri, 13 Dec 2002 06:40:14 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/az33exr02) with ESMTP id gBDDeOD31632; Fri, 13 Dec 2002 07:40:25 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0455B2EC86; Fri, 13 Dec 2002 14:40:10 +0100 (CET) To: Mattias Pettersson Cc: Subject: Re: [nemo] MR definition References: <3DF9D3DC.1DA2184A@era.ericsson.se> <3DF9DC22.FDC62DED@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: <3DF9DC22.FDC62DED@era.ericsson.se> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Dec 2002 14:40:10 +0100 Mattias Pettersson writes: > Ok, I can see your concern. I don't know if such a thing has ever been > discussed in Mobile IP, although it may be a very reasonable thing to > do. I don't know either, might very well be that IPsec protects everything between MH and HA (sorry for using MH instead of MN) and thus no need of these kinds of "functional" checks. > In general, checking the source address of packets would certainly > help for various reasons. Yes. > Maybe we can add a recommendation that a Home Agent supporting NEMOs > should perform ingress filtering, so that only topologically correct > packets leave the HA. Could you be more explicit? Do you mean that LFN sends packet to CN: goes to MR that encapsulates towards HA that decapsulates and, before sending, checks to see the source of that outgoing packet is correct? Or something else? What is ingress filtering at the HA? Alex From nemo-admin@nal.motlabs.com Fri Dec 13 09:20:19 2002 Received: from jessica.nal.motlabs.com ([195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24011 for ; Fri, 13 Dec 2002 09:20:18 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDE61S13854; Fri, 13 Dec 2002 15:06:01 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBDE5TS13844 for ; Fri, 13 Dec 2002 15:05:29 +0100 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBDE5SKV024235; Fri, 13 Dec 2002 15:05:28 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YV61WW18; Fri, 13 Dec 2002 15:05:28 +0100 Message-ID: <3DF9E812.348CC619@era.ericsson.se> X-Sybari-Trust: f05cabfc ca231590 8becf6dc 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <3DF9D3DC.1DA2184A@era.ericsson.se> <3DF9DC22.FDC62DED@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 13 Dec 2002 15:00:50 +0100 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > > Maybe we can add a recommendation that a Home Agent supporting NEMOs > > should perform ingress filtering, so that only topologically correct > > packets leave the HA. > > Could you be more explicit? Do you mean that LFN sends packet to CN: > goes to MR that encapsulates towards HA that decapsulates and, before > sending, checks to see the source of that outgoing packet is correct? > Or something else? Sorry for being unclear. But I meant exactly what you describe. HA should verify that packets it receives from the MRHA tunnel have a source address that matches what's in HA's routing table. HA should have a route for the mobile prefix pointing into the MRHA tunnel, and the LFN should have use a source address derived from that prefix when sending its packets. Other packets will be dropped. > > What is ingress filtering at the HA? What you described. /Mattias > > Alex From nemo-admin@nal.motlabs.com Tue Dec 17 15:07:02 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21966 for ; Tue, 17 Dec 2002 15:07:01 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBHK37S12325; Tue, 17 Dec 2002 21:03:07 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBHK2lS12315 for ; Tue, 17 Dec 2002 21:02:47 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA15672; Tue, 17 Dec 2002 12:02:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBHK2bM23801; Tue, 17 Dec 2002 12:02:37 -0800 X-mProtect: <200212172002> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpP7jxl; Tue, 17 Dec 2002 12:02:36 PST Message-ID: <3DFF82DC.5F8CDFD4@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: "Pascal Thubert (pthubert)" , nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 17 Dec 2002 12:02:36 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > "- Every home agent MUST support decapsulating [15] reverse tunneled > packets sent to it from a mobile node's home address. Every home > agent MUST also check that the source address in the tunneled > packets corresponds to the currently registered location of the > mobile node (Section 10.4.3)." > > In the MR case, the src address of the encapsulated packet is not MR's > CoA, but it is the fixed address of an LFN or the address of a > visiting MH that derives its CoA from the MNP. This is probably a > security threat. MIPv6 meant check the source address on the outer header. compare it with the CoA in the binding cache entry for the corresponding home address. this is to prevent a node from tunneling traffic through the home agent, if it is not registered with the home agent currently. this is similar to ingress filtering that a router would do when it forwards packets. For the MR case, the HA needs to do this check, but the check is slightly different. it has to make sure the source address in the inner header belongs to the MR's prefix. and the source address in the outer header needs to match the current CoA of the MR. > "- Every home agent SHOULD support sending ICMP Mobile Prefix > Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix > Solicitations (Section 6.7). This behavior MUST be configurable, > so that home agents can be configured to avoid sending such > Prefix Advertisements according to the needs of the network > administration in the home domain." > > In the NEMO case, this SHOULD could be a MAY. MR will probably not > need Mobile Prefix Advertisements from its home link. We were saying > previously that MR will probably not need to receive RAs from the home > link, so neither will it need Mobile Prefix Advertisements. agreed. > In addition to the above requirements, if MRTP with MRHA uses dynamic > routing protocols between MR and HA then "HA MUST subscribe to the > all-routers mc address with link scope". HA is a router. it would have joined the all-routers multicast address anyway. Vijay From nemo-admin@nal.motlabs.com Tue Dec 17 15:07:25 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21987 for ; Tue, 17 Dec 2002 15:07:24 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBHK81S12357; Tue, 17 Dec 2002 21:08:01 +0100 Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBHK7KS12347 for ; Tue, 17 Dec 2002 21:07:20 +0100 Received: from [192.168.1.10] (reflection.kniveton.com [192.168.1.10]) by multihop.net (8.12.6/8.11.1) with ESMTP id gBHK8FTg093722 for ; Tue, 17 Dec 2002 12:08:15 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 From: "T.J. Kniveton" To: NeMo Discussion Subscribers Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [nemo] Quiet.. Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 17 Dec 2002 12:07:17 -0800 Content-Transfer-Encoding: 7bit Hi folks, A couple people have asked why it is so quiet on the list lately, so I wanted to share the info with everyone. It is mainly because of the holidays. Thierry and I have both been on vacation, as well as others who are regular posters coming and going from vacation (/"holiday"). I believe Thierry is presently returning from his travels, and I will be back at work next week. Other than that, I would expect it to remain at a lower activity level until Christmas and New Year's are over. We will still respond to administrative requests on the list, but it may take a bit longer than usual. Thanks, -TJ From nemo-admin@nal.motlabs.com Wed Dec 18 06:02:56 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01939 for ; Wed, 18 Dec 2002 06:02:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIAsiS15576; Wed, 18 Dec 2002 11:54:48 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIAqqS15562 for ; Wed, 18 Dec 2002 11:52:59 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gBIAqLVd022232; Wed, 18 Dec 2002 03:52:21 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id DAA16878; Wed, 18 Dec 2002 03:52:20 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/az33exr01) with ESMTP id gBIAqGE26153; Wed, 18 Dec 2002 04:52:17 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id CBF882EC8B; Wed, 18 Dec 2002 11:52:14 +0100 (CET) To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <3DFF82DC.5F8CDFD4@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DFF82DC.5F8CDFD4@iprg.nokia.com> Message-ID: Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 18 Dec 2002 11:52:14 +0100 Vijay Devarapalli writes: > > In the MR case, the src address of the encapsulated packet is not MR's > > CoA, but it is the fixed address of an LFN or the address of a > > visiting MH that derives its CoA from the MNP. This is probably a > > security threat. > > MIPv6 meant check the source address on the outer header. compare > it with the CoA in the binding cache entry for the corresponding > home address. this is to prevent a node from tunneling traffic > through the home agent, if it is not registered with the home agent > currently. this is similar to ingress filtering that a router would > do when it forwards packets. > > For the MR case, the HA needs to do this check, but the check is > slightly different. it has to make sure the source address in the > inner header belongs to the MR's prefix. and the source address in > the outer header needs to match the current CoA of the MR. Yes, right. When nested mobility, and several HAs, then a HA will receive packets from an MR that have several headers inside. Thus, talking about inner and outer header should be talking about addresses in "outermost"(?) header and "next to outermost"(?) header? I mean, the HA will only check src and dst addresses only in the outermost and next to outermost headers, but not the addresses in deeper headers, right? Alex From nemo-admin@nal.motlabs.com Wed Dec 18 07:12:22 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03290 for ; Wed, 18 Dec 2002 07:12:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBICB2S16074; Wed, 18 Dec 2002 13:11:03 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBICApS16064 for ; Wed, 18 Dec 2002 13:10:51 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIC8sNl023563; Wed, 18 Dec 2002 13:09:05 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 18 Dec 2002 13:10:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [nemo] MR definition Message-ID: Thread-Topic: [nemo] MR definition Thread-Index: AcKmg6FiPKpoFUhbSUK/NL2hE/aoowACNvNQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 18 Dec 2002 12:10:24.0990 (UTC) FILETIME=[721D87E0:01C2A68E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gBICApS16064 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 18 Dec 2002 12:10:20 -0000 Content-Transfer-Encoding: 8bit Becomes tricky. The MR is tunneling things home. That may threaten home. So the tunnel home should get the same security level as 'inside' home. Seems to me this all boils down to configuration. Whether an authentication such as 802.1x runs on the ingress interfaces with the same policy as home - we run LEAP inside Cisco. Whether visitors are accepted in at all, and whether their packets can be routed over the home tunnel (note that RRH does not require the latter). Whether ingress filtering is performed by the MR on its ingress interfaces, or whether the HA does it when it decaps from a tunnel interface (additional nesting being invisible at that point). What we must say is which configuration capabilities MAY, SHOULD or MUST be present on HA and MR, correct? Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@crm.mot.com] > Sent: mercredi 18 décembre 2002 11:52 > To: Vijay Devarapalli > Cc: Pascal Thubert (pthubert); nemo@nal.motlabs.com > Subject: Re: [nemo] MR definition > > > Vijay Devarapalli writes: > > > In the MR case, the src address of the encapsulated packet is not > > > MR's CoA, but it is the fixed address of an LFN or the > address of a > > > visiting MH that derives its CoA from the MNP. This is > probably a > > > security threat. > > > > MIPv6 meant check the source address on the outer header. compare > > it with the CoA in the binding cache entry for the corresponding > > home address. this is to prevent a node from tunneling traffic > > through the home agent, if it is not registered with the home agent > > currently. this is similar to ingress filtering that a router would > > do when it forwards packets. > > > > For the MR case, the HA needs to do this check, but the check is > > slightly different. it has to make sure the source address in the > > inner header belongs to the MR's prefix. and the source address in > > the outer header needs to match the current CoA of the MR. > > Yes, right. When nested mobility, and several HAs, then a HA > will receive packets from an MR that have several headers > inside. Thus, talking about inner and outer header should be > talking about addresses in "outermost"(?) header and "next to > outermost"(?) header? > > I mean, the HA will only check src and dst addresses only in > the outermost and next to outermost headers, but not the > addresses in deeper headers, right? > > Alex > > From nemo-admin@nal.motlabs.com Wed Dec 18 08:34:11 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06077 for ; Wed, 18 Dec 2002 08:34:10 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIDY2S16562; Wed, 18 Dec 2002 14:34:03 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIDX2S16546 for ; Wed, 18 Dec 2002 14:33:02 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gBIDWqVd025606; Wed, 18 Dec 2002 06:32:52 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA15428; Wed, 18 Dec 2002 06:27:57 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/il06exr03) with ESMTP id gBIDTZY22881; Wed, 18 Dec 2002 07:29:36 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id D60F52EC86; Wed, 18 Dec 2002 14:29:36 +0100 (CET) To: "Pascal Thubert (pthubert)" Cc: "Vijay Devarapalli", Subject: Re: [nemo] MR definition References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 18 Dec 2002 14:29:36 +0100 "Pascal Thubert (pthubert)" writes: > Seems to me this all boils down to configuration. Whether an > authentication such as 802.1x runs on the ingress interfaces with the > same policy as home - we run LEAP inside Cisco. Whether visitors are > accepted in at all, and whether their packets can be routed over the > home tunnel (note that RRH does not require the latter). This looks to me more like a "make LEAP/Cisco work over the MRHA tunnel" problem. Just like "make multicast work over the MRHA tunnel", or "make renumbering over the MRHA tunnel". But may I suggest to extract from LEAP/Cisco scenario three things: (1) the description of how attackers could arrive in a system that is not protected by LEAP/Cisco, (2) the damage they could cause and (3) the description of how LEAP/Cisco prevents from this happening. Maybe we can find amongst these three descriptions one threat that we could derive into a NEMO threat. If we can not derive a NEMO-specific threat, then it is clear that the suggestion you have is more of "make LEAP work over MRHA tunnel". An example, please excuse if my description is wrong. In a system that runs no LEAP, a non-legitimate user could obtain a valid address, a default route and access to a DNS server. Once that user has that, it could listen to all other connections in that network (traffic analysis), it could download large files for extended periods of time (DoS for networking resources to legitimate users) or it could attack other systems (masquerading). However, in a system where LEAP is active, a user is required to authenticate to LEAP by showing evidence of owning a secret password. In this way, users that are not legitimate and have no passwords will not be offered neither a valid address, nor a default route, they will not be allowed to talk at L2 layer, they will not be able to DoS, or masquerade or analyze the neighbours' traffic. Now, in the above description substitute "network at home or away from home" for "system" and the whole problem becomes a problem of "making LEAP work over MRHA". Alternatively, one could describe the following: a non-legitimate user visits a mobile network that is not at home. That mobile network is nested under 3 other mobile networks that are themselves nested one under the other. The attacker, instead of using the CoA as source address, it uses a fake source address (the address of a legitimate user). In this scheme, if the HA does ingress filtering, the attacker will be able to provoke DoS of network resources on the path between TLMR's HA and the immediately above MR's HA. In this scheme, MR ingress filtering could help, and HA ingress filtering could help by looking at deeper headers. What do you think Pascal? > Whether ingress filtering is performed by the MR on its ingress > interfaces, or whether the HA does it when it decaps from a tunnel > interface (additional nesting being invisible at that point). Yes, good question. It would be fine to require both MR and HA to do ingress filtering. MR ingress filtering is simpler to specify than HA ingress filtering. Alex From nemo-admin@nal.motlabs.com Wed Dec 18 09:06:33 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07605 for ; Wed, 18 Dec 2002 09:06:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIE71S16810; Wed, 18 Dec 2002 15:07:01 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIE6LS16798 for ; Wed, 18 Dec 2002 15:06:22 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBIE4L0Y017731; Wed, 18 Dec 2002 15:04:47 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 18 Dec 2002 15:05:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [nemo] MR definition Message-ID: Thread-Topic: [nemo] MR definition Thread-Index: AcKmmf6CibtYhukhSCe6Bd9BaJp50gAAbtiQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 18 Dec 2002 14:05:51.0691 (UTC) FILETIME=[92C039B0:01C2A69E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gBIE6LS16798 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 18 Dec 2002 14:05:50 -0000 Content-Transfer-Encoding: 8bit > This looks to me more like a "make LEAP/Cisco work over the > MRHA tunnel" problem. Just like "make multicast work over > the MRHA tunnel", LEAP (and 802.1x for that matter) is a L2 thing. It gives a secured L2 access to an ingress network. It does not "work over the MRHA tunnel" -though connection to the back end will happen there- but filters out who can join in the ingress network at L2. This is the first barrier to protect the MR and the home. Giving away a broadcast access on a ingress network to an anonymous visitor opens to ND attacks, which can easily disrupt all traffic on that ingress interface. We may want to look at what SeND does but at the moment, it's suicidal, so an existing L2 access control seems desirable. Letting anonymous Visitors on the MRHA opens the home door to strangers. I suggest we install a lock. I mentioned LEAP because if you consider Cisco premises as my "home", I can log in from outside of the building using 802.11/LEAP. Since LEAP provides a security level that matches the policy 'inside', I can use it from 'outside'. If a MR has a secured MRHA tunnel to the inside of Cisco (a VPN) then LEAP is required on the ingress interface to maintain the security policy. Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@crm.mot.com] > Sent: mercredi 18 décembre 2002 14:30 > To: Pascal Thubert (pthubert) > Cc: Vijay Devarapalli; nemo@nal.motlabs.com > Subject: Re: [nemo] MR definition > > > "Pascal Thubert (pthubert)" writes: > > Seems to me this all boils down to configuration. Whether an > > authentication such as 802.1x runs on the ingress > interfaces with the > > same policy as home - we run LEAP inside Cisco. Whether > visitors are > > accepted in at all, and whether their packets can be routed > over the > > home tunnel (note that RRH does not require the latter). > > This looks to me more like a "make LEAP/Cisco work over the > MRHA tunnel" problem. Just like "make multicast work over > the MRHA tunnel", or "make renumbering over the MRHA tunnel". > > But may I suggest to extract from LEAP/Cisco scenario three things: > (1) the description of how attackers could arrive in a system > that is not protected by LEAP/Cisco, (2) the damage they > could cause and (3) the description of how LEAP/Cisco > prevents from this happening. Maybe we can find amongst > these three descriptions one threat that we could derive into > a NEMO threat. > > If we can not derive a NEMO-specific threat, then it is clear > that the suggestion you have is more of "make LEAP work over > MRHA tunnel". > > An example, please excuse if my description is wrong. In a > system that runs no LEAP, a non-legitimate user could obtain > a valid address, a default route and access to a DNS server. > Once that user has that, it could listen to all other > connections in that network (traffic analysis), it could > download large files for extended periods of time (DoS for > networking resources to legitimate users) or it could attack > other systems (masquerading). However, in a system where > LEAP is active, a user is required to authenticate to LEAP by > showing evidence of owning a secret password. In this way, > users that are not legitimate and have no passwords will not > be offered neither a valid address, nor a default route, they > will not be allowed to talk at L2 layer, they will not be > able to DoS, or masquerade or analyze the neighbours' traffic. > > Now, in the above description substitute "network at home or > away from home" for "system" and the whole problem becomes a > problem of "making LEAP work over MRHA". > > Alternatively, one could describe the following: a > non-legitimate user visits a mobile network that is not at > home. That mobile network is nested under 3 other mobile > networks that are themselves nested one under the other. The > attacker, instead of using the CoA as source address, it uses > a fake source address (the address of a legitimate user). In > this scheme, if the HA does ingress filtering, the attacker > will be able to provoke DoS of network resources on the path > between TLMR's HA and the immediately above MR's HA. In this > scheme, MR ingress filtering could help, and HA ingress > filtering could help by looking at deeper headers. > > What do you think Pascal? > > > Whether ingress filtering is performed by the MR on its ingress > > interfaces, or whether the HA does it when it decaps from a tunnel > > interface (additional nesting being invisible at that point). > > Yes, good question. It would be fine to require both MR and > HA to do ingress filtering. MR ingress filtering is simpler > to specify than HA ingress filtering. > > Alex > > From nemo-admin@nal.motlabs.com Wed Dec 18 09:31:26 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09332 for ; Wed, 18 Dec 2002 09:31:25 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIEW1S16961; Wed, 18 Dec 2002 15:32:01 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIEVgS16951 for ; Wed, 18 Dec 2002 15:31:42 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gBIEV6F6028800 for ; Wed, 18 Dec 2002 07:31:07 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA00600 for ; Wed, 18 Dec 2002 07:31:39 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/il06exr01) with ESMTP id gBIEVXc09945; Wed, 18 Dec 2002 08:31:34 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8C3452EC86; Wed, 18 Dec 2002 15:31:34 +0100 (CET) To: "Pascal Thubert (pthubert)" Cc: Subject: Re: [nemo] MR definition References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 18 Dec 2002 15:31:34 +0100 "Pascal Thubert (pthubert)" writes: > Letting anonymous Visitors on the MRHA opens the home door to > strangers. I suggest we install a lock. Yes, perfect, there are two possible locks: SEND and Diameter. Which does one prefer? I guess LEAP is out of discussion. I mean we can jump and leap here and there out of the context, just for the fun of it, but I don't think we could seriously look into security analysis based on the LEAP tool. My oppinion only, group members may think otherwise. Alex From nemo-admin@nal.motlabs.com Wed Dec 18 12:20:42 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13191 for ; Wed, 18 Dec 2002 12:20:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIHL2S17691; Wed, 18 Dec 2002 18:21:03 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIHKcS17681 for ; Wed, 18 Dec 2002 18:20:38 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gBIHKZpl001489 for ; Wed, 18 Dec 2002 10:20:36 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA26483 for ; Wed, 18 Dec 2002 10:20:35 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/az33exr01) with ESMTP id gBIHKWE19866 for ; Wed, 18 Dec 2002 11:20:32 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id E67EF2EC8B for ; Wed, 18 Dec 2002 18:20:30 +0100 (CET) To: From: Alexandru Petrescu Message-ID: Lines: 61 User-Agent: Emacs Gnus MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [nemo] nested requirement? Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 18 Dec 2002 18:20:30 +0100 I've been looking at the requirements as presented in the last meeting minutes. It's not yet clear to me whether those requirements catch the nesting aspects. If yes, then there's probably a new requirement that has been suggested recently: "Nested mobility support between two mobile routers (allowing MR1 to nest under MR2) is required only when the path from MR2 to MR1's HA does not go through MR1 (path considered when both mobile routers are at home and no tunnels are in place)." Consider the following example, where both MRs are at home and where MR1's mobile network contains HA2. MR1 belongs to HA1 and MR2 belongs to HA2. ----------/ ------- | | -----------------------| HA1/BR|---| Internet | | ------- | | | ---------- ----- ----- | MR1 | | HA2 | ----- ----- | | ------------ | ----- ----- | MR2 | | LFN | ----- ----- | | ------------ In this case, it is possible for the MR1 to go visit AR, together with MR1 under it (that will not see mobility). It is also possible for MR2 to go visit other places. But it would be probably difficult to require a nested configuration like this to work: ----------/ ------- | | | HA1/BR|---| Internet | ------- | | ----------\ \ ----- | AR | ----- | ----- ----- | MR2 | | LFN | ----- ----- | | ------------ | ----- ----- | MR1 | | HA2 | ----- ----- | | ------------ What do you think, do I miss anything? Alex From nemo-admin@nal.motlabs.com Wed Dec 18 13:48:52 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15604 for ; Wed, 18 Dec 2002 13:48:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIIh2S20149; Wed, 18 Dec 2002 19:43:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIIgdS20139 for ; Wed, 18 Dec 2002 19:42:39 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29211; Wed, 18 Dec 2002 10:42:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBIIgTv16398; Wed, 18 Dec 2002 10:42:29 -0800 X-mProtect: <200212181842> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnq9w62; Wed, 18 Dec 2002 10:42:27 PST Message-ID: <3E00C194.19802914@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <3DFF82DC.5F8CDFD4@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 18 Dec 2002 10:42:28 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > > > > For the MR case, the HA needs to do this check, but the check is > > slightly different. it has to make sure the source address in the > > inner header belongs to the MR's prefix. and the source address in > > the outer header needs to match the current CoA of the MR. > > Yes, right. When nested mobility, and several HAs, then a HA will > receive packets from an MR that have several headers inside. Thus, > talking about inner and outer header should be talking about addresses > in "outermost"(?) header and "next to outermost"(?) header? > > I mean, the HA will only check src and dst addresses only in the > outermost and next to outermost headers, but not the addresses in > deeper headers, right? it is simple. each HA has to check the source addresses of outer and inner IPv6 headers of the packet it decapsulates and forwards. it doesnt matter how many times the packet has been encapsulated. why check the destination address? the destination address on the outer header is going to the HA and on the inner header some random CN. Vijay From nemo-admin@nal.motlabs.com Wed Dec 18 14:04:49 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16017 for ; Wed, 18 Dec 2002 14:04:49 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIJ71S20319; Wed, 18 Dec 2002 20:07:01 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIJ6pS20309 for ; Wed, 18 Dec 2002 20:06:51 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gBIJ6hpl025803; Wed, 18 Dec 2002 12:06:43 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA27752; Wed, 18 Dec 2002 12:01:48 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/az33exr01) with ESMTP id gBIJ6eE22931; Wed, 18 Dec 2002 13:06:41 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id F37062EC86; Wed, 18 Dec 2002 20:06:34 +0100 (CET) To: Vijay Devarapalli Cc: Subject: Re: [nemo] MR definition References: <3DFF82DC.5F8CDFD4@iprg.nokia.com> <3E00C194.19802914@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3E00C194.19802914@iprg.nokia.com> Message-ID: Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 18 Dec 2002 20:06:35 +0100 Vijay Devarapalli writes: > > > For the MR case, the HA needs to do this check, but the check is > > > slightly different. it has to make sure the source address in the > > > inner header belongs to the MR's prefix. and the source address in > > > the outer header needs to match the current CoA of the MR. > > > > Yes, right. When nested mobility, and several HAs, then a HA will > > receive packets from an MR that have several headers inside. Thus, > > talking about inner and outer header should be talking about addresses > > in "outermost"(?) header and "next to outermost"(?) header? > > > > I mean, the HA will only check src and dst addresses only in the > > outermost and next to outermost headers, but not the addresses in > > deeper headers, right? > > it is simple. each HA has to check the source addresses of outer > and inner IPv6 headers of the packet it decapsulates and forwards. > it doesnt matter how many times the packet has been encapsulated. I see, so let's have a path of HAs like this: HA1--HA2--HA3--HA4 And the packet is decapsulated progressively by HA1, 2 and only at HA4 is it totally decapsulated and has no outer header at all. HA1 receives a packet with 4 headers inside. It "checks src in outer header" ok. Then it checks src in inner header, but there are 3 inner headers, so which one to check. Maybe, the first inner header? The second inner header? If HA1 only checks the first inner header, then it is possible for an attacker deep in the mobile network hierarchy to put a fake source address that will only be discarded at HA4 when HA4 checks the source address and drops it. Thus the attacker generated network load on the path HA1-HA2...4 Did I miss anything in unfolding my scenario? Alex From nemo-admin@nal.motlabs.com Wed Dec 18 15:07:55 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17731 for ; Wed, 18 Dec 2002 15:07:54 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIK74S20671; Wed, 18 Dec 2002 21:07:04 +0100 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIK63S20659 for ; Wed, 18 Dec 2002 21:06:03 +0100 Message-ID: <010a01c2a6d0$a4b1f690$546015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Pascal Thubert \(pthubert\)" , "Alexandru Petrescu" Cc: References: Subject: Re: [nemo] MR definition MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 18 Dec 2002 12:04:15 -0800 Content-Transfer-Encoding: 7bit > "Pascal Thubert (pthubert)" writes: > > Letting anonymous Visitors on the MRHA opens the home door to > > strangers. I suggest we install a lock. > > Yes, perfect, there are two possible locks: SEND and Diameter. Which > does one prefer? > > I guess LEAP is out of discussion. I mean we can jump and leap here > and there out of the context, just for the fun of it, but I don't > think we could seriously look into security analysis based on the LEAP > tool. > > My oppinion only, group members may think otherwise. I think we should look at different legs of security here regarding network access: - Between a host and the mobile network: This is a network access authentication issue. One can use PANA/802.1x/PPP between the node and the access router. - Between the MR and the access router on the Internet side: This is also a network access authentication issue. Again, one can use PANA/802.1x/PPP between the MR and the access router on the Internet side. - Between the MR and HA: The binding updates sent by MR should provide sufficient authentication information for creating the tunnel between two. Further protection can be provided by per-packet authentication (and encryption if desired) of the tunnel (e.g., using IPsec AH tunnel mode). Just to put things in perspective: LEAP is an instance of 802.1x standard. In this discussion, we can refer to 802.1x instead of this vendor-specific implementation. SEND is not concerned with network access authentication. That is the job of PANA. SEND addresses other posible threats once a client is admitted (after authentication and authorization) to the network. DIAMETER is a specific AAA protocol. In the context of access authentication, it can be seen as the backend transport for authentication messaging between the local AAA server and remote AAA server. For example: PANA carries the authentication information between the host and the access router in the NEMO. DIAMETER can carry the authentication information between the access router and the AAA backend (possibly sitting somewhere on the Internet). alper From nemo-admin@nal.motlabs.com Wed Dec 18 15:29:51 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18032 for ; Wed, 18 Dec 2002 15:29:49 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIKR2S20748; Wed, 18 Dec 2002 21:27:02 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIKQhS20737 for ; Wed, 18 Dec 2002 21:26:43 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gBIKQapl014039; Wed, 18 Dec 2002 13:26:36 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA20498; Wed, 18 Dec 2002 13:26:35 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/il06exr02) with ESMTP id gBIKQTr13696; Wed, 18 Dec 2002 14:26:30 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id D11942EC8B; Wed, 18 Dec 2002 21:26:29 +0100 (CET) To: "Alper E. YEGIN" Cc: "Pascal Thubert (pthubert)" , Subject: Re: [nemo] MR definition References: <010a01c2a6d0$a4b1f690$546015ac@AlperVAIO> From: Alexandru Petrescu In-Reply-To: <010a01c2a6d0$a4b1f690$546015ac@AlperVAIO> Message-ID: Lines: 57 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 18 Dec 2002 21:26:29 +0100 Alper, thank you for putting things in a clear perspective. May I try to fit my previous oppinion in this framework. "Alper E. YEGIN" writes: > - Between a host and the mobile network: This is a network > access authentication issue. One can use PANA/802.1x/PPP between > the node and the access router. Yes, and I understand that PANA/802.1x/PPP without a backend tool such as DIAMETER is probably not very useful? Or maybe I'm wrong? Please clarify whether this can be done. If not, then 802.1x with a DIAMETER backend should work well when MR's CoA has changed. So I could state this into a problem of making DIAMETER work over MRHA, that was my previous intention. Or maybe there's nothing to modify on any backend, it will work just fine over the MRHA tunnels. > - Between the MR and the access router on the Internet side: > This is also a network access authentication issue. Again, > one can use PANA/802.1x/PPP between the MR and the access router > on the Internet side. Yes, in that case, the DIAMETER backend will not be affected by any form of mobility, because AR is fixed and is connected to a fixed backbone. > - Between the MR and HA: The binding updates sent by MR should > provide sufficient authentication information for creating the > tunnel between two. Further protection can be provided by > per-packet authentication (and encryption if desired) of > the tunnel (e.g., using IPsec AH tunnel mode). Yes, exactly, that's the kind of issues that are very important here I believe. And I would be very interested to see what are the risks that are eliminated with this strong security between MR and HA. Thanks, Alex > Just to put things in perspective: > > LEAP is an instance of 802.1x standard. In this discussion, > we can refer to 802.1x instead of this vendor-specific implementation. > > SEND is not concerned with network access authentication. That is > the job of PANA. SEND addresses other posible threats once a client is > admitted (after authentication and authorization) to the network. > > DIAMETER is a specific AAA protocol. In the context of access > authentication, it can be seen as the backend transport for > authentication messaging between the local AAA server and remote > AAA server. For example: PANA carries the authentication > information between the host and the access router in the NEMO. > DIAMETER can carry the authentication information between the access > router and the AAA backend (possibly sitting somewhere on the Internet). > > alper From nemo-admin@nal.motlabs.com Wed Dec 18 15:57:30 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18522 for ; Wed, 18 Dec 2002 15:57:28 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIKw2S20939; Wed, 18 Dec 2002 21:58:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBIKvPS20929 for ; Wed, 18 Dec 2002 21:57:25 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA05235; Wed, 18 Dec 2002 12:57:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBIKvG105549; Wed, 18 Dec 2002 12:57:16 -0800 X-mProtect: <200212182057> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrNwsYJ; Wed, 18 Dec 2002 12:57:14 PST Message-ID: <3E00E12B.9BC73BBD@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <3DFF82DC.5F8CDFD4@iprg.nokia.com> <3E00C194.19802914@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 18 Dec 2002 12:57:15 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > I see, so let's have a path of HAs like this: > > HA1--HA2--HA3--HA4 > > And the packet is decapsulated progressively by HA1, 2 and only at HA4 > is it totally decapsulated and has no outer header at all. > > HA1 receives a packet with 4 headers inside. It "checks src in outer > header" ok. Then it checks src in inner header, but there are 3 inner > headers, so which one to check. Maybe, the first inner header? The > second inner header? > > If HA1 only checks the first inner header, then it is possible for an only the first inner header. > attacker deep in the mobile network hierarchy to put a fake source > address that will only be discarded at HA4 when HA4 checks the source > address and drops it. Thus the attacker generated network load on the > path HA1-HA2...4 > > Did I miss anything in unfolding my scenario? yes. a HA cannot always look beyond the first inner header. it could be encrypted by a tunnel ESP SA between the corresponding MR and HA. for example lets assume the following. MR3 is nested under MR2 which is nested under MR1. also assume HA1 is serving MR1, HA2 is serving MR2 and HA3 is serving MR3. the packet could look like the following. IPv6 hdr (MR1_CoA, HA1) IPv6 hdr (MR2_CoA, HA2) IPv6 hdr (MR3_CoA, HA3) IPv6 hdr (x, CN) (x is a node in MR3's network). Payload now further assume MR2 and HA2 use an ESP encrypted tunnel. that means when HA1 receives a packet which looks like the following. IPv6 hdr (MR1_CoA, HA1) IPv6 hdr (MR2_CoA, HA2) ESP hdr... encrypted payload. HA1 MUST verify MR1_CoA is valid by looking at the binding cache entry for MR1. it SHOULD also verify that MR2_CoA belongs to MR1's mobile network. it shouldnt care if MR2_CoA is a mobile router. infact it shouldnt care what IPv6 headers follow. it should be concerned only about the packet it is decapsulating and forwarding. Vijay From nemo-admin@nal.motlabs.com Wed Dec 18 16:42:34 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19443 for ; Wed, 18 Dec 2002 16:42:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBILgCS21111; Wed, 18 Dec 2002 22:42:12 +0100 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBILfrS21101 for ; Wed, 18 Dec 2002 22:41:54 +0100 Message-ID: <014801c2a6de$03e82050$546015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Alexandru Petrescu" Cc: "Pascal Thubert \(pthubert\)" , References: <010a01c2a6d0$a4b1f690$546015ac@AlperVAIO> Subject: Re: [nemo] MR definition MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 18 Dec 2002 13:39:54 -0800 Content-Transfer-Encoding: 7bit Hi Alex, > Alper, thank you for putting things in a clear perspective. May I try > to fit my previous oppinion in this framework. > > "Alper E. YEGIN" writes: > > - Between a host and the mobile network: This is a network > > access authentication issue. One can use PANA/802.1x/PPP between > > the node and the access router. > > Yes, and I understand that PANA/802.1x/PPP without a backend tool such > as DIAMETER is probably not very useful? Or maybe I'm wrong? Please > clarify whether this can be done. Nothing in those protocols require a AAA backend. They can utilize local database stored on PAA/AP/NAS. But in reality, they are/will_be used with the AAA backend for centralizing AAA information and supporting roaming. > If not, then 802.1x with a DIAMETER > backend should work well when MR's CoA has changed. So I could state > this into a problem of making DIAMETER work over MRHA, that was my > previous intention. Or maybe there's nothing to modify on any > backend, it will work just fine over the MRHA tunnels. As far as admission control is concerned, I don't think we have to change anything in DIAMETER for host-AR authentication, or for MR-AR authentication. Accounting is a different story.. NEMO might move from cheaper access network to a more expensive access network. NEMO does not have to authenticate the hosts again, but does it want to increase the rates that are applied to the hosts? Does it want to inform them? > > > - Between the MR and the access router on the Internet side: > > This is also a network access authentication issue. Again, > > one can use PANA/802.1x/PPP between the MR and the access router > > on the Internet side. > > Yes, in that case, the DIAMETER backend will not be affected by any > form of mobility, because AR is fixed and is connected to a fixed > backbone. > > > - Between the MR and HA: The binding updates sent by MR should > > provide sufficient authentication information for creating the > > tunnel between two. Further protection can be provided by > > per-packet authentication (and encryption if desired) of > > the tunnel (e.g., using IPsec AH tunnel mode). > > Yes, exactly, that's the kind of issues that are very important here I > believe. And I would be very interested to see what are the risks > that are eliminated with this strong security between MR and HA. > > Thanks, alper > > Alex > > > Just to put things in perspective: > > > > LEAP is an instance of 802.1x standard. In this discussion, > > we can refer to 802.1x instead of this vendor-specific implementation. > > > > SEND is not concerned with network access authentication. That is > > the job of PANA. SEND addresses other posible threats once a client is > > admitted (after authentication and authorization) to the network. > > > > DIAMETER is a specific AAA protocol. In the context of access > > authentication, it can be seen as the backend transport for > > authentication messaging between the local AAA server and remote > > AAA server. For example: PANA carries the authentication > > information between the host and the access router in the NEMO. > > DIAMETER can carry the authentication information between the access > > router and the AAA backend (possibly sitting somewhere on the Internet). > > > > alper > > From nemo-admin@nal.motlabs.com Wed Dec 18 21:16:28 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26044 for ; Wed, 18 Dec 2002 21:16:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBJ2H3S21988; Thu, 19 Dec 2002 03:17:03 +0100 Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBJ2GaS21978 for ; Thu, 19 Dec 2002 03:16:38 +0100 Received: from tchaikovsky.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id gBJ29MZ09491; Thu, 19 Dec 2002 10:09:23 +0800 (SGT) Received: by tchaikovsky.psl.com.sg (Postfix, from userid 1000) id 28CA410E9785; Thu, 19 Dec 2002 10:28:17 +0800 (SGT) Subject: Re: [nemo] MR definition From: Chan-Wah Ng To: "Alper E. YEGIN" Cc: Alexandru Petrescu , Pascal "Thubert (pthubert)" , nemo@nal.motlabs.com In-Reply-To: <014801c2a6de$03e82050$546015ac@AlperVAIO> References: <010a01c2a6d0$a4b1f690$546015ac@AlperVAIO> <014801c2a6de$03e82050$546015ac@AlperVAIO> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Message-Id: <1040264896.1761.17.camel@beethoven> Mime-Version: 1.0 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 19 Dec 2002 10:28:16 +0800 Content-Transfer-Encoding: 7bit On Thu, 2002-12-19 at 05:39, Alper E. YEGIN wrote: > Hi Alex, > > > Alper, thank you for putting things in a clear perspective. May I try > > to fit my previous oppinion in this framework. > > > > "Alper E. YEGIN" writes: > > > - Between a host and the mobile network: This is a network > > > access authentication issue. One can use PANA/802.1x/PPP between > > > the node and the access router. > > > > Yes, and I understand that PANA/802.1x/PPP without a backend tool such > > as DIAMETER is probably not very useful? Or maybe I'm wrong? Please > > clarify whether this can be done. > > Nothing in those protocols require a AAA backend. They can utilize > local database stored on PAA/AP/NAS. But in reality, they are/will_be > used with the AAA backend for centralizing AAA information and supporting > roaming. > Just to re-emphazoe what Alper had said: True that nothing in PANA/802.1x/PPP requires a backend protocol. But without a backend protocol, you are requiring each mobile router to carry the AAA database ... a administration nightmare, IMHO. The more pratical deployment scenario I see is that MR will use backend AAA protocols to check credentials of hosts with AAA databases located at the home domain (possibly at the other side of the Internet, hence a need for Internet-wide protocols such as Diameter/Radius). > > > If not, then 802.1x with a DIAMETER > > backend should work well when MR's CoA has changed. So I could state > > this into a problem of making DIAMETER work over MRHA, that was my > > previous intention. Or maybe there's nothing to modify on any > > backend, it will work just fine over the MRHA tunnels. > > As far as admission control is concerned, I don't think we have to change > anything in DIAMETER for host-AR authentication, or for MR-AR > authentication. Accounting is a different story.. NEMO might move from > cheaper access network to a more expensive access network. NEMO > does not have to authenticate the hosts again, but does it want to > increase the rates that are applied to the hosts? Does it want to inform > them? > Is it the current practice of service providers to change rates without notice during a on-going sessions? Possible deployment scenarios I see is: (1) Service provider (of the mobile network) charge a flat fee no matter where the mobile network roams to. Hence no need to inform the visiting hosts. (2) Service providers state on the subscription policy that the rates will be based on the current access network the mobile network roams to, and vary the rates accordingly, without notifying the hosts. (3) As above, but hosts are notified when a rate change occurs. But the question is, is there mechanism in PANA/802.1x/PPP to support such notifications? /cwng > > > > > > - Between the MR and the access router on the Internet side: > > > This is also a network access authentication issue. Again, > > > one can use PANA/802.1x/PPP between the MR and the access router > > > on the Internet side. > > > > Yes, in that case, the DIAMETER backend will not be affected by any > > form of mobility, because AR is fixed and is connected to a fixed > > backbone. > > > > > - Between the MR and HA: The binding updates sent by MR should > > > provide sufficient authentication information for creating the > > > tunnel between two. Further protection can be provided by > > > per-packet authentication (and encryption if desired) of > > > the tunnel (e.g., using IPsec AH tunnel mode). > > > > Yes, exactly, that's the kind of issues that are very important here I > > believe. And I would be very interested to see what are the risks > > that are eliminated with this strong security between MR and HA. > > > > Thanks, > > > alper > > > > > > Alex > > > > > Just to put things in perspective: > > > > > > LEAP is an instance of 802.1x standard. In this discussion, > > > we can refer to 802.1x instead of this vendor-specific implementation. > > > > > > SEND is not concerned with network access authentication. That is > > > the job of PANA. SEND addresses other posible threats once a client is > > > admitted (after authentication and authorization) to the network. > > > > > > DIAMETER is a specific AAA protocol. In the context of access > > > authentication, it can be seen as the backend transport for > > > authentication messaging between the local AAA server and remote > > > AAA server. For example: PANA carries the authentication > > > information between the host and the access router in the NEMO. > > > DIAMETER can carry the authentication information between the access > > > router and the AAA backend (possibly sitting somewhere on the Internet). > > > > > > alper > > > > > > From nemo-admin@nal.motlabs.com Thu Dec 19 03:36:35 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11725 for ; Thu, 19 Dec 2002 03:36:34 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBJ8b5S23468; Thu, 19 Dec 2002 09:37:05 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBJ8ajS23458 for ; Thu, 19 Dec 2002 09:36:45 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBJ8YhRF028713; Thu, 19 Dec 2002 09:35:13 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 19 Dec 2002 09:36:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] MR definition Message-ID: Thread-Topic: [nemo] MR definition Thread-Index: AcKnM5R0jfpYAx84QJq2hkMDPbc+MwABbVfw From: "Pascal Thubert (pthubert)" To: "Chan-Wah Ng" Cc: X-OriginalArrivalTime: 19 Dec 2002 08:36:28.0657 (UTC) FILETIME=[B97A4E10:01C2A739] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gBJ8ajS23458 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 19 Dec 2002 08:36:28 -0000 Content-Transfer-Encoding: 8bit > > Hi, Pascal, > > On Thu, 2002-12-19 at 15:34, Pascal Thubert (pthubert) wrote: > > > The more pratical deployment scenario I see is that MR will > > > use backend AAA protocols to check credentials of hosts with > > > AAA databases located at the home domain (possibly at the > > > other side of the Internet, hence a need for Internet-wide > > > protocols such as Diameter/Radius). > > > > There may be a little more to it. I may be useful to have a > local AAA > > database in a MR for the local nodes, and a remote (accessed via > > Diameter, Radius, LDAP, tbd) for visiting nodes. The local database > > may be a cache. But in any case, it's needed to allow L2 > access when > > the home connection is not available... > > > > Pascal > > Agree, if you want to authenticate the local nodes. > By the way, you replied only to me. Is it intentional? :) > > /br > /cwng > > Oups! :) From nemo-admin@nal.motlabs.com Thu Dec 19 10:36:10 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18042 for ; Thu, 19 Dec 2002 10:36:09 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBJFa3S25527; Thu, 19 Dec 2002 16:36:03 +0100 Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBJFZZS25517 for ; Thu, 19 Dec 2002 16:35:35 +0100 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id gBJFZBBE004445; Thu, 19 Dec 2002 09:35:12 -0600 (CST) Message-ID: <3E01E771.9020605@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah Ng CC: "Alper E. YEGIN" , Alexandru Petrescu , "Pascal Thubert (pthubert)" , nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <010a01c2a6d0$a4b1f690$546015ac@AlperVAIO> <014801c2a6de$03e82050$546015ac@AlperVAIO> <1040264896.1761.17.camel@beethoven> Content-Type: multipart/alternative; boundary="------------040209060408080306040209" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 19 Dec 2002 09:36:17 -0600 --------------040209060408080306040209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > > > >>>If not, then 802.1x with a DIAMETER >>>backend should work well when MR's CoA has changed. So I could state >>>this into a problem of making DIAMETER work over MRHA, that was my >>>previous intention. Or maybe there's nothing to modify on any >>>backend, it will work just fine over the MRHA tunnels. >>> >>> >>As far as admission control is concerned, I don't think we have to change >>anything in DIAMETER for host-AR authentication, or for MR-AR >>authentication. Accounting is a different story.. NEMO might move from >>cheaper access network to a more expensive access network. NEMO >>does not have to authenticate the hosts again, but does it want to >>increase the rates that are applied to the hosts? Does it want to inform >>them? >> >> >> > >Is it the current practice of service providers to change rates without >notice during a on-going sessions? > >Possible deployment scenarios I see is: >(1) Service provider (of the mobile network) charge a flat fee no matter >where the mobile network roams to. Hence no need to inform the visiting >hosts. >(2) Service providers state on the subscription policy that the rates >will be based on the current access network the mobile network roams to, >and vary the rates accordingly, without notifying the hosts. >(3) As above, but hosts are notified when a rate change occurs. But the >question is, is there mechanism in PANA/802.1x/PPP to support such >notifications? > >/cwng > > PANA is not a protocol for accounting, only the last A of AAA is for accounting. >--behcet > > --------------040209060408080306040209 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
  
If not, then 802.1x with a DIAMETER
backend should work well when MR's CoA has changed.  So I could state
this into a problem of making DIAMETER work over MRHA, that was my
previous intention.  Or maybe there's nothing to modify on any
backend, it will work just fine over the MRHA tunnels.
      
As far as admission control is concerned, I don't think we have to change
anything in DIAMETER for host-AR authentication, or for MR-AR
authentication. Accounting is a different story.. NEMO might move from
cheaper access network to a more expensive access network. NEMO
does not have to authenticate the hosts again, but does it want to
increase the rates that are applied to the hosts? Does it want to inform
them?

    

Is it the current practice of service providers to change rates without
notice during a on-going sessions? 

Possible deployment scenarios I see is:
(1) Service provider (of the mobile network) charge a flat fee no matter
where the mobile network roams to.  Hence no need to inform the visiting
hosts.
(2) Service providers state on the subscription policy that the rates
will be based on the current access network the mobile network roams to,
and vary the rates accordingly, without notifying the hosts.
(3) As above, but hosts are notified when a rate change occurs.  But the
question is, is there mechanism in PANA/802.1x/PPP to support such
notifications?

/cwng
PANA is not a protocol for accounting, only the last A of AAA is for accounting.
--behcet
--------------040209060408080306040209-- From nemo-admin@nal.motlabs.com Wed Dec 25 01:38:46 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19027 for ; Wed, 25 Dec 2002 01:38:45 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBP6W8S30418; Wed, 25 Dec 2002 07:32:09 +0100 Received: from mgate2.csie.nctu.edu.tw (mgate2.csie.nctu.edu.tw [140.113.235.201]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBP6VtS30408 for ; Wed, 25 Dec 2002 07:31:56 +0100 Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B4CD23C5DB for ; Wed, 25 Dec 2002 14:31:43 +0800 (CST) Received: from cctsengIBM (dhcp-24-203.csie.nctu.edu.tw [140.113.24.203]) by mgate2.csie.nctu.edu.tw (Postfix) with SMTP id 9388523C53C for ; Wed, 25 Dec 2002 14:31:42 +0800 (CST) From: "cctseng" To: Message-ID: <002501c2abe0$a63ced70$cb18718c@cctsengIBM> MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <200212201102.gBKB2BS29670@jessica.nal.motlabs.com> Importance: Normal Subject: [nemo] RE: nemo digest, Vol 1 #54 - 1 msg Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 25 Dec 2002 14:41:26 +0800 Content-Transfer-Encoding: 7bit Happy New Year. CC -----Original Message----- From: nemo-admin@nal.motlabs.com [mailto:nemo-admin@nal.motlabs.com]On Behalf Of nemo-request@nal.motlabs.com Sent: Friday, December 20, 2002 7:02 PM To: nemo@nal.motlabs.com Subject: nemo digest, Vol 1 #54 - 1 msg Send nemo mailing list submissions to nemo@nal.motlabs.com To subscribe or unsubscribe via the World Wide Web, visit http://www.nal.motlabs.com/mailman/listinfo/nemo or, via email, send a message with subject or body 'help' to nemo-request@nal.motlabs.com You can reach the person managing the list at nemo-admin@nal.motlabs.com When replying, please edit your Subject line so it is more specific than "Re: Contents of nemo digest..." Today's Topics: 1. Re: MR definition (Behcet Sarikaya) --__--__-- Message: 1 Date: Thu, 19 Dec 2002 09:36:17 -0600 From: Behcet Sarikaya Organization: Alcatel USA To: Chan-Wah Ng CC: "Alper E. YEGIN" , Alexandru Petrescu , "Pascal Thubert (pthubert)" , nemo@nal.motlabs.com Subject: Re: [nemo] MR definition --------------040209060408080306040209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > > > >>>If not, then 802.1x with a DIAMETER >>>backend should work well when MR's CoA has changed. So I could state >>>this into a problem of making DIAMETER work over MRHA, that was my >>>previous intention. Or maybe there's nothing to modify on any >>>backend, it will work just fine over the MRHA tunnels. >>> >>> >>As far as admission control is concerned, I don't think we have to change >>anything in DIAMETER for host-AR authentication, or for MR-AR >>authentication. Accounting is a different story.. NEMO might move from >>cheaper access network to a more expensive access network. NEMO >>does not have to authenticate the hosts again, but does it want to >>increase the rates that are applied to the hosts? Does it want to inform >>them? >> >> >> > >Is it the current practice of service providers to change rates without >notice during a on-going sessions? > >Possible deployment scenarios I see is: >(1) Service provider (of the mobile network) charge a flat fee no matter >where the mobile network roams to. Hence no need to inform the visiting >hosts. >(2) Service providers state on the subscription policy that the rates >will be based on the current access network the mobile network roams to, >and vary the rates accordingly, without notifying the hosts. >(3) As above, but hosts are notified when a rate change occurs. But the >question is, is there mechanism in PANA/802.1x/PPP to support such >notifications? > >/cwng > > PANA is not a protocol for accounting, only the last A of AAA is for accounting. >--behcet > > --------------040209060408080306040209 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
  
If not, then 802.1x with a DIAMETER
backend should work well when MR's CoA has changed.  So I could state
this into a problem of making DIAMETER work over MRHA, that was my
previous intention.  Or maybe there's nothing to modify on any
backend, it will work just fine over the MRHA tunnels.
      
As far as admission control is concerned, I don't think we
have to change
anything in DIAMETER for host-AR authentication, or for MR-AR
authentication. Accounting is a different story.. NEMO might move from
cheaper access network to a more expensive access network. NEMO
does not have to authenticate the hosts again, but does it want to
increase the rates that are applied to the hosts? Does it want to inform
them?

    

Is it the current practice of service providers to change rates without
notice during a on-going sessions?

Possible deployment scenarios I see is:
(1) Service provider (of the mobile network) charge a flat fee no matter
where the mobile network roams to.  Hence no need to inform the visiting
hosts.
(2) Service providers state on the subscription policy that the rates
will be based on the current access network the mobile network roams to,
and vary the rates accordingly, without notifying the hosts.
(3) As above, but hosts are notified when a rate change occurs.  But the
question is, is there mechanism in PANA/802.1x/PPP to support such
notifications?

/cwng
PANA is not a protocol for accounting, only the last A of AAA is for accounting.
--behcet
--------------040209060408080306040209-- --__--__-- _______________________________________________ nemo mailing list nemo@nal.motlabs.com http://www.nal.motlabs.com/mailman/listinfo/nemo End of nemo Digest From nemo-admin@nal.motlabs.com Sat Dec 28 18:01:34 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10148 for ; Sat, 28 Dec 2002 18:01:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBSMt7S16073; Sat, 28 Dec 2002 23:55:07 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBSMssS16061 for ; Sat, 28 Dec 2002 23:54:54 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gBSMt3GR015305; Sat, 28 Dec 2002 15:55:03 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA01966; Sat, 28 Dec 2002 15:54:45 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/il06exr02) with ESMTP id gBSMpTr18097; Sat, 28 Dec 2002 16:51:31 -0600 Received: from test9.crm.mot.com.crm.mot.com (t_il01_c_slip6.corp.mot.com [199.2.172.66]) by thorgal.crm.mot.com (Postfix) with ESMTP id 44E1D2EC86; Sat, 28 Dec 2002 23:51:26 +0100 (CET) To: Vijay Devarapalli Cc: Subject: Re: [nemo] MR definition References: <3DFF82DC.5F8CDFD4@iprg.nokia.com> <3E00C194.19802914@iprg.nokia.com> <3E00E12B.9BC73BBD@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3E00E12B.9BC73BBD@iprg.nokia.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 28 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 21 Dec 2002 02:40:58 +0100 Vijay Devarapalli writes: > > attacker deep in the mobile network hierarchy to put a fake source > > address that will only be discarded at HA4 when HA4 checks the source > > address and drops it. Thus the attacker generated network load on the > > path HA1-HA2...4 > > > > Did I miss anything in unfolding my scenario? > > yes. a HA cannot always look beyond the first inner header. it could > be encrypted by a tunnel ESP SA between the corresponding MR and HA. > for example lets assume the following. Ah yes, thanks for the example with ESP. It is very true that HA can not look deeper at packet headers if ESP is used. But if ESP is not used, then it could, right? (it is not clear to me whether Mobile IPv6 requires that MN MUST use ESP to HA for signalling only, or for all communication to HA? Do you know?) So, maybe the HA could be instructed to look at all packet headers as deep as it could (as long as it doesn't encounter an ESP header), and do checks on addresses. To me, the unknown is what kinds of checks could be done on addresses that are deep in the tunnel headers, and that are in no relation to the addresses known by this HA. Alex From nemo-admin@nal.motlabs.com Mon Dec 30 13:11:51 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28662 for ; Mon, 30 Dec 2002 13:11:50 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBUIC8S31797; Mon, 30 Dec 2002 19:12:08 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBUIBOS31787 for ; Mon, 30 Dec 2002 19:11:24 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA01488; Mon, 30 Dec 2002 10:11:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBUIBDV00744; Mon, 30 Dec 2002 10:11:13 -0800 X-mProtect: <200212301811> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSWKQRT; Mon, 30 Dec 2002 10:11:12 PST Message-ID: <3E108C40.D01B3C00@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <3DFF82DC.5F8CDFD4@iprg.nokia.com> <3E00C194.19802914@iprg.nokia.com> <3E00E12B.9BC73BBD@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 30 Dec 2002 10:11:12 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > > It is very true that HA can not look deeper at packet headers if ESP > is used. But if ESP is not used, then it could, right? (it is not > clear to me whether Mobile IPv6 requires that MN MUST use ESP to HA > for signalling only, or for all communication to HA? Do you know?) no. Mobile IPv6 requires ESP tunnel only for RR signaling. but, at any time any MR could setup an ESP tunnel instead of an unprotected tunnel between its home agent and itself. it could use the ESP tunnel for all traffic. the tunnel could also be a VPN tunnel between the MR (in the foreign link) and its HA back in its corporate network. the VPN case (IMO) might be very common. > So, maybe the HA could be instructed to look at all packet headers as > deep as it could (as long as it doesn't encounter an ESP header), and > do checks on addresses. no. a HA has no business looking beyond the IPv6 header of the packet it decapsulates and forwards. > To me, the unknown is what kinds of checks could be done on addresses > that are deep in the tunnel headers, and that are in no relation to > the addresses known by this HA. these addresses are not related to this HA. so it cant do any checks even if it wants to. it should leave it to the corresponding HA. Vijay From nemo-admin@nal.motlabs.com Tue Dec 31 02:02:41 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12521 for ; Tue, 31 Dec 2002 02:02:40 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBV705S01933; Tue, 31 Dec 2002 08:00:06 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBV6xIS01919 for ; Tue, 31 Dec 2002 07:59:18 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gBV6x9LZ027087; Mon, 30 Dec 2002 23:59:09 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id XAA01157; Mon, 30 Dec 2002 23:59:09 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (8.11.6/az33exr04) with ESMTP id gBV6wvY20794; Tue, 31 Dec 2002 00:58:58 -0600 Received: from test9.crm.mot.com.crm.mot.com (t_il06_k_slip4.corp.mot.com [129.188.171.206]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1003B2EC86; Tue, 31 Dec 2002 07:59:01 +0100 (CET) To: Vijay Devarapalli Cc: Subject: Re: [nemo] MR definition References: <3DFF82DC.5F8CDFD4@iprg.nokia.com> <3E00C194.19802914@iprg.nokia.com> <3E00E12B.9BC73BBD@iprg.nokia.com> <3E108C40.D01B3C00@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3E108C40.D01B3C00@iprg.nokia.com> Message-ID: Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 31 Dec 2002 08:57:35 +0100 Vijay Devarapalli writes: > the tunnel could also be a VPN tunnel between the MR (in the > foreign link) and its HA back in its corporate network. the VPN > case (IMO) might be very common. IMO there's an important difference between a VPN Gateway and a HA. The VPN Gateway is usually one per company, while there can be as many HAs as there are IP subnets in that company. If VPN Gateway is used then there are potentially 2 tunnels even if we only talk mobile hosts (not routers). One tunnel between MN and VPN GW and another tunnel, through the first, between MN and its HA. > > To me, the unknown is what kinds of checks could be done on addresses > > that are deep in the tunnel headers, and that are in no relation to > > the addresses known by this HA. > > these addresses are not related to this HA. so it cant do any checks > even if it wants to. it should leave it to the corresponding HA. Every MR will generate encapsulated packets of the form: MR_CoA (this MR's CoA) MR_HA (the address of the HA of this MR) ------ LFN_source (the address of the LFN behind MR) dest The LFN_source and MR_HA addresses should have a common prefix, usually. This could be checked by any HA. Of course, there could be deployments where the mobile network's prefix is totally different than the prefix of the fixed home network. I see these as exceptions. Alex From nemo-admin@nal.motlabs.com Tue Dec 31 13:42:21 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27298 for ; Tue, 31 Dec 2002 13:42:20 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBVId5S04098; Tue, 31 Dec 2002 19:39:05 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBVIcQS04088 for ; Tue, 31 Dec 2002 19:38:26 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05745; Tue, 31 Dec 2002 10:38:19 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gBVIcHI06446; Tue, 31 Dec 2002 10:38:17 -0800 X-mProtect: <200212311838> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddpNbad; Tue, 31 Dec 2002 10:38:14 PST Message-ID: <3E11E417.E9ED139D@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR definition References: <3DFF82DC.5F8CDFD4@iprg.nokia.com> <3E00C194.19802914@iprg.nokia.com> <3E00E12B.9BC73BBD@iprg.nokia.com> <3E108C40.D01B3C00@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 31 Dec 2002 10:38:15 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli writes: > > the tunnel could also be a VPN tunnel between the MR (in the > > foreign link) and its HA back in its corporate network. the VPN > > case (IMO) might be very common. > > IMO there's an important difference between a VPN Gateway and a HA. > The VPN Gateway is usually one per company, while there can be as many > HAs as there are IP subnets in that company. we could get into an endless argument here about where a VPN gateway and HA are placed in a network. but what you say below is not true. > If VPN Gateway is used then there are potentially 2 tunnels even if we > only talk mobile hosts (not routers). One tunnel between MN and VPN > GW and another tunnel, through the first, between MN and its HA. see section 7.2.4 of http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-01.txt. just change 'proto = X' to 'proto = any' in mobile node SPD OUT entry. this basically becomes your IPsec VPN tunnel encrypting all traffic reverse tunneled between the MN and the HA. you can do with just one tunnel in this case. > > > > these addresses are not related to this HA. so it cant do any checks > > even if it wants to. it should leave it to the corresponding HA. > > Every MR will generate encapsulated packets of the form: > MR_CoA (this MR's CoA) > MR_HA (the address of the HA of this MR) > ------ what is -----? > LFN_source (the address of the LFN behind MR) > dest > > The LFN_source and MR_HA addresses should have a common prefix, > usually. This could be checked by any HA. ofcouse I agree with that. I kept saying each HA checks only the outer and inner IPv6 headers of the packets it decapsulate and forwards. if the packet is as follows, MR_CoA MR_HA LFN_source CN then the HA has to make sure LFN_source belongs to the HA prefix. but if the packet looks as follows MR1_CoA MR1_HA1 MR2_CoA MR2_HA2 LFN_source CN then HA1 checks if MR2_CoA belongs to the HA1 prefix. but does not look beyond that header. it doesnt care what headers follow. HA2 checks if LFN_source belongs to HA2's prefix. > Of course, there could be deployments where the mobile network's > prefix is totally different than the prefix of the fixed home network. > I see these as exceptions. I was not talking about that at all. Vijay ps: maybe we can take it offline.... From nemo-admin@nal.motlabs.com Tue Dec 31 13:52:58 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27445 for ; Tue, 31 Dec 2002 13:52:58 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBVIr2S04159; Tue, 31 Dec 2002 19:53:02 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gBVIqlS04149 for ; Tue, 31 Dec 2002 19:52:47 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gBVIqjsX001058 for ; Tue, 31 Dec 2002 11:52:45 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA16190 for ; Tue, 31 Dec 2002 11:52:26 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/il06exr01) with ESMTP id gBVIqcc24894; Tue, 31 Dec 2002 12:52:39 -0600 Received: from crm.mot.com (t-il06ac-port3.corp.mot.com [129.188.170.29]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1DB8A2EC86; Tue, 31 Dec 2002 19:52:36 +0100 (CET) Message-ID: <3E11F52C.4030708@crm.mot.com> From: Alexandru Petrescu Reply-To: petrescu@crm.mot.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Subject: Re: [nemo] MR definition References: <3DFF82DC.5F8CDFD4@iprg.nokia.com> <3E00C194.19802914@iprg.nokia.com> <3E00E12B.9BC73BBD@iprg.nokia.com> <3E108C40.D01B3C00@iprg.nokia.com> <3E11E417.E9ED139D@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 31 Dec 2002 20:51:08 +0100 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > we could get into an endless argument here about where a VPN > gateway and HA are placed in a network. Yes... :-) >>If VPN Gateway is used then there are potentially 2 tunnels even if we >>only talk mobile hosts (not routers). One tunnel between MN and VPN >>GW and another tunnel, through the first, between MN and its HA. > > > see section 7.2.4 of > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-01.txt. > just change 'proto = X' to 'proto = any' in mobile node SPD OUT > entry. this basically becomes your IPsec VPN tunnel encrypting > all traffic reverse tunneled between the MN and the HA. you can > do with just one tunnel in this case. I'll look at that description Vijay. >>>these addresses are not related to this HA. so it cant do any checks >>>even if it wants to. it should leave it to the corresponding HA. >> >>Every MR will generate encapsulated packets of the form: >>MR_CoA (this MR's CoA) >>MR_HA (the address of the HA of this MR) >>------ > > > what is -----? Separator, fine line :-) > then the HA has to make sure LFN_source belongs to the HA prefix. > but if the packet looks as follows > > MR1_CoA > MR1_HA1 > MR2_CoA > MR2_HA2 > LFN_source > CN > > then HA1 checks if MR2_CoA belongs to the HA1 prefix. but does not > look beyond that header. it doesnt care what headers follow. HA2 > checks if LFN_source belongs to HA2's prefix. It's not that HA1 couldn't check for this. Ok, maybe we can move this offline. Alex From test-admin@nal.motlabs.com Tue Dec 31 22:58:58 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03882 for ; Tue, 31 Dec 2002 22:58:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id h01424S07571 for ; Wed, 1 Jan 2003 05:02:04 +0100 Date: Wed, 1 Jan 2003 05:02:04 +0100 Message-Id: <200301010402.h01424S07571@jessica.nal.motlabs.com> Subject: nal.motlabs.com mailing list memberships reminder From: mailman-owner@jessica.nal.motlabs.com To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: test-admin@nal.motlabs.com Errors-To: test-admin@nal.motlabs.com X-BeenThere: test@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your nal.motlabs.com 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@nal.motlabs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@jessica.nal.motlabs.com. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@nal.motlabs.com pupafo http://www.nal.motlabs.com/mailman/options/nemo/nemo-archive%40lists.ietf.org