From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 07:23:44 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22467 for ; Mon, 1 Apr 2002 07:23:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03214; Mon, 1 Apr 2002 05:20:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20333; Mon, 1 Apr 2002 04:20:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31CJ4KL028609 for ; Mon, 1 Apr 2002 04:19:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31CJ41J028608 for mobile-ip-dist; Mon, 1 Apr 2002 04:19:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31CJ0KL028601 for ; Mon, 1 Apr 2002 04:19:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23327 for ; Mon, 1 Apr 2002 04:19:03 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02883 for ; Mon, 1 Apr 2002 05:19:02 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21972; Mon, 1 Apr 2002 07:15:51 -0500 (EST) Message-Id: <200204011215.HAA21972@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-johansson-mip-aaa-nai-00.txt Date: Mon, 01 Apr 2002 07:15:41 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : AAA NAI for Mobile IPv4 Extension Author(s) : T. Johansson Filename : draft-johansson-mip-aaa-nai-00.txt Pages : 9 Date : 29-Mar-02 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple AAA servers the reauthentication request may not be received by the same AAAH as previous authentication requests. In order for the new AAAH to be able to forward the request to the correct HA it has to know the identity of the HA. This document defines an extension that enables the HA to pass its identity to the mobile node which can in turn pass it to the AAA server when changing point of attachment. This document specifies a NAI extension that can carry these NAIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-johansson-mip-aaa-nai-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-johansson-mip-aaa-nai-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020329130817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-johansson-mip-aaa-nai-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-johansson-mip-aaa-nai-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020329130817.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 13:19:16 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09121 for ; Mon, 1 Apr 2002 13:19:15 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19010; Mon, 1 Apr 2002 11:16:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25784; Mon, 1 Apr 2002 10:16:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31IEZKL029145 for ; Mon, 1 Apr 2002 10:14:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31IEYKf029144 for mobile-ip-dist; Mon, 1 Apr 2002 10:14:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31IEWKL029137 for ; Mon, 1 Apr 2002 10:14:32 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02571 for ; Mon, 1 Apr 2002 13:14:36 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA22707 for mobile-ip@sunroof.eng.sun.com; Mon, 1 Apr 2002 13:15:32 -0500 (EST) Received: from odin.France.Sun.COM (odin.France.Sun.COM [129.157.174.8]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAqKKL018112 for ; Thu, 28 Mar 2002 02:52:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by odin.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2SAqLF16122; Thu, 28 Mar 2002 11:52:21 +0100 (MET) Date: Thu, 28 Mar 2002 11:52:07 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Comments on Draft 16 To: mohanp@tahoenetworks.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <416B5AF360DED54088DAD3CA8BFBEA6E1DF194@TNEXVS02.tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Or if the binding cache entry is removed/expired, a replayed binding > update > will be accepted (assuming nonces are still valid). I am not sure > how bad is this. But requiring the implementors to store it in NV might > be a overkill because you have to store one per MN plus the home > address and how do you know when to ever remove them from NV ? Mohan, The issue with non-volatile memory for the sequence number is just an issue for the HA. BUs sent to CNs rely on fresh cookies to prevent replays combined with using the sequence number when the CN already has a BCE. This requires some case (not well-specified in -16) on how to deleted BCEs at a CN - essentially it needs to keep a tombstone BCE around until the cookies used to create it are so old they would be rejected. Since we're not using RR cookies for the home registration (for better performance) and allow IPsec with static keys (which can't provide IPsec replay protection) it seems like we need the sequence numbers to provide strong replay protection for home registrations. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 14:30:02 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11358 for ; Mon, 1 Apr 2002 14:29:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26953; Mon, 1 Apr 2002 12:28:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19253; Mon, 1 Apr 2002 11:28:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31JRdKL029368 for ; Mon, 1 Apr 2002 11:27:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31JRcAe029367 for mobile-ip-dist; Mon, 1 Apr 2002 11:27:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31JRaKL029360 for ; Mon, 1 Apr 2002 11:27:37 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22992 for ; Mon, 1 Apr 2002 14:27:39 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA22763 for mobile-ip@sunroof.eng.sun.com; Mon, 1 Apr 2002 14:28:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SMmYKL022850 for ; Thu, 28 Mar 2002 14:48:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11038 for ; Thu, 28 Mar 2002 14:48:36 -0800 (PST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03193 for ; Thu, 28 Mar 2002 15:48:35 -0700 (MST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2SMmYV08729; Thu, 28 Mar 2002 16:48:34 -0600 (CST) Message-ID: <3CA39DBD.6040300@alcatel.com> Date: Thu, 28 Mar 2002 16:48:29 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, seamoby@ietf.org Subject: [mobile-ip] Launcing ip-paging mailing list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear all, I am pleased to announce the mailing list to discuss IP Paging at ip-paging@alcatel.com To subscribe send an email to the mailing list administrator at: behcet.sarikaya@alcatel.com We expect to post more info next Tuesday after Easter. Have a Happy Easter. -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 15:10:53 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12479 for ; Mon, 1 Apr 2002 15:10:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28815; Mon, 1 Apr 2002 12:10:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00921; Mon, 1 Apr 2002 12:10:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31K9KKL029588 for ; Mon, 1 Apr 2002 12:09:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31K9KRd029587 for mobile-ip-dist; Mon, 1 Apr 2002 12:09:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31K9GKL029580 for ; Mon, 1 Apr 2002 12:09:16 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g31K9Bx17433; Mon, 1 Apr 2002 22:09:11 +0200 (MEST) Date: Mon, 1 Apr 2002 22:08:51 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 To: Rajeev Koodli Cc: mobile-ip@sunroof.eng.sun.com, "'Erik Nordmark'" , "Hesham Soliman (ERA)" In-Reply-To: "Your message with ID" <3CA50C5F.766DC047@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Perhaps Erik was thinking that MN may wish to send a BU to CN > from AR-1 itself. Is that right ? This is not needed for FMIPv6, since > BU transmission epoch is not time-critical. Yes, that was the source of my confusion. Thanks for clearing it up. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 15:15:54 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12656 for ; Mon, 1 Apr 2002 15:15:49 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00151; Mon, 1 Apr 2002 12:15:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02229; Mon, 1 Apr 2002 12:15:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31KEhKL029667 for ; Mon, 1 Apr 2002 12:14:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31KEhVB029666 for mobile-ip-dist; Mon, 1 Apr 2002 12:14:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31KEdKL029659 for ; Mon, 1 Apr 2002 12:14:40 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g31KEYx17683; Mon, 1 Apr 2002 22:14:34 +0200 (MEST) Date: Mon, 1 Apr 2002 22:14:04 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Comments on Draft 16 To: jari.arkko@piuha.net Cc: Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com, erik.nordmark@Sun.COM In-Reply-To: "Your message with ID" <3CA5DEF9.1070100@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Although, it adds extra replay protection at HA, I'd think, the > > home-agent usage of NV memory could be optional. I'd like to know > > how big is the threat in this particular case (i,e if HA reboots). > > If we somehow decide that HA should preserve the bindings accross reboot, > > then obviously, it makes sense to have all the information intact. > > > Yes. Why don't we use the -15 scheme, describe the remaining threat and > make the seqno-preservation through reboots a SHOULD (or a MAY). Stable storage at the HA for the seqno can presumably be a SHOULD, with the ability to "lock in" on the first sequence number is receives from a MN after rebooting. But I thought the concerns were more on the MN side (where stable storage would often be implemented using NVram with a finite number of writes during the lifetime of the memory. We can't relax that constraint as far as I can tell. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 15:51:40 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14236 for ; Mon, 1 Apr 2002 15:51:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06416; Mon, 1 Apr 2002 12:49:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10247; Mon, 1 Apr 2002 12:48:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31KlCKL029786 for ; Mon, 1 Apr 2002 12:47:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31KlCBC029785 for mobile-ip-dist; Mon, 1 Apr 2002 12:47:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31Kl9KL029778 for ; Mon, 1 Apr 2002 12:47:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12425; Mon, 1 Apr 2002 12:47:13 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08902; Mon, 1 Apr 2002 13:47:12 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g31KlBK10864; Mon, 1 Apr 2002 12:47:11 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABG76620; Mon, 1 Apr 2002 12:44:48 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA13575; Mon, 1 Apr 2002 12:47:11 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15528.51023.55916.42961@thomasm-u1.cisco.com> Date: Mon, 1 Apr 2002 12:47:11 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: jari.arkko@piuha.net, Samita Chakrabarti , erik.nordmark@Sun.COM Subject: [mobile-ip] replacing IPsec's replay protection? In-Reply-To: References: <3CA5DEF9.1070100@piuha.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > Stable storage at the HA for the seqno can presumably be a SHOULD, with > the ability to "lock in" on the first sequence number is receives from > a MN after rebooting. > But I thought the concerns were more on the MN side (where stable storage > would often be implemented using NVram with a finite number of writes > during the lifetime of the memory. > We can't relax that constraint as far as I can tell. So, I'm pretty far behind here, but I'm having a really hard time understanding why you'd want to replace IPsec's replay protection when you have key management. If it's there, it should be used. Also: requiring home agent routers to store *anything* on a per mobile node basis is going to be unacceptible. Worse, the possibilities here of missynchronized state seem really high. What happens if they're out of sync? How is it corrected? Blech. I really don't think we should be going here and strongly object to making this a MUST. A SHOULD on some form of key management (IKE, KINK, SOI) would be a *much* better idea. Let us not forget that keying is primarily a local policy issue, so forcing a MUST IMPLEMENT here will not necessarily get us any close to deployability. Indeed, it could delay it. Also: manual keying with IPsec is a known problem, and should be addressed within IPsec itself instead of special-casing mobile IP. This would be a win-win. Some of our folks are interested in this too, so contact me if you're interested. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 15:57:32 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14446 for ; Mon, 1 Apr 2002 15:57:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14053; Mon, 1 Apr 2002 13:56:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11909; Mon, 1 Apr 2002 12:56:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31KrIKL029878 for ; Mon, 1 Apr 2002 12:53:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31KrIH7029877 for mobile-ip-dist; Mon, 1 Apr 2002 12:53:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31KrCKL029867 for ; Mon, 1 Apr 2002 12:53:13 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g31Kr6x18948; Mon, 1 Apr 2002 22:53:07 +0200 (MEST) Date: Mon, 1 Apr 2002 22:52:46 +0200 (CEST) From: Erik Nordmark Subject: [mobile-ip] Re: replacing IPsec's replay protection? To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net, Samita Chakrabarti , erik.nordmark@sun.com In-Reply-To: "Your message with ID" <15528.51023.55916.42961@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > So, I'm pretty far behind here, but I'm having a > really hard time understanding why you'd want to > replace IPsec's replay protection when you have > key management. If it's there, it should be > used. The issue on the table is based on the assumption that folks want to secure the HA-MN using IPsec without IKE i.e. manual keys. In that case IPsec doesn't provide replay protection as I understand. > Also: requiring home agent routers to store > *anything* on a per mobile node basis is going to > be unacceptible. With manual keys the HA must have a table with Home Address Key(s) With IKE the HA must have a table with e.g. Home Address Certificate OR Home Address CA+subject(alt)name in certificate or Home Address public key Do you think you can avoid those and still get security for the home registrations? Erik > Worse, the possibilities here of > missynchronized state seem really high. What > happens if they're out of sync? How is it > corrected? Blech. > > I really don't think we should be going here and > strongly object to making this a MUST. A SHOULD on > some form of key management (IKE, KINK, SOI) would > be a *much* better idea. Let us not forget that > keying is primarily a local policy issue, so > forcing a MUST IMPLEMENT here will not necessarily > get us any close to deployability. Indeed, it > could delay it. Also: manual keying with IPsec is > a known problem, and should be addressed within > IPsec itself instead of special-casing mobile > IP. This would be a win-win. Some of our folks are > interested in this too, so contact me if you're > interested. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 16:13:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15154 for ; Mon, 1 Apr 2002 16:13:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21799; Mon, 1 Apr 2002 14:11:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15299; Mon, 1 Apr 2002 13:11:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31LAdKL029989 for ; Mon, 1 Apr 2002 13:10:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31LAcFi029988 for mobile-ip-dist; Mon, 1 Apr 2002 13:10:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31LAZKL029981 for ; Mon, 1 Apr 2002 13:10:35 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20126 for ; Mon, 1 Apr 2002 13:10:39 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24127 for ; Mon, 1 Apr 2002 13:10:19 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g31LAZf01524; Mon, 1 Apr 2002 15:10:35 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Apr 2002 15:10:37 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB39@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip'" Cc: "Ahmad Muhanna", "'Charlie Perkins'" , "'Pete McCann'" , "Kent Nickell" Subject: [mobile-ip] RFC3220 and possible forward compatibility issue "Dynamic Home Ag ent Allocation" Date: Mon, 1 Apr 2002 15:10:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D9C1.AB723A30" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D9C1.AB723A30 Content-Type: text/plain; charset="iso-8859-1" Hello all; RFC3220 (RFC2002) proposes a mechanism for Dynamic Home Agent Resolution or allocation. Sections 3.6.1.1, 3.6.1.2, and 3.8.2.2 introduces this mechanism for the following two scenarios: MN with a co-located IP address: i. MN sets the destination IP address of the IP packet that contain the MN Registration Request to the subnet-directed broadcast. ii. RFC3220 does not specify what IP address the Mobile Node insert in the HA field in the RRQ message. However, it may be understood that it is the same IP address. "subnet-directed broadcast" Since it does not know its HA. iii. Home Agent listens to the subnet-directed broadcast and "255.255.255.255." as mentioned in the RFC3220. iv. Every Home Agent which receives this IP packet MUST reject the RRQ with a code of 136 and insert its HA unicast IP address in the RRP message to the MN. v. After MN receives all the RRP messages from the different HAs, it chooses which HA to register with and then uses that HA IP address. MN with a FA Care-Of Address: i. MN sets the destination IP address of the IP packet that contain the MN Registration Request to the FA Care-Of Address. ii. RFC3220 specify that MN MAY use the "subnet-directed broadcast" IP address in the HA field in the RRQ message. iii. RFC3220 does not specify what the FA SHOULD do when receiving an IP packet which contains a RRQ message with a HA field is set to the "subnet-directed broadcast". It is basically very wise to do so by leaving the door open for future forward compatibility. However, IF FA just uses the same concept of the MN co-located IP address, then FA will forward the RRQ message to the HA "subnet-directed broadcast" by inserting this address in the destination IP address of the IP packet containing the RRQ message. iv. Home Agents listens to the subnet-directed broadcast and Broadcast IP address "255.255.255.255." as mentioned in the RFC3220. v. Every Home Agent which receives this IP packet MUST reject the RRQ with a code of 136 and insert the HA unicast IP address in the RRP message to the MN through the Foreign Agent Care-Of Address. vi. After MN receives all the RRP messages from the different HAs, it chooses which HA to register with and then use that HA IP address. Now, the only conflict I see is what mentioned in section 3.8.3.2 which reads: Section 3.8.2.2: " If the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, the home agent MUST reject the registration with a suitable code (e.g., Code 136) to prevent the mobile node from possibly being simultaneously registered with two or more home agents. " This section mandates that every HA rejects any RRQ message with HA field is different than the HA unicast IP address. This will not allow dynamic Home agent allocation using RADIUS or future Diameter in ONE SINGLE ROUND TRIP of the initial registration. In the spirit of resolving this issue to avoid forward compatibility problems, I believe this text SHOULD be modified to be consistent with what the RFC3220 is trying to propose for Home Agent dynamic allocation. Proposed TEXT: Section 3.8.2.2: " If the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case and only if this IP packet was distant to either the subnet-directed broadcast or 255.255.255.255, the home agent MUST reject the registration with a suitable code (e.g., Code 136) to prevent the mobile node from possibly being simultaneously registered with two or more home agents. " Thanks for consideration. Regards; Ahmad Muhanna ------_=_NextPart_001_01C1D9C1.AB723A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC3220 and possible forward compatibility issue "Dynamic = Home Agent Allocation"

Hello all;

RFC3220 (RFC2002) proposes a mechanism = for Dynamic Home Agent Resolution or allocation.
Sections 3.6.1.1, 3.6.1.2, and = 3.8.2.2 introduces this mechanism for the following two = scenarios:

MN with a co-located IP = address:
i.  MN sets the destination IP = address of the IP packet that contain the MN
    Registration = Request to the subnet-directed = broadcast.
ii. RFC3220 does not specify what IP = address the Mobile Node insert in the HA
    field in the RRQ = message. However, it may be understood that it is the
    same IP address. = "subnet-directed broadcast" Since it does not know its = HA.
iii. Home Agent listens to the = subnet-directed broadcast and "255.255.255.255."
    as mentioned in = the RFC3220.
iv. Every Home Agent which receives = this IP packet MUST reject the RRQ with a code
    of 136 and insert = its HA unicast IP address in the RRP message to the MN.
v.  After MN receives all the = RRP messages from the different HAs, it chooses which HA
     to register = with and then uses that HA IP address.


MN with a FA Care-Of = Address:
i.  MN sets the destination IP = address of the IP packet that contain the MN
    Registration = Request to the FA Care-Of = Address.
ii. RFC3220 specify that MN MAY use = the "subnet-directed broadcast" IP address in the HA
    field in the RRQ = message.
iii. RFC3220 does not specify what = the FA SHOULD do when receiving an IP packet which
    contains a RRQ = message with a HA field is set to the "subnet-directed = broadcast".
    It is basically = very wise to do so by leaving the door open for future forward = compatibility.
   
    However, IF FA = just uses the same concept of the MN co-located IP address,
    then FA will = forward the RRQ message to the HA "subnet-directed broadcast" = by
    inserting this = address in the destination IP address of the IP packet containing =
    the RRQ = message.

iv. Home Agents listens to the = subnet-directed broadcast and Broadcast
    IP address = "255.255.255.255." as mentioned in the RFC3220.
v. Every Home Agent which receives = this IP packet MUST reject the RRQ with a code
    of 136 and insert = the HA unicast IP address in the RRP message to the MN through the =
    Foreign Agent = Care-Of Address.
vi.  After MN receives all the = RRP messages from the different HAs, it chooses which HA
     to register = with and then use that HA IP address.

Now, the only conflict I see is what = mentioned in section 3.8.3.2 which reads:

Section 3.8.2.2:
"
   If the Home Agent field = in the Registration Request contains a
   unicast address of this = home agent, then that field MUST be copied
   into the Home Agent = field of the Registration Reply.  Otherwise, the
   home agent MUST set the = Home Agent field in the Registration Reply to
   its unicast = address.  In this latter case, the home agent MUST reject
   the registration with a = suitable code (e.g., Code 136) to prevent the
   mobile node from = possibly being simultaneously registered with two or
   more home agents.
"
This section mandates that every HA = rejects any RRQ message with HA
field is different than the HA = unicast IP address.
This will not allow dynamic Home = agent allocation using RADIUS or future
Diameter in ONE SINGLE ROUND TRIP of = the initial registration.

In the spirit of resolving this issue = to avoid forward compatibility problems,
I believe this text SHOULD be = modified to be consistent with
what the RFC3220 is trying to propose = for Home Agent dynamic allocation.

Proposed TEXT:
 Section 3.8.2.2:
"
   If the Home Agent field = in the Registration Request contains a
   unicast address of this = home agent, then that field MUST be copied
   into the Home Agent = field of the Registration Reply.  Otherwise, the
   home agent MUST set the = Home Agent field in the Registration Reply to
   its unicast = address.  In this latter case and only if this IP packet was distant
   to either the = subnet-directed broadcast or = 255.255.255.255, the home
   agent MUST reject the = registration with a suitable code (e.g., Code 136)
   to prevent the mobile = node from possibly being simultaneously registered
   with two or more home = agents.
"
 


Thanks for consideration.

Regards;
Ahmad = Muhanna

------_=_NextPart_001_01C1D9C1.AB723A30-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 16:18:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15278 for ; Mon, 1 Apr 2002 16:18:28 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00983; Mon, 1 Apr 2002 14:17:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16551; Mon, 1 Apr 2002 13:17:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31LGQKL000094 for ; Mon, 1 Apr 2002 13:16:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31LGPdH000093 for mobile-ip-dist; Mon, 1 Apr 2002 13:16:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31LGMKL000086 for ; Mon, 1 Apr 2002 13:16:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22733 for ; Mon, 1 Apr 2002 13:16:26 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23929 for ; Mon, 1 Apr 2002 14:16:25 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g31LG5I23555; Mon, 1 Apr 2002 13:16:05 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABG77294; Mon, 1 Apr 2002 13:13:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA13578; Mon, 1 Apr 2002 13:16:16 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15528.52767.937972.250225@thomasm-u1.cisco.com> Date: Mon, 1 Apr 2002 13:16:15 -0800 (PST) To: Erik Nordmark Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net, Samita Chakrabarti , erik.nordmark@sun.com Subject: [mobile-ip] Re: replacing IPsec's replay protection? In-Reply-To: References: <15528.51023.55916.42961@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > > So, I'm pretty far behind here, but I'm having a > > really hard time understanding why you'd want to > > replace IPsec's replay protection when you have > > key management. If it's there, it should be > > used. > > The issue on the table is based on the assumption that folks want to > secure the HA-MN using IPsec without IKE i.e. manual keys. > In that case IPsec doesn't provide replay protection as I understand. Correct. The better option here is to write a draft which solves this IPsec instead of doing a one-off for mobile IPv6. > > Also: requiring home agent routers to store > > *anything* on a per mobile node basis is going to > > be unacceptible. > > With manual keys the HA must have a table with > Home Address Key(s) > With IKE the HA must have a table with e.g. > Home Address Certificate > OR > Home Address CA+subject(alt)name in certificate > or > Home Address public key > > Do you think you can avoid those and still get security for the home > registrations? Sorry, I meant storing stuff in non-volatile memory on a per mobile node basis. With key management, you don't need to store per MN data in non-volatile memory. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 16:19:03 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15343 for ; Mon, 1 Apr 2002 16:19:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13047; Mon, 1 Apr 2002 13:18:08 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16795; Mon, 1 Apr 2002 13:17:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31LH2KL000107 for ; Mon, 1 Apr 2002 13:17:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31LH1l2000106 for mobile-ip-dist; Mon, 1 Apr 2002 13:17:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31LGuKL000099 for ; Mon, 1 Apr 2002 13:16:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22853 for ; Mon, 1 Apr 2002 13:17:00 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00650 for ; Mon, 1 Apr 2002 14:16:59 -0700 (MST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 1 Apr 2002 13:16:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D9C2.8EF3EC48" Subject: RE: [mobile-ip] Re: replacing IPsec's replay protection? Date: Mon, 1 Apr 2002 13:16:58 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Re: replacing IPsec's replay protection? Thread-Index: AcHZv9Nh3mvsZa6JQWmadgQQ1dRnzgAAdkuA From: "Mohan Parthasarathy" To: , "Michael Thomas" Cc: , "Samita Chakrabarti" X-OriginalArrivalTime: 01 Apr 2002 21:16:59.0104 (UTC) FILETIME=[8F1D7600:01C1D9C2] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D9C2.8EF3EC48 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Erik, >=20 >=20 > > So, I'm pretty far behind here, but I'm having a > > really hard time understanding why you'd want to > > replace IPsec's replay protection when you have > > key management. If it's there, it should be > > used. >=20 > The issue on the table is based on the assumption that folks=20 > want to secure the HA-MN using IPsec without IKE i.e. manual=20 > keys. In that case IPsec doesn't provide replay protection as=20 > I understand. >=20 Are we sure we really want to allow this ? You may want to allow the MN-HA to use pre-shared keys instead of certificates and still use IKE. I don't understand why someone would want to use manual keys. > > Also: requiring home agent routers to store > > *anything* on a per mobile node basis is going to > > be unacceptible. >=20 > With manual keys the HA must have a table with > Home Address Key(s) > With IKE the HA must have a table with e.g. > Home Address Certificate=20 > OR > Home Address CA+subject(alt)name in certificate > or > Home Address public key >=20 > Do you think you can avoid those and still get security for=20 > the home registrations? >=20 Agreed, that HA needs to store some information per-MN. -mohan > Erik >=20 > > Worse, the possibilities here of > > missynchronized state seem really high. What > > happens if they're out of sync? How is it > > corrected? Blech. > >=20 > > I really don't think we should be going here and > > strongly object to making this a MUST. A SHOULD on > > some form of key management (IKE, KINK, SOI) would > > be a *much* better idea. Let us not forget that > > keying is primarily a local policy issue, so > > forcing a MUST IMPLEMENT here will not necessarily > > get us any close to deployability. Indeed, it > > could delay it. Also: manual keying with IPsec is > > a known problem, and should be addressed within > > IPsec itself instead of special-casing mobile > > IP. This would be a win-win. Some of our folks are > > interested in this too, so contact me if you're > > interested. > >=20 > > Mike >=20 >=20 >=20 ------_=_NextPart_001_01C1D9C2.8EF3EC48 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: replacing IPsec's replay protection?

Erik,

>
>
> > So, I'm pretty far behind here, but I'm = having a
> > really hard time understanding why you'd = want to
> > replace IPsec's replay protection when you = have
> > key management. If it's there, it should = be
> > used.
>
> The issue on the table is based on the = assumption that folks
> want to secure the HA-MN using IPsec without IKE = i.e. manual
> keys. In that case IPsec doesn't provide replay = protection as
> I understand.
>
Are we sure we really want to allow this ? You may = want to allow
the MN-HA to use pre-shared keys instead of = certificates and
still use IKE. I don't understand why someone would = want to
use manual keys.

> > Also: requiring home agent routers to = store
> > *anything* on a per mobile node basis is = going to
> > be unacceptible.
>
> With manual keys the HA must have a table = with
>       Home = Address    Key(s)
> With IKE the HA must have a table with = e.g.
>       Home = Address    Certificate
> OR
>       Home = Address    CA+subject(alt)name in certificate
> or
>       Home = Address    public key
>
> Do you think you can avoid those and still get = security for
> the home registrations?
>
Agreed, that HA needs to store some information = per-MN.

-mohan

>   Erik
>
> > Worse, the possibilities here of
> > missynchronized state seem really high. = What
> > happens if they're out of sync?  How = is it
> > corrected? Blech.
> >
> > I really don't think we should be going = here and
> > strongly object to making this a MUST. A = SHOULD on
> > some form of key management (IKE, KINK, = SOI) would
> > be a *much* better idea. Let us not forget = that
> > keying is primarily a local policy issue, = so
> > forcing a MUST IMPLEMENT here will not = necessarily
> > get us any close to deployability.  = Indeed, it
> > could delay it. Also: manual keying with = IPsec is
> > a known problem, and should be addressed = within
> > IPsec itself instead of special-casing = mobile
> > IP. This would be a win-win. Some of our = folks are
> > interested in this too, so contact me if = you're
> > interested.
> >
> >     =         Mike
>
>
>

------_=_NextPart_001_01C1D9C2.8EF3EC48-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 18:21:41 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18758 for ; Mon, 1 Apr 2002 18:21:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27173; Mon, 1 Apr 2002 16:21:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03640; Mon, 1 Apr 2002 15:21:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31NKDKL000406 for ; Mon, 1 Apr 2002 15:20:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g31NKDE5000405 for mobile-ip-dist; Mon, 1 Apr 2002 15:20:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31NKBKL000398 for ; Mon, 1 Apr 2002 15:20:11 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA14954 for ; Mon, 1 Apr 2002 18:20:14 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA23083 for mobile-ip@sunroof.eng.sun.com; Mon, 1 Apr 2002 18:21:10 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g31MWWKL000353 for ; Mon, 1 Apr 2002 14:32:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04562 for ; Mon, 1 Apr 2002 14:32:35 -0800 (PST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16795 for ; Mon, 1 Apr 2002 14:32:14 -0800 (PST) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g31MWW403389 for ; Mon, 1 Apr 2002 17:32:33 -0500 (EST) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA28287; Mon, 1 Apr 2002 17:32:31 -0500 (EST) To: mobile-ip@sunroof.eng.sun.com, "Mohan Parthasarathy" , "Michael Thomas" Cc: , "Samita Chakrabarti" Received: from there by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA28283; Mon, 1 Apr 2002 17:32:30 -0500 (EST) Message-Id: <200204012232.RAA28283@nwmail.wh.lucent.com> Content-Type: text/plain; charset="koi8-r" From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs Original-To: mobile-ip@sunroof.eng.sun.com, "Mohan Parthasarathy" , "Michael Thomas" Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Date: Mon, 1 Apr 2002 17:29:15 -0500 X-Mailer: KMail [version 1.3.2] Original-Cc: , "Samita Chakrabarti" References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g31MWWKL000354 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Monday 01 April 2002 16:16, Mohan Parthasarathy wrote: > > The issue on the table is based on the assumption that folks > > want to secure the HA-MN using IPsec without IKE i.e. manual > > keys. In that case IPsec doesn't provide replay protection as > > I understand. > > Are we sure we really want to allow this ? You may want to allow > the MN-HA to use pre-shared keys instead of certificates and > still use IKE. I don't understand why someone would want to > use manual keys. I think Erik meant "pre-shared" - how they got there is another story. As for IKE - some people say it adds too much overhead (one of the reasons IKEv2 is being born :-). -- Regards, Uri -=-=-<>-=-=- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 21:02:33 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21664 for ; Mon, 1 Apr 2002 21:02:24 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA00946; Mon, 1 Apr 2002 17:46:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15500; Mon, 1 Apr 2002 17:46:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g321jnKL000775 for ; Mon, 1 Apr 2002 17:45:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g321jnT3000774 for mobile-ip-dist; Mon, 1 Apr 2002 17:45:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g321jkKL000764 for ; Mon, 1 Apr 2002 17:45:46 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g321jm7p739289; Mon, 1 Apr 2002 17:45:48 -0800 (PST) Message-Id: <200204020145.g321jm7p739289@jurassic.eng.sun.com> Date: Mon, 1 Apr 2002 17:48:04 -0800 (PST) From: Samita Chakrabarti Subject: Re: [mobile-ip] Comments on Draft 16 To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com, erik.nordmark@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Ia34eTPlrqTO+wQb/5ClUw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Vijay's description below clears concept for MN behavior in case it reboots. > > As per Vijay's description on draft15, HA can accept BUs with any seq# after HA > > reboots as it does not keep the state upon reboot. > > > Right, I believe what Vijay described does have a small vulnerability > in that after a reboot replays are possible. > > Agreed. > > Although, it adds extra replay protection at HA, I'd think, the > > home-agent usage of NV memory could be optional. I'd like to know > > how big is the threat in this particular case (i,e if HA reboots). > > If we somehow decide that HA should preserve the bindings accross reboot, > > then obviously, it makes sense to have all the information intact. > > > Yes. Why don't we use the -15 scheme, describe the remaining threat and > make the seqno-preservation through reboots a SHOULD (or a MAY). > > OK. > > Also this section mentions "The mobile node and homeagent MAY on a new key > > for the security association before this many (2**31) BU have been sent if > > this is an issue". > > I wonder if we leave it as MAY, then there might be some interoperability issues > > as MN and HA may have different expectations. > > > I don't think so. There has to be a key management scheme to change the key, > and I can only think of two: IKE and a manual change. In either case it will > be apparent if the other side does not support this activity. For instance, if > manual keying is used then the administrator either gets hold of the mobile node's > owner and asks him to change the key, or he doesn't ;-) > Ok. I got your point. > But perhaps we should clarify in the draft that the mobile IP protocol as such > will not start complaining about too old keys. So, as far as mobile IP concerned > this wrapping over is ok, and does not result in any error codes. > > Yes, clarification would be good, thanks. > > 1. section 4.5.5, please clarify in words how the Correspondent node > > secret key Kcn would be used. There is an example of MAC_Kcn in COT > > message processing, but that is not very clear. > > > This key is used by the correspondent node to accept only the use of cookies > which it has created itself. Adding some text... > > Ok. > > 2. In HOTI and COTI messages we use "nonce" index. What is "nonce" index? > > Is it a random number ? IBM has IPR on nonces, how different or same > > is this nonce index from IBM's nonces ? > > > It is just an efficient way to find the right nonce. Adding some text.. > > As for the IPRs, please tell me more! Do you have a pointer to IBM's > claim? > Actually MobileIPv4 uses "nonces" as optional mechanism for replay protection. I find the pointer for IBM patent in RFC2002 (appendix. A.2). A.2. IBM Patent #5,148,479 This patent, also assigned to IBM, may be relevant to those who implement nonce-based replay protection as described in Section 5.6.2. Note that nonce-based replay protection is an optional feature of this specification. Timestamp-based replay protection, on the other hand, (Section 5.6.1) is a requirement of this specification. However, I cannot see the reference anymore in latest version of MobileIPv4 -RFC3220. RFC3220, '5.7.2 Replay Protection using Nonces' has description how to use nonces for replay protection. Here it refers to RFC1750. Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. Since "nonces" are the default replay protection method in MIPv6 HOTI/COTI messages, a clarification on it's usage will be quite useful. I am not sure whether the IPR issue still holds here-perhaps needs to be investigated? Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 1 21:31:15 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22047 for ; Mon, 1 Apr 2002 21:31:14 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA05870; Mon, 1 Apr 2002 18:27:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26601; Mon, 1 Apr 2002 18:27:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g322R2KL000976 for ; Mon, 1 Apr 2002 18:27:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g322R1Cc000975 for mobile-ip-dist; Mon, 1 Apr 2002 18:27:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g322QxKL000968 for ; Mon, 1 Apr 2002 18:26:59 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g322R17p745713; Mon, 1 Apr 2002 18:27:02 -0800 (PST) Message-Id: <200204020227.g322R17p745713@jurassic.eng.sun.com> Date: Mon, 1 Apr 2002 18:29:17 -0800 (PST) From: Samita Chakrabarti Subject: Re: [mobile-ip] Comments on Draft 16 To: Erik.Nordmark@Sun.COM Cc: jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jNDqDsQl37259if7xd+8zg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > Although, it adds extra replay protection at HA, I'd think, the > > > home-agent usage of NV memory could be optional. I'd like to know > > > how big is the threat in this particular case (i,e if HA reboots). > > > If we somehow decide that HA should preserve the bindings accross reboot, > > > then obviously, it makes sense to have all the information intact. > > > > > > Yes. Why don't we use the -15 scheme, describe the remaining threat and > > make the seqno-preservation through reboots a SHOULD (or a MAY). > > Stable storage at the HA for the seqno can presumably be a SHOULD, with > the ability to "lock in" on the first sequence number is receives from > a MN after rebooting. > But I thought the concerns were more on the MN side (where stable storage > would often be implemented using NVram with a finite number of writes > during the lifetime of the memory. > We can't relax that constraint as far as I can tell. I thought that is what Jari was referring to, but perhaps it's not clear. Thanks for pointing it out. -Samita From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 03:40:22 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10009 for ; Tue, 2 Apr 2002 03:40:22 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11450; Tue, 2 Apr 2002 01:39:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19507; Tue, 2 Apr 2002 00:39:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g328b1KL001303 for ; Tue, 2 Apr 2002 00:37:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g328b1pW001302 for mobile-ip-dist; Tue, 2 Apr 2002 00:37:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g328awKL001295 for ; Tue, 2 Apr 2002 00:36:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11315 for ; Tue, 2 Apr 2002 00:36:56 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13046 for ; Tue, 2 Apr 2002 01:36:56 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g328at3G002583 for ; Tue, 2 Apr 2002 10:36:55 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 02 10:32:43 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 10:32:42 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABD9@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 2 Apr 2002 10:34:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > > => Which is exactly my point. IAPP is not relevant here. > > The only way to do it in WLAN (at least so far) is to > > make sure that the MN initiates the handover > > based on internal triggers. > > > > If the vendors build IAPP into their APs and 802.11 > handover is designed > to require a secure IAPP transaction to complete before the > new AP lets > the MN send packets onto the new link, then this will > lengthen 802.11 > handover out considerably beyond the rather poor performance of the > current round of AP products. Regardless of what the MN > does prior to > handover. So I think it is very relevent indeed. => I think there is something missing in our communication. I didn't think IAPP will run between subnets, is this correct? If yes, then this is something for IEEE to work out. Like all other L2 designers, they will do their best to minimise their L2's handover time. > > > => James I don't understand why or how you can do that. > > Unless you have connection oriented l2s with the MN > > reporting measurements to the APs, you can't > > do it. Is IEEE going to design a cellular network > > now? > > Even if this happens, are we going to run IAPP > > between subnets?? Even if we do that, wouldn't > > there still be some interruption from the time > > IAPP does its thing, till the MN actually moves? > > > > The level of complication is astounding and frankly > > I don't understand why you would want to do that. > > > > If people within the WG keep ignoring the work that this > > WG is doing, then I agree, nothing produced > > by the WG will ever be used! > > > > Please stay calm, Hesham. => I am calm, asking a lot of questions does not mean I'm hysterical. > > "We" are not going to run IAPP, that is what the 802.11 > committee wants > to do. The problem IAPP is supposed to solve is to tell the > old access > point to unallocate buffers and clean up other data structures > associated with providing the MN with IP connectivity. Onto > that, there > has been additional stuff loaded, like context transfer. => OK I understand this, but I'm trying to understand the relevance to IP handover, which is what we care about here. If this is only running within the same subnet, then it shouldn't matter to us. > I'd suggest that if you have some interest in seeing the right thing > done, you contact Bernard Abboba who has been monitoring > them closely, => Thanks. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 03:50:25 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10189 for ; Tue, 2 Apr 2002 03:50:24 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25526; Tue, 2 Apr 2002 00:49:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20668; Tue, 2 Apr 2002 00:49:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g328mjKL001407 for ; Tue, 2 Apr 2002 00:48:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g328mj1q001406 for mobile-ip-dist; Tue, 2 Apr 2002 00:48:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g328mgKL001399 for ; Tue, 2 Apr 2002 00:48:42 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20634 for ; Tue, 2 Apr 2002 00:48:45 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02478 for ; Tue, 2 Apr 2002 00:48:44 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g328mh3G010782 for ; Tue, 2 Apr 2002 10:48:44 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 02 10:42:40 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 10:32:27 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABDC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 2 Apr 2002 10:42:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Agreed. Hesham > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Thursday, March 28, 2002 9:00 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Sorry to interrupt.. > > I think if IAPP is improved in IEEE, that's good; another > crucial step > towards supporting real-time applications during WLAN mobility.. > For us, we should constrain ourselves with IP mobility > aspects. If it > turns out that certain link-specific issues are of > interest, they should > be handled separately in an appropriate "link-specific extensions" > document. > > In general, I have reservations to including L2-specific > optimizations > in the base specification. > > My 2 cents.. > > -Rajeev > > > George Tsirtsis wrote: > > > James, > > > > Maybe the larger question is why WE (the IETF) is > concerned with how a link > > layer mobility management protocol works and indeed why > are we discussing > > how it should be changed to become better or worst. > Otherwise we should also > > get the specs from GSMA, 3GPP, 3GPP2, and a hundred other > organizations and > > start analyzing them and trying to make them do this and that. > > > > I think this does not make any sense at all...and I > wonder...is it only me? > > > > George > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Thursday, March 28, 2002 6:46 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > Hesham, > > > > > => Which is exactly my point. IAPP is not relevant here. > > > The only way to do it in WLAN (at least so far) is to > > > make sure that the MN initiates the handover > > > based on internal triggers. > > > > > > > If the vendors build IAPP into their APs and 802.11 > handover is designed > > to require a secure IAPP transaction to complete before > the new AP lets > > the MN send packets onto the new link, then this will > lengthen 802.11 > > handover out considerably beyond the rather poor > performance of the > > current round of AP products. Regardless of what the MN > does prior to > > handover. So I think it is very relevent indeed. > > > > > => I don't understand why PREREG is not considered > > > a solution here? We always assumed that IAPP is > > > not relevant. > > > > > > > It doesn't matter which fast handover algorithm is used, > if the IAPP > > transaction takes, say, 200 ms to complete and the L2 > handover takes 200 > > ms to complete before the MN is allowed to get new > packets through the > > new AP, then any optimization at Layer 3 will be in the > noise. I wasn't > > making a point about PREREG v.s. POSTREG, I was making a > point about how > > the assumptions being made by the 802.11 committee are > causing both > > algorithms to be not useful. > > > > > => James I don't understand why or how you can do that. > > > Unless you have connection oriented l2s with the MN > > > reporting measurements to the APs, you can't > > > do it. Is IEEE going to design a cellular network > > > now? > > > Even if this happens, are we going to run IAPP > > > between subnets?? Even if we do that, wouldn't > > > there still be some interruption from the time > > > IAPP does its thing, till the MN actually moves? > > > > > > The level of complication is astounding and frankly > > > I don't understand why you would want to do that. > > > > > > If people within the WG keep ignoring the work that this > > > WG is doing, then I agree, nothing produced > > > by the WG will ever be used! > > > > > > > Please stay calm, Hesham. > > > > "We" are not going to run IAPP, that is what the 802.11 > committee wants > > to do. The problem IAPP is supposed to solve is to tell > the old access > > point to unallocate buffers and clean up other data structures > > associated with providing the MN with IP connectivity. > Onto that, there > > has been additional stuff loaded, like context transfer. > Also, I believe > > they are thinking of using it for flushing the ARP cache. > > > > I'd suggest that if you have some interest in seeing the > right thing > > done, you contact Bernard Abboba who has been monitoring > them closely, > > and have him brief you on the details. Also, take a look > at the 802.11f > > IAPP spec, http://grouper.ieee.org/groups/802/11/ and > browse from there. > > If you see something that he and I have missed, then > please let us > > know. We are just trying to convince them that their > protocol needs some > > work if it will properly support fast IP handover. > > > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 04:30:05 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10547 for ; Tue, 2 Apr 2002 04:30:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18407; Tue, 2 Apr 2002 02:29:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25345; Tue, 2 Apr 2002 01:29:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g329SgKL001580 for ; Tue, 2 Apr 2002 01:28:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g329Sgis001579 for mobile-ip-dist; Tue, 2 Apr 2002 01:28:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g329SdKL001572 for ; Tue, 2 Apr 2002 01:28:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19720 for ; Tue, 2 Apr 2002 01:28:41 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20385 for ; Tue, 2 Apr 2002 02:28:40 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 04:28:39 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC8B@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" , "'jari.arkko@piuha.net'" Cc: "'PRoberts@MEGISTO.com'" , "'Basavaraj.Patil@nokia.com'" Subject: RE: [mobile-ip] Reverse tunneling issues Date: Tue, 2 Apr 2002 04:28:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-7" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari, Here is the deal... draft-oneill-mip-revtun-ho-00.txt in section 6. "IPv6 Considerations" currently suggest: "The IPv6 HA should support the automatic invocation of a fan-in binding if reverse tunneling is requested." "Fan-in bindings" are explained earlier in the document This essentially says that when reverse tunneling is used the HA has to maintain at least 2 bindings for the MN, at least for a short time during handoff. So for example, - Assume a MN that uses reverse tunneling - After the MN hands off to a new CoA it sends the appropriate BU to the HA - The HA registers the new binding to the newCoA and immediately uses it for all downlink traffic. - The HA also keeps the oldCoA binding for a while but only uses it so that it can accept in-flight packets from that oldCoA - The old binding is removed if/when the MN moves to yet another (third) CoA or after a default timeout. The above works for both MIPv4 and MIPv6 and does not require any signaling changes, but only behavior changes at the HA i.e.: currently a new Binding REPLACES the old Binding. The text needs to be revised to say that the new Binding REPLACES the old Binding for downlink traffic but it is ADDED to the old Binding for reverse tunneled traffic. Also note that while the above helps, it does not solve the problem completely for reasons explained in the draft. To solve all problems with reverse tunneling we need signaling changes/extensions which I guess could be described in a new draft. Does this make sense? Regards George -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Saturday, March 30, 2002 2:09 PM To: mobile-ip@sunroof.eng.sun.com Cc: 'PRoberts@MEGISTO.com'; 'Basavaraj.Patil@nokia.com' Subject: Re: [mobile-ip] Reverse tunneling issues George Tsirtsis wrote: > GT> No problem...have a look at the draft and do not let the too many > options of how to solve the problem confuse you ...this is not complex...it > is just that it has to be dealt with. Assuming something has to be done, is this something that has to go to the base RFC, or something that can be done in an extension separately? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 04:39:44 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10658 for ; Tue, 2 Apr 2002 04:39:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20775; Tue, 2 Apr 2002 02:35:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26513; Tue, 2 Apr 2002 01:35:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g329YfKL001663 for ; Tue, 2 Apr 2002 01:34:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g329YfQq001662 for mobile-ip-dist; Tue, 2 Apr 2002 01:34:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g329YbKL001655 for ; Tue, 2 Apr 2002 01:34:37 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20999; Tue, 2 Apr 2002 01:34:40 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-225.France.Sun.COM [129.157.212.225]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g329YaL00142; Tue, 2 Apr 2002 01:34:36 -0800 (PST) Message-ID: <3CA97AD2.6C4B7D6E@sun.com> Date: Tue, 02 Apr 2002 11:33:07 +0200 From: gabriel montenegro X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "'jari.arkko@piuha.net'" , "'PRoberts@MEGISTO.com'" , "'Basavaraj.Patil@nokia.com'" Subject: Re: [mobile-ip] Reverse tunneling issues References: <8C92E23A3E87FB479988285F9E22BE465ABC8B@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George, Your draft talks about IPR on your proposal. Could you clarify how much (if not all) is covered, etc? -gabriel From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 04:41:43 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10760 for ; Tue, 2 Apr 2002 04:41:43 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03714; Tue, 2 Apr 2002 01:39:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27015; Tue, 2 Apr 2002 01:39:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g329cRKL001740 for ; Tue, 2 Apr 2002 01:38:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g329cR5g001739 for mobile-ip-dist; Tue, 2 Apr 2002 01:38:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g329cMKL001732 for ; Tue, 2 Apr 2002 01:38:23 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21625; Tue, 2 Apr 2002 01:38:25 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-225.France.Sun.COM [129.157.212.225]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g329cKL00167; Tue, 2 Apr 2002 01:38:22 -0800 (PST) Message-ID: <3CA97BB0.A7D9B6AA@sun.com> Date: Tue, 02 Apr 2002 11:36:48 +0200 From: gabriel montenegro X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Singh Ajoy-ASINGH1 Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 References: <4DA6EA82906FD511BE2F00508BCF053802C6AB6E@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > Also, there were some other questions raised about > > bicasting around the > > effect on reliable transports that need resolution, we're > > planning on > > looking into experimentally them soon. > > => I haven't seen any substantial proof of that. > In fact I saw a paper that proved the opposite > (and neither me or Karim had anything to do > with it :) ). > Also the Eifel algorithm can solve any potential > problems. If in fact, there is no problem, this question is not relevant, but are there any other proposals (besides Eifel) to solve this? Eifel has IPR. This IPR is royalty free for implementation on open source platforms. It is not royalty free for other platforms. -gabriel From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 04:45:50 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10796 for ; Tue, 2 Apr 2002 04:45:50 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10751; Tue, 2 Apr 2002 02:42:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27504; Tue, 2 Apr 2002 01:42:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g329feKL001815 for ; Tue, 2 Apr 2002 01:41:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g329fegE001814 for mobile-ip-dist; Tue, 2 Apr 2002 01:41:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g329fUKL001800 for ; Tue, 2 Apr 2002 01:41:30 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22052; Tue, 2 Apr 2002 01:41:33 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-225.France.Sun.COM [129.157.212.225]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g329fUL00193; Tue, 2 Apr 2002 01:41:30 -0800 (PST) Message-ID: <3CA97C6C.87B0EA3F@sun.com> Date: Tue, 02 Apr 2002 11:39:56 +0200 From: gabriel montenegro X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: jari.arkko@piuha.net, erik.nordmark@sun.com Subject: Re: [mobile-ip] Comments on Draft 16 References: <200204020145.g321jm7p739289@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: > Actually MobileIPv4 uses "nonces" as optional mechanism for replay protection. It used to be the other way around, with timestamps as optional. IBM liberated the IPR on nonces for IPsec, but since the corresponding statement for Mobile IP was not produced, the working group changed it to optional. > I find the pointer for IBM patent in RFC2002 (appendix. A.2). > > A.2. IBM Patent #5,148,479 > > This patent, also assigned to IBM, may be relevant to those who > implement nonce-based replay protection as described in Section > 5.6.2. Note that nonce-based replay protection is an optional > feature of this specification. Timestamp-based replay protection, on > the other hand, (Section 5.6.1) is a requirement of this > specification. > > However, I cannot see the reference anymore in latest version of MobileIPv4 > -RFC3220. > > RFC3220, '5.7.2 Replay Protection using Nonces' has description how to > use nonces for replay protection. Here it refers to RFC1750. > Eastlake, D., Crocker, S. and J. Schiller, "Randomness > Recommendations for Security", RFC 1750, December 1994. > > > Since "nonces" are the default replay protection method in MIPv6 > HOTI/COTI messages, a clarification on it's usage will be quite useful. > I am not sure whether the IPR issue still holds here-perhaps needs to be > investigated? Good question, I don't know. -gabriel From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 05:07:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11041 for ; Tue, 2 Apr 2002 05:07:02 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00763; Tue, 2 Apr 2002 03:04:16 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28297; Tue, 2 Apr 2002 02:04:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32A3OKL001952 for ; Tue, 2 Apr 2002 02:03:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32A3OTX001951 for mobile-ip-dist; Tue, 2 Apr 2002 02:03:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32A3LKL001944 for ; Tue, 2 Apr 2002 02:03:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28558 for ; Tue, 2 Apr 2002 02:03:25 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02835 for ; Tue, 2 Apr 2002 03:03:24 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g32A3N3G002854 for ; Tue, 2 Apr 2002 12:03:23 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 02 11:57:23 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 11:57:23 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABDF@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Singh Ajoy-ASINGH1 Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 2 Apr 2002 11:59:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Gabriel, > > => I haven't seen any substantial proof of that. > > In fact I saw a paper that proved the opposite > > (and neither me or Karim had anything to do > > with it :) ). > > Also the Eifel algorithm can solve any potential > > problems. > > If in fact, there is no problem, this question is not relevant, but > are there any other proposals (besides Eifel) to solve this? > Eifel has IPR. This IPR is royalty free for implementation on > open source platforms. It is not royalty free for other platforms. > => :) You want royalty free for everyone do you ? :) I believe on top of the royalty free, there are some words on reciprocity ...etc. But of course, all this comes down to whether there *is* a problem at all. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 06:04:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11897 for ; Tue, 2 Apr 2002 06:04:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07524; Tue, 2 Apr 2002 04:02:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06549; Tue, 2 Apr 2002 03:02:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32B1UKL002097 for ; Tue, 2 Apr 2002 03:01:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32B1U2A002096 for mobile-ip-dist; Tue, 2 Apr 2002 03:01:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32B1RKL002089 for ; Tue, 2 Apr 2002 03:01:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00689 for ; Tue, 2 Apr 2002 03:01:29 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA22191 for ; Tue, 2 Apr 2002 04:01:28 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g32B1Os7006043 for ; Tue, 2 Apr 2002 13:01:28 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 02 12:59:12 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:51:10 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABE2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'jari.arkko@piuha.net'" Cc: "'mobile-ip@sunroof.eng.sun.com'" , Glenn Morrow Subject: RE: [mobile-ip] Comments on Draft 16 Date: Tue, 2 Apr 2002 13:01:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Anyway, there seems to be a few different issues: > > 1. Now that reverse tunneling is mandatory if there's no > RO, part of the problem goes away. => The problem is whether we can allow a node to reverse tunnel to the HA, when using a site-local address as a home address, without authenticating the tunnel. The problem is not so much in the reverse tunnelling part, but rather due to using a Site-local HoA, which is most likely communicating with a Site-local address within the home site. So by not authenticating the tunnel we're allowing anyone to spoof the HoA and start sending messages to a server within the home site, that perhaps is not meant to be reached from outside the site. Of course the question is, since the server's replies will be sent to the MN, is this a problem? But independantly of that, if the tunnel is not authenticated, an outsider is getting a hole that he wouldn't normally get with standard IPv6 routers on the border of the site. > 2. When RO is used, a CoA is not site-local, so this isn't > a problem either. => Well in theory you can have a site-local CoA when talking to a CN in the same site. I don't know if people want to allow this in the spec though. > 3. Authentication of the tunnel. Is there some difference > in the security impacts whether or note link/site-local > addresses or global addresses are used? => See above and let me know if it makes any sense :) Link local traffic is not forwarded by the HA. At least this is what the draft said till 15. I don't know if that was changed in 16, I haven't checked it in detail. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 07:31:19 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13057 for ; Tue, 2 Apr 2002 07:31:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28609; Tue, 2 Apr 2002 04:30:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14939; Tue, 2 Apr 2002 04:29:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32CShKL002252 for ; Tue, 2 Apr 2002 04:28:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32CShPk002251 for mobile-ip-dist; Tue, 2 Apr 2002 04:28:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32CSdKL002244 for ; Tue, 2 Apr 2002 04:28:39 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g32CSdx08531; Tue, 2 Apr 2002 14:28:39 +0200 (MEST) Date: Tue, 2 Apr 2002 14:27:13 +0200 (CEST) From: Erik Nordmark Subject: RE: [mobile-ip] Re: replacing IPsec's replay protection? To: mohanp@tahoenetworks.com Cc: mobile-ip@sunroof.eng.sun.com, Michael Thomas , jari.arkko@piuha.net, Samita Chakrabarti In-Reply-To: "Your message with ID" <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Are we sure we really want to allow this ? You may want to allow > the MN-HA to use pre-shared keys instead of certificates and > still use IKE. I don't understand why someone would want to > use manual keys. I think there are people thinking about small mobile nodes that might not want to require using IKE on those devices. But I'm not one of them - perhaps they should speak for themselves. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 07:37:18 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13251 for ; Tue, 2 Apr 2002 07:37:17 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08265; Tue, 2 Apr 2002 05:35:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15807; Tue, 2 Apr 2002 04:35:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32CYUKL002334 for ; Tue, 2 Apr 2002 04:34:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32CYTon002333 for mobile-ip-dist; Tue, 2 Apr 2002 04:34:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32CYPKL002326 for ; Tue, 2 Apr 2002 04:34:26 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g32CYQx09102; Tue, 2 Apr 2002 14:34:26 +0200 (MEST) Date: Tue, 2 Apr 2002 14:34:07 +0200 (CEST) From: Erik Nordmark Subject: RE: [mobile-ip] Comments on Draft 16 To: hesham.soliman@era.ericsson.se Cc: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" , Glenn Morrow In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053802C6ABE2@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => The problem is whether we can allow a node to reverse > tunnel to the HA, when using a site-local address as > a home address, without authenticating the tunnel. > The problem is not so much in the reverse tunnelling > part, but rather due to using a Site-local HoA, which > is most likely communicating with a Site-local address > within the home site. So by not authenticating the tunnel > we're allowing anyone to spoof the HoA and start sending > messages to a server within the home site, that perhaps > is not meant to be reached from outside the site. > Of course the question is, since the server's replies > will be sent to the MN, is this a problem? > But independantly of that, if the tunnel is not > authenticated, an outsider is getting a hole > that he wouldn't normally get with standard IPv6 > routers on the border of the site. Hesham, I don't think allowing reverse tunnels without IPsec protection adds any new residual threats as long as the HA verifies that packets contain an outer source = CoA and an inner source = HoA (where there is a valid binding between HoA and CoA). For example, in the site-local case, if there is no internal ingress filtering within a site then anybody could spoof site-local source addresses without using MIPv6. Did you mean "IPsec" when you said "authenticated" or did you mean "verified"? (the term we used for HAO verification by CNs) Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 08:03:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13751 for ; Tue, 2 Apr 2002 08:03:52 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01637; Tue, 2 Apr 2002 05:59:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06017; Tue, 2 Apr 2002 04:58:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32CwBKL002519 for ; Tue, 2 Apr 2002 04:58:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32CwA4U002518 for mobile-ip-dist; Tue, 2 Apr 2002 04:58:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32Cw7KL002511 for ; Tue, 2 Apr 2002 04:58:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24823 for ; Tue, 2 Apr 2002 04:58:11 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA03642 for ; Tue, 2 Apr 2002 05:58:09 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g32Cw83G015428 for ; Tue, 2 Apr 2002 14:58:08 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 02 14:58:04 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 14:47:50 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABE8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" , Glenn Morrow Subject: RE: [mobile-ip] Comments on Draft 16 Date: Tue, 2 Apr 2002 14:58:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik, > I don't think allowing reverse tunnels without IPsec > protection adds any > new residual threats as long as the HA verifies that packets contain > an outer source = CoA and an inner source = HoA (where > there is a valid > binding between HoA and CoA). => I was thinking of the case where ingress filtering is used in the visited network, but in the case of multiaccess links this would not stop someone from spoofing another node's CoA. So I'm not sure it's due to the absence of ingress filtering , it's more due to the absence access control. But my point was, if I want to talk to a site-local address inside ericsson.com, while I'm at the IETF I would have to have some sort of VPN access (IPsec tunnel) to the firewall. I'm assuming that someone might want to use site-local addresses inside a site to prevent anyone from reaching the server from outside the site. So if we allow any MN to tunnel a site-local HoA from a CoA through the HA, don't we want to make sure that the tunnel is authenticated to prevent anyone snooping the traffic from creating this tunnel? Or do we assume that there will be a secured tunnel anyway to the firewall in the home network, in order for the MN to reach the HA? I guess this would work as well. But the spec in general does not assume the existence of firewalls in every site. > > For example, in the site-local case, if there is no > internal ingress filtering > within a site then anybody could spoof site-local source addresses > without using MIPv6. => Sure, but I was concerned about the case where they can reach a site-local address in the home site, while located at a visited site. Which is normally impossible. > > Did you mean "IPsec" when you said "authenticated" or did you mean > "verified"? (the term we used for HAO verification by CNs) => I meant IPsec. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 09:24:31 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16424 for ; Tue, 2 Apr 2002 09:24:30 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20980; Tue, 2 Apr 2002 06:24:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28151; Tue, 2 Apr 2002 06:24:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32ENHKL002703 for ; Tue, 2 Apr 2002 06:23:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32ENH6e002702 for mobile-ip-dist; Tue, 2 Apr 2002 06:23:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32ENCKL002695 for ; Tue, 2 Apr 2002 06:23:13 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g32ENBx19867; Tue, 2 Apr 2002 16:23:11 +0200 (MEST) Date: Tue, 2 Apr 2002 16:22:53 +0200 (CEST) From: Erik Nordmark Subject: RE: [mobile-ip] Comments on Draft 16 To: "Hesham Soliman (ERA)" Cc: "'Erik Nordmark'" , "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" , Glenn Morrow In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053802C6ABE8@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > But my point was, if I want to talk to a site-local > address inside ericsson.com, while I'm at the IETF > I would have to have some sort of VPN access > (IPsec tunnel) to the firewall. I'm assuming that > someone might want to use site-local addresses > inside a site to prevent anyone from reaching the > server from outside the site. > So if we allow any MN to tunnel a site-local HoA from > a CoA through the HA, don't we want to make sure that > the tunnel is authenticated to prevent anyone snooping > the traffic from creating this tunnel? Yes, but that is because you have a policy, independent of MIPv6, of wanting VPN protection for your data packets. That is one possible policy. But there might be other policies that don't require an IPsec VPN when packets are tunneled to home site-local addresses. There shouldn't be a need to pick and cast in stone any particular policy here as far as I can tell. > => Sure, but I was concerned about the case where > they can reach a site-local address in the home > site, while located at a visited site. Which is > normally impossible. But even that isn't unique to MIPv6. A node could run an IPv6-in-IPv6 tunnel endpoint - one entity outside the firwall and one inside. BTW: Section 11 in draft-ietf-ipngwg-scoping-arch-03.txt is quite restrictive in this space, while previous versions where more open. Do people think it should be more or less restrictive when it comes to tunning site-locals? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 10:01:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18082 for ; Tue, 2 Apr 2002 10:01:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16077; Tue, 2 Apr 2002 08:01:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06830; Tue, 2 Apr 2002 07:01:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32F0BKL002841 for ; Tue, 2 Apr 2002 07:00:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32F0B70002840 for mobile-ip-dist; Tue, 2 Apr 2002 07:00:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32F08KL002833 for ; Tue, 2 Apr 2002 07:00:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12737 for ; Tue, 2 Apr 2002 07:00:11 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25298 for ; Tue, 2 Apr 2002 08:00:10 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g32F093G026704 for ; Tue, 2 Apr 2002 17:00:09 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 02 16:58:14 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:00:08 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABEB@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" , Glenn Morrow Subject: RE: [mobile-ip] Comments on Draft 16 Date: Tue, 2 Apr 2002 16:59:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > But my point was, if I want to talk to a site-local > > address inside ericsson.com, while I'm at the IETF > > I would have to have some sort of VPN access > > (IPsec tunnel) to the firewall. I'm assuming that > > someone might want to use site-local addresses > > inside a site to prevent anyone from reaching the > > server from outside the site. > > So if we allow any MN to tunnel a site-local HoA from > > a CoA through the HA, don't we want to make sure that > > the tunnel is authenticated to prevent anyone snooping > > the traffic from creating this tunnel? > > Yes, but that is because you have a policy, independent of MIPv6, of > wanting VPN protection for your data packets. => Sure. > > That is one possible policy. But there might be other policies > that don't require an IPsec VPN when packets are tunneled to home > site-local addresses. > There shouldn't be a need to pick and cast in stone any > particular policy here > as far as I can tell. => Ok. I guess organisations that care about their security will set the right policies. > > => Sure, but I was concerned about the case where > > they can reach a site-local address in the home > > site, while located at a visited site. Which is > > normally impossible. > > But even that isn't unique to MIPv6. A node could run an > IPv6-in-IPv6 tunnel > endpoint - one entity outside the firwall and one inside. => Right, but today the tunnel will be dropped if it's not secured. I guess your point is that this behaviour does not need to be explicitly mandated, it's more like common sense for administrators to set this policy. Sounds fair enough. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 10:51:48 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19882 for ; Tue, 2 Apr 2002 10:51:47 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21258; Tue, 2 Apr 2002 08:51:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16885; Tue, 2 Apr 2002 07:51:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32FoWKL003024 for ; Tue, 2 Apr 2002 07:50:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32FoVsh003023 for mobile-ip-dist; Tue, 2 Apr 2002 07:50:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32FoSKL003016 for ; Tue, 2 Apr 2002 07:50:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20713 for ; Tue, 2 Apr 2002 07:50:31 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10094 for ; Tue, 2 Apr 2002 08:50:30 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g32FoT3G015692 for ; Tue, 2 Apr 2002 17:50:29 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 02 17:48:34 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:40:15 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABEF@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com, Rajeev Koodli Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16 Date: Tue, 2 Apr 2002 17:50:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I'm not sure I understand. The MN does need to send an F-BU > to the old > AR. That either happens when the MN is on the old link or > on the new. > What I'm saying is that I don't believe there needs to be > an RR test on > the new CoA because the HI/HAck exchange allows the old AR, which > is serving as the on link home agent, can be strongly authenticated. => I think that it ultimately comes down to the basis of the trust between the MN and the old AR. Authenticating HI and HAck between the old and new ARs does not necessarily mean that the MN is not trying to bomb the new network does it ? But everyone seems to assume that it is enough so what am I missing? Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 11:14:35 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21048 for ; Tue, 2 Apr 2002 11:14:35 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03227; Tue, 2 Apr 2002 09:13:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26082; Tue, 2 Apr 2002 08:13:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32GCxKL003128 for ; Tue, 2 Apr 2002 08:12:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32GCxko003127 for mobile-ip-dist; Tue, 2 Apr 2002 08:12:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32GCtKL003120 for ; Tue, 2 Apr 2002 08:12:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23112 for ; Tue, 2 Apr 2002 08:12:59 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24271 for ; Tue, 2 Apr 2002 09:12:58 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32G8uQ13534; Tue, 2 Apr 2002 10:08:56 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 10:09:01 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB45@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip'" Cc: "'Charlie Perkins'" , "'Pete McCann'" , "Kent Nickell" Subject: [mobile-ip] RE: RFC3220 and possible forward compatibility issue "Dynamic Hom e Agent Allocation" Date: Tue, 2 Apr 2002 10:08:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA60.B1F0ABE0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DA60.B1F0ABE0 Content-Type: text/plain; charset="iso-8859-1" Hello all; I am sorry for the spelling mistake in the proposed text. Please see correction inserted. Regards; Ahmad Muhanna > -----Original Message----- > From: Muhanna, Ahmad [RICH1:2Q20:EXCH] > Sent: Monday, April 01, 2002 3:11 PM > To: 'mobile-ip' > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Charlie Perkins'; 'Pete McCann'; > Nickell, Kent [RICH2:2Q20:EXCH] > Subject: RFC3220 and possible forward compatibility issue "Dynamic > Home Agent Allocation" > > Hello all; > > RFC3220 (RFC2002) proposes a mechanism for Dynamic Home Agent Resolution > or allocation. > Sections 3.6.1.1, 3.6.1.2, and 3.8.2.2 introduces this mechanism for the > following two scenarios: > > MN with a co-located IP address: > i. MN sets the destination IP address of the IP packet that contain the > MN > Registration Request to the subnet-directed broadcast. > ii. RFC3220 does not specify what IP address the Mobile Node insert in the > HA > field in the RRQ message. However, it may be understood that it is the > > same IP address. "subnet-directed broadcast" Since it does not know > its HA. > iii. Home Agent listens to the subnet-directed broadcast and > "255.255.255.255." > as mentioned in the RFC3220. > iv. Every Home Agent which receives this IP packet MUST reject the RRQ > with a code > of 136 and insert its HA unicast IP address in the RRP message to the > MN. > v. After MN receives all the RRP messages from the different HAs, it > chooses which HA > to register with and then uses that HA IP address. > > > MN with a FA Care-Of Address: > i. MN sets the destination IP address of the IP packet that contain the > MN > Registration Request to the FA Care-Of Address. > ii. RFC3220 specify that MN MAY use the "subnet-directed broadcast" IP > address in the HA > field in the RRQ message. > iii. RFC3220 does not specify what the FA SHOULD do when receiving an IP > packet which > contains a RRQ message with a HA field is set to the "subnet-directed > broadcast". > It is basically very wise to do so by leaving the door open for future > forward compatibility. > > However, IF FA just uses the same concept of the MN co-located IP > address, > then FA will forward the RRQ message to the HA "subnet-directed > broadcast" by > inserting this address in the destination IP address of the IP packet > containing > the RRQ message. > > iv. Home Agents listens to the subnet-directed broadcast and Broadcast > IP address "255.255.255.255." as mentioned in the RFC3220. > v. Every Home Agent which receives this IP packet MUST reject the RRQ with > a code > of 136 and insert the HA unicast IP address in the RRP message to the > MN through the > Foreign Agent Care-Of Address. > vi. After MN receives all the RRP messages from the different HAs, it > chooses which HA > to register with and then use that HA IP address. > > Now, the only conflict I see is what mentioned in section 3.8.3.2 which > reads: > > Section 3.8.2.2: > " > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be copied > into the Home Agent field of the Registration Reply. Otherwise, the > home agent MUST set the Home Agent field in the Registration Reply to > its unicast address. In this latter case, the home agent MUST reject > the registration with a suitable code (e.g., Code 136) to prevent the > mobile node from possibly being simultaneously registered with two or > more home agents. > " > This section mandates that every HA rejects any RRQ message with HA > field is different than the HA unicast IP address. > This will not allow dynamic Home agent allocation using RADIUS or future > Diameter in ONE SINGLE ROUND TRIP of the initial registration. > > In the spirit of resolving this issue to avoid forward compatibility > problems, > I believe this text SHOULD be modified to be consistent with > what the RFC3220 is trying to propose for Home Agent dynamic allocation. > > Proposed TEXT: > Section 3.8.2.2: > " > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be copied > into the Home Agent field of the Registration Reply. Otherwise, the > home agent MUST set the Home Agent field in the Registration Reply to > its unicast address. In this latter case and only if this IP packet > was distant > to either the subnet-directed broadcast or 255.255.255.255, the home [Muhanna, Ahmad] I meant "In this latter case and only if this IP packet was destined to either the subnet-directed broadcast or 255.255.255.255, the home .." > agent MUST reject the registration with a suitable code (e.g., Code > 136) > to prevent the mobile node from possibly being simultaneously > registered > with two or more home agents. > " > > Thanks for consideration. > > Regards; > Ahmad Muhanna > ------_=_NextPart_001_01C1DA60.B1F0ABE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RFC3220 and possible forward compatibility issue = "Dynamic Home Agent Allocation"

Hello all;

I am sorry for the = spelling mistake in the proposed text.
Please see = correction inserted.


Regards;
Ahmad = Muhanna


     -----Original Message-----
    From:   Muhanna, Ahmad [RICH1:2Q20:EXCH] 
    Sent:   = Monday, April 01, 2002 3:11 PM
    To:     'mobile-ip'
    Cc:     Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Charlie Perkins'; = 'Pete McCann'; Nickell, Kent [RICH2:2Q20:EXCH]
    Subject:        RFC3220 and possible forward = compatibility issue "Dynamic Home Agent Allocation"

    Hello all;

    RFC3220 (RFC2002) proposes a mechanism = for Dynamic Home Agent Resolution or allocation.
    Sections 3.6.1.1, 3.6.1.2, and = 3.8.2.2 introduces this mechanism for the following two = scenarios:

    MN with a co-located IP = address:
    i.  MN sets the destination IP = address of the IP packet that contain the MN
        Registration = Request to the subnet-directed = broadcast.
    ii. RFC3220 does not specify what IP = address the Mobile Node insert in the HA
        field in the RRQ = message. However, it may be understood that it is the
        same IP address. = "subnet-directed broadcast" Since it does not know its = HA.
    iii. Home Agent listens to the = subnet-directed broadcast and "255.255.255.255."
        as mentioned in = the RFC3220.
    iv. Every Home Agent which receives = this IP packet MUST reject the RRQ with a code
        of 136 and insert = its HA unicast IP address in the RRP message to the MN.
    v.  After MN receives all the = RRP messages from the different HAs, it chooses which HA
         to register = with and then uses that HA IP address.


    MN with a FA Care-Of = Address:
    i.  MN sets the destination IP = address of the IP packet that contain the MN
        Registration = Request to the FA Care-Of = Address.
    ii. RFC3220 specify that MN MAY use = the "subnet-directed broadcast" IP address in the HA
        field in the RRQ = message.
    iii. RFC3220 does not specify what = the FA SHOULD do when receiving an IP packet which
        contains a RRQ = message with a HA field is set to the "subnet-directed = broadcast".
        It is basically = very wise to do so by leaving the door open for future forward = compatibility.
       
        However, IF FA = just uses the same concept of the MN co-located IP address,
        then FA will = forward the RRQ message to the HA "subnet-directed broadcast" = by
        inserting this = address in the destination IP address of the IP packet containing =
        the RRQ = message.

    iv. Home Agents listens to the = subnet-directed broadcast and Broadcast
        IP address = "255.255.255.255." as mentioned in the RFC3220.
    v. Every Home Agent which receives = this IP packet MUST reject the RRQ with a code
        of 136 and insert = the HA unicast IP address in the RRP message to the MN through the =
        Foreign Agent = Care-Of Address.
    vi.  After MN receives all the = RRP messages from the different HAs, it chooses which HA
         to register = with and then use that HA IP address.

    Now, the only conflict I see is what = mentioned in section 3.8.3.2 which reads:

    Section 3.8.2.2:
    "
       If the Home Agent field = in the Registration Request contains a
       unicast address of this = home agent, then that field MUST be copied
       into the Home Agent = field of the Registration Reply.  Otherwise, the
       home agent MUST set the = Home Agent field in the Registration Reply to
       its unicast = address.  In this latter case, the home agent MUST reject
       the registration with a = suitable code (e.g., Code 136) to prevent the
       mobile node from = possibly being simultaneously registered with two or
       more home agents.
    "
    This section mandates that every HA = rejects any RRQ message with HA
    field is different than the HA = unicast IP address.
    This will not allow dynamic Home = agent allocation using RADIUS or future
    Diameter in ONE SINGLE ROUND TRIP of = the initial registration.

    In the spirit of resolving this issue = to avoid forward compatibility problems,
    I believe this text SHOULD be = modified to be consistent with
    what the RFC3220 is trying to propose = for Home Agent dynamic allocation.

    Proposed TEXT:
     Section 3.8.2.2:
    "
       If the Home Agent field = in the Registration Request contains a
       unicast address of this = home agent, then that field MUST be copied
       into the Home Agent = field of the Registration Reply.  Otherwise, the
       home agent MUST set the = Home Agent field in the Registration Reply to
       its unicast = address.  In this latter case and only if this IP packet was distant
       to either the = subnet-directed broadcast or = 255.255.255.255, the home
    [Muhanna, = Ahmad] 
    I meant = "In this latter = case and only if this IP packet was = destined to either
    the subnet-directed broadcast or = 255.255.255.255, the home .." =

       agent MUST reject the = registration with a suitable code (e.g., Code 136)
       to prevent the mobile = node from possibly being simultaneously registered
       with two or more home = agents.
    "

    Thanks for consideration.

    Regards;
    Ahmad = Muhanna

------_=_NextPart_001_01C1DA60.B1F0ABE0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 11:25:00 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21504 for ; Tue, 2 Apr 2002 11:24:59 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15934; Tue, 2 Apr 2002 08:24:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28692; Tue, 2 Apr 2002 08:24:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32GNZKL003214 for ; Tue, 2 Apr 2002 08:23:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32GNYdT003213 for mobile-ip-dist; Tue, 2 Apr 2002 08:23:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32GNVKL003206 for ; Tue, 2 Apr 2002 08:23:31 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28590 for ; Tue, 2 Apr 2002 08:23:35 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07778 for ; Tue, 2 Apr 2002 08:23:13 -0800 (PST) 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 IAA17939; Tue, 2 Apr 2002 08:23:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32GNVR03138; Tue, 2 Apr 2002 08:23:31 -0800 X-mProtect: <200204021623> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzo049T; Tue, 02 Apr 2002 08:23:29 PST Message-ID: <3CA9DB01.92FBD878@iprg.nokia.com> Date: Tue, 02 Apr 2002 08:23:29 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ahmad Muhanna , "'Pete McCann'" , Kent Nickell CC: Mobile IP Working Group , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [mobile-ip] Re: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" References: <6B49EDFE974BD51197D70002A56079D801AFCB45@zrc2c013.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, May I assume that this corrective text is acceptable to everyone concerned? I would like to incorporate the necessary revisions and reissue RFC3220bis soon. Is there any impact on RFC3012bis? Regards, Charlie P. > Ahmad Muhanna wrote: > > Hello all; > > I am sorry for the spelling mistake in the proposed text. > Please see correction inserted. > > Regards; > Ahmad Muhanna > > -----Original Message----- > From: Muhanna, Ahmad [RICH1:2Q20:EXCH] > Sent: Monday, April 01, 2002 3:11 PM > To: 'mobile-ip' > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Charlie Perkins'; 'Pete > McCann'; Nickell, Kent [RICH2:2Q20:EXCH] > Subject: RFC3220 and possible forward compatibility issue "Dynamic > Home Agent Allocation" > > Hello all; > > RFC3220 (RFC2002) proposes a mechanism for Dynamic Home Agent Resolution > or allocation. > Sections 3.6.1.1, 3.6.1.2, and 3.8.2.2 introduces this mechanism for the > following two scenarios: > > MN with a co-located IP address: > i. MN sets the destination IP address of the IP packet that contain the > MN > Registration Request to the subnet-directed broadcast. > ii. RFC3220 does not specify what IP address the Mobile Node insert in > the HA > field in the RRQ message. However, it may be understood that it is > the > same IP address. "subnet-directed broadcast" Since it does not know > its HA. > iii. Home Agent listens to the subnet-directed broadcast and > "255.255.255.255." > as mentioned in the RFC3220. > iv. Every Home Agent which receives this IP packet MUST reject the RRQ > with a code > of 136 and insert its HA unicast IP address in the RRP message to the > MN. > v. After MN receives all the RRP messages from the different HAs, it > chooses which HA > to register with and then uses that HA IP address. > > MN with a FA Care-Of Address: > i. MN sets the destination IP address of the IP packet that contain the > MN > Registration Request to the FA Care-Of Address. > ii. RFC3220 specify that MN MAY use the "subnet-directed broadcast" IP > address in the HA > field in the RRQ message. > iii. RFC3220 does not specify what the FA SHOULD do when receiving an IP > packet which > contains a RRQ message with a HA field is set to the "subnet-directed > broadcast". > It is basically very wise to do so by leaving the door open for > future forward compatibility. > > However, IF FA just uses the same concept of the MN co-located IP > address, > then FA will forward the RRQ message to the HA "subnet-directed > broadcast" by > inserting this address in the destination IP address of the IP packet > containing > the RRQ message. > > iv. Home Agents listens to the subnet-directed broadcast and Broadcast > IP address "255.255.255.255." as mentioned in the RFC3220. > v. Every Home Agent which receives this IP packet MUST reject the RRQ > with a code > of 136 and insert the HA unicast IP address in the RRP message to the > MN through the > Foreign Agent Care-Of Address. > vi. After MN receives all the RRP messages from the different HAs, it > chooses which HA > to register with and then use that HA IP address. > > Now, the only conflict I see is what mentioned in section 3.8.3.2 which > reads: > > Section 3.8.2.2: > " > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be copied > into the Home Agent field of the Registration Reply. Otherwise, the > home agent MUST set the Home Agent field in the Registration Reply to > its unicast address. In this latter case, the home agent MUST reject > the registration with a suitable code (e.g., Code 136) to prevent the > mobile node from possibly being simultaneously registered with two or > more home agents. > " > This section mandates that every HA rejects any RRQ message with HA > field is different than the HA unicast IP address. > This will not allow dynamic Home agent allocation using RADIUS or future > Diameter in ONE SINGLE ROUND TRIP of the initial registration. > > In the spirit of resolving this issue to avoid forward compatibility > problems, > I believe this text SHOULD be modified to be consistent with > what the RFC3220 is trying to propose for Home Agent dynamic allocation. > > Proposed TEXT: > Section 3.8.2.2: > " > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be copied > into the Home Agent field of the Registration Reply. Otherwise, the > home agent MUST set the Home Agent field in the Registration Reply to > its unicast address. In this latter case and only if this IP packet > was distant > to either the subnet-directed broadcast or 255.255.255.255, the home > [Muhanna, Ahmad] > I meant "In this latter case and only if this IP packet was destined to > either > the subnet-directed broadcast or 255.255.255.255, the home .." > > agent MUST reject the registration with a suitable code (e.g., Code > 136) > to prevent the mobile node from possibly being simultaneously > registered > with two or more home agents. > " > > Thanks for consideration. > > Regards; > Ahmad Muhanna From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 11:42:57 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22180 for ; Tue, 2 Apr 2002 11:42:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07872; Tue, 2 Apr 2002 09:40:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02513; Tue, 2 Apr 2002 08:40:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32GdTKL003368 for ; Tue, 2 Apr 2002 08:39:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32GdSQ3003367 for mobile-ip-dist; Tue, 2 Apr 2002 08:39:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32GdPKL003360 for ; Tue, 2 Apr 2002 08:39:25 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02356 for ; Tue, 2 Apr 2002 08:39:29 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03541 for ; Tue, 2 Apr 2002 08:39:28 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32GdOQ21659; Tue, 2 Apr 2002 10:39:24 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 10:39:29 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D2402EE8B17@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: mobile-ip@sunroof.eng.sun.com, "Ahmad Muhanna", "'Pete McCann'" , "Kent Nickell" Cc: "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: RE: [mobile-ip] Re: RFC3220 and possible forward compatibility is sue "Dynamic Home Agent Allocation" Date: Tue, 2 Apr 2002 10:39:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA64.F4AFC7F0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DA64.F4AFC7F0 Content-Type: text/plain; charset="iso-8859-1" Charlie, This will certainly address the forward/backward compatibility issues related to various dynamic HA assignment schemes. The suggested change ensures a "single trip" dynamic HA solution and also covers the concern about multiple simultaneous registrations with the dynamic HA assignment scheme using "subnet directed broadcast". Regards, Kuntal -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Tuesday, April 02, 2002 10:23 AM To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Pete McCann'; Nickell, Kent [RICH2:2Q20:EXCH] Cc: Mobile IP Working Group; Basavaraj Patil (NTC/Dallas); Phil Roberts Subject: [mobile-ip] Re: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" Hello folks, May I assume that this corrective text is acceptable to everyone concerned? I would like to incorporate the necessary revisions and reissue RFC3220bis soon. Is there any impact on RFC3012bis? Regards, Charlie P. > Ahmad Muhanna wrote: > > Hello all; > > I am sorry for the spelling mistake in the proposed text. > Please see correction inserted. > > Regards; > Ahmad Muhanna > > -----Original Message----- > From: Muhanna, Ahmad [RICH1:2Q20:EXCH] > Sent: Monday, April 01, 2002 3:11 PM > To: 'mobile-ip' > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Charlie Perkins'; 'Pete > McCann'; Nickell, Kent [RICH2:2Q20:EXCH] > Subject: RFC3220 and possible forward compatibility issue "Dynamic > Home Agent Allocation" > > Hello all; > > RFC3220 (RFC2002) proposes a mechanism for Dynamic Home Agent Resolution > or allocation. > Sections 3.6.1.1, 3.6.1.2, and 3.8.2.2 introduces this mechanism for the > following two scenarios: > > MN with a co-located IP address: > i. MN sets the destination IP address of the IP packet that contain the > MN > Registration Request to the subnet-directed broadcast. > ii. RFC3220 does not specify what IP address the Mobile Node insert in > the HA > field in the RRQ message. However, it may be understood that it is > the > same IP address. "subnet-directed broadcast" Since it does not know > its HA. > iii. Home Agent listens to the subnet-directed broadcast and > "255.255.255.255." > as mentioned in the RFC3220. > iv. Every Home Agent which receives this IP packet MUST reject the RRQ > with a code > of 136 and insert its HA unicast IP address in the RRP message to the > MN. > v. After MN receives all the RRP messages from the different HAs, it > chooses which HA > to register with and then uses that HA IP address. > > MN with a FA Care-Of Address: > i. MN sets the destination IP address of the IP packet that contain the > MN > Registration Request to the FA Care-Of Address. > ii. RFC3220 specify that MN MAY use the "subnet-directed broadcast" IP > address in the HA > field in the RRQ message. > iii. RFC3220 does not specify what the FA SHOULD do when receiving an IP > packet which > contains a RRQ message with a HA field is set to the "subnet-directed > broadcast". > It is basically very wise to do so by leaving the door open for > future forward compatibility. > > However, IF FA just uses the same concept of the MN co-located IP > address, > then FA will forward the RRQ message to the HA "subnet-directed > broadcast" by > inserting this address in the destination IP address of the IP packet > containing > the RRQ message. > > iv. Home Agents listens to the subnet-directed broadcast and Broadcast > IP address "255.255.255.255." as mentioned in the RFC3220. > v. Every Home Agent which receives this IP packet MUST reject the RRQ > with a code > of 136 and insert the HA unicast IP address in the RRP message to the > MN through the > Foreign Agent Care-Of Address. > vi. After MN receives all the RRP messages from the different HAs, it > chooses which HA > to register with and then use that HA IP address. > > Now, the only conflict I see is what mentioned in section 3.8.3.2 which > reads: > > Section 3.8.2.2: > " > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be copied > into the Home Agent field of the Registration Reply. Otherwise, the > home agent MUST set the Home Agent field in the Registration Reply to > its unicast address. In this latter case, the home agent MUST reject > the registration with a suitable code (e.g., Code 136) to prevent the > mobile node from possibly being simultaneously registered with two or > more home agents. > " > This section mandates that every HA rejects any RRQ message with HA > field is different than the HA unicast IP address. > This will not allow dynamic Home agent allocation using RADIUS or future > Diameter in ONE SINGLE ROUND TRIP of the initial registration. > > In the spirit of resolving this issue to avoid forward compatibility > problems, > I believe this text SHOULD be modified to be consistent with > what the RFC3220 is trying to propose for Home Agent dynamic allocation. > > Proposed TEXT: > Section 3.8.2.2: > " > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be copied > into the Home Agent field of the Registration Reply. Otherwise, the > home agent MUST set the Home Agent field in the Registration Reply to > its unicast address. In this latter case and only if this IP packet > was distant > to either the subnet-directed broadcast or 255.255.255.255, the home > [Muhanna, Ahmad] > I meant "In this latter case and only if this IP packet was destined to > either > the subnet-directed broadcast or 255.255.255.255, the home .." > > agent MUST reject the registration with a suitable code (e.g., Code > 136) > to prevent the mobile node from possibly being simultaneously > registered > with two or more home agents. > " > > Thanks for consideration. > > Regards; > Ahmad Muhanna ------_=_NextPart_001_01C1DA64.F4AFC7F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: RFC3220 and possible forward compatibility = issue "Dynamic Home Agent Allocation"

Charlie,
This will certainly address the forward/backward = compatibility issues related to various dynamic HA assignment schemes. = The suggested change ensures a "single trip" dynamic HA = solution and also covers the concern about multiple simultaneous = registrations with the dynamic HA assignment scheme using "subnet = directed broadcast".

Regards,
Kuntal


-----Original Message-----
From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
Sent: Tuesday, April 02, 2002 10:23 AM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Pete McCann'; = Nickell, Kent
[RICH2:2Q20:EXCH]
Cc: Mobile IP Working Group; Basavaraj Patil = (NTC/Dallas); Phil Roberts
Subject: [mobile-ip] Re: RFC3220 and possible = forward compatibility
issue "Dynamic Home Agent = Allocation"


Hello folks,

May I assume that this corrective text is acceptable = to
everyone concerned?  I would like to = incorporate the necessary
revisions and reissue RFC3220bis soon.  Is = there any impact
on RFC3012bis?

Regards,
Charlie P.


> Ahmad Muhanna wrote:
>
> Hello all;
>
> I am sorry for the spelling mistake in the = proposed text.
> Please see correction inserted.
>
> Regards;
> Ahmad Muhanna
>
>       = -----Original Message-----
>      From:   = Muhanna, Ahmad [RICH1:2Q20:EXCH]
>      Sent:   = Monday, April 01, 2002 3:11 PM
>      = To:     'mobile-ip'
>      = Cc:     Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Charlie = Perkins'; 'Pete
>      McCann'; Nickell, = Kent [RICH2:2Q20:EXCH]
>      = Subject:        RFC3220 and possible = forward compatibility issue "Dynamic
>      Home Agent = Allocation"
>
>      Hello all;
>
>      RFC3220 (RFC2002) = proposes a mechanism for Dynamic Home Agent Resolution
>      or = allocation.
>      Sections 3.6.1.1, = 3.6.1.2, and 3.8.2.2 introduces this mechanism for the
>      following two = scenarios:
>
>      MN with a = co-located IP address:
>      i.  MN sets = the destination IP address of the IP packet that contain the
>      MN
>          = Registration Request to the subnet-directed broadcast.
>      ii. RFC3220 does = not specify what IP address the Mobile Node insert in
>      the HA
>          = field in the RRQ message. However, it may be understood that it = is
>      the
>          = same IP address. "subnet-directed broadcast" Since it does = not know
>      its HA.
>      iii. Home Agent = listens to the subnet-directed broadcast and
>      = "255.255.255.255."
>          as = mentioned in the RFC3220.
>      iv. Every Home = Agent which receives this IP packet MUST reject the RRQ
>      with a = code
>          of = 136 and insert its HA unicast IP address in the RRP message to = the
>      MN.
>      v.  After MN = receives all the RRP messages from the different HAs, it
>      chooses which = HA
>          = ; to register with and then uses that HA IP address.
>
>      MN with a FA = Care-Of Address:
>      i.  MN sets = the destination IP address of the IP packet that contain the
>      MN
>          = Registration Request to the FA Care-Of Address.
>      ii. RFC3220 = specify that MN MAY use the "subnet-directed broadcast" = IP
>      address in the = HA
>          = field in the RRQ message.
>      iii. RFC3220 does = not specify what the FA SHOULD do when receiving an IP
>      packet = which
>          = contains a RRQ message with a HA field is set to the = "subnet-directed
>      = broadcast".
>          It = is basically very wise to do so by leaving the door open for
>      future forward = compatibility.
>
>          = However, IF FA just uses the same concept of the MN co-located = IP
>      address,
>          = then FA will forward the RRQ message to the HA = "subnet-directed
>      broadcast" = by
>          = inserting this address in the destination IP address of the IP = packet
>      containing
>          the = RRQ message.
>
>      iv. Home Agents = listens to the subnet-directed broadcast and Broadcast
>          IP = address "255.255.255.255." as mentioned in the = RFC3220.
>      v. Every Home = Agent which receives this IP packet MUST reject the RRQ
>      with a = code
>          of = 136 and insert the HA unicast IP address in the RRP message to = the
>      MN through = the
>          = Foreign Agent Care-Of Address.
>      vi.  After = MN receives all the RRP messages from the different HAs, it
>      chooses which = HA
>          = ; to register with and then use that HA IP address.
>
>      Now, the only = conflict I see is what mentioned in section 3.8.3.2 which
>      reads:
>
>      Section = 3.8.2.2:
>      "
>         = If the Home Agent field in the Registration Request contains a
>         = unicast address of this home agent, then that field MUST be = copied
>         = into the Home Agent field of the Registration Reply.  Otherwise, = the
>         = home agent MUST set the Home Agent field in the Registration Reply = to
>         = its unicast address.  In this latter case, the home agent MUST = reject
>         = the registration with a suitable code (e.g., Code 136) to prevent = the
>         = mobile node from possibly being simultaneously registered with two = or
>         = more home agents.
>      "
>      This section = mandates that every HA rejects any RRQ message with HA
>      field is = different than the HA unicast IP address.
>      This will not = allow dynamic Home agent allocation using RADIUS or future
>      Diameter in ONE = SINGLE ROUND TRIP of the initial registration.
>
>      In the spirit of = resolving this issue to avoid forward compatibility
>      problems,
>      I believe this = text SHOULD be modified to be consistent with
>      what the RFC3220 = is trying to propose for Home Agent dynamic allocation.
>
>      Proposed = TEXT:
>       Section = 3.8.2.2:
>      "
>         = If the Home Agent field in the Registration Request contains a
>         = unicast address of this home agent, then that field MUST be = copied
>         = into the Home Agent field of the Registration Reply.  Otherwise, = the
>         = home agent MUST set the Home Agent field in the Registration Reply = to
>         = its unicast address.  In this latter case and only if this IP = packet
>      was = distant
>         = to either the subnet-directed broadcast or 255.255.255.255, the = home
>      [Muhanna, = Ahmad]
>      I meant "In = this latter case and only if this IP packet was destined to
>      either
>      the = subnet-directed broadcast or 255.255.255.255, the home .."
>
>         = agent MUST reject the registration with a suitable code (e.g., = Code
>      136)
>         = to prevent the mobile node from possibly being simultaneously
>      registered
>         = with two or more home agents.
>      "
>
>      Thanks for = consideration.
>
>      Regards;
>      Ahmad = Muhanna

------_=_NextPart_001_01C1DA64.F4AFC7F0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 11:51:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22593 for ; Tue, 2 Apr 2002 11:51:03 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15340; Tue, 2 Apr 2002 09:50:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05001; Tue, 2 Apr 2002 08:50:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32GnfKL003456 for ; Tue, 2 Apr 2002 08:49:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32Gnf76003455 for mobile-ip-dist; Tue, 2 Apr 2002 08:49:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32GncKL003448 for ; Tue, 2 Apr 2002 08:49:38 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29166 for ; Tue, 2 Apr 2002 08:49:42 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16649 for ; Tue, 2 Apr 2002 08:49:20 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g32GnfI07467 for ; Tue, 2 Apr 2002 08:49:41 -0800 (PST) Message-ID: <00cd01c1da66$29083e50$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053802C6ABD9@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 2 Apr 2002 08:48:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > => I think there is something missing in our > communication. I didn't think IAPP will run > between subnets, is this correct? If yes, then > this is something for IEEE to work out. > Like all other L2 designers, they will do their > best to minimise their L2's handover time. > Yes, IAPP will run between subnets. That is why they use IP rather than 802 for it. That is also why we are concerned about it. The underlying problem is that the architecture on which the 802.11 committee is basing their design does not include routers. They have a notion of an ESS (Extended Service System, I think) but it has no notion of IP subnets. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 11:55:21 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22768 for ; Tue, 2 Apr 2002 11:55:20 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15606; Tue, 2 Apr 2002 09:54:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06045; Tue, 2 Apr 2002 08:54:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32Gs8KL003536 for ; Tue, 2 Apr 2002 08:54:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32Gs8VO003535 for mobile-ip-dist; Tue, 2 Apr 2002 08:54:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32Gs5KL003528 for ; Tue, 2 Apr 2002 08:54:05 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10069 for ; Tue, 2 Apr 2002 08:54:09 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18117 for ; Tue, 2 Apr 2002 08:53:48 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g32Gs8I07650; Tue, 2 Apr 2002 08:54:08 -0800 (PST) Message-ID: <00df01c1da66$c8865250$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: , References: <8C92E23A3E87FB479988285F9E22BE465ABC8B@ftmail> Subject: Re: [mobile-ip] Reverse tunneling issues Date: Tue, 2 Apr 2002 08:52:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George, While I support this, I'd like to ask you the same question that was asked about BETH: what causes the old tunnel state to get cleaned up? People seemed to feel that cleaning up tunnel state in ARs was important for BETH, and I believe the same argument can be made for the HA. jak ----- Original Message ----- From: "George Tsirtsis" To: ; Cc: ; Sent: Tuesday, April 02, 2002 1:28 AM Subject: RE: [mobile-ip] Reverse tunneling issues > Jari, > > Here is the deal... > > draft-oneill-mip-revtun-ho-00.txt in section 6. "IPv6 Considerations" > currently suggest: > "The IPv6 HA should support the automatic invocation of a fan-in binding if > reverse tunneling is requested." > > "Fan-in bindings" are explained earlier in the document > This essentially says that when reverse tunneling is used the HA has to > maintain at least 2 bindings for the MN, at least for a short time during > handoff. > > So for example, > - Assume a MN that uses reverse tunneling > - After the MN hands off to a new CoA it sends the appropriate BU to the HA > - The HA registers the new binding to the newCoA and immediately uses it for > all downlink traffic. > - The HA also keeps the oldCoA binding for a while but only uses it so that > it can accept in-flight packets from that oldCoA > - The old binding is removed if/when the MN moves to yet another (third) CoA > or after a default timeout. > > The above works for both MIPv4 and MIPv6 and does not require any signaling > changes, but only behavior changes at the HA i.e.: currently a new Binding > REPLACES the old Binding. The text needs to be revised to say that the new > Binding REPLACES the old Binding for downlink traffic but it is ADDED to the > old Binding for reverse tunneled traffic. > > Also note that while the above helps, it does not solve the problem > completely for reasons explained in the draft. To solve all problems with > reverse tunneling we need signaling changes/extensions which I guess could > be described in a new draft. > > Does this make sense? > > Regards > George > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Saturday, March 30, 2002 2:09 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: 'PRoberts@MEGISTO.com'; 'Basavaraj.Patil@nokia.com' > Subject: Re: [mobile-ip] Reverse tunneling issues > > > George Tsirtsis wrote: > > > > GT> No problem...have a look at the draft and do not let the too many > > options of how to solve the problem confuse you ...this is not > complex...it > > is just that it has to be dealt with. > > > Assuming something has to be done, is this something that has to go to > the base RFC, or something that can be done in an extension separately? > > Jari > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 12:07:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23535 for ; Tue, 2 Apr 2002 12:07:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24883; Tue, 2 Apr 2002 10:07:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09340; Tue, 2 Apr 2002 09:07:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32H6JKL003612 for ; Tue, 2 Apr 2002 09:06:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32H6JTG003611 for mobile-ip-dist; Tue, 2 Apr 2002 09:06:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32H6GKL003604 for ; Tue, 2 Apr 2002 09:06:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14541 for ; Tue, 2 Apr 2002 09:06:20 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24143 for ; Tue, 2 Apr 2002 10:06:19 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g32H6FI08092; Tue, 2 Apr 2002 09:06:15 -0800 (PST) Message-ID: <012b01c1da68$79b762c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "Erik Nordmark" Cc: , "Rajeev Koodli" References: <4DA6EA82906FD511BE2F00508BCF053802C6ABEF@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 Date: Tue, 2 Apr 2002 09:04:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, > => I think that it ultimately comes down to the > basis of the trust between the MN and the > old AR. Authenticating HI and HAck between > the old and new ARs does not necessarily mean > that the MN is not trying to bomb the new network > does it ? > > But everyone seems to assume that it is enough > so what am I missing? > Actually, you are right, there does need to be an initial bootstrapping of trust between the MN and the old AR. Link security is being discussed on the SEND list (so far, somewhat inactive). jak From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 12:10:10 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23718 for ; Tue, 2 Apr 2002 12:10:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26215; Tue, 2 Apr 2002 09:09:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09867; Tue, 2 Apr 2002 09:09:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32H96KL003653 for ; Tue, 2 Apr 2002 09:09:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32H96SW003652 for mobile-ip-dist; Tue, 2 Apr 2002 09:09:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32H93KL003645 for ; Tue, 2 Apr 2002 09:09:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09689 for ; Tue, 2 Apr 2002 09:09:07 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01751 for ; Tue, 2 Apr 2002 10:09:05 -0700 (MST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g32H8ka14503; Tue, 2 Apr 2002 09:08:46 -0800 (PST) Received: from cisco.com (sjc-vpn1-737.cisco.com [10.21.98.225]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACH32685; Tue, 2 Apr 2002 09:08:17 -0800 (PST) Message-ID: <3CA9E59C.5864790A@cisco.com> Date: Tue, 02 Apr 2002 09:08:45 -0800 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Ahmad Muhanna , "'Pete McCann'" , Kent Nickell , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [mobile-ip] Re: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" References: <6B49EDFE974BD51197D70002A56079D801AFCB45@zrc2c013.us.nortel.com> <3CA9DB01.92FBD878@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie. I think the current specification is very clear on how MN can signal that it needs to be dynamically assigned an HA - by specifying a non-unicast IP address in the HA field of Reg Request. This happens when MN boots up, and once assigned, MN can reregister to that HA. Seems counter-intuitive that HA field is changed in Reg Reply when MN already specified exactly which HA to use? See comments below .. "Charles E. Perkins" wrote: > Hello folks, > > May I assume that this corrective text is acceptable to > everyone concerned? I would like to incorporate the necessary > revisions and reissue RFC3220bis soon. Is there any impact > on RFC3012bis? > > Regards, > Charlie P. > > > > > Section 3.8.2.2: > > " > > If the Home Agent field in the Registration Request contains a > > unicast address of this home agent, then that field MUST be copied > > into the Home Agent field of the Registration Reply. Otherwise, the > > home agent MUST set the Home Agent field in the Registration Reply to > > its unicast address. In this latter case, the home agent MUST reject > > the registration with a suitable code (e.g., Code 136) to prevent the > > mobile node from possibly being simultaneously registered with two or > > more home agents. > > " > > This section mandates that every HA rejects any RRQ message with HA > > field is different than the HA unicast IP address. The advantage of this scheme is avoiding ambiguity of which MN wanted to registered with when using unicast IP address of the HA. If MN doesn't know which HA, then it should not be setting HA field to a unicast address, right? > > > This will not allow dynamic Home agent allocation using RADIUS or future > > Diameter in ONE SINGLE ROUND TRIP of the initial registration. > > Well, this depends on the scheme. :) > > > In the spirit of resolving this issue to avoid forward compatibility > > problems, > > I believe this text SHOULD be modified to be consistent with > > what the RFC3220 is trying to propose for Home Agent dynamic allocation. > > I'm not in favor of changing the HA field in the Reg Reply when MN requested a unicast IP address. I think if HA needs to be dynamically assigned, then MN should set HA field to non-unicast IP address (which makes it clear that's what MN wants). Once MN is anchored to an HA, then MN uses unicast IP address for reregistrations. Else, might get into situations where HA is constantly reassigned (ie. MN has no control to stop this) even when MN is using unicast IP address. With the current specificiation, this can't happen since only the initial Reg Request with non-unicast HA field will assign the MN an HA. After that, MN will be using that HA for roaming. No playing around with the HA field in the Reg Reply. I think this proposed approach is trying to fit some particular scheme, but breaks the generality and clarity of existing specification. IMHO. Kent From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 12:35:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25073 for ; Tue, 2 Apr 2002 12:35:22 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09623; Tue, 2 Apr 2002 10:35:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15580; Tue, 2 Apr 2002 09:34:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32HY4KL003836 for ; Tue, 2 Apr 2002 09:34:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32HY4uL003835 for mobile-ip-dist; Tue, 2 Apr 2002 09:34:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32HY0KL003828 for ; Tue, 2 Apr 2002 09:34:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09765 for ; Tue, 2 Apr 2002 09:34:05 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06383 for ; Tue, 2 Apr 2002 10:34:04 -0700 (MST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g32HXUl17821; Tue, 2 Apr 2002 09:33:30 -0800 (PST) Received: from cisco.com (sjc-vpn1-737.cisco.com [10.21.98.225]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACH33332; Tue, 2 Apr 2002 09:33:13 -0800 (PST) Message-ID: <3CA9EB75.902E3391@cisco.com> Date: Tue, 02 Apr 2002 09:33:41 -0800 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Ahmad Muhanna , "'Pete McCann'" , Kent Nickell , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [mobile-ip] Re: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" References: <6B49EDFE974BD51197D70002A56079D801AFCB45@zrc2c013.us.nortel.com> <3CA9DB01.92FBD878@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry folks. Somehow I misread the text and assumed it was about the unicast IP address. Comments below... "Charles E. Perkins" wrote: > Hello folks, > > May I assume that this corrective text is acceptable to > everyone concerned? I would like to incorporate the necessary > revisions and reissue RFC3220bis soon. Is there any impact > on RFC3012bis? > > Regards, > Charlie P. > > > Proposed TEXT: > > Section 3.8.2.2: > > " > > If the Home Agent field in the Registration Request contains a > > unicast address of this home agent, then that field MUST be copied > > into the Home Agent field of the Registration Reply. Otherwise, the > > home agent MUST set the Home Agent field in the Registration Reply to > > its unicast address. In this latter case and only if this IP packet > > was distant > > to either the subnet-directed broadcast or 255.255.255.255, the home > > [Muhanna, Ahmad] > > I meant "In this latter case and only if this IP packet was destined to > > either > > the subnet-directed broadcast or 255.255.255.255, the home .." > > What about 0.0.0.0? Isn't the current language already saying that in the non-unicast case, set the HA field and reject? This non-unicast address broadly covers subnet-directed broadcast, 255.255.255.255, and 0.0.0.0. "If the Home Agent field in the Registration Request contains a unicast address of this home agent, .... Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, ..." I don't have a problem with listing out specific IP addresses in the spec, just not sure if it's really needed. Thanks. Kent > > > agent MUST reject the registration with a suitable code (e.g., Code > > 136) > > to prevent the mobile node from possibly being simultaneously > > registered > > with two or more home agents. > > " > > > > Thanks for consideration. > > > > Regards; > > Ahmad Muhanna From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 12:40:47 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25326 for ; Tue, 2 Apr 2002 12:40:46 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18674; Tue, 2 Apr 2002 10:40:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16488; Tue, 2 Apr 2002 09:40:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32HdLKL003921 for ; Tue, 2 Apr 2002 09:39:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32HdLnW003920 for mobile-ip-dist; Tue, 2 Apr 2002 09:39:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32HdIKL003913 for ; Tue, 2 Apr 2002 09:39:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27809 for ; Tue, 2 Apr 2002 09:39:22 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22617 for ; Tue, 2 Apr 2002 09:39:22 -0800 (PST) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g32Hd9J8025146; Tue, 2 Apr 2002 09:39:09 -0800 (PST) Received: from cisco.com (sjc-vpn1-737.cisco.com [10.21.98.225]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACH33514; Tue, 2 Apr 2002 09:38:40 -0800 (PST) Message-ID: <3CA9ECBA.C8DE743F@cisco.com> Date: Tue, 02 Apr 2002 09:39:06 -0800 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Ahmad Muhanna , "'Pete McCann'" , Kent Nickell , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: Re: [mobile-ip] Re: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" References: <23BDB0046F3ED51185CD0002A5608D2402EE8B17@zrc2c009.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hmm, I've always assumed that "single trip" scheme is when MN sends Reg Request with non-unicast HA address field and an assigned HA responds with Reg Reply with its unicast address? The proposed text still requires another trip after HA rejects. MN has to send another Reg Request to set up tunneling. This dynamic HA assignment scheme takes 2 transactions. Kent Kuntal Chowdhury wrote: > > > Charlie, > This will certainly address the forward/backward compatibility issues > related to various dynamic HA assignment schemes. The suggested change > ensures a "single trip" dynamic HA solution and also covers the > concern about multiple simultaneous registrations with the dynamic HA > assignment scheme using "subnet directed broadcast". > > Regards, > Kuntal From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 12:54:13 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25981 for ; Tue, 2 Apr 2002 12:54:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25246; Tue, 2 Apr 2002 10:53:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26151; Tue, 2 Apr 2002 09:53:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32HqpKL004051 for ; Tue, 2 Apr 2002 09:52:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32HqpeF004050 for mobile-ip-dist; Tue, 2 Apr 2002 09:52:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32HqmKL004043 for ; Tue, 2 Apr 2002 09:52:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25933 for ; Tue, 2 Apr 2002 09:52:52 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19234 for ; Tue, 2 Apr 2002 10:52:52 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:52:49 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC95@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" , jari.arkko@piuha.net Cc: PRoberts@MEGISTO.com, Basavaraj.Patil@nokia.com Subject: RE: [mobile-ip] Reverse tunneling issues Date: Tue, 2 Apr 2002 12:52:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-7" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, The draft talks about a few ways of handling the state removal at the HA...you obviously still have not read it :-) The two options that do not require configuration change are i) fixed timer (say 5sec) that the HA will keep the old binding after a new binding is received or ii) the HA could just keep the old binding until its lifetime expires...which is for lazy implementers that do not want to implement yet another timer in their system, present company excluded of course :-). How does that sound? George -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, April 02, 2002 5:53 PM To: mobile-ip@sunroof.eng.sun.com; jari.arkko@piuha.net Cc: PRoberts@MEGISTO.com; Basavaraj.Patil@nokia.com Subject: Re: [mobile-ip] Reverse tunneling issues George, While I support this, I'd like to ask you the same question that was asked about BETH: what causes the old tunnel state to get cleaned up? People seemed to feel that cleaning up tunnel state in ARs was important for BETH, and I believe the same argument can be made for the HA. jak ----- Original Message ----- From: "George Tsirtsis" To: ; Cc: ; Sent: Tuesday, April 02, 2002 1:28 AM Subject: RE: [mobile-ip] Reverse tunneling issues > Jari, > > Here is the deal... > > draft-oneill-mip-revtun-ho-00.txt in section 6. "IPv6 Considerations" > currently suggest: > "The IPv6 HA should support the automatic invocation of a fan-in binding if > reverse tunneling is requested." > > "Fan-in bindings" are explained earlier in the document > This essentially says that when reverse tunneling is used the HA has to > maintain at least 2 bindings for the MN, at least for a short time during > handoff. > > So for example, > - Assume a MN that uses reverse tunneling > - After the MN hands off to a new CoA it sends the appropriate BU to the HA > - The HA registers the new binding to the newCoA and immediately uses it for > all downlink traffic. > - The HA also keeps the oldCoA binding for a while but only uses it so that > it can accept in-flight packets from that oldCoA > - The old binding is removed if/when the MN moves to yet another (third) CoA > or after a default timeout. > > The above works for both MIPv4 and MIPv6 and does not require any signaling > changes, but only behavior changes at the HA i.e.: currently a new Binding > REPLACES the old Binding. The text needs to be revised to say that the new > Binding REPLACES the old Binding for downlink traffic but it is ADDED to the > old Binding for reverse tunneled traffic. > > Also note that while the above helps, it does not solve the problem > completely for reasons explained in the draft. To solve all problems with > reverse tunneling we need signaling changes/extensions which I guess could > be described in a new draft. > > Does this make sense? > > Regards > George > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Saturday, March 30, 2002 2:09 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: 'PRoberts@MEGISTO.com'; 'Basavaraj.Patil@nokia.com' > Subject: Re: [mobile-ip] Reverse tunneling issues > > > George Tsirtsis wrote: > > > > GT> No problem...have a look at the draft and do not let the too many > > options of how to solve the problem confuse you ...this is not > complex...it > > is just that it has to be dealt with. > > > Assuming something has to be done, is this something that has to go to > the base RFC, or something that can be done in an extension separately? > > Jari > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 12:55:35 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26038 for ; Tue, 2 Apr 2002 12:55:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05578; Tue, 2 Apr 2002 09:55:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27002; Tue, 2 Apr 2002 09:55:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32HsUKL004083 for ; Tue, 2 Apr 2002 09:54:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32HsURu004082 for mobile-ip-dist; Tue, 2 Apr 2002 09:54:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32HsRKL004074 for ; Tue, 2 Apr 2002 09:54:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03959 for ; Tue, 2 Apr 2002 09:54:32 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23355 for ; Tue, 2 Apr 2002 10:54:31 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:54:29 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC96@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'jari.arkko@piuha.net'" , "'PRoberts@MEGISTO.com'" , "'Basavaraj.Patil@nokia.com'" Subject: RE: [mobile-ip] Reverse tunneling issues Date: Tue, 2 Apr 2002 12:54:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Gabriel, Let me clarify this and come back to you, ok? Thanks George -----Original Message----- From: gabriel montenegro [mailto:gab@sun.com] Sent: Tuesday, April 02, 2002 10:33 AM To: mobile-ip@sunroof.eng.sun.com Cc: 'jari.arkko@piuha.net'; 'PRoberts@MEGISTO.com'; 'Basavaraj.Patil@nokia.com' Subject: Re: [mobile-ip] Reverse tunneling issues George, Your draft talks about IPR on your proposal. Could you clarify how much (if not all) is covered, etc? -gabriel From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 13:18:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26759 for ; Tue, 2 Apr 2002 13:18:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02953; Tue, 2 Apr 2002 11:18:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06452; Tue, 2 Apr 2002 10:18:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32IH6KL004235 for ; Tue, 2 Apr 2002 10:17:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32IH6eE004234 for mobile-ip-dist; Tue, 2 Apr 2002 10:17:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32IH2KL004227 for ; Tue, 2 Apr 2002 10:17:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28346 for ; Tue, 2 Apr 2002 10:17:07 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04279 for ; Tue, 2 Apr 2002 11:17:06 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g32IH5I10406; Tue, 2 Apr 2002 10:17:05 -0800 (PST) Message-ID: <01d001c1da72$5e6b45e0$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: , References: <8C92E23A3E87FB479988285F9E22BE465ABC95@ftmail> Subject: Re: [mobile-ip] Reverse tunneling issues Date: Tue, 2 Apr 2002 10:15:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The draft talks about a few ways of handling the state removal at the > HA...you obviously still have not read it :-) Yes, sorry. > The two options that do not require configuration change are i) fixed timer > (say 5sec) that the HA will keep the old binding after a new binding is > received or ii) the HA could just keep the old binding until its lifetime > expires...which is for lazy implementers that do not want to implement yet > another timer in their system, present company excluded of course :-). > The first option has the problem that it may cut off traffic prematurely, though 5 sec. is pretty generous and the packets would need to be really laggard for that to be a problem. The second sounds OK and is probably better from a practical standpoint. There were objections to letting tunnel state simply time out on ARs for BETH and there was some insistence on actually having signaling to clean it up, if I recall correctly. But if nobody is complaining now, then I've got no problem with it. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 13:19:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26831 for ; Tue, 2 Apr 2002 13:19:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08302; Tue, 2 Apr 2002 11:19:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06936; Tue, 2 Apr 2002 10:18:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32IICKL004252 for ; Tue, 2 Apr 2002 10:18:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32IICkc004251 for mobile-ip-dist; Tue, 2 Apr 2002 10:18:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32IIAKL004244 for ; Tue, 2 Apr 2002 10:18:11 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21236 for ; Tue, 2 Apr 2002 13:18:15 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA23494 for mobile-ip@sunroof.eng.sun.com; Tue, 2 Apr 2002 13:19:11 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g329fYKL001807 for ; Tue, 2 Apr 2002 01:41:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24293 for ; Tue, 2 Apr 2002 01:41:38 -0800 (PST) Received: from Mistralsoftware.com (ptil-150-145-ban.primus-india.net [203.196.145.150] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA25696 for ; Tue, 2 Apr 2002 02:41:34 -0700 (MST) Received: from kalyana [192.168.13.46] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Tue, 02 Apr 2002 15:19:26 +0530 Message-ID: <00dc01c1da2b$31c0c390$2e0da8c0@kalyana> From: "Kalyan" To: References: <8C92E23A3E87FB479988285F9E22BE465ABC8B@ftmail> Subject: Re: [mobile-ip] Reverse tunneling issues Date: Tue, 2 Apr 2002 15:15:59 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MDRemoteIP: 192.168.13.46 X-Return-Path: kalyan@mistralsoftware.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George, Are there any latest enhancements proposed for Mobile IPv4.what all rfcs should be considered for those advanced features.Please let me know at the earliest. regards, Kalyan. ----- Original Message ----- From: "George Tsirtsis" To: ; Cc: ; Sent: Tuesday, April 02, 2002 2:58 PM Subject: RE: [mobile-ip] Reverse tunneling issues > Jari, > > Here is the deal... > > draft-oneill-mip-revtun-ho-00.txt in section 6. "IPv6 Considerations" > currently suggest: > "The IPv6 HA should support the automatic invocation of a fan-in binding if > reverse tunneling is requested." > > "Fan-in bindings" are explained earlier in the document > This essentially says that when reverse tunneling is used the HA has to > maintain at least 2 bindings for the MN, at least for a short time during > handoff. > > So for example, > - Assume a MN that uses reverse tunneling > - After the MN hands off to a new CoA it sends the appropriate BU to the HA > - The HA registers the new binding to the newCoA and immediately uses it for > all downlink traffic. > - The HA also keeps the oldCoA binding for a while but only uses it so that > it can accept in-flight packets from that oldCoA > - The old binding is removed if/when the MN moves to yet another (third) CoA > or after a default timeout. > > The above works for both MIPv4 and MIPv6 and does not require any signaling > changes, but only behavior changes at the HA i.e.: currently a new Binding > REPLACES the old Binding. The text needs to be revised to say that the new > Binding REPLACES the old Binding for downlink traffic but it is ADDED to the > old Binding for reverse tunneled traffic. > > Also note that while the above helps, it does not solve the problem > completely for reasons explained in the draft. To solve all problems with > reverse tunneling we need signaling changes/extensions which I guess could > be described in a new draft. > > Does this make sense? > > Regards > George > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Saturday, March 30, 2002 2:09 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: 'PRoberts@MEGISTO.com'; 'Basavaraj.Patil@nokia.com' > Subject: Re: [mobile-ip] Reverse tunneling issues > > > George Tsirtsis wrote: > > > > GT> No problem...have a look at the draft and do not let the too many > > options of how to solve the problem confuse you ...this is not > complex...it > > is just that it has to be dealt with. > > > Assuming something has to be done, is this something that has to go to > the base RFC, or something that can be done in an extension separately? > > Jari > > From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 13:23:04 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27074 for ; Tue, 2 Apr 2002 13:23:03 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02007; Tue, 2 Apr 2002 11:22:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00708; Tue, 2 Apr 2002 10:22:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32ILeKL004416 for ; Tue, 2 Apr 2002 10:21:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32ILeQx004415 for mobile-ip-dist; Tue, 2 Apr 2002 10:21:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32ILbKL004408 for ; Tue, 2 Apr 2002 10:21:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23737 for ; Tue, 2 Apr 2002 10:21:40 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05714 for ; Tue, 2 Apr 2002 10:21:39 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32ILSQ13754; Tue, 2 Apr 2002 12:21:29 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:21:34 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB49@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'kleung'" , mobile-ip@sunroof.eng.sun.com Cc: "'Pete McCann'" , "Kent Nickell", "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: RE: [mobile-ip] Re: RFC3220 and possible forward compatibility is sue "Dynamic Home Agent Allocation" Date: Tue, 2 Apr 2002 12:21:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA73.376589A0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DA73.376589A0 Content-Type: text/plain; charset="iso-8859-1" Hi, Kent, Thanks for your input. Please see my comments inserted below. Regards; Ahmad Muhanna > -----Original Message----- > From: kleung [mailto:kleung@cisco.com] > Sent: Tuesday, April 02, 2002 11:34 AM > To: mobile-ip@sunroof.eng.sun.com > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Pete McCann'; Nickell, Kent > [RICH2:2Q20:EXCH]; Basavaraj Patil (NTC/Dallas); Phil Roberts > Subject: Re: [mobile-ip] Re: RFC3220 and possible forward > compatibility > issue "Dynamic Home Agent Allocation" > > > Sorry folks. Somehow I misread the text and assumed it was about > the unicast IP address. > > Comments below... > > "Charles E. Perkins" wrote: > > > Hello folks, > > > > May I assume that this corrective text is acceptable to > > everyone concerned? I would like to incorporate the necessary > > revisions and reissue RFC3220bis soon. Is there any impact > > on RFC3012bis? > > > > Regards, > > Charlie P. > > > > > Proposed TEXT: > > > Section 3.8.2.2: > > > " > > > If the Home Agent field in the Registration > Request contains a > > > unicast address of this home agent, then that > field MUST be copied > > > into the Home Agent field of the Registration > Reply. Otherwise, the > > > home agent MUST set the Home Agent field in the > Registration Reply to > > > its unicast address. In this latter case and > only if this IP packet > > > was distant > > > to either the subnet-directed broadcast or > 255.255.255.255, the home > > > [Muhanna, Ahmad] > > > I meant "In this latter case and only if this IP > packet was destined to > > > either > > > the subnet-directed broadcast or 255.255.255.255, > the home .." > > > > > What about 0.0.0.0? > > Isn't the current language already saying that in the non-unicast > case, set the HA field and reject? This non-unicast address broadly > covers subnet-directed broadcast, 255.255.255.255, and 0.0.0.0. > > "If the Home Agent field in the Registration Request contains a > unicast address of this home agent, .... Otherwise, the > home agent MUST set the Home Agent field in the Registration Reply to > its unicast address. In this latter case, ..." > > I don't have a problem with listing out specific IP addresses > in the spec, > just not sure if it's really needed. > > Thanks. > > Kent Well, I do not think that we can send any IP packet to a destination IP address of 0.0.0.0. It is possible that my text is not very clear. What I meant by destined is "The destination IP address in the IP packet (which contains the RRQ message) is set to either the subnet-directed broadcast or 255.255.255.255." I hope this clarifies the issue. Thanks; Ahmad > > > > > > > agent MUST reject the registration with a > suitable code (e.g., Code > > > 136) > > > to prevent the mobile node from possibly being > simultaneously > > > registered > > > with two or more home agents. > > > " > > > > > > Thanks for consideration. > > > > > > Regards; > > > Ahmad Muhanna > > ------_=_NextPart_001_01C1DA73.376589A0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation"

Hi, Kent,
Thanks for your input.
Please see my comments inserted below.

Regards;
Ahmad Muhanna

> -----Original Message-----
> From: kleung [mailto:kleung@cisco.com]
> Sent: Tuesday, April 02, 2002 11:34 AM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Pete McCann'; Nickell, Kent
> [RICH2:2Q20:EXCH]; Basavaraj Patil (NTC/Dallas); Phil Roberts
> Subject: Re: [mobile-ip] Re: RFC3220 and possible forward
> compatibility
> issue "Dynamic Home Agent Allocation"
>
>
> Sorry folks.  Somehow I misread the text and assumed it was about
> the unicast IP address.
>
> Comments below...
>
> "Charles E. Perkins" wrote:
>
> > Hello folks,
> >
> > May I assume that this corrective text is acceptable to
> > everyone concerned?  I would like to incorporate the necessary
> > revisions and reissue RFC3220bis soon.  Is there any impact
> > on RFC3012bis?
> >
> > Regards,
> > Charlie P.
> >
> > >      Proposed TEXT:
> > >       Section 3.8.2.2:
> > >      "
> > >         If the Home Agent field in the Registration
> Request contains a
> > >         unicast address of this home agent, then that
> field MUST be copied
> > >         into the Home Agent field of the Registration
> Reply.  Otherwise, the
> > >         home agent MUST set the Home Agent field in the
> Registration Reply to
> > >         its unicast address.  In this latter case and
> only if this IP packet
> > >      was distant
> > >         to either the subnet-directed broadcast or
> 255.255.255.255, the home
> > >      [Muhanna, Ahmad]
> > >      I meant "In this latter case and only if this IP
> packet was destined to
> > >      either
> > >      the subnet-directed broadcast or 255.255.255.255,
> the home .."
> > >
>
> What about 0.0.0.0?
>
> Isn't the current language already saying that in the non-unicast
> case, set the HA field and reject?  This non-unicast address broadly
> covers subnet-directed broadcast, 255.255.255.255, and 0.0.0.0.
>
> "If the Home Agent field in the Registration Request contains a
> unicast address of this home agent, ....  Otherwise, the
> home agent MUST set the Home Agent field in the Registration Reply to
> its unicast address.  In this latter case, ..."
>
> I don't have a problem with listing out specific IP addresses
> in the spec,
> just not sure if it's really needed.
>
> Thanks.
>
> Kent

Well, I do not think that we can send any IP packet to a destination IP address of 0.0.0.0.
It is possible that my text is not very clear.
What I meant by destined is
"The destination IP address in the IP packet (which contains the RRQ message) is set to
either the subnet-directed broadcast or 255.255.255.255."

I hope this clarifies the issue.
Thanks;

Ahmad
 
>
>
> >
> > >         agent MUST reject the registration with a
> suitable code (e.g., Code
> > >      136)
> > >         to prevent the mobile node from possibly being
> simultaneously
> > >      registered
> > >         with two or more home agents.
> > >      "
> > >
> > >      Thanks for consideration.
> > >
> > >      Regards;
> > >      Ahmad Muhanna
>
>

------_=_NextPart_001_01C1DA73.376589A0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 14:43:14 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29730 for ; Tue, 2 Apr 2002 14:43:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12914; Tue, 2 Apr 2002 12:42:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13843; Tue, 2 Apr 2002 11:42:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32JfqKL004756 for ; Tue, 2 Apr 2002 11:41:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32Jfq2a004755 for mobile-ip-dist; Tue, 2 Apr 2002 11:41:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32JfmKL004748 for ; Tue, 2 Apr 2002 11:41:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25578 for ; Tue, 2 Apr 2002 11:41:52 -0800 (PST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12387 for ; Tue, 2 Apr 2002 12:41:51 -0700 (MST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g32JfpV01105; Tue, 2 Apr 2002 13:41:51 -0600 (CST) Message-ID: <3CAA097D.4000300@alcatel.com> Date: Tue, 02 Apr 2002 13:41:49 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: seamoby@ietf.org, stefano.faccin@nokia.com Subject: Re: [mobile-ip] ip-paging work References: <3CA39DBD.6040300@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear all, As promised, here is more info: Stefano and I would like to sollicit your participation in the new work on ip-paging. The proposed charter which will be base to the discussions on the mailing can be obtained from: http://pages.sbcglobal.net/bsarikaya/ip-paging/charter.htm If you have not done so you can get to the list by sending an email to behcet.sarikaya@alcatel.com Regards, -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 15:13:47 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01053 for ; Tue, 2 Apr 2002 15:13:46 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04673; Tue, 2 Apr 2002 13:13:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02905; Tue, 2 Apr 2002 12:13:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32KC8KL004869 for ; Tue, 2 Apr 2002 12:12:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32KC8pb004868 for mobile-ip-dist; Tue, 2 Apr 2002 12:12:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32KC5KL004861 for ; Tue, 2 Apr 2002 12:12:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25252 for ; Tue, 2 Apr 2002 12:12:09 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04207 for ; Tue, 2 Apr 2002 13:12:08 -0700 (MST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 2 Apr 2002 12:12:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA82.A9C7836E" Subject: RE: [mobile-ip] Comments on Draft 16 Date: Tue, 2 Apr 2002 12:12:07 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A5@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Comments on Draft 16 Thread-Index: AcHaQvoPntohBd9MQzW0vOY1t7VvOQAPtcBQ From: "Mohan Parthasarathy" To: , Cc: , "Glenn Morrow" X-OriginalArrivalTime: 02 Apr 2002 20:12:07.0654 (UTC) FILETIME=[AA0B1060:01C1DA82] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C1DA82.A9C7836E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 > > =3D> The problem is whether we can allow a node to reverse=20 > tunnel to the=20 > > HA, when using a site-local address as a home address, without=20 > > authenticating the tunnel. The problem is not so much in=20 > the reverse=20 > > tunnelling part, but rather due to using a Site-local HoA, which > > is most likely communicating with a Site-local address > > within the home site. So by not authenticating the tunnel > > we're allowing anyone to spoof the HoA and start sending=20 > > messages to a server within the home site, that perhaps > > is not meant to be reached from outside the site.=20 > > Of course the question is, since the server's replies > > will be sent to the MN, is this a problem?=20 > > But independantly of that, if the tunnel is not > > authenticated, an outsider is getting a hole > > that he wouldn't normally get with standard IPv6 > > routers on the border of the site. >=20 > Hesham, >=20 > I don't think allowing reverse tunnels without IPsec=20 > protection adds any new residual threats as long as the HA=20 > verifies that packets contain an outer source =3D CoA and an=20 > inner source =3D HoA (where there is a valid binding between=20 > HoA and CoA). >=20 So the mipv6 draft does not mandate that the reverse tunnel from MN to HA be Ipsec protected. It is only the HA to MN tunnel that is Ipsec protected. Could you clarify ? Thanks mohan > For example, in the site-local case, if there is no internal=20 > ingress filtering within a site then anybody could spoof=20 > site-local source addresses without using MIPv6. >=20 > Did you mean "IPsec" when you said "authenticated" or did you=20 > mean "verified"? (the term we used for HAO verification by CNs) >=20 > Erik >=20 >=20 ------_=_NextPart_001_01C1DA82.A9C7836E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Comments on Draft 16

 
>
> > =3D> The problem is whether we can allow = a node to reverse
> tunnel to the
> > HA, when using a site-local address as a = home address, without
> > authenticating the tunnel. The problem is = not so much in
> the reverse
> > tunnelling part, but rather due to using a = Site-local HoA, which
> > is most likely communicating with a = Site-local address
> > within the home site. So by not = authenticating the tunnel
> > we're allowing anyone to spoof the HoA and = start sending
> > messages to a server within the home site, = that perhaps
> > is not meant to be reached from outside the = site.
> > Of course the question is, since the = server's replies
> > will be sent to the MN, is this a problem? =
> > But independantly of that, if the tunnel is = not
> > authenticated, an outsider is getting a = hole
> > that he wouldn't normally get with standard = IPv6
> > routers on the border of the site.
>
> Hesham,
>
> I don't think allowing reverse tunnels without = IPsec
> protection adds any new residual threats as long = as the HA
> verifies that packets contain an outer source = =3D CoA and an
> inner source =3D HoA (where there is a valid = binding between
> HoA and CoA).
>
So the mipv6 draft does not mandate that the reverse = tunnel
from MN to HA  be Ipsec protected. It is only = the HA to MN
tunnel that is Ipsec protected. Could you clarify = ?

Thanks
mohan

> For example, in the site-local case, if there is = no internal
> ingress filtering within a site then anybody = could spoof
> site-local source addresses without using = MIPv6.
>
> Did you mean "IPsec" when you said = "authenticated" or did you
> mean "verified"? (the term we used for = HAO verification by CNs)
>
>   Erik
>
>

------_=_NextPart_001_01C1DA82.A9C7836E-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 15:27:54 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01556 for ; Tue, 2 Apr 2002 15:27:53 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17133; Tue, 2 Apr 2002 11:35:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06437; Tue, 2 Apr 2002 10:35:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32IYpKL004604 for ; Tue, 2 Apr 2002 10:34:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32IYpEl004603 for mobile-ip-dist; Tue, 2 Apr 2002 10:34:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32IYmKL004596 for ; Tue, 2 Apr 2002 10:34:48 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20077 for ; Tue, 2 Apr 2002 10:34:51 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09863 for ; Tue, 2 Apr 2002 10:34:50 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32IYIQ20084; Tue, 2 Apr 2002 12:34:19 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:34:24 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02EC5B01@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Hesham Soliman (ERA)" , "'Erik Nordmark'" Cc: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Comments on Draft 16 Date: Tue, 2 Apr 2002 12:34:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA75.01A2A670" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DA75.01A2A670 Content-Type: text/plain; charset="iso-8859-1" Sorry I haven't kept up on the mail list lately. I guess this is a generic tunneling issue. We need to ask ourselves the question, "what harm would tunneling in unauthenticated packets using site-local source addresses do?". What are site-locals are use for anyway? I did a search and couldn't find anything explicit; although there is a proposed use for manet autoconfig. I guess the only use for it is some sort of guaranteed retriction that communications are originating from and contrained to a particular site. So the only harm I might see is that this guarantee could be broken by tunneling somehow. In the case of a remote node tunneling in site-locals there is nothing wrong with that as long as you can guarantee that it really is an authorized remoted node of the network. Note for globals there is no auro of perception that the originator was definitely site-local. Just checking the source address may not help. Any node on a mobile's shared medium could forge a packet using the mobile's care of address and a site local in the inner tunnel. If there is no percieved harm in this then there is no problem. If there is harm then we might consider putting some statements in the tunneling specs or the applications which employ their use. I'm beginning to get a little confused with what is and isn't a security requirement and what is a BCP. It seems a bit arbitrary to me how these decision have been made. With the criteria used for RO'd MIP I honestly think we might consider reviewing the IPv4 targeting BCPs to see if these should be made requirements of IPv6. This would be a bit on the extreme side though. This begs the question should site-local source checks be done on the ingress into sites? I think the original suggestion was that we insure that some terminology was included "somewhere" that RECOMMENDS that a policy of integrity checking be set up to guarantee the site-local nature. I guess the tunneling specs should be the place for it. I'm hoping that a few recommended words will map to a default configuration on routing devices. Also tunneled link-locals should also require integrity as well. There are probably more security issues related to these. Thanks, Glenn > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Tuesday, April 02, 2002 9:00 AM > To: 'Erik Nordmark'; Hesham Soliman (ERA) > Cc: 'jari.arkko@piuha.net'; 'mobile-ip@sunroof.eng.sun.com'; Morrow, > Glenn [RICH2:C330:EXCH] > Subject: RE: [mobile-ip] Comments on Draft 16 > > > > > But my point was, if I want to talk to a site-local > > > address inside ericsson.com, while I'm at the IETF > > > I would have to have some sort of VPN access > > > (IPsec tunnel) to the firewall. I'm assuming that > > > someone might want to use site-local addresses > > > inside a site to prevent anyone from reaching the > > > server from outside the site. > > > So if we allow any MN to tunnel a site-local HoA from > > > a CoA through the HA, don't we want to make sure that > > > the tunnel is authenticated to prevent anyone snooping > > > the traffic from creating this tunnel? > > > > Yes, but that is because you have a policy, independent > of MIPv6, of > > wanting VPN protection for your data packets. > > => Sure. > > > > > That is one possible policy. But there might be other policies > > that don't require an IPsec VPN when packets are tunneled to home > > site-local addresses. > > There shouldn't be a need to pick and cast in stone any > > particular policy here > > as far as I can tell. > > => Ok. I guess organisations that care about > their security will set the right policies. > > > > => Sure, but I was concerned about the case where > > > they can reach a site-local address in the home > > > site, while located at a visited site. Which is > > > normally impossible. > > > > But even that isn't unique to MIPv6. A node could run an > > IPv6-in-IPv6 tunnel > > endpoint - one entity outside the firwall and one inside. > > => Right, but today the tunnel will be dropped > if it's not secured. I guess your point > is that this behaviour does not need to be > explicitly mandated, it's more like common sense > for administrators to set this policy. Sounds fair enough. > > Hesham > ------_=_NextPart_001_01C1DA75.01A2A670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Comments on Draft 16

Sorry I haven't kept up on the mail list lately. I = guess this is a generic tunneling issue. We need to ask ourselves the = question, "what harm would tunneling in unauthenticated packets = using site-local source addresses do?".

What are site-locals are use for anyway? I did a = search and couldn't find anything explicit; although there is a = proposed use for manet autoconfig. I guess the only use for it is some = sort of guaranteed retriction that communications are originating from = and contrained to a particular site.

So the only harm I might see is that this guarantee = could be broken by tunneling somehow. In the case of a remote node = tunneling in site-locals there is nothing wrong with that as long as = you can guarantee that it really is an authorized remoted node of the = network. Note for globals  there is no auro of perception that the = originator was definitely site-local.

Just checking the source address may not help. Any = node on a mobile's shared medium could forge a packet using the = mobile's care of address and a site local in the inner = tunnel.

If there is no percieved harm in this then there is = no problem. If there is harm then we might consider putting some = statements in the tunneling specs or the applications which employ = their use.

I'm beginning to get a little confused with what is = and isn't a security requirement and what is a BCP. It seems a bit = arbitrary to me how these decision have been made. With the criteria = used for RO'd MIP I honestly think we might consider reviewing the IPv4 = targeting BCPs to see if these should be made requirements of IPv6. = This would be a bit on the extreme side though. This begs the question = should site-local source checks be done on the ingress into = sites?

I think the original suggestion was that we insure = that some terminology was included "somewhere" that = RECOMMENDS that a policy of integrity checking be set up to guarantee = the site-local nature. I guess the tunneling specs should be the place = for it. I'm hoping that a few recommended words will map to a default = configuration on routing devices.

Also tunneled link-locals should also require = integrity as well. There are probably more security issues related to = these.

Thanks,

Glenn

> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:hesham.soliman@era= .ericsson.se]
> Sent: Tuesday, April 02, 2002 9:00 AM
> To: 'Erik Nordmark'; Hesham Soliman = (ERA)
> Cc: 'jari.arkko@piuha.net'; = 'mobile-ip@sunroof.eng.sun.com'; Morrow,
> Glenn [RICH2:C330:EXCH]
> Subject: RE: [mobile-ip] Comments on Draft = 16
>
>
>   > > But my point was, if I = want to talk to a site-local
>   > > address inside = ericsson.com, while I'm at the IETF
>   > > I would have to have some = sort of VPN access
>   > > (IPsec tunnel) to the = firewall. I'm assuming that
>   > > someone might want to use = site-local addresses
>   > > inside a site to prevent = anyone from reaching the
>   > > server from outside the = site.
>   > > So if we allow any MN to = tunnel a site-local HoA from
>   > > a CoA through the HA, = don't we want to make sure that
>   > > the tunnel is = authenticated to prevent anyone snooping
>   > > the traffic from creating = this tunnel?
>   >
>   > Yes, but that is because you = have a policy, independent
> of MIPv6, of
>   > wanting VPN protection for = your data packets.
>
> =3D> Sure.
>
>   >
>   > That is one possible policy. = But there might be other policies
>   > that don't require an IPsec = VPN when packets are tunneled to home
>   > site-local addresses.
>   > There shouldn't be a need to = pick and cast in stone any
>   > particular policy here
>   > as far as I can tell.
>
> =3D> Ok. I guess organisations that care = about
> their security will set the right = policies.
>
>   > > =3D> Sure, but I was = concerned about the case where
>   > > they can reach a = site-local address in the home
>   > > site, while located at a = visited site. Which is
>   > > normally = impossible.
>   >
>   > But even that isn't unique to = MIPv6. A node could run an
>   > IPv6-in-IPv6 tunnel
>   > endpoint - one entity outside = the firwall and one inside.
>
> =3D> Right, but today the tunnel will be = dropped
> if it's not secured. I guess your point
> is that this behaviour does not need to be =
> explicitly mandated, it's more like common = sense
> for administrators to set this policy. Sounds = fair enough.
>
> Hesham
>

------_=_NextPart_001_01C1DA75.01A2A670-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 16:40:02 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04587 for ; Tue, 2 Apr 2002 16:40:01 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13914; Tue, 2 Apr 2002 14:39:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19597; Tue, 2 Apr 2002 13:38:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32Lc7KL005048 for ; Tue, 2 Apr 2002 13:38:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32Lc7ne005045 for mobile-ip-dist; Tue, 2 Apr 2002 13:38:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32Lc3KL005037 for ; Tue, 2 Apr 2002 13:38:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23180 for ; Tue, 2 Apr 2002 13:38:08 -0800 (PST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19842 for ; Tue, 2 Apr 2002 13:37:47 -0800 (PST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g32Lc6s05101; Tue, 2 Apr 2002 16:38:06 -0500 (EST) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA07084; Tue, 2 Apr 2002 15:38:05 -0600 (CST) Received: (from mccap@localhost) by nwsgpc.ih.lucent.com (8.11.6+Sun/8.11.6) id g32Lc5p24095; Tue, 2 Apr 2002 15:38:05 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15530.9405.417724.901454@nwsgpc.ih.lucent.com> Date: Tue, 2 Apr 2002 15:38:05 -0600 (CST) From: Pete McCann To: mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" , "Kent Nickell", "Ahmad Muhanna" Subject: [mobile-ip] RE: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCB45@zrc2c013.us.nortel.com> References: <6B49EDFE974BD51197D70002A56079D801AFCB45@zrc2c013.us.nortel.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Ahmad, I think this is your current proposal, cleaned up a bit: Ahmad Muhanna writes: > Proposed TEXT: > Section 3.8.3.2: > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be > copied into the Home Agent field of the Registration Reply. > Otherwise, the home agent MUST set the Home Agent field in the > Registration Reply to its unicast address. In this latter case > and only if this IP packet was destined to either the > subnet-directed broadcast or 255.255.255.255, the home agent > MUST reject the registration with a suitable code (e.g., Code > 136) to prevent the mobile node from possibly being > simultaneously registered with two or more home agents. If I may summarize, you are proposing that the HA base its decision on whether to accept or reject the request not only on the contents of the HA field but also on the contents of the IP destination address of the Registration Request. Both the existing and proposed texts mandate that an HA reject requests that were subnet-directed broadcast, if they contain an HA address that doesn't match one of the unicast interfaces of the HA. However, you are proposing that the HA be allowed to respond successfully to Registration Requests no matter what the content of the HA field, as long as they were not subnet-directed broadcast. I am not sure this is entirely safe. Rather, I would propose something like the following: If the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, the Home Agent MUST reject the request with a suitable code (e.g., Code 136) unless the Home Agent can determine by means outside the scope of this document (e.g., by receiving the Registration Request from a trusted authenticating entity) that it has been allocated to service the registration and that no other Home Agent will receive the same request. This will prevent the mobile node from possibly being simultaneously registered with two or more home agents. In case such a determination is made, the Home Agent MAY respond successfully if the Registration Request is otherwise valid. -Pete From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 18:20:33 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07723 for ; Tue, 2 Apr 2002 18:20:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09461; Tue, 2 Apr 2002 16:20:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00405; Tue, 2 Apr 2002 15:20:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32NJJKL005244 for ; Tue, 2 Apr 2002 15:19:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32NJJnF005243 for mobile-ip-dist; Tue, 2 Apr 2002 15:19:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32NJGKL005236 for ; Tue, 2 Apr 2002 15:19:16 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26274 for ; Tue, 2 Apr 2002 15:19:20 -0800 (PST) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20813 for ; Tue, 2 Apr 2002 15:18:58 -0800 (PST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 08AC03F2B for ; Tue, 2 Apr 2002 17:19:19 -0600 (CST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 47F359A8 for ; Tue, 2 Apr 2002 15:19:18 -0800 (PST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g32NJGR12333; Tue, 2 Apr 2002 18:19:17 -0500 (EST) Received: from compaq.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id SAA0000177008; Tue, 2 Apr 2002 18:19:16 -0500 (EST) Message-ID: <3CAA3C74.9FD17536@compaq.com> Date: Tue, 02 Apr 2002 18:19:16 -0500 From: Vladislav Yasevich Organization: Compaq X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6ABE2@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I guess I missed the whole site-local issue in all the discussion but... I think there might be a problem for a mobile use site-local addresses. First, to use a site-local address the mobile would have to register it with a HA. However, there is no place in the BU or a BCE to specify a zone id (I may have missed this in the new draft). Second, even if there was space in the BCE and a BU, the zone id would be at least meaningless and at worst incorrect to the home agent, which could potentially be multi-sited. The zone ids on the home agent most likely will not be the same as the ids on the mobile node. To me, it looks like site-local addresses will be problematic once moving away from home. -vlad "Hesham Soliman (ERA)" wrote: > > => The problem is whether we can allow a node to reverse > tunnel to the HA, when using a site-local address as > a home address, without authenticating the tunnel. > The problem is not so much in the reverse tunnelling > part, but rather due to using a Site-local HoA, which > is most likely communicating with a Site-local address > within the home site. So by not authenticating the tunnel > we're allowing anyone to spoof the HoA and start sending > messages to a server within the home site, that perhaps > is not meant to be reached from outside the site. > Of course the question is, since the server's replies > will be sent to the MN, is this a problem? > But independantly of that, if the tunnel is not > authenticated, an outsider is getting a hole > that he wouldn't normally get with standard IPv6 > routers on the border of the site. > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich IPv6 Project Lead Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Tel: (603) 884-1079 Nashua, NH 03062 Fax: (435) 514-6884 From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 18:38:19 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08067 for ; Tue, 2 Apr 2002 18:38:18 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17086; Tue, 2 Apr 2002 16:38:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02915; Tue, 2 Apr 2002 15:37:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32Nb5KL005397 for ; Tue, 2 Apr 2002 15:37:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g32Nb4L9005396 for mobile-ip-dist; Tue, 2 Apr 2002 15:37:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g32Nb1KL005389 for ; Tue, 2 Apr 2002 15:37:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25128 for ; Tue, 2 Apr 2002 15:37:05 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10092 for ; Tue, 2 Apr 2002 16:37:04 -0700 (MST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g32Nama11325; Tue, 2 Apr 2002 15:36:48 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-122.cisco.com [128.107.163.122]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACH43398; Tue, 2 Apr 2002 15:36:19 -0800 (PST) Message-ID: <3CAA408F.1B899026@cisco.com> Date: Tue, 02 Apr 2002 15:36:47 -0800 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "'Charlie Perkins'" , Kent Nickell , Ahmad Muhanna Subject: Re: [mobile-ip] RE: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" References: <6B49EDFE974BD51197D70002A56079D801AFCB45@zrc2c013.us.nortel.com> <15530.9405.417724.901454@nwsgpc.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pete McCann wrote: > If I may summarize, you are proposing that the HA base its decision on > whether to accept or reject the request not only on the contents of > the HA field but also on the contents of the IP destination address of > the Registration Request. Both the existing and proposed texts > mandate that an HA reject requests that were subnet-directed > broadcast, if they contain an HA address that doesn't match one of the > unicast interfaces of the HA. However, you are proposing that the HA > be allowed to respond successfully to Registration Requests no matter > what the content of the HA field, as long as they were not > subnet-directed broadcast. I am not sure this is entirely safe. > Thanks for the clarification. Though just a little disagreement over the intention. :) To keep scheme safe, my proposal follows below. > > Rather, I would propose something like the following: > > If the Home Agent field in the Registration Request contains a unicast > address of this home agent, then that field MUST be copied into the > Home Agent field of the Registration Reply. Otherwise, the home agent > MUST set the Home Agent field in the Registration Reply to its unicast > address. In this latter case, the Home Agent MUST reject the request > with a suitable code (e.g., Code 136) unless the Home Agent can > determine by means outside the scope of this document (e.g., by > receiving the Registration Request from a trusted authenticating > entity) that it has been allocated to service the registration and > that no other Home Agent will receive the same request. This > will prevent the mobile node from possibly being simultaneously > registered with two or more home agents. In case such a > determination is made, the Home Agent MAY respond successfully if > the Registration Request is otherwise valid. > If the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, the Home Agent MUST reject the request with a suitable code (e.g., Code 136) unless the destination IP address of the Registation Request is an unicast address. In this case, the Home Agent MAY accept the Registration Request. This will prevent the mobile node from possibly being simultaneously registered with two or more home agents. How does this sound? Was this the intent? Kent From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 19:17:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09250 for ; Tue, 2 Apr 2002 19:17:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00422; Tue, 2 Apr 2002 17:17:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17911; Tue, 2 Apr 2002 16:17:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g330G6KL005604 for ; Tue, 2 Apr 2002 16:16:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g330G6Ms005603 for mobile-ip-dist; Tue, 2 Apr 2002 16:16:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g330G2KL005596 for ; Tue, 2 Apr 2002 16:16:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21007 for ; Tue, 2 Apr 2002 16:16:07 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06650 for ; Tue, 2 Apr 2002 16:15:45 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g330Ftt10317; Tue, 2 Apr 2002 18:15:56 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 18:16:02 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB4E@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'kleung'" , mobile-ip@sunroof.eng.sun.com Cc: "'Charlie Perkins'" , "Kent Nickell", "Kuntal Chowdhury" Subject: RE: [mobile-ip] RE: RFC3220 and possible forward compatibility is sue "Dynamic Home Agent Allocation" Date: Tue, 2 Apr 2002 18:16:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DAA4.BC0C02C0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DAA4.BC0C02C0 Content-Type: text/plain; charset="iso-8859-1" Hello Pete/Kent; I agree, however some fine tuning to a simpler text below. > > > > Pete McCann wrote: > > > If I may summarize, you are proposing that the HA base its > decision on > > whether to accept or reject the request not only on the contents of > > the HA field but also on the contents of the IP destination > address of > > the Registration Request. Both the existing and proposed texts > > mandate that an HA reject requests that were subnet-directed > > broadcast, if they contain an HA address that doesn't match > one of the > > unicast interfaces of the HA. However, you are proposing > that the HA > > be allowed to respond successfully to Registration Requests > no matter > > what the content of the HA field, as long as they were not > > subnet-directed broadcast. I am not sure this is entirely safe. > > > > Thanks for the clarification. Though just a little disagreement over > the intention. :) > > To keep scheme safe, my proposal follows below. > > > > > > Rather, I would propose something like the following: > > > > If the Home Agent field in the Registration Request > contains a unicast > > address of this home agent, then that field MUST be > copied into the > > Home Agent field of the Registration Reply. Otherwise, > the home agent > > MUST set the Home Agent field in the Registration Reply > to its unicast > > address. In this latter case, the Home Agent MUST > reject the request > > with a suitable code (e.g., Code 136) unless the Home Agent can > > determine by means outside the scope of this document (e.g., by > > receiving the Registration Request from a trusted authenticating > > entity) that it has been allocated to service the > registration and > > that no other Home Agent will receive the same request. This > > will prevent the mobile node from possibly being simultaneously > > registered with two or more home agents. In case such a > > determination is made, the Home Agent MAY respond successfully if > > the Registration Request is otherwise valid. > > > > If the Home Agent field in the Registration Request > contains a unicast > address of this home agent, then that field MUST be copied into the > Home Agent field of the Registration Reply. Otherwise, > the home agent > MUST set the Home Agent field in the Registration Reply to > its unicast > address. In this latter case, the Home Agent MUST reject > the request > with a suitable code (e.g., Code 136) unless the > destination IP address > of the Registation Request is an unicast address. In this > case, the > Home Agent MAY accept the Registration Request. This > will prevent the mobile node from possibly being simultaneously > registered with two or more home agents. > > How does this sound? Was this the intent? > > Kent > > If the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, the home agent MUST reject the registration with a suitable code (e.g., Code 136) to prevent the mobile node from possibly being simultaneously registered with two or more home agents. However, if the destination IP address of the Registration Request is the unicast IP address of this Home Agent, the Home Agent MAY accept the Registration Request. Ahmad Muhanna ------_=_NextPart_001_01C1DAA4.BC0C02C0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RE: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation"

Hello Pete/Kent;

I agree, however some fine tuning to a simpler text below.

>
>
>
> Pete McCann wrote:
>
> > If I may summarize, you are proposing that the HA base its
> decision on
> > whether to accept or reject the request not only on the contents of
> > the HA field but also on the contents of the IP destination
> address of
> > the Registration Request.  Both the existing and proposed texts
> > mandate that an HA reject requests that were subnet-directed
> > broadcast, if they contain an HA address that doesn't match
> one of the
> > unicast interfaces of the HA.  However, you are proposing
> that the HA
> > be allowed to respond successfully to Registration Requests
> no matter
> > what the content of the HA field, as long as they were not
> > subnet-directed broadcast.  I am not sure this is entirely safe.
> >
>
> Thanks for the clarification.  Though just a little disagreement over
> the intention.  :)
>
> To keep scheme safe, my proposal follows below.
>
>
> >
> > Rather, I would propose something like the following:
> >
> >    If the Home Agent field in the Registration Request
> contains a unicast
> >    address of this home agent, then that field MUST be
> copied into the
> >    Home Agent field of the Registration Reply.  Otherwise,
> the home agent
> >    MUST set the Home Agent field in the Registration Reply
> to its unicast
> >    address.  In this latter case, the Home Agent MUST
> reject the request
> >    with a suitable code (e.g., Code 136) unless the Home Agent can
> >    determine by means outside the scope of this document (e.g., by
> >    receiving the Registration Request from a trusted authenticating
> >    entity) that it has been allocated to service the
> registration and
> >    that no other Home Agent will receive the same request.  This
> >    will prevent the mobile node from possibly being simultaneously
> >    registered with two or more home agents.  In case such a
> >    determination is made, the Home Agent MAY respond successfully if
> >    the Registration Request is otherwise valid.
> >
>
>    If the Home Agent field in the Registration Request
> contains a unicast
>    address of this home agent, then that field MUST be copied into the
>    Home Agent field of the Registration Reply.  Otherwise,
> the home agent
>    MUST set the Home Agent field in the Registration Reply to
> its unicast
>    address.  In this latter case, the Home Agent MUST reject
> the request
>    with a suitable code (e.g., Code 136) unless the
> destination IP address
>    of the Registation Request is an unicast address.  In this
> case, the
>    Home Agent MAY accept the Registration Request.  This
>    will prevent the mobile node from possibly being simultaneously
>    registered with two or more home agents.
>
> How does this sound?  Was this the intent?
>
> Kent
>
>

   If the Home Agent field in the Registration Request contains a
   unicast address of this home agent, then that field MUST be copied
   into the Home Agent field of the Registration Reply.  Otherwise, the
   home agent MUST set the Home Agent field in the Registration Reply to
   its unicast address.  In this latter case, the home agent MUST reject
   the registration with a suitable code (e.g., Code 136) to prevent the
   mobile node from possibly being simultaneously registered with two or
   more home agents. However, if the destination IP address of the Registration
   Request is the unicast IP address of this Home Agent, the Home Agent MAY
   accept the Registration Request.

Ahmad Muhanna

------_=_NextPart_001_01C1DAA4.BC0C02C0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 20:10:02 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10523 for ; Tue, 2 Apr 2002 20:10:02 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA28653; Tue, 2 Apr 2002 17:09:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05408; Tue, 2 Apr 2002 17:09:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3318bKL005766 for ; Tue, 2 Apr 2002 17:08:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3318aFS005765 for mobile-ip-dist; Tue, 2 Apr 2002 17:08:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3318XKL005758 for ; Tue, 2 Apr 2002 17:08:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19544 for ; Tue, 2 Apr 2002 17:08:38 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA02244 for ; Tue, 2 Apr 2002 18:08:37 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g3318Rb07468; Tue, 2 Apr 2002 17:08:27 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABH06848; Tue, 2 Apr 2002 17:06:04 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA13940; Tue, 2 Apr 2002 17:08:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15530.22026.752100.186019@thomasm-u1.cisco.com> Date: Tue, 2 Apr 2002 17:08:26 -0800 (PST) To: Erik Nordmark Cc: mohanp@tahoenetworks.com, mobile-ip@sunroof.eng.sun.com, Michael Thomas , jari.arkko@piuha.net, Samita Chakrabarti Subject: RE: [mobile-ip] Re: replacing IPsec's replay protection? In-Reply-To: References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > Are we sure we really want to allow this ? You may want to allow > > the MN-HA to use pre-shared keys instead of certificates and > > still use IKE. I don't understand why someone would want to > > use manual keys. > > I think there are people thinking about small mobile nodes > that might not want to require using IKE on those devices. > But I'm not one of them - perhaps they should speak > for themselves. Eric, If people want a "light weight" keying scheme for IPsec, it should either be pursued in IPsec WG, or through a BOF. It most certainly should not be done in MIP WG. As I've mentioned, there are some of our folks who have some interest in this, and their scheme doesn't require per node storage of anything but the key and something akin to the EngineBoots counter in SNMPv3. This would be a much better solution to this problem. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 20:28:22 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10924 for ; Tue, 2 Apr 2002 20:28:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA01247; Tue, 2 Apr 2002 17:28:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11635; Tue, 2 Apr 2002 17:27:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g331R4KL005894 for ; Tue, 2 Apr 2002 17:27:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g331R3hB005893 for mobile-ip-dist; Tue, 2 Apr 2002 17:27:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g331R0KL005886 for ; Tue, 2 Apr 2002 17:27:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13676 for ; Tue, 2 Apr 2002 17:27:05 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08344 for ; Tue, 2 Apr 2002 18:27:04 -0700 (MST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g331QUbx027879; Tue, 2 Apr 2002 17:26:30 -0800 (PST) Received: from MLIOY.qualcomm.com (mlioy.qualcomm.com [129.46.219.140]) by sabrina.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g331QNe8025510; Tue, 2 Apr 2002 17:26:23 -0800 (PST) Message-Id: <5.1.0.14.2.20020402171754.02119ec0@mail1.qualcomm.com> X-Sender: mlioy@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 17:20:02 -0800 To: mobile-ip@sunroof.eng.sun.com From: Marcello Lioy Subject: Re: [mobile-ip] Re: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" Cc: Ahmad Muhanna , "'Pete McCann'" , Kent Nickell , "Basavaraj Patil (NTC/Dallas)" , Phil Roberts In-Reply-To: <3CA9EB75.902E3391@cisco.com> References: <6B49EDFE974BD51197D70002A56079D801AFCB45@zrc2c013.us.nortel.com> <3CA9DB01.92FBD878@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: At 09:33 4/2/2002, kleung wrote: >What about 0.0.0.0? I am with Kent on this one. We already have fielded software out there that assumes that an address of 0.0.0.0 if for dynamic home agent allocation. Also to my mind it makes the most sence as this is not a valid address for a host to have (correct me if I am wrong) while 255.255.255.255 already has a meaning. >Isn't the current language already saying that in the non-unicast >case, set the HA field and reject? This non-unicast address broadly >covers subnet-directed broadcast, 255.255.255.255, and 0.0.0.0. > >"If the Home Agent field in the Registration Request contains a >unicast address of this home agent, .... Otherwise, the >home agent MUST set the Home Agent field in the Registration Reply to >its unicast address. In this latter case, ..." > >I don't have a problem with listing out specific IP addresses in the spec, >just not sure if it's really needed. > >Thanks. > >Kent > > > > > > > agent MUST reject the registration with a suitable code > (e.g., Code > > > 136) > > > to prevent the mobile node from possibly being simultaneously > > > registered > > > with two or more home agents. > > > " > > > > > > Thanks for consideration. > > > > > > Regards; > > > Ahmad Muhanna -- Marcello From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 22:10:16 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13024 for ; Tue, 2 Apr 2002 22:10:16 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12024; Tue, 2 Apr 2002 19:09:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08996; Tue, 2 Apr 2002 19:09:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3338tKL006238 for ; Tue, 2 Apr 2002 19:08:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3338tmZ006237 for mobile-ip-dist; Tue, 2 Apr 2002 19:08:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3338qKL006230 for ; Tue, 2 Apr 2002 19:08:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07297 for ; Tue, 2 Apr 2002 19:08:56 -0800 (PST) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28981 for ; Tue, 2 Apr 2002 20:08:52 -0700 (MST) Received: from mail.ustc.edu.cn (mail.ustc.edu.cn [202.38.64.10]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id LAA13748 for ; Wed, 3 Apr 2002 11:05:31 +0800 Received: (qmail 649 invoked by uid 1187); 3 Apr 2002 03:05:36 -0000 Date: Wed, 3 Apr 2002 11:05:36 +0800 (CST) From: Wang Hui X-X-Sender: To: Subject: [mobile-ip] LIN6 vs mobile-ipv6? In-Reply-To: <5.1.0.14.2.20020402173224.026f6308@mail1.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, folks here, I found that WIDE project has been doing a protocol (called LIN6) to support "mobility" for IPv6. As they claim that LIN6 provides mobility to IPv6 without impact on the existing IPv6 infrastructure and maintains compatibility with traditional IPv6. So what do you think of LIN6? Here is the web site for LIN6: http://www.lin6.net/ Best, Wang Hui From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 22:35:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14244 for ; Tue, 2 Apr 2002 22:35:28 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01056; Tue, 2 Apr 2002 18:33:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13236; Tue, 2 Apr 2002 17:32:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g331WFKL005982 for ; Tue, 2 Apr 2002 17:32:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g331WFla005981 for mobile-ip-dist; Tue, 2 Apr 2002 17:32:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g331WCKL005974 for ; Tue, 2 Apr 2002 17:32:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27112 for ; Tue, 2 Apr 2002 17:32:17 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00727 for ; Tue, 2 Apr 2002 18:32:16 -0700 (MST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g331Vm9Z027567 for ; Tue, 2 Apr 2002 17:31:49 -0800 (PST) Received: from JEFFD.qualcomm.com (jeffd.qualcomm.com [129.46.209.167]) by sabrina.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g331Vje8025867 for ; Tue, 2 Apr 2002 17:31:46 -0800 (PST) Message-Id: <5.1.0.14.2.20020402173224.026f6308@mail1.qualcomm.com> X-Sender: jeffd@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Apr 2002 17:32:44 -0800 To: mobile-ip@sunroof.eng.sun.com From: Jeff Dyck Subject: Re: [mobile-ip] Re: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" In-Reply-To: <5.1.0.14.2.20020402171754.02119ec0@mail1.qualcomm.com> References: <3CA9EB75.902E3391@cisco.com> <6B49EDFE974BD51197D70002A56079D801AFCB45@zrc2c013.us.nortel.com> <3CA9DB01.92FBD878@iprg.nokia.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_539643946==_.ALT" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --=====================_539643946==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed sense. At 05:20 PM 4/2/2002 -0800, you wrote: >At 09:33 4/2/2002, kleung wrote: > >>What about 0.0.0.0? > >I am with Kent on this one. We already have fielded software out there >that assumes that an address of 0.0.0.0 if for dynamic home agent allocation. > >Also to my mind it makes the most sence as this is not a valid address for >a host to have (correct me if I am wrong) while 255.255.255.255 already >has a meaning. > >>Isn't the current language already saying that in the non-unicast >>case, set the HA field and reject? This non-unicast address broadly >>covers subnet-directed broadcast, 255.255.255.255, and 0.0.0.0. >> >>"If the Home Agent field in the Registration Request contains a >>unicast address of this home agent, .... Otherwise, the >>home agent MUST set the Home Agent field in the Registration Reply to >>its unicast address. In this latter case, ..." >> >>I don't have a problem with listing out specific IP addresses in the spec, >>just not sure if it's really needed. >> >>Thanks. >> >>Kent >> >> >> > >> > > agent MUST reject the registration with a suitable code >> (e.g., Code >> > > 136) >> > > to prevent the mobile node from possibly being simultaneously >> > > registered >> > > with two or more home agents. >> > > " >> > > >> > > Thanks for consideration. >> > > >> > > Regards; >> > > Ahmad Muhanna > > >-- Marcello > __________________________________________________ Jeffrey Dyck, Engineer QUALCOMM CDMA Technologies (858) 845-7548 jeffd@qualcomm.com --=====================_539643946==_.ALT Content-Type: text/html; charset="us-ascii"
sense.

At 05:20 PM 4/2/2002 -0800, you wrote:
At 09:33 4/2/2002, kleung wrote:

What about 0.0.0.0?

I am with Kent on this one.  We already have fielded software out there that assumes that an address of 0.0.0.0 if for dynamic home agent allocation.

Also to my mind it makes the most sence as this is not a valid address for a host to have (correct me if I am wrong) while 255.255.255.255 already has a meaning.

Isn't the current language already saying that in the non-unicast
case, set the HA field and reject?  This non-unicast address broadly
covers subnet-directed broadcast, 255.255.255.255, and 0.0.0.0.

"If the Home Agent field in the Registration Request contains a
unicast address of this home agent, ....  Otherwise, the
home agent MUST set the Home Agent field in the Registration Reply to
its unicast address.  In this latter case, ..."

I don't have a problem with listing out specific IP addresses in the spec,
just not sure if it's really needed.

Thanks.

Kent


>
> >         agent MUST reject the registration with a suitable code (e.g., Code
> >      136)
> >         to prevent the mobile node from possibly being simultaneously
> >      registered
> >         with two or more home agents.
> >      "
> >
> >      Thanks for consideration.
> >
> >      Regards;
> >      Ahmad Muhanna


-- Marcello

__________________________________________________
Jeffrey Dyck, Engineer
QUALCOMM CDMA Technologies
(858) 845-7548
jeffd@qualcomm.com
--=====================_539643946==_.ALT-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 2 23:17:24 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15352 for ; Tue, 2 Apr 2002 23:17:24 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16159; Tue, 2 Apr 2002 21:16:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23272; Tue, 2 Apr 2002 20:16:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g334FdKL006371 for ; Tue, 2 Apr 2002 20:15:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g334FdFs006370 for mobile-ip-dist; Tue, 2 Apr 2002 20:15:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g334FaKL006363 for ; Tue, 2 Apr 2002 20:15:36 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA24720 for ; Tue, 2 Apr 2002 20:15:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02010 for ; Tue, 2 Apr 2002 20:15:09 -0800 (PST) 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 UAA29763 for ; Tue, 2 Apr 2002 20:15:30 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g334FTI27353 for ; Tue, 2 Apr 2002 20:15:29 -0800 X-mProtect: <200204030415> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpOhnov; Tue, 02 Apr 2002 20:15:28 PST Message-ID: <3CAA81E7.EED80C70@iprg.nokia.com> Date: Tue, 02 Apr 2002 20:15:35 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LIN6 vs mobile-ipv6? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, I think that LIN6 is mainly for people who want some of the features of Mobile IPv6, but who got tired of waiting for us to be finished with it. It basically moves the binding update to be a nameserver operation instead of a Mobile IP operation, and I think it doesn't offer any advantages other than just moving the necessary components to other parts of the protocol stack. I believe applications have to be rewritten to handle a new nameserver record type, and smooth handover is not really possible. Binding updates are not delivered to correspondent nodes. If I have some of the details wrong, please excuse, but this is my impression of it. Regards, Charlie P. Wang Hui wrote: > Hi, folks here, > > I found that WIDE project has been doing a protocol (called LIN6) to > support "mobility" for IPv6. > > As they claim that LIN6 provides mobility to IPv6 without impact on the > existing IPv6 infrastructure and maintains compatibility with traditional IPv6. > > So what do you think of LIN6? > > Here is the web site for LIN6: > http://www.lin6.net/ > > Best, > Wang Hui From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 00:11:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16427 for ; Wed, 3 Apr 2002 00:11:57 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01905; Tue, 2 Apr 2002 22:11:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28202; Tue, 2 Apr 2002 21:11:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3359WKL006568 for ; Tue, 2 Apr 2002 21:09:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3359Wgs006567 for mobile-ip-dist; Tue, 2 Apr 2002 21:09:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3359TKL006560 for ; Tue, 2 Apr 2002 21:09:29 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28014 for ; Tue, 2 Apr 2002 21:09:34 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA14594 for ; Tue, 2 Apr 2002 21:09:11 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3359We21576 for ; Wed, 3 Apr 2002 08:09:32 +0300 Date: Wed, 3 Apr 2002 08:09:31 +0300 (EEST) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LIN6 vs mobile-ipv6? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Wed, 3 Apr 2002, Wang Hui wrote: > So what do you think of LIN6? LIN6 has IPR. 'nuff said. Even if it was any good, it isn't really worth checking out. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 00:30:49 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16736 for ; Wed, 3 Apr 2002 00:30:49 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA23871; Tue, 2 Apr 2002 21:30:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA01416; Tue, 2 Apr 2002 21:30:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g335TKKL006652 for ; Tue, 2 Apr 2002 21:29:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g335TJLo006651 for mobile-ip-dist; Tue, 2 Apr 2002 21:29:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g335TGKL006644 for ; Tue, 2 Apr 2002 21:29:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06792 for ; Tue, 2 Apr 2002 21:29:20 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16362 for ; Tue, 2 Apr 2002 22:29:19 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g335TFe03549 for ; Tue, 2 Apr 2002 23:29:16 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 23:29:23 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02EC64AA@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LIN6 vs mobile-ipv6? Date: Tue, 2 Apr 2002 23:29:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DAD0.83148F60" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DAD0.83148F60 Content-Type: text/plain; charset="iso-8859-1" I see security holes in LIN6 as well. I.e. how do you know to trust the mapping agents, etc.. Do you have to establish security associations with them too? Are we going to get into a DNS security and scalability debate? I'm not trying to bash it. I just think there would be work to do there as well. On the positive side, I do like the idea of avoiding the tunnel overhead by identifying the separation of locator from global id. I think you might have some trouble with mobile prefixes and perhaps multicast optimizations based upon the existing choice of bit used to identify the LIN6 GID. Perhaps there is room in the IETF or IRTF for a more neutral exploration of node mobility. There does seem to be a long history of other thinking going on with respect to the solution set. I suppose the namespace IRTG group is one such venue that these other concepts have been explored. I know of: 8+8/GES, IIP, LAR, LIN6, MBG, Application, Dynamic DNS, HIP variants intermingled with each, others, sorry if I didn't mention one, etc.. It also seems that the requirements of MIP have been actificially restricted with the excuse of expediting more simple functionality. This has resulted in numerous spin-offs of the technology into other WGs such as Seamoby, Monet, IRTF wrecking ground, etc.. etc.. etc.. more coming I'm sure. My opinion of this is that it only serves to complicate the introduction of a more complete and possibly more optimal solution that might actually have been designed to meet all of the requirements. So, while I don't think the work on MIPv6 should be abandoned, it may be prudent to at least start something in the IRTF to take a more greenfield look at the solution set. This would perhaps at least let the MIPv6 WG continue on its current charted course while allowing a more accepting and open exploration of these other concepts. I don't mean to offend MIP supporters or the people with other ideas. I just think that such a new research group would help out both parties in both the short and long term. This might also be a healthy thing for IPv6 and the IETF as a whole. Perhaps the namespace IRTF group is already set up to explore these other concepts. I sincerely hope this helps both parties. Glenn ------_=_NextPart_001_01C1DAD0.83148F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] LIN6 vs mobile-ipv6?

I see security holes in LIN6 as well. I.e. how do you = know to trust the mapping agents, etc.. Do you have to establish = security associations with them too? Are we going to get into a DNS = security and scalability debate?

I'm not trying to bash it. I just think there would = be work to do there as well.

On the positive side, I do like the idea of avoiding = the tunnel overhead by identifying the separation of locator from = global id. I think you might have some trouble with mobile prefixes and = perhaps multicast optimizations based upon the existing choice of bit = used to identify the LIN6 GID.

Perhaps there is room in the IETF or IRTF for a more = neutral exploration of node mobility. There does seem to be a long = history of other thinking going on with respect to the solution set. I = suppose the namespace IRTG group is one such venue that these other = concepts have been explored.

I know of:

8+8/GES, IIP, LAR, LIN6, MBG, Application, Dynamic = DNS, HIP variants intermingled with each, others, sorry if I didn't = mention one, etc..

It also seems that the requirements of MIP have been = actificially restricted with the excuse of expediting more simple = functionality. This has resulted in numerous spin-offs of the = technology into other WGs such as Seamoby, Monet, IRTF wrecking ground, = etc.. etc.. etc.. more coming I'm sure. My opinion of this is that it = only serves to complicate the introduction of a more complete and = possibly more optimal solution that might actually have been designed = to meet all of the requirements.

So, while I don't think the work on MIPv6 should be = abandoned, it may be prudent to at least start something in the IRTF to = take a more greenfield look at the solution set.

This would perhaps at least let the MIPv6 WG continue = on its current charted course while allowing a more accepting and open = exploration of these other concepts.

I don't mean to offend MIP supporters or the people = with other ideas. I just think that such a new research group would = help out both parties in both the short and long term. This might also = be a healthy thing for IPv6 and the IETF as a whole. Perhaps the = namespace IRTF group is already set up to explore these other = concepts.

I sincerely hope this helps both parties.

Glenn

------_=_NextPart_001_01C1DAD0.83148F60-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 03:36:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27225 for ; Wed, 3 Apr 2002 03:36:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25966; Wed, 3 Apr 2002 01:36:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27881; Wed, 3 Apr 2002 00:34:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g338XsKL006959 for ; Wed, 3 Apr 2002 00:33:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g338XrZO006958 for mobile-ip-dist; Wed, 3 Apr 2002 00:33:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g338XnKL006951 for ; Wed, 3 Apr 2002 00:33:50 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g338Xhx26672; Wed, 3 Apr 2002 10:33:43 +0200 (MEST) Date: Wed, 3 Apr 2002 10:33:25 +0200 (CEST) From: Erik Nordmark Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16 To: "Hesham Soliman (ERA)" Cc: "'James Kempf'" , Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Rajeev Koodli In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053802C6ABEF@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => I think that it ultimately comes down to the > basis of the trust between the MN and the > old AR. Authenticating HI and HAck between > the old and new ARs does not necessarily mean > that the MN is not trying to bomb the new network > does it ? > > But everyone seems to assume that it is enough > so what am I missing? When oldAR lets the MN get service from the domain it is exposing the domain to traffic related to this MN - e.g. the MN could decide to send or receive useless traffic just to create load. But the domain can limit this "damage" by the link bandwith the MN is using, and perhaps have ways of allocating cost based on usage (e.g. usage based billing). The fact that this ability to consume resources can be transferred between oldAR and newAR doesn't really add a new threat as far as I can tell - oldAR and newAR trust eachother and there is a way to prevent others to fake such transfers. Hmm - if the link bandwith at oldAR and newAR is X, can a misbehaving MN use up 2X of resources by pretenting to move to newAR (consuming resources at newAR by bombing) while in fact remaining at oldAR using the resources. Could a malicious MN use this to pretend to be at more than 2 CoAs? (oldAR, newAR1, newAR2, etc even though it has never left oldAR?) Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 04:26:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27901 for ; Wed, 3 Apr 2002 04:26:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14042; Wed, 3 Apr 2002 02:26:05 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26049; Wed, 3 Apr 2002 01:25:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g339P4KL007155 for ; Wed, 3 Apr 2002 01:25:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g339P4xl007154 for mobile-ip-dist; Wed, 3 Apr 2002 01:25:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g339OwKL007147 for ; Wed, 3 Apr 2002 01:24:58 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04158 for ; Wed, 3 Apr 2002 01:25:01 -0800 (PST) Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA23210 for ; Wed, 3 Apr 2002 01:24:59 -0800 (PST) Received: (qmail 7364 invoked by uid 0); 3 Apr 2002 09:24:59 -0000 Date: Wed, 3 Apr 2002 11:24:59 +0200 (MEST) From: Jens Kuehlberg To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Subject: [mobile-ip] Routing Header - New MIPv6 draft X-Priority: 3 (Normal) X-Authenticated-Sender: #0012344765@gmx.net X-Authenticated-IP: [192.35.17.10] Message-ID: <5063.1017825899@www9.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hallo, I have read the new MIPv6-Draft. Section 5.4 defined the new Routing Header Type 2. 5.4. Routing Header type 2 Mobile IPv6 uses a routing header to carry the Home Address for packets sent from a correspondent node to a mobile node, which the Care of Address of the MN is carried in the IPv6 destination field. This uses a different routing header type than what is defined for ``regular'' IPv6 source routing to make it possible for e.g., firewalls to have different rules for source routing versus MIPv6. This routing header type (type 2) is restricted to only carry one IPv6 address and all IPv6 nodes which process it MUST verify that the address contained in the routing header is the home address of the node in order to prevent packets with this routing header type to be forwarded after decrementing the segments left field. Section 8.9 describe "Sending Packets to a Mobile Node" from the CN In this Section Routing Header (Type 0) are used for the Packets. My Question: When MIP should use the Routing Header (Type 0) and when should use Type 2? Thanks in advance Bye Jens -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 04:45:22 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28047 for ; Wed, 3 Apr 2002 04:45:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25525; Wed, 3 Apr 2002 01:45:02 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29678; Wed, 3 Apr 2002 01:44:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g339i6KL007240 for ; Wed, 3 Apr 2002 01:44:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g339i6CQ007239 for mobile-ip-dist; Wed, 3 Apr 2002 01:44:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g339i2KL007232 for ; Wed, 3 Apr 2002 01:44:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06568 for ; Wed, 3 Apr 2002 01:44:05 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03306 for ; Wed, 3 Apr 2002 02:44:04 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g339i33G001190 for ; Wed, 3 Apr 2002 11:44:03 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Apr 03 11:41:49 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 11:33:31 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABF6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] LIN6 vs mobile-ipv6? Date: Wed, 3 Apr 2002 11:43:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g339i3KL007233 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > I think that LIN6 is mainly for people who want some of the > features of Mobile IPv6, but who got tired of waiting for us > to be finished with it. => It is more like 'people who want to solve the problem differently'. ´LIN6 was presented in San Diego, and was done way before that. So I don't think it was a result of the delays of MIPv6. It basically moves the binding update > to be a nameserver operation instead of a Mobile IP operation, > and I think it doesn't offer any advantages other than just > moving the necessary components to other parts of the > protocol stack. I believe applications have to be rewritten > to handle a new nameserver record type, and smooth handover > is not really possible. Binding updates are not delivered to > correspondent nodes. => Fully agree. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 05:55:46 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29116 for ; Wed, 3 Apr 2002 05:55:45 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11931; Wed, 3 Apr 2002 03:55:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14135; Wed, 3 Apr 2002 02:54:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33ArhKL007397 for ; Wed, 3 Apr 2002 02:53:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33ArgOf007396 for mobile-ip-dist; Wed, 3 Apr 2002 02:53:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33ArdKL007389 for ; Wed, 3 Apr 2002 02:53:39 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13974 for ; Wed, 3 Apr 2002 02:53:43 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11418 for ; Wed, 3 Apr 2002 02:53:42 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id DAA05385 for ; Wed, 3 Apr 2002 03:53:41 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id DAA26183 for ; Wed, 3 Apr 2002 03:53:41 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g33Arcg21990 for ; Wed, 3 Apr 2002 04:53: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 668D42EC86 for ; Wed, 3 Apr 2002 12:53:36 +0200 (CEST) To: Subject: Re: [mobile-ip] LIN6 vs mobile-ipv6? References: <933FADF5E673D411B8A30002A5608A0E02EC64AA@zrc2c012.us.nortel.com> From: Alexandru Petrescu Date: 03 Apr 2002 12:53:36 +0200 In-Reply-To: <933FADF5E673D411B8A30002A5608A0E02EC64AA@zrc2c012.us.nortel.com> Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: "Glenn Morrow" writes: [...] > I know of: > > 8+8/GES, IIP, LAR, LIN6, MBG, Application, Dynamic DNS, HIP variants > intermingled with each, others, sorry if I didn't mention one, etc.. Hi, don't want to interfere too much here and I fully agree with your fine argumentation about potential interactions with research (IRTF). Just wanted to agree that doing mobility within a TCP/IP framework is a very vast framework ranging from what routing protocols can do to what overlaying tunneling can offer and to what directory services can do (classifying is difficult). I'm maintaining a bibliography on this and there are about 340 entries, and there are no RFC nor I-D's in it. What's 8+8/GES, what's LAR, what's MBG? Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 06:23:32 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29546 for ; Wed, 3 Apr 2002 06:23:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20269; Wed, 3 Apr 2002 04:23:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22895; Wed, 3 Apr 2002 03:23:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33BMJKL007546 for ; Wed, 3 Apr 2002 03:22:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33BMJrM007545 for mobile-ip-dist; Wed, 3 Apr 2002 03:22:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33BMFKL007538 for ; Wed, 3 Apr 2002 03:22:15 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16513 for ; Wed, 3 Apr 2002 03:22:18 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12031 for ; Wed, 3 Apr 2002 03:21:54 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g33BMF3G025885 for ; Wed, 3 Apr 2002 13:22:15 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g33BMEUD005143 for ; Wed, 3 Apr 2002 14:22:15 +0300 (EET DST) Message-ID: <3CAAE5E6.44B1C2E8@lmf.ericsson.se> Date: Wed, 03 Apr 2002 14:22:14 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing Header - New MIPv6 draft References: <5063.1017825899@www9.gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jens Kuehlberg wrote: > Section 8.9 describe "Sending Packets to a Mobile Node" from the CN > > In this Section Routing Header (Type 0) are used for the Packets. This is incorrect. Should be Type 2 even in section 8.9. Thanks for pointing this out. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 07:57:16 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01471 for ; Wed, 3 Apr 2002 07:57:16 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07715; Wed, 3 Apr 2002 05:56:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27068; Wed, 3 Apr 2002 04:56:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33CtvKL007794 for ; Wed, 3 Apr 2002 04:55:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33CtvMs007793 for mobile-ip-dist; Wed, 3 Apr 2002 04:55:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33CtqKL007786 for ; Wed, 3 Apr 2002 04:55:53 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g33Ctqx15458; Wed, 3 Apr 2002 14:55:52 +0200 (MEST) Date: Wed, 3 Apr 2002 14:55:33 +0200 (CEST) From: Erik Nordmark Subject: RE: [mobile-ip] Comments on Draft 16 To: mohanp@tahoenetworks.com Cc: mobile-ip@sunroof.eng.sun.com, hesham.soliman@era.ericsson.se, jari.arkko@piuha.net, Glenn Morrow In-Reply-To: "Your message with ID" <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A5@TNEXVS02.tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > So the mipv6 draft does not mandate that the reverse tunnel > from MN to HA be Ipsec protected. It is only the HA to MN > tunnel that is Ipsec protected. Could you clarify ? It is only the HoT message that MUST/SHOULD be protected by ESP to prevent attackers between the HA and MN from being able to spoof BUs. I think the way to make this fit with IPsec selectors in RFC 2401 is to make all packets whose terminal payload is the MH protocol be subject to ESP in both directions. But that doesn't require data packets (TCP, UDP, whatever) to be IPsec protected. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 07:57:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01495 for ; Wed, 3 Apr 2002 07:57:27 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09375; Wed, 3 Apr 2002 05:57:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27100; Wed, 3 Apr 2002 04:56:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33CtpKL007784 for ; Wed, 3 Apr 2002 04:55:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33CtpsQ007783 for mobile-ip-dist; Wed, 3 Apr 2002 04:55:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33CtlKL007776 for ; Wed, 3 Apr 2002 04:55:48 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g33Ctlx15454; Wed, 3 Apr 2002 14:55:48 +0200 (MEST) Date: Wed, 3 Apr 2002 14:55:28 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Routing Header - New MIPv6 draft To: jens_kue@gmx.de Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5063.1017825899@www9.gmx.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Section 8.9 describe "Sending Packets to a Mobile Node" from the CN > > In this Section Routing Header (Type 0) are used for the Packets. That is an editorial bug in the current version of the draft. > My Question: > When MIP should use the Routing Header (Type 0) and when should use Type 2? It should always use type 2. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 07:57:51 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01536 for ; Wed, 3 Apr 2002 07:57:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08041; Wed, 3 Apr 2002 05:57:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27225; Wed, 3 Apr 2002 04:57:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33CuiKL007818 for ; Wed, 3 Apr 2002 04:56:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33Cuimq007817 for mobile-ip-dist; Wed, 3 Apr 2002 04:56:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33CueKL007810 for ; Wed, 3 Apr 2002 04:56:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10900 for ; Wed, 3 Apr 2002 04:56:43 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06435 for ; Wed, 3 Apr 2002 04:56:20 -0800 (PST) Received: from mobinet (mobinet.u-strasbg.fr [130.79.90.159]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id OAA29640; Wed, 3 Apr 2002 14:56:41 +0200 From: "Thomas Noel" To: Cc: "'Alexandru Petrescu'" Subject: RE : [mobile-ip] LIN6 vs mobile-ipv6? Date: Wed, 3 Apr 2002 14:56:46 +0200 Message-ID: <000601c1db0f$0312a330$9f5a4f82@mobinet> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Alex >what's LAR, what's MBG? LAR (Logical Addressing and Routing layer) integrates in a native way, both point-to-point and multicast communications for mobile hosts. We implemented it with IPv6 and its extension headers. We have an Internet Draft (expired) draft-pansiot-logical-addressing-01.txt and several research reports. I can send them to you if you want. Regards -------------------------------------------------------- Thomas Noel LSIIT Louis Pasteur University From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 08:18:14 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02317 for ; Wed, 3 Apr 2002 08:18:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01738; Wed, 3 Apr 2002 06:17:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00048; Wed, 3 Apr 2002 05:17:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33DGcKL008047 for ; Wed, 3 Apr 2002 05:16:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33DGce9008046 for mobile-ip-dist; Wed, 3 Apr 2002 05:16:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33DGZKL008039 for ; Wed, 3 Apr 2002 05:16:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01253 for ; Wed, 3 Apr 2002 05:16:38 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01311 for ; Wed, 3 Apr 2002 06:16:38 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id GAA19246 for ; Wed, 3 Apr 2002 06:16:17 -0700 (MST)] Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA13939 for ; Wed, 3 Apr 2002 06:16:16 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/8.11.6) with ESMTP id g33DFkX26309 for ; Wed, 3 Apr 2002 07:15:47 -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 ED1E32EC86 for ; Wed, 3 Apr 2002 15:15:44 +0200 (CEST) To: Subject: Re: RE : [mobile-ip] LIN6 vs mobile-ipv6? References: <000601c1db0f$0312a330$9f5a4f82@mobinet> From: Alexandru Petrescu Date: 03 Apr 2002 15:15:44 +0200 In-Reply-To: <000601c1db0f$0312a330$9f5a4f82@mobinet> Message-ID: Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: "Thomas Noel" writes: > Hi Alex > > >what's LAR, what's MBG? > > LAR (Logical Addressing and Routing layer) integrates in a native way, > both point-to-point and multicast communications for mobile hosts. We > implemented it with IPv6 and its extension headers. > > We have an Internet Draft (expired) > draft-pansiot-logical-addressing-01.txt and several research reports. I > can send them to you if you want. Yes please send references and the tech reps themselves (I need to know who published it, e.g. your University). I won't need the I-D, it won't be there as long as the tech reps. Thanks, Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 08:37:53 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02819 for ; Wed, 3 Apr 2002 08:37:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24443; Wed, 3 Apr 2002 06:37:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02668; Wed, 3 Apr 2002 05:37:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33DaWKL008191 for ; Wed, 3 Apr 2002 05:36:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33DaWFa008190 for mobile-ip-dist; Wed, 3 Apr 2002 05:36:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33DaTKL008183 for ; Wed, 3 Apr 2002 05:36:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14977 for ; Wed, 3 Apr 2002 05:36:32 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24061 for ; Wed, 3 Apr 2002 06:36:32 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id GAA00687 for ; Wed, 3 Apr 2002 06:36:30 -0700 (MST)] Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA17478 for ; Wed, 3 Apr 2002 06:36:28 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (8.11.6/8.11.6) with ESMTP id g33DaPd21168 for ; Wed, 3 Apr 2002 07:36: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 111C32EC86 for ; Wed, 3 Apr 2002 15:36:23 +0200 (CEST) To: Subject: [mobile-ip] The Reply-To header of this list References: <000601c1db0f$0312a330$9f5a4f82@mobinet> From: Alexandru Petrescu Date: 03 Apr 2002 15:36:23 +0200 In-Reply-To: Message-ID: Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Could anyone please fix the Reply-To of this list? I suggest to either remove the Reply-To header or make it point to the original poster; but in any case _not_ to the list. Or is there a specific intention to keep the Reply-To as is? Thank you in advance, Alex (after several follow-up mistakes) From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 09:03:58 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03518 for ; Wed, 3 Apr 2002 09:03:57 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06309; Wed, 3 Apr 2002 07:03:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07477; Wed, 3 Apr 2002 06:03:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33E2PKL008348 for ; Wed, 3 Apr 2002 06:02:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33E2PMY008347 for mobile-ip-dist; Wed, 3 Apr 2002 06:02:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33E2MKL008340 for ; Wed, 3 Apr 2002 06:02:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19841 for ; Wed, 3 Apr 2002 06:02:25 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16507 for ; Wed, 3 Apr 2002 07:02:23 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g33E2Ns7025996 for ; Wed, 3 Apr 2002 16:02:23 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 03 16:02:16 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 16:03:58 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABF9@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com, Rajeev Koodli Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16 Date: Wed, 3 Apr 2002 16:02:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => I think that it ultimately comes down to the > > basis of the trust between the MN and the > > old AR. Authenticating HI and HAck between > > the old and new ARs does not necessarily mean > > that the MN is not trying to bomb the new network > > does it ? > > > > But everyone seems to assume that it is enough > > so what am I missing? > > When oldAR lets the MN get service from the domain > it is exposing the domain to traffic related to this MN - > e.g. the MN > could decide to send or receive useless traffic just to create load. > But the domain can limit this "damage" by the link bandwith > the MN is > using, and perhaps have ways of allocating cost based on > usage (e.g. usage > based billing). => That's possible. But so far we've been making very few assumptions, if any, about the 'supporting' functions in the network or other components that can give useful hints. For instance, the link might be a multiaccess link where it might be a challenge to limit BW consumption per node. > > The fact that this ability to consume resources can be > transferred between > oldAR and newAR doesn't really add a new threat as far as I > can tell - > oldAR and newAR trust eachother and there is a way to > prevent others to > fake such transfers. => But the transfer is based on some information received from the MN. So while the 2 ARs trust each other, the MN might have fooled the first AR. So unless preventing the MN from fooling the first AR is within the context of MIP signalling, the ultimate security level will depend on the circumstances in each network and the nature of links ...etc. This is unlike the security level in the base spec, which makes very little assumption about the operation environment. > > Hmm - if the link bandwith at oldAR and newAR is X, can a > misbehaving > MN use up 2X of resources by pretenting to move to newAR > (consuming resources > at newAR by bombing) while in fact remaining at oldAR using > the resources. => That's exactly on of my concern. > Could a malicious MN use this to pretend to be at more than > 2 CoAs? (oldAR, > newAR1, newAR2, etc even though it has never left oldAR?) => Yep! In fact, if we take a couple of steps back and look at the fact that a MN can not do bombing attacks when a BU is sent e2e to a CN, having the AR as a temp HA might open up the door for malicious nodes to get around the restrictions in the basic spec by letting the AR do the forwarding instead of the CN and getting away without the CoA test. I admit though, I need to look into this in a lot more detail, so if I'm on a tangent someone please let me know :) Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 11:16:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07819 for ; Wed, 3 Apr 2002 11:16:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26561; Wed, 3 Apr 2002 09:16:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01314; Wed, 3 Apr 2002 08:15:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33GEeKL008684 for ; Wed, 3 Apr 2002 08:14:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33GEeDu008683 for mobile-ip-dist; Wed, 3 Apr 2002 08:14:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33GEbKL008676 for ; Wed, 3 Apr 2002 08:14:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29116 for ; Wed, 3 Apr 2002 08:14:40 -0800 (PST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25808 for ; Wed, 3 Apr 2002 09:14:39 -0700 (MST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g33GEbZ10239; Wed, 3 Apr 2002 11:14:37 -0500 (EST) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA21228; Wed, 3 Apr 2002 10:14:37 -0600 (CST) Received: (from mccap@localhost) by nwsgpc.ih.lucent.com (8.11.6+Sun/8.11.6) id g33GEaA24111; Wed, 3 Apr 2002 10:14:36 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15531.10860.835983.144219@nwsgpc.ih.lucent.com> Date: Wed, 3 Apr 2002 10:14:36 -0600 (CST) From: Pete McCann To: mobile-ip@sunroof.eng.sun.com Cc: "'kleung'" , "'Charlie Perkins'" , "Kent Nickell", "Kuntal Chowdhury" Subject: RE: [mobile-ip] RE: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCB4E@zrc2c013.us.nortel.com> References: <6B49EDFE974BD51197D70002A56079D801AFCB4E@zrc2c013.us.nortel.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Kent Leung writes: > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be > copied into the Home Agent field of the Registration Reply. > Otherwise, the home agent MUST set the Home Agent field in the > Registration Reply to its unicast address. In this latter > case, the Home Agent MUST reject the request with a suitable > code (e.g., Code 136) unless the destination IP address of the > Registation Request is an unicast address. In this case, the > Home Agent MAY accept the Registration Request. This will > prevent the mobile node from possibly being simultaneously > registered with two or more home agents. Ahmad Muhanna writes: > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be > copied into the Home Agent field of the Registration Reply. > Otherwise, the home agent MUST set the Home Agent field in the > Registration Reply to its unicast address. In this latter case, > the home agent MUST reject the registration with a suitable code > (e.g., Code 136) to prevent the mobile node from possibly being > simultaneously registered with two or more home agents. However, > if the destination IP address of the Registration Request is > the unicast IP address of this Home Agent, the Home Agent MAY > accept the Registration Request. I think it is important to at least apply Ahmad's restriction that the IP destination address of the RRQ belongs to the HA, so I would go along with this text. Question for the group: is this enough to prevent simultaneous registration with two or more home agents? The original logic of rejecting the request if the HA field didn't match a unicast address was definitely stronger than this. Was there a reason for that? -Pete From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 11:55:39 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08971 for ; Wed, 3 Apr 2002 11:55:39 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09109; Wed, 3 Apr 2002 09:55:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14078; Wed, 3 Apr 2002 08:55:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33GsRKL008866 for ; Wed, 3 Apr 2002 08:54:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33GsROL008865 for mobile-ip-dist; Wed, 3 Apr 2002 08:54:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33GsNKL008858 for ; Wed, 3 Apr 2002 08:54:23 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12162 for ; Wed, 3 Apr 2002 08:54:27 -0800 (PST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21859 for ; Wed, 3 Apr 2002 08:54:04 -0800 (PST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g33GsQ613695; Wed, 3 Apr 2002 10:54:26 -0600 (CST) Message-ID: <3CAB33C1.70700@alcatel.com> Date: Wed, 03 Apr 2002 10:54:25 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: seamoby@ietf.org, stefano.faccin@nokia.com Subject: [mobile-ip] New mailing list for ip-paging work References: <3CA39DBD.6040300@alcatel.com> <3CAA097D.4000300@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear all, Hopefully this is going to be the last announcement mail, sorry if you receive multiple copies: The mailing list for ip-paging work has moved to: ip-paging@tpd.usa.alcatel.com We subscribed everybody on the previous list to the new list. This new list is a majordomo administered list so you can get there (new members) by sending an email to majordomo@tpd.usa.alcatel.com with your request, i.e subsribe ip-paging your email If you have questions let us know. Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 12:01:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09153 for ; Wed, 3 Apr 2002 12:01:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12025; Wed, 3 Apr 2002 10:00:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15764; Wed, 3 Apr 2002 09:00:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33H05KL008954 for ; Wed, 3 Apr 2002 09:00:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33H05Y4008953 for mobile-ip-dist; Wed, 3 Apr 2002 09:00:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33H01KL008943 for ; Wed, 3 Apr 2002 09:00:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14433 for ; Wed, 3 Apr 2002 09:00:01 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19353 for ; Wed, 3 Apr 2002 10:00:00 -0700 (MST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g33GxVl11998; Wed, 3 Apr 2002 08:59:31 -0800 (PST) Received: from cisco.com (sjc-vpn1-1112.cisco.com [10.21.100.88]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACH58313; Wed, 3 Apr 2002 08:59:15 -0800 (PST) Message-ID: <3CAB34FE.D4CB8BF2@cisco.com> Date: Wed, 03 Apr 2002 08:59:42 -0800 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "'Charlie Perkins'" , Kent Nickell , Kuntal Chowdhury Subject: Re: [mobile-ip] RE: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation" References: <6B49EDFE974BD51197D70002A56079D801AFCB4E@zrc2c013.us.nortel.com> <15531.10860.835983.144219@nwsgpc.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pete McCann wrote: > > > > If the Home Agent field in the Registration Request contains a > > unicast address of this home agent, then that field MUST be > > copied into the Home Agent field of the Registration Reply. > > Otherwise, the home agent MUST set the Home Agent field in the > > Registration Reply to its unicast address. In this latter case, > > the home agent MUST reject the registration with a suitable code > > (e.g., Code 136) to prevent the mobile node from possibly being > > simultaneously registered with two or more home agents. However, > > if the destination IP address of the Registration Request is > > the unicast IP address of this Home Agent, the Home Agent MAY > > accept the Registration Request. > > I think it is important to at least apply Ahmad's restriction that the > IP destination address of the RRQ belongs to the HA, so I would go > along with this text. Agreed. > Question for the group: is this enough to > prevent simultaneous registration with two or more home agents? Using a unicast destination IP address in the Registration Request with non-unicast HA address field is already being used in implementations. This scheme should not result in multiple HAs being registered since mobility entity directing the Registration Request via a unicast destination IP address either knows or was told which specific HA is anchoring the MN. > The > original logic of rejecting the request if the HA field didn't match a > unicast address was definitely stronger than this. Was there a reason > for that? > I think the original focus was subnet directed broadcast scheme. This translated to subnet directed broadcast destination IP address, which meant that multiple HAs will receive the same Registration Request. And it made more sense for each HA to reject so MN can select one from the subnet. Now, folks have gotten shrewder with schemes that select the HA via the unicast destination IP address. At that point, it seems senseless to reject the request which creates 2 trips needlessly. Kent From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 12:22:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09727 for ; Wed, 3 Apr 2002 12:22:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24372; Wed, 3 Apr 2002 10:22:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24741; Wed, 3 Apr 2002 09:22:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HL8KL009080 for ; Wed, 3 Apr 2002 09:21:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33HL8Wi009079 for mobile-ip-dist; Wed, 3 Apr 2002 09:21:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HL6KL009072 for ; Wed, 3 Apr 2002 09:21:07 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20720 for ; Wed, 3 Apr 2002 12:21:10 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA24217 for mobile-ip@sunroof.eng.sun.com; Wed, 3 Apr 2002 12:22:05 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g335lbKL006727 for ; Tue, 2 Apr 2002 21:47:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05206 for ; Tue, 2 Apr 2002 21:47:40 -0800 (PST) Received: from tera.ics.keio.ac.jp (tera-relay.tera.ics.keio.ac.jp [131.113.126.176] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA03276 for ; Tue, 2 Apr 2002 22:47:39 -0700 (MST) Received: (qmail 49493 invoked from network); 3 Apr 2002 14:49:23 -0000 Received: from unknown (HELO hotaka.tera.ics.keio.ac.jp) (203.178.139.42) by softdnserror with SMTP; 3 Apr 2002 14:49:23 -0000 Message-Id: <5.0.2.7.2.20020403144335.03c6fbd0@pop.tera.ics.keio.ac.jp> X-Sender: tera@pop.tera.ics.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Wed, 03 Apr 2002 14:47:03 +0900 To: mobile-ip@sunroof.eng.sun.com From: Fumio Teraoka Subject: Re: [mobile-ip] LIN6 vs mobile-ipv6? In-Reply-To: <3CAA81E7.EED80C70@iprg.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, Charlie, LIN6 is based on a different architecture than that of MIP, i.e., separation of node ID and node locator. LIN6 has several advantages against MIPv6. For example: 1) LIN6 has no header overhead while MIPv6 uses large extension headers for every packet. 2) LIN6 is more fault tolerant than MIPv6. In MIPv6, the HA is the single point of failure and the HA cannot be replicated to the subnet other than the home network. In LIN6, the Mapping Agent can be replicated to anywhere. No modifications are necessary to applications, name servers, resolvers, and TCP/UDP for LIN6. LIN6 is running on several UNIX operating systems and Win2k. Source code is available from http://www.lin6.net/ Smooth handoff is already implemented to LIN6 although there is no i-d of smooth handoff in LIN6. Fumio Teraoka At 02/04/02 20:15 -0800, Charlie Perkins wrote: >Hello, > >I think that LIN6 is mainly for people who want some of the >features of Mobile IPv6, but who got tired of waiting for us >to be finished with it. It basically moves the binding update >to be a nameserver operation instead of a Mobile IP operation, >and I think it doesn't offer any advantages other than just >moving the necessary components to other parts of the >protocol stack. I believe applications have to be rewritten >to handle a new nameserver record type, and smooth handover >is not really possible. Binding updates are not delivered to >correspondent nodes. > >If I have some of the details wrong, please excuse, but this >is my impression of it. > >Regards, >Charlie P. > > > >Wang Hui wrote: > >> Hi, folks here, >> >> I found that WIDE project has been doing a protocol (called LIN6) to >> support "mobility" for IPv6. >> >> As they claim that LIN6 provides mobility to IPv6 without impact on the >> existing IPv6 infrastructure and maintains compatibility with traditional IPv6. >> >> So what do you think of LIN6? >> >> Here is the web site for LIN6: >> http://www.lin6.net/ >> >> Best, >> Wang Hui From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 12:25:12 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09820 for ; Wed, 3 Apr 2002 12:25:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14271; Wed, 3 Apr 2002 09:24:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25799; Wed, 3 Apr 2002 09:24:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HOEKL009224 for ; Wed, 3 Apr 2002 09:24:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33HOE7n009223 for mobile-ip-dist; Wed, 3 Apr 2002 09:24:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HOAKL009213 for ; Wed, 3 Apr 2002 09:24:10 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22703 for ; Wed, 3 Apr 2002 09:24:14 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01519 for ; Wed, 3 Apr 2002 09:24:13 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33HO9e04126; Wed, 3 Apr 2002 11:24:10 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 11:24:11 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB5B@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'kleung'" , "'Charlie Perkins'" , "Kent Nickell", "Kuntal Chowdhury" Subject: RE: [mobile-ip] RE: RFC3220 and possible forward compatibility is sue "Dynamic Home Agent Allocation" Date: Wed, 3 Apr 2002 11:24:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB34.5DB43CC0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB34.5DB43CC0 Content-Type: text/plain; charset="iso-8859-1" Hello, > > > Hi, > > Kent Leung writes: > > > If the Home Agent field in the Registration Request contains a > > unicast address of this home agent, then that field MUST be > > copied into the Home Agent field of the Registration Reply. > > Otherwise, the home agent MUST set the Home Agent field in the > > Registration Reply to its unicast address. In this latter > > case, the Home Agent MUST reject the request with a suitable > > code (e.g., Code 136) unless the destination IP address of the > > Registation Request is an unicast address. In this case, the > > Home Agent MAY accept the Registration Request. This will > > prevent the mobile node from possibly being simultaneously > > registered with two or more home agents. > > > Ahmad Muhanna writes: > > > If the Home Agent field in the Registration Request contains a > > unicast address of this home agent, then that field MUST be > > copied into the Home Agent field of the Registration Reply. > > Otherwise, the home agent MUST set the Home Agent field in the > > Registration Reply to its unicast address. In this latter case, > > the home agent MUST reject the registration with a suitable code > > (e.g., Code 136) to prevent the mobile node from possibly being > > simultaneously registered with two or more home agents. However, > > if the destination IP address of the Registration Request is > > the unicast IP address of this Home Agent, the Home Agent MAY > > accept the Registration Request. > > I think it is important to at least apply Ahmad's restriction that the > IP destination address of the RRQ belongs to the HA, so I would go > along with this text. Question for the group: is this enough to > prevent simultaneous registration with two or more home agents? The > original logic of rejecting the request if the HA field didn't match a > unicast address was definitely stronger than this. Was there a reason > for that? > > -Pete > The original scenario depends on preventing simultaneous registration by using a two round trip initial Registration. The objective of these two trips as all of us know are as follows: First Round Trip: It addresses the issue of identifying a Dynamically located HA IP address for the Mobile Node to use and prevents simultaneous registration. Second Round Trip: It is the regular initial Registration the Mobile Node usually does to establish a Mobile IP call. Now: with the availability of other Helping infrastructure to the Mobility agents (Diameter, RADIUS), it becomes ineffective and expensive to use two round trips for establishing a Mobile IP call. Therefore, I believe that the First Round Trip of the initial Registration MUST be handled all together BY the helping infrastructure. In other words, (DIAMETER, or RADIUS) Dynamically allocate an HA and prevent simultaneous registration. ------_=_NextPart_001_01C1DB34.5DB43CC0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RE: RFC3220 and possible forward compatibility issue "Dynamic Home Agent Allocation"

Hello,
>
>
> Hi,
>
> Kent Leung writes:
>
>  >    If the Home Agent field in the Registration Request contains a
>  >    unicast address of this home agent, then that field MUST be
>  >    copied into the Home Agent field of the Registration Reply.
>  >    Otherwise, the home agent MUST set the Home Agent field in the
>  >    Registration Reply to its unicast address.  In this latter
>  >    case, the Home Agent MUST reject the request with a suitable
>  >    code (e.g., Code 136) unless the destination IP address of the
>  >    Registation Request is an unicast address.  In this case, the
>  >    Home Agent MAY accept the Registration Request.  This will
>  >    prevent the mobile node from possibly being simultaneously
>  >    registered with two or more home agents.
>
>
> Ahmad Muhanna writes:
>
>  >   If the Home Agent field in the Registration Request contains a
>  >   unicast address of this home agent, then that field MUST be
>  >   copied into the Home Agent field of the Registration Reply.
>  >   Otherwise, the home agent MUST set the Home Agent field in the
>  >   Registration Reply to its unicast address.  In this latter case,
>  >   the home agent MUST reject the registration with a suitable code
>  >   (e.g., Code 136) to prevent the mobile node from possibly being
>  >   simultaneously registered with two or more home agents. However,
>  >   if the destination IP address of the Registration Request is
>  >   the unicast IP address of this Home Agent, the Home Agent MAY
>  >   accept the Registration Request.
>
> I think it is important to at least apply Ahmad's restriction that the
> IP destination address of the RRQ belongs to the HA, so I would go
> along with this text.  Question for the group: is this enough to
> prevent simultaneous registration with two or more home agents?  The
> original logic of rejecting the request if the HA field didn't match a
> unicast address was definitely stronger than this.  Was there a reason
> for that?
>
> -Pete
>

The original scenario depends on preventing simultaneous registration by
using a two round trip initial Registration. The objective of these two trips
as all of us know are as follows:

First Round Trip:
It addresses the issue of identifying a Dynamically located HA IP address for the Mobile Node to use
and prevents simultaneous registration.

Second Round Trip:
It is the regular initial Registration the Mobile Node usually does to establish
a Mobile IP call.

Now: with the availability of other Helping infrastructure to the Mobility agents
(Diameter, RADIUS), it becomes ineffective and expensive to use
two round trips for establishing a Mobile IP call.

Therefore, I believe that the First Round Trip of the initial Registration MUST be handled
all together BY the helping infrastructure.
In other words, (DIAMETER, or RADIUS) Dynamically allocate an HA and prevent
simultaneous registration.

------_=_NextPart_001_01C1DB34.5DB43CC0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 12:28:40 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09947 for ; Wed, 3 Apr 2002 12:28:40 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23544; Wed, 3 Apr 2002 10:28:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27101; Wed, 3 Apr 2002 09:28:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HRiKL009329 for ; Wed, 3 Apr 2002 09:27:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33HRiIv009328 for mobile-ip-dist; Wed, 3 Apr 2002 09:27:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HRgKL009321 for ; Wed, 3 Apr 2002 09:27:42 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22726 for ; Wed, 3 Apr 2002 12:27:45 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA24233 for mobile-ip@sunroof.eng.sun.com; Wed, 3 Apr 2002 12:28:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g335pLKL006738 for ; Tue, 2 Apr 2002 21:51:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11793 for ; Tue, 2 Apr 2002 21:51:24 -0800 (PST) Received: from tera.ics.keio.ac.jp (tera-relay.tera.ics.keio.ac.jp [131.113.126.176] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA04381 for ; Tue, 2 Apr 2002 22:51:23 -0700 (MST) Received: (qmail 49524 invoked from network); 3 Apr 2002 14:53:09 -0000 Received: from unknown (HELO hotaka.tera.ics.keio.ac.jp) (203.178.139.42) by softdnserror with SMTP; 3 Apr 2002 14:53:09 -0000 Message-Id: <5.0.2.7.2.20020403144926.03f02240@pop.tera.ics.keio.ac.jp> X-Sender: tera@pop.tera.ics.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Wed, 03 Apr 2002 14:51:08 +0900 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Fumio Teraoka Subject: Re: [mobile-ip] LIN6 vs mobile-ipv6? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Section 8 of draft-teraoka-ipng-lin6-01.txt says: We really intend to contribute to development of the Internet community and to keep a good relationship with IETF. And our primary concern is to promote our technology so that others may feel it is useful and worthwhile in the spirit of the IETF. If indeed the mechanisms are granted as patents, the patents will be licensed under reasonable and non-discriminatory conditions to any person who wants to implement the mechanisms. Fumio Teraoka At 02/04/03 08:09 +0300, Pekka Savola wrote: >On Wed, 3 Apr 2002, Wang Hui wrote: >> So what do you think of LIN6? > >LIN6 has IPR. 'nuff said. Even if it was any good, it isn't really worth >checking out. > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 12:42:53 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10330 for ; Wed, 3 Apr 2002 12:42:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00912; Wed, 3 Apr 2002 10:42:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27950; Wed, 3 Apr 2002 09:42:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HfUKL009539 for ; Wed, 3 Apr 2002 09:41:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33HfU2L009538 for mobile-ip-dist; Wed, 3 Apr 2002 09:41:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HfSKL009531 for ; Wed, 3 Apr 2002 09:41:28 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26575 for ; Wed, 3 Apr 2002 12:41:32 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA24299 for mobile-ip@sunroof.eng.sun.com; Wed, 3 Apr 2002 12:42:26 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33CjSKL007761 for ; Wed, 3 Apr 2002 04:45:28 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27650 for ; Wed, 3 Apr 2002 04:45:31 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06956 for ; Wed, 3 Apr 2002 04:45:29 -0800 (PST) Received: from mobinet (mobinet.u-strasbg.fr [130.79.90.159]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id OAA29515 for ; Wed, 3 Apr 2002 14:45:29 +0200 From: "Thomas Noel" To: Subject: RE : [mobile-ip] LIN6 vs mobile-ipv6? Date: Wed, 3 Apr 2002 14:45:33 +0200 Message-ID: <000101c1db0d$72310ec0$9f5a4f82@mobinet> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Alex >what's LAR, what's MBG? LAR (Logical Addressing and Routing layer) integrates in a native way, both point-to-point and multicast communications for mobile hosts. We implemented it with IPv6 and its extension headers. We have an Internet Draft (expired) draft-pansiot-logical-addressing-01.txt and several research reports. I can send them to you if you want. Regards -------------------------------------------------------- Thomas Noel LSIIT Louis Pasteur University From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 12:50:46 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10596 for ; Wed, 3 Apr 2002 12:50:45 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16154; Wed, 3 Apr 2002 10:50:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01381; Wed, 3 Apr 2002 09:50:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HnVKL009724 for ; Wed, 3 Apr 2002 09:49:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33HnUsQ009723 for mobile-ip-dist; Wed, 3 Apr 2002 09:49:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33HnTKL009716 for ; Wed, 3 Apr 2002 09:49:29 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29055 for ; Wed, 3 Apr 2002 12:49:32 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA24309 for mobile-ip@sunroof.eng.sun.com; Wed, 3 Apr 2002 12:50:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33GPiKL008801 for ; Wed, 3 Apr 2002 08:25:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02407 for ; Wed, 3 Apr 2002 08:25:47 -0800 (PST) Received: from smtp13.singnet.com.sg (smtp13.singnet.com.sg [165.21.6.33]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19171 for ; Wed, 3 Apr 2002 09:25:45 -0700 (MST) Received: from homepilakkat (bb-203-125-211-124.singnet.com.sg [203.125.211.124]) by smtp13.singnet.com.sg (8.12.2/8.12.2) with SMTP id g33GPgT7002936 for ; Thu, 4 Apr 2002 00:25:42 +0800 Message-ID: <002901c1db2c$2df74bb0$7cd37dcb@homepilakkat> From: "Santhosh K. Pilakkat" To: References: <4DA6EA82906FD511BE2F00508BCF053802C6ABD9@Esealnt861.al.sw.ericsson.se> <00cd01c1da66$29083e50$7e6015ac@T23KEMPF> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 4 Apr 2002 00:25:28 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C1DB6F.39031280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C1DB6F.39031280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just noticed this thread of discussion. Not sure everybody is on the same page about the 802.11 ESS (Extended Service Set), that is 802.11 systems that have more than one Access Points but all have the same SSID (network name). 802.11 calls the interconnecting medium as DS (Distributtion System), which consists of the Access Points, the interconnecting medium and a Portal. 802.11 specifies only the functions of these elements and hence IP or any other protocol can be used to inter-connect the entities and deos not matter whether there are routers/subnets or not as long as frames can be transported between the end points (e.g. encapsulated in UDP). In ESS all AP's does not bridge the ethernet frames from the Stations to the IP network, instead only the Portal bridges them. That is the entire ESS (all stations attached to all APs of ESS) appears to be on the IP subnet to which the portal is attached. In the case where IP is used to inter-connect APs (the normal case), the IP addresses of APs are used only to forward the ethernet packets (porbably as UDP packets) from AP to portal, which sends it out. (Or if the destination is another Wireless STA in the same ESS, to the AP to which it is associated). The result is that: 1. The entire ESS appears to be on the same IP subnet (the subnet to which the portal is connected), even if the AP's are connected to different subnets. 2. 802.11 takes care of mobility between AP's of same ESS. As long as the Old and New AP's belong to the same ESS, the IP address of Wireless Station remains the same. That is from Mobile IP point of view, the station has not moved. 3. Reassociation may not be useful as a trigger as in this case the Station is attaching to another AP of same ESS. To the IP network it has not moved. 4. The only point when the IP point of attachement for a Station changes is when the managment entity finds that current AP signal is weak and after scanniing finds that there are no other AP's of same ESS that it can attach to. In this case the device needs to either attach to any other ESS or get disconnected. If it is going to disconnect the trigger is not useful. AFAIK the current drivers does not successfully log on to the new ESS (at least LINUX, not sure of MS), as this needs triggerring of DHCP to get and configure the new IP address. Even if this can be implemented, the station is going to get the ESSID and MAC address of the target AP, where as what we need is the IP address of the Access Router to which the Portal is connected. One of the reason for confusion I believe is that most initial deployments of WLANs used IBSS mode which was intended for adhoc networks, where each AP does bridging. And moving from AP to AP infact means movement of Mobile Node. In this case however there is no relation between APs and IAPP etc. does not apply. In conclusion: Mobility between APs of same ESS is handled by the 802.11 transparent to the IP layer, even when the APs are physically connected to different IP subnets. If there is a latency issue, then only 802.11 can address it. The mobility and latency to be addressed by Mobile IP is when stations are moving from one ESS to another. [Wasn't following the list closely of late. May be some of the above may be out of context or plane inaccurate and sorry for the long mail. But hope the above is helpful.] Regards Santhosh ----- Original Message ----- From: "James Kempf" To: Sent: Wednesday, April 03, 2002 12:48 AM Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > => I think there is something missing in our > > communication. I didn't think IAPP will run > > between subnets, is this correct? If yes, then > > this is something for IEEE to work out. > > Like all other L2 designers, they will do their > > best to minimise their L2's handover time. > > > > Yes, IAPP will run between subnets. That is why they use IP rather than > 802 for it. That is also why we are concerned about it. > > The underlying problem is that the architecture on which the 802.11 > committee is basing their design does not include routers. They have a > notion of an ESS (Extended Service System, I think) but it has no notion > of IP subnets. > > jak > > > > ------=_NextPart_000_0022_01C1DB6F.39031280 Content-Type: application/pdf; name="802.11 Fast Handoff2.pdf.pdf" Content-Disposition: attachment; filename="802.11 Fast Handoff2.pdf.pdf" Content-Transfer-Encoding: base64 ------=_NextPart_000_0022_01C1DB6F.39031280-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 13:06:39 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11067 for ; Wed, 3 Apr 2002 13:06:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25015; Wed, 3 Apr 2002 11:06:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06184; Wed, 3 Apr 2002 10:06:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33I1KKL009927 for ; Wed, 3 Apr 2002 10:01:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33I1Kr9009926 for mobile-ip-dist; Wed, 3 Apr 2002 10:01:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33I1FKL009919 for ; Wed, 3 Apr 2002 10:01:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09653 for ; Wed, 3 Apr 2002 10:01:19 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23777 for ; Wed, 3 Apr 2002 11:01:18 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7C0846A905; Wed, 3 Apr 2002 21:01:11 +0300 (EEST) Message-ID: <3CAB35BC.3030304@kolumbus.fi> Date: Wed, 03 Apr 2002 20:02:52 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: uri@bell-labs.com, ipsec@lists.tislabs.com, marcovici@lucent.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <15530.22026.752100.186019@thomasm-u1.cisco.com> <200204030446.XAA13831@nwmail.wh.lucent.com> <3CAB122B.8000505@kolumbus.fi> <15531.10727.959342.461589@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > I honestly don't see why MIP needs to go beyond > saying "use IPsec, beware manual keys". > ... > In any case, my larger point here is that a > mandatory mechanism for MIP which requires per > node consumption of NVRAM on a Home Agent as a > MUST IMPLEMENT, where IKE, JFK, KINK, etc don't > place any such requirements on IPsec seems > onerous, and should be optional. Ideally, it > would be one of a set of acceptible choices. You may have a point here. How about this: 1. We require at least manual IPsec 2. We provide application layer sequence# in order to order BUs (not just prevent replay) 3. We point out that if the HA reboots and loses state when only manually keyed IPsec is used, replays become possible (vendors can still prevent losing state if they want to) Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 13:14:40 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11272 for ; Wed, 3 Apr 2002 13:14:40 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24706; Wed, 3 Apr 2002 10:14:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08706; Wed, 3 Apr 2002 10:14:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33IDHKL010022 for ; Wed, 3 Apr 2002 10:13:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33IDGbE010021 for mobile-ip-dist; Wed, 3 Apr 2002 10:13:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33IDDKL010014 for ; Wed, 3 Apr 2002 10:13:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08423 for ; Wed, 3 Apr 2002 10:13:17 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17955 for ; Wed, 3 Apr 2002 11:13:02 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33ICwe03229 for ; Wed, 3 Apr 2002 12:12:58 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 12:13:00 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02F246E8@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LIN6 vs mobile-ipv6? Date: Wed, 3 Apr 2002 12:12:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB3B.2FF8C330" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB3B.2FF8C330 Content-Type: text/plain; charset="iso-8859-1" Alex, I meant GSE. Global, Site and End-System Designator (GSE). Sorry I always seem to do this typo. You've already got the answer to LAR. MBG is mobile border gateway. It uses the home agent as the database. > > What's 8+8/GES, what's LAR, what's MBG? ------_=_NextPart_001_01C1DB3B.2FF8C330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] LIN6 vs mobile-ipv6?

Alex,

I meant GSE. Global, Site and End-System Designator = (GSE). Sorry  I always seem to do this typo. You've already got = the answer to LAR.

MBG is mobile border gateway. It uses the home agent = as the database.

>
> What's 8+8/GES, what's LAR, what's MBG?



------_=_NextPart_001_01C1DB3B.2FF8C330-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 13:33:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11697 for ; Wed, 3 Apr 2002 13:33:34 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04892; Wed, 3 Apr 2002 11:33:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13986; Wed, 3 Apr 2002 10:32:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33IVLKL010140 for ; Wed, 3 Apr 2002 10:31:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33IVLIp010139 for mobile-ip-dist; Wed, 3 Apr 2002 10:31:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33IVHKL010132 for ; Wed, 3 Apr 2002 10:31:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21370 for ; Wed, 3 Apr 2002 10:31:19 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03992 for ; Wed, 3 Apr 2002 11:31:19 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 13:31:13 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCA0@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'jari.arkko@piuha.net'" , "'PRoberts@MEGISTO.com'" , "'Basavaraj.Patil@nokia.com'" Subject: RE: [mobile-ip] Reverse tunneling issues Date: Wed, 3 Apr 2002 13:31:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Gabriel, The whole thing is covered. The statement of course complies with RFC2026 etc etc Regards George -----Original Message----- From: gabriel montenegro [mailto:gab@sun.com] Sent: Tuesday, April 02, 2002 10:33 AM To: mobile-ip@sunroof.eng.sun.com Cc: 'jari.arkko@piuha.net'; 'PRoberts@MEGISTO.com'; 'Basavaraj.Patil@nokia.com' Subject: Re: [mobile-ip] Reverse tunneling issues George, Your draft talks about IPR on your proposal. Could you clarify how much (if not all) is covered, etc? -gabriel From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 14:08:35 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12510 for ; Wed, 3 Apr 2002 14:08:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06399; Wed, 3 Apr 2002 11:08:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05787; Wed, 3 Apr 2002 11:08:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33J7JKL010274 for ; Wed, 3 Apr 2002 11:07:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33J7JbK010273 for mobile-ip-dist; Wed, 3 Apr 2002 11:07:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33J7FKL010266 for ; Wed, 3 Apr 2002 11:07:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24268 for ; Wed, 3 Apr 2002 11:07:17 -0800 (PST) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05419 for ; Wed, 3 Apr 2002 11:07:17 -0800 (PST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 53C855D66; Wed, 3 Apr 2002 11:14:14 -0800 (PST) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 2DA86163B; Wed, 3 Apr 2002 14:07:15 -0500 (EST) Received: from compaq.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id OAA0000575256; Wed, 3 Apr 2002 14:07:14 -0500 (EST) Message-ID: <3CAB52E2.863A512F@compaq.com> Date: Wed, 03 Apr 2002 14:07:14 -0500 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: erik.nordmark@Sun.COM Subject: Re: [mobile-ip] Comments on Draft 16 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > Stable storage at the HA for the seqno can presumably be a SHOULD, with > the ability to "lock in" on the first sequence number is receives from > a MN after rebooting. So how many MN/Seqno pairs does the HA need to store? Seems like the number could be quite large for HAs with lots of MNs (10K), which can be unwieldy, since they can never be removed once created or we open a hole. And every time the HA reboots it must re-load them from storage into some data structure - yuck! This looks more unattractive every time I think about it. So is there a better way to solve this problem? For manually keyed SAs between a HA<->MN we could define a new sub-option that carries a timestamp (like seconds since Mobile IPv6 became an RFC :), and the HA rejects BUs with the timestamp out of a certain range. Of course this would require synchronization, but most MNs should know what time it is... -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 14:17:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12694 for ; Wed, 3 Apr 2002 14:16:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22245; Wed, 3 Apr 2002 12:15:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07979; Wed, 3 Apr 2002 11:15:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33JERKL010392 for ; Wed, 3 Apr 2002 11:14:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33JER0u010391 for mobile-ip-dist; Wed, 3 Apr 2002 11:14:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33JEOKL010384 for ; Wed, 3 Apr 2002 11:14:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25994 for ; Wed, 3 Apr 2002 11:14:26 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27251 for ; Wed, 3 Apr 2002 12:14:26 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33JEMe02972 for ; Wed, 3 Apr 2002 13:14:22 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 13:14:24 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02F2481A@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Comments on Draft 16 Date: Wed, 3 Apr 2002 13:14:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB43.C3659230" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB43.C3659230 Content-Type: text/plain; charset="iso-8859-1" This noncesense is very much appreciated today :). I think you might be on to something here. > > So is there a better way to solve this problem? For manually > keyed SAs between > a HA<->MN we could define a new sub-option that carries a > timestamp (like > seconds since Mobile IPv6 became an RFC :), and the HA > rejects BUs with the > timestamp out of a certain range. Of course this would > require synchronization, > > but most MNs should know what time it is... > > -Brian > > ------_=_NextPart_001_01C1DB43.C3659230 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Comments on Draft 16

This noncesense is very much appreciated today :). I think you might be on to something here.

>
> So is there a better way to solve this problem?  For manually
> keyed SAs between
> a HA<->MN we could define a new sub-option that carries a
> timestamp (like
> seconds since Mobile IPv6 became an RFC :), and the HA
> rejects BUs with the
> timestamp out of a certain range.  Of course this would
> require synchronization,
>
> but most MNs should know what time it is...
>
> -Brian
>
>

------_=_NextPart_001_01C1DB43.C3659230-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 15:00:07 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14116 for ; Wed, 3 Apr 2002 15:00:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17077; Wed, 3 Apr 2002 11:59:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01583; Wed, 3 Apr 2002 11:59:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33JwfKL010606 for ; Wed, 3 Apr 2002 11:58:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33JwfnW010605 for mobile-ip-dist; Wed, 3 Apr 2002 11:58:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33JwbKL010598 for ; Wed, 3 Apr 2002 11:58:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07067 for ; Wed, 3 Apr 2002 11:58:40 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17507 for ; Wed, 3 Apr 2002 12:58:40 -0700 (MST) 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 LAA09319; Wed, 3 Apr 2002 11:58:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33JwdY29253; Wed, 3 Apr 2002 11:58:39 -0800 X-mProtect: <200204031958> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd90H18r; Wed, 03 Apr 2002 11:58:38 PST Message-ID: <3CAB5EEE.5952072B@iprg.nokia.com> Date: Wed, 03 Apr 2002 11:58:38 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: "Hesham Soliman (ERA)" , "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > => I think that it ultimately comes down to the > > basis of the trust between the MN and the > > old AR. Authenticating HI and HAck between > > the old and new ARs does not necessarily mean > > that the MN is not trying to bomb the new network > > does it ? > > > > But everyone seems to assume that it is enough > > so what am I missing? > > When oldAR lets the MN get service from the domain > it is exposing the domain to traffic related to this MN - e.g. the MN > could decide to send or receive useless traffic just to create load. > But the domain can limit this "damage" by the link bandwith the MN is > using, and perhaps have ways of allocating cost based on usage (e.g. usage > based billing). > I agree. How an AR does traffic conditioning is dependent on local constraints. > > The fact that this ability to consume resources can be transferred between > oldAR and newAR doesn't really add a new threat as far as I can tell - > oldAR and newAR trust eachother and there is a way to prevent others to > fake such transfers. To be more specific, - oldAR has means to trust CoA-1 - old AR trusts new AR, hence trusts CoA-2 > > > Hmm - if the link bandwith at oldAR and newAR is X, can a misbehaving > MN use up 2X of resources by pretenting to move to newAR (consuming resources > at newAR by bombing) while in fact remaining at oldAR using the resources. > Could a malicious MN use this to pretend to be at more than 2 CoAs? (oldAR, > newAR1, newAR2, etc even though it has never left oldAR?) > I don't think so. Until the MN actually announces its attachment to new AR (via Neighbor Advertisement), the new AR only has a proxy ND cache entry corresponding to CoA-2. So, if a bogus MN sends a BU authorizing old AR to redirect traffic to new AR, nobody other than the new AR sees those packets. Furthermore, since the new AR has a very small buffer corresponding to ND cache (1 or two packets), the MN cannot "bomb" new AR either. Also note that the new AR does not send any Neighbor Solicitation (since it is proxying CoA-2) when packets arrive; so I don't see any issue with wasting link bandwidth either. The same reasoning holds holds for multiple CoAs with the observation that the MN has to figure out multiple AR prefixes in order to configure multiple CoAs in the first place. Regards, -Rajeev > > Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 15:18:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14571 for ; Wed, 3 Apr 2002 15:18:27 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26953; Wed, 3 Apr 2002 13:18:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06510; Wed, 3 Apr 2002 12:17:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33KGwKL010748 for ; Wed, 3 Apr 2002 12:16:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33KGwik010747 for mobile-ip-dist; Wed, 3 Apr 2002 12:16:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33KGtKL010740 for ; Wed, 3 Apr 2002 12:16:55 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06213 for ; Wed, 3 Apr 2002 12:16:58 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29666 for ; Wed, 3 Apr 2002 12:16:35 -0800 (PST) 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 MAA10761; Wed, 3 Apr 2002 12:16:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33KGsR18414; Wed, 3 Apr 2002 12:16:54 -0800 X-mProtect: <200204032016> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQjljo2; Wed, 03 Apr 2002 12:16:52 PST Message-ID: <3CAB6335.C1457D0A@iprg.nokia.com> Date: Wed, 03 Apr 2002 12:16:53 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "'Erik Nordmark'" , "Hesham Soliman (ERA)" , "'James Kempf'" Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6ABF9@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > > > When oldAR lets the MN get service from the domain > > it is exposing the domain to traffic related to this MN - > > e.g. the MN > > could decide to send or receive useless traffic just to create load. > > But the domain can limit this "damage" by the link bandwith > > the MN is > > using, and perhaps have ways of allocating cost based on > > usage (e.g. usage > > based billing). > > => That's possible. But so far we've been making very few > assumptions, if any, about the 'supporting' functions > in the network or other components that can give useful > hints. For instance, the link might be a multiaccess > link where it might be a challenge to limit BW > consumption per node. > [Rajeev:] I don't believe that with FMIPv6, there are additional assumptions in this sense. The issue is whether old AR has forwarded packets to/from CoA-1. The question of whether that MN is "real" or bogus is a separate identity proving issue. > > > > > The fact that this ability to consume resources can be > > transferred between > > oldAR and newAR doesn't really add a new threat as far as I > > can tell - > > oldAR and newAR trust eachother and there is a way to > > prevent others to > > fake such transfers. > > => But the transfer is based on some information > received from the MN. So while the 2 ARs trust > each other, the MN might have fooled the first > AR. So unless preventing the MN from fooling > the first AR is within the context of MIP > signalling, the ultimate security level will > depend on the circumstances in each network > and the nature of links ...etc. This is unlike > the security level in the base spec, which > makes very little assumption about the operation > environment. > [Rajeev:] Even if the MN could fool old AR to believe that it is going to new AR, there is no harm; the bad MN cannot bomb an innocent node on new AR nor can it be fictitiously present on the new link consuming resources. This is because packets sent to CoA-2 goto new AR's proxy ND cache, which is 1 or 2 packets big. > > > > > Hmm - if the link bandwith at oldAR and newAR is X, can a > > misbehaving > > MN use up 2X of resources by pretenting to move to newAR > > (consuming resources > > at newAR by bombing) while in fact remaining at oldAR using > > the resources. > > => That's exactly on of my concern. > [Rajeev:] This is not possible with FMIPv6. Packets only goto new AR's proxy ND cache. Besides, once FBU is sent, old AR does not forward packets to MN. I described this in some detail to Erik's message.. > > > Could a malicious MN use this to pretend to be at more than > > 2 CoAs? (oldAR, > > newAR1, newAR2, etc even though it has never left oldAR?) > > => Yep! In fact, if we take a couple of steps > back and look at the fact that a MN can not do > bombing attacks when a BU is sent e2e to a CN, > having the AR as a temp HA might open up the > door for malicious nodes to get around the restrictions > in the basic spec by letting the AR do the > forwarding instead of the CN and getting away > without the CoA test. > > I admit though, I need to look into this in a lot > more detail, so if I'm on a tangent someone please > let me know :) > [Rajeev:] As I mentioned in my reply to Erik's message, the reasoning (that packets can only go as far as new AR's proxy ND cache) holds good for multiple CoAs as well. In addition, the MN has to first obtain all the prospective prefixes. Furthermore, proxy ND cache has a lifetime within which the MN has to attach to _some_ AR and declare its presence. Hope this is useful.. Regards, -Rajeev > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 17:13:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17486 for ; Wed, 3 Apr 2002 17:13:28 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12822; Wed, 3 Apr 2002 14:13:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02519; Wed, 3 Apr 2002 14:13:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33MCOKL011142 for ; Wed, 3 Apr 2002 14:12:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33MCOcL011141 for mobile-ip-dist; Wed, 3 Apr 2002 14:12:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33MCLKL011134 for ; Wed, 3 Apr 2002 14:12:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02373 for ; Wed, 3 Apr 2002 14:12:24 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02374 for ; Wed, 3 Apr 2002 14:12:23 -0800 (PST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 17:12:20 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCA1@ftmail> From: George Tsirtsis To: mobile-ip@sunroof.eng.sun.com Cc: Scott Corson , Vincent Park , Matt Impett Subject: [mobile-ip] parameters in draft v16 Date: Wed, 3 Apr 2002 17:12:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-7" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: All, During a review of the MIPv6 draft v16 we noticed the following issue with the Parameters defined for various messages like BR and BU. The spec states that: "...The receiver [of a Parameter] MUST ignore and skip any parameters which it does not understand..." and this is repeated for every instance of the field "Parameter". Given the hope that MIPv6 will be with us for considerable time :-) we were wondering if something better can be done for future compatibility. The current spec only allows for skippable parameters. Wouldn't be useful to also allow for non-skippable parameters? Since "parameters" are TLVs, one could set aside 'Type' space for non-skippable parameters. If one of the non-skippable parameters is received but not recognized the receiver should send an error code indicating "unknown parameter". Is this something that has been considered before ...and maybe rejected? reasons? Thanks George (and Matt, Vince, Scott) From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 17:33:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17787 for ; Wed, 3 Apr 2002 17:33:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10746; Wed, 3 Apr 2002 15:32:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07293; Wed, 3 Apr 2002 14:32:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33MVtKL011263 for ; Wed, 3 Apr 2002 14:31:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33MVtqs011262 for mobile-ip-dist; Wed, 3 Apr 2002 14:31:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33MVqKL011255 for ; Wed, 3 Apr 2002 14:31:52 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13405 for ; Wed, 3 Apr 2002 14:31:55 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13019 for ; Wed, 3 Apr 2002 14:31:31 -0800 (PST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D74E56A905; Thu, 4 Apr 2002 01:31:47 +0300 (EEST) Message-ID: <3CAB7527.3030808@piuha.net> Date: Thu, 04 Apr 2002 00:33:27 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: Scott Corson , Vincent Park , Matt Impett Subject: Re: [mobile-ip] parameters in draft v16 References: <8C92E23A3E87FB479988285F9E22BE465ABCA1@ftmail> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George Tsirtsis wrote: > Given the hope that MIPv6 will be with us for considerable time :-) we were > wondering if something better can be done for future compatibility. The > current spec only allows for skippable parameters. Wouldn't be useful to > also allow for non-skippable parameters? Since "parameters" are TLVs, one > could set aside 'Type' space for non-skippable parameters. If one of the > non-skippable parameters is received but not recognized the receiver should > send an error code indicating "unknown parameter". Ah, the 'M' bit familiar to us from a number of other protocols ;-) It's possible. I'm not sure if it's worth it though. Exactly what will we lose if we don't have that possibility? On a related note, I have been wondering whether the flag field rules are correct. The receiver MUST ignore unknown flags. This might be fine on [HC]oT{,} if we assume that at that stage the peers learn about the capabilities of the other side, but what about the Binding Update? What if, say, a new algorithm needed to be implemented instead of SHA1, how can we ensure the other side uses it. At [HC]oT{,} stage, the peers would presumably learn that the other side supports this new algorithm, and then they would just use it on the BU, and set the corresponding bit. The other side would be sure to understand the bit since it set the bit itself earlier in another message. However, what about BUs to the home? Anyway, the 'M' bit approach for parameters has also some concerns, one of them being the possibility that vendors "lock in" peers to use the same vendors since a vendor-specific parameter would have the 'M' bit on. But perhaps this can be handled by the IETF not allocating any parameter type codes with the 'M' bit on without a very general purpose use. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 17:40:46 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17926 for ; Wed, 3 Apr 2002 17:40:45 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17965; Wed, 3 Apr 2002 14:40:32 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09294; Wed, 3 Apr 2002 14:40:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33MdiKL011352 for ; Wed, 3 Apr 2002 14:39:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33MdiGV011351 for mobile-ip-dist; Wed, 3 Apr 2002 14:39:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33MdfKL011344 for ; Wed, 3 Apr 2002 14:39:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15992 for ; Wed, 3 Apr 2002 14:39:44 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04670 for ; Wed, 3 Apr 2002 15:39:43 -0700 (MST) 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 OAA19981 for ; Wed, 3 Apr 2002 14:39:43 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33MdgD03971 for ; Wed, 3 Apr 2002 14:39:42 -0800 X-mProtect: <200204032239> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7TeA1l; Wed, 03 Apr 2002 14:39:40 PST Message-ID: <3CAB84AC.EA65291B@iprg.nokia.com> Date: Wed, 03 Apr 2002 14:39:40 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Luca, I wonder why it is more expensive for multicast advertisements than for unicast. For each challenge used by a mobile node (multicast or not), the foreign agent needs to keep track of the mobile node's IP address and that challenge value. What is different? If a mobile node erroneously tries to re-use a value that is still being multicast, then it would be rejected, right? Regards, Charlie P. Luca Salgarelli wrote: > Hi. > > I was wondering if anybody, e.g. at the last Connectathon, came across > the following. > > How would a Mobile-IP client react if a FA: > > - did NOT include challenges in broadcast agent advertisements AND > - did include challenges in unicast agent advertisements AND > - did include challenges in every registration reply. > > The reason I am asking this is that it seems to me very computationally > expensive at the FA to keep track of which client already used a > challenge included in a multicast advertisement. This is even more true > if the challenge window is more than 1. > > Including challenges only in unicast advertisements and registration > replies would make the protocol much lighter to implement. > > Any thoughts? > > Thanks > Luca From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 18:41:39 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19096 for ; Wed, 3 Apr 2002 18:41:39 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29317; Wed, 3 Apr 2002 15:41:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29453; Wed, 3 Apr 2002 15:41:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33NeHKL011593 for ; Wed, 3 Apr 2002 15:40:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33NeHBM011592 for mobile-ip-dist; Wed, 3 Apr 2002 15:40:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33NeEKL011585 for ; Wed, 3 Apr 2002 15:40:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05269 for ; Wed, 3 Apr 2002 15:40:17 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA01998 for ; Wed, 3 Apr 2002 15:39:54 -0800 (PST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Wed Apr 3 18:39:27 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g33Ndek73865 for ; Wed, 3 Apr 2002 18:39:41 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA04265 for ; Wed, 3 Apr 2002 18:39:40 -0500 (EST) Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3CAB84AC.EA65291B@iprg.nokia.com> References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 03 Apr 2002 18:39:40 -0500 Message-Id: <1017877180.24852.56.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Charlie. > For each challenge used by a mobile node (multicast or not), > the foreign agent needs to keep track of the mobile node's IP > address and that challenge value. What is different? If a > mobile node erroneously tries to re-use a value that is still > being multicast, then it would be rejected, right? Right. But then the question is: does the FA have to keep the list of used challenges for every client for the entire duration of their session, and check against that list every registration request? I hope not, right? If not, then how does the FA decide which challenge to delete and when from the per-client "used challenges list"? Unless I am missing something, this is the (very) expensive part of the procedure. If instead the FA sent challenges only in reg. replies and in unicast advertisements, then the check becomes very simple: a challenge from a client is valid only if it was either in the last unicast advertisement or in the last reg. reply. Implementation becomes trivial: the FA just has to keep two fields per client with the last two challenges issued to that client. Does this make sense? Luca From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 18:55:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19296 for ; Wed, 3 Apr 2002 18:55:05 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20762; Wed, 3 Apr 2002 16:54:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11042; Wed, 3 Apr 2002 15:54:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33NrwKL011741 for ; Wed, 3 Apr 2002 15:53:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33NrwGi011740 for mobile-ip-dist; Wed, 3 Apr 2002 15:53:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33NrtKL011733 for ; Wed, 3 Apr 2002 15:53:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10827 for ; Wed, 3 Apr 2002 15:53:58 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10027 for ; Wed, 3 Apr 2002 16:53:58 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 18:53:57 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCA2@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Scott Corson , Vincent Park , Matt Impett Subject: RE: [mobile-ip] parameters in draft v16 Date: Wed, 3 Apr 2002 18:53:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-7" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Wednesday, April 03, 2002 10:33 PM To: mobile-ip@sunroof.eng.sun.com Cc: Scott Corson; Vincent Park; Matt Impett Subject: Re: [mobile-ip] parameters in draft v16 George Tsirtsis wrote: > Given the hope that MIPv6 will be with us for considerable time :-) we were > wondering if something better can be done for future compatibility. The > current spec only allows for skippable parameters. Wouldn't be useful to > also allow for non-skippable parameters? Since "parameters" are TLVs, one > could set aside 'Type' space for non-skippable parameters. If one of the > non-skippable parameters is received but not recognized the receiver should > send an error code indicating "unknown parameter". Ah, the 'M' bit familiar to us from a number of other protocols ;-) It's possible. I'm not sure if it's worth it though. Exactly what will we lose if we don't have that possibility? GT> Well, we can think of something I am sure :-). But seriously the concern is about any type of future extension that will result in error if the receiver just ignores it and processes the rest of the packet. Without the 'M' bit, we will never have the option of creating such extensions. Are we prepared to make that call now? and why would we? ... Anyway, the 'M' bit approach for parameters has also some concerns, one of them being the possibility that vendors "lock in" peers to use the same vendors since a vendor-specific parameter would have the 'M' bit on. But perhaps this can be handled by the IETF not allocating any parameter type codes with the 'M' bit on without a very general purpose use. GT> And/Or maybe we place a requirement that only extensions that result in actual error, rather than inconvenience, are allowed to set the 'M' flag. George George From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 19:03:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19460 for ; Wed, 3 Apr 2002 19:03:25 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02387; Wed, 3 Apr 2002 14:24:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21918; Wed, 3 Apr 2002 13:24:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33LNaKL010899 for ; Wed, 3 Apr 2002 13:23:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g33LNa6h010898 for mobile-ip-dist; Wed, 3 Apr 2002 13:23:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g33LNXKL010891 for ; Wed, 3 Apr 2002 13:23:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26803 for ; Wed, 3 Apr 2002 13:23:37 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA01746 for ; Wed, 3 Apr 2002 14:23:36 -0700 (MST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Wed Apr 3 16:23:00 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g33LMYk63616 for ; Wed, 3 Apr 2002 16:22:34 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA28452 for ; Wed, 3 Apr 2002 16:22:33 -0500 (EST) Subject: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 03 Apr 2002 16:22:33 -0500 Message-Id: <1017868954.22420.36.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi. I was wondering if anybody, e.g. at the last Connectathon, came across the following. How would a Mobile-IP client react if a FA: - did NOT include challenges in broadcast agent advertisements AND - did include challenges in unicast agent advertisements AND - did include challenges in every registration reply. The reason I am asking this is that it seems to me very computationally expensive at the FA to keep track of which client already used a challenge included in a multicast advertisement. This is even more true if the challenge window is more than 1. Including challenges only in unicast advertisements and registration replies would make the protocol much lighter to implement. Any thoughts? Thanks Luca From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 19:29:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19871 for ; Wed, 3 Apr 2002 19:29:12 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22730; Wed, 3 Apr 2002 17:28:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11075; Wed, 3 Apr 2002 16:28:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g340RpKL011858 for ; Wed, 3 Apr 2002 16:27:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g340RoVI011857 for mobile-ip-dist; Wed, 3 Apr 2002 16:27:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g340RlKL011849 for ; Wed, 3 Apr 2002 16:27:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05223 for ; Wed, 3 Apr 2002 16:27:51 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06963 for ; Wed, 3 Apr 2002 17:27:50 -0700 (MST) Received: from docomocarl (dhcp104.docomolabs-usa.com [172.21.96.104]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g340RkI29868; Wed, 3 Apr 2002 16:27:47 -0800 (PST) Message-ID: <003e01c1db70$0d75f960$686015ac@docomocarl> From: "Carl Williams" To: Cc: "Aaron Falk" , "Scott Bradner" , "James Kempf" , "John Wroclawski" , "Allison Mankin" Subject: [mobile-ip] notes from L2 Triggers meeting Date: Wed, 3 Apr 2002 16:31:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C1DB2C.FE2A3EF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C1DB2C.FE2A3EF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable L2-Trigger unofficial meeting Tuesday, March 18th, 2002 IETF-53 Minneapolis, MN led by (& notes taken by) Aaron Falk and Carl Williams attendance: 56 people (beer courtesy of NTT DoCoMo) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Based on interest from folks engaged in manet, mobileip, and seamoby working groups, an unofficial meeting was held to discuss issues surrounding the triggers at layer 2 to communicate information to upper layers in a hosts protocol stack. Two drafts, one discussing the issues (draft-manyfolks-l2-mobilereq-01.txt) and another proposing an API (draft-guri-seamoby-paging-trigger-00.txt) had been previously submitted. The objective of the meeting was to discover if the scope should be more broad than the drafts proposed. This was accomplished by a somewhat unstructured discussion that touched on several topics including what information to express, how it is delivered, and some possible next steps. The conversation and some perceived conclusions are summarized below. WHAT TO EXPRESS Not a new problem, past experience likely useful: The need for communication about L2 state to L3 is not new. Routers = have been handling it, largely with proprietary means for years. Routers are = in fact the canonical customers for this function; they by definition = perform their principal L3 function based on L2 state info. Routing folks have learned a lot about how links lie about their state (e.g., links that = fail half-duplex). In fact, router manufacturers may have insight as to which metrics would = be of interest or possibly how to extend or abstract them if they are = willing to share the information. Getting input from people familiar with = routing would be valuable. Small set of common functions seen as useful: The most common need expressed for information to be revealed was a link up/down indicator. This might be extended to be a table containing reachability to multiple access points for technologies where that is possible. (There already exists an appropriate SNMP message but it appears to be largely unused.) Interaction with MobileIP: In mobileIP on a wireless link, an L3 handover may, but does not always, occur when the mobile node moves to a new access point. Link layer protocols provide more accurate, and possibly timelier, reachability information than L3 'hello' protocols. There is great benefit if a mobileIP L3 can learn that a handover is imminent, rather than waiting until after the old link is gone. Early warning may allow mobileIP to optimize the L3 hand-off process in a number of ways, such as triggering = an L3 early hand-off or moving context to the new router. Discussion about architectural principles and amount of revealed = information: It was suggested that it might be valuable to reveal *any* information = that might be of interest to any part of the host, e.g., bit error rate, or = link bandwidth. For example, a video codec (e.g., MPEG-4) might behave differently if it was aware of the bit error rate of the wireless link. This was widely thought to be a bad idea as it suggests an architecture which is not general - leading to applications that are too tightly = bound to specific link types or depend on the assumption that the 'difficult' = link is the one nearest the end host. The Internet layer, as the 'waist in = the protocol hourglass' insulates the application from the link layer. The question of what information ought to be passed up from L3 is separate = from what info L3 could usefully get from L2, and should be considered separately. Only a very limited, general set of parameters would be appropriate above L3 and defining appropriate parameters based on link characteristics is a very difficult task. Even adding a metric such as signal strength is difficult when link technologies are heterogeneous. Some other caveats that were suggested: Triggers should only enable performance enhancements and not be used for correct protocol operation. There's value in finding implicit rather than explicit mechanisms. Again: the focus should be firmly on L2/L3 communication, rather than enabling applications (or, presumably, transport) to interact directly with L2. Apps can fight with L3 if it's done wrong. Management applications considered a special case: In the context of the above discussion, management applications were = seen as a special case that might require greater access to link information than would normally be made available to normal applications (or even protocol stack internals). This is because the application is intentionally associated with the management of a specific L2 = technology. For example, 802.11 cards typically come with a management application = that reveals information about the card status, link status, and access point(s). This information is necessary to ensure the correct = functioning of the card and should not be considered an Internet network = application. HOW IS L2 INFORMATION DELIVERED Options for how to implement L2/3 communication include an API, a MIB, = or a protocol. Most of the applications discussed above do not require communication across the wire and so a protocol does not seem to be justified or appropriate. It's unclear whether an API or MIB is more appropriate. MIBs were considered by some as somewhat 'heavyweight' because accessing local information typically requires SNMP to localhost and implies ASN.1 marshaling that is not needed in this situation. This issue is particularly important to small memory and power-limited = wireless devices. Most participants agreed that the difficult task that needs to be done = is to determine the right set of metrics to abstract and capture them in a = common location. It was widely recognized that the question of MIB or API is really secondary to the question of what information should be passed between L2 and L3. In the IETF, that process is frequently captured in = a MIB. However, since the issue is really a matter of internal = communication within a host, it may not be necessary to standardize or even specify = the format or mechanism which is used to communicate across the L2/L3 = boundary. SOME NEXT STEPS Since the IETF doesn't develop link technologies, one output of an IETF effort might include an informational RFC on which information to export/reveal. This document will likely be of interest to other = standards bodies who standardize link technologies. (Some of these ideas have already been taken to IEEE 802.11. The IEEE is also working on related issues in the context of OAM.) This might be considered a natural = extension of the PILC working group document "Advice to Subnet Designers." The IESG will provide advice as to the next process steps. They could include doing the work in PILC, possibly requiring rechartering, holding a BoF, creating a new working group, or possibly just an individual RFC submission. For the moment, the discussion should take place on the PILC mail list. Subscription instructions are available through the working group charter page at http://www.ietf.org/html.charters/pilc-charter.html. Should the work take place in a seperate working group, naturally a new mailing list will be formed. --aaron (for aaron and carl) Postscript In the wireless directorate meeting (of chairs of wireless-related = working groups, it was suggested that besides advising link designers, we should also consider an advisory document to upper layers on how to handle L2 information. ------=_NextPart_000_003B_01C1DB2C.FE2A3EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
L2-Trigger unofficial = meeting

Tuesday, March=20 18th, 2002
IETF-53 Minneapolis, MN

led by (& notes taken=20 by)
Aaron Falk <falk@isi.edu>=20 and
Carl Williams <carlw@docomolabs-usa.com>=
attendance:=20 56 people

(beer courtesy of NTT=20 DoCoMo)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Based on interest from folks=20 engaged in manet, mobileip, and seamoby
working groups, an unofficial = meeting=20 was held to discuss issues
surrounding the triggers at layer 2 to = communicate=20 information to
upper layers in a hosts protocol stack.  Two = drafts, one=20 discussing
the issues (draft-manyfolks-l2-mobilereq-01.txt) and = another=20 proposing
an API (draft-guri-seamoby-paging-trigger-00.txt) had been=20 previously
submitted.  The objective of the meeting was to = discover if=20 the scope
should be more broad than the drafts proposed.  This = was=20 accomplished
by a somewhat unstructured discussion that touched on = several=20 topics
including what information to express, how it is delivered, = and=20 some
possible next steps.  The conversation and some perceived=20 conclusions
are summarized below.

WHAT TO EXPRESS

Not a = new=20 problem, past experience likely useful:

The need for = communication about=20 L2 state to L3 is not new.  Routers have
been handling it, = largely with=20 proprietary means for years.  Routers are in
fact the canonical=20 customers for this function; they by definition perform
their = principal L3=20 function based on L2 state info.  Routing folks have
learned a = lot about=20 how links lie about their state (e.g., links that=20 fail
half-duplex).

In fact, router manufacturers may have = insight as=20 to which metrics would be
of interest or possibly how to extend or = abstract=20 them if they are willing
to share the information.  Getting = input from=20 people familiar with routing
would be valuable.

Small set of = common=20 functions seen as useful:

The most common need expressed for = information=20 to be revealed was a
link up/down indicator.  This might be = extended to=20 be a table
containing reachability to multiple access points for=20 technologies
where that is possible.  (There already exists an=20 appropriate SNMP
message but it appears to be largely=20 unused.)

Interaction with MobileIP:

In mobileIP on a = wireless=20 link, an L3 handover may, but does not always,
occur when the mobile = node=20 moves to a new access point.  Link layer
protocols provide more=20 accurate, and possibly timelier, reachability
information than L3 = 'hello'=20 protocols.  There is great benefit if a
mobileIP L3 can learn = that a=20 handover is imminent, rather than waiting
until after the old link is = gone.  Early warning may allow mobileIP to
optimize the L3 = hand-off=20 process in a number of ways, such as triggering an
L3 early hand-off = or=20 moving context to the new router.

Discussion about architectural=20 principles and amount of revealed information:

It was suggested = that it=20 might be valuable to reveal *any* information that
might be of = interest to=20 any part of the host, e.g., bit error rate, or link
bandwidth.  = For=20 example, a video codec (e.g., MPEG-4) might behave
differently if it = was=20 aware of the bit error rate of the wireless link.
This was widely = thought to=20 be a bad idea as it suggests an architecture
which is not general - = leading=20 to applications that are too tightly bound to
specific link types or = depend=20 on the assumption that the 'difficult' link
is the one nearest the = end=20 host.  The Internet layer, as the 'waist in the
protocol = hourglass'=20 insulates the application from the link layer.  The
question of = what=20 information ought to be passed up from L3 is separate from
what info = L3 could=20 usefully get from L2, and should be considered
separately.  Only = a very=20 limited, general set of parameters would be
appropriate above L3 and = defining=20 appropriate parameters based on link
characteristics is a very = difficult=20 task.  Even adding a metric such as
signal strength is difficult = when=20 link technologies are heterogeneous.

Some other caveats that were = suggested: Triggers should only enable
performance enhancements and = not be=20 used for correct protocol
operation.  There's value in finding = implicit=20 rather than explicit
mechanisms.  Again: the focus should be = firmly on=20 L2/L3 communication,
rather than enabling applications (or, = presumably,=20 transport) to
interact directly with L2.  Apps can fight with L3 = if it's=20 done wrong.

Management applications considered a special = case:

In=20 the context of the above discussion, management applications were = seen
as a=20 special case that might require greater access to link = information
than would=20 normally be made available to normal applications (or even
protocol = stack=20 internals).  This is because the application is
intentionally = associated=20 with the management of a specific L2 technology.
For example, 802.11 = cards=20 typically come with a management application that
reveals information = about=20 the card status, link status, and access
point(s).  This = information is=20 necessary to ensure the correct functioning
of the card and should = not be=20 considered an Internet network application.

HOW IS L2 INFORMATION = DELIVERED

Options for how to implement L2/3 communication include = an API,=20 a MIB, or a
protocol.  Most of the applications discussed above = do not=20 require
communication across the wire and so a protocol does not seem = to=20 be
justified or appropriate.  It's unclear whether an API or MIB = is=20 more
appropriate.  MIBs were considered by some as somewhat=20 'heavyweight'
because accessing local information typically requires = SNMP to=20 localhost
and implies ASN.1 marshaling that is not needed in this=20 situation.  This
issue is particularly important to small memory = and=20 power-limited wireless
devices.

Most participants agreed that = the=20 difficult task that needs to be done is to
determine the right set of = metrics=20 to abstract and capture them in a common
location.  It was = widely=20 recognized that the question of MIB or API is
really secondary to the = question of what information should be passed
between L2 and = L3.  In the=20 IETF, that process is frequently captured in a
MIB. However, since = the issue=20 is really a matter of internal communication
within a host, it may = not be=20 necessary to standardize or even specify the
format or mechanism = which is=20 used to communicate across the L2/L3 boundary.

SOME NEXT=20 STEPS

Since the IETF doesn't develop link technologies, one = output of an=20 IETF
effort might include an informational RFC on which information=20 to
export/reveal.  This document will likely be of interest to = other=20 standards
bodies who standardize link technologies.  (Some of = these=20 ideas have
already been taken to IEEE 802.11.  The IEEE is also = working=20 on related
issues in the context of OAM.) This might be considered a = natural=20 extension
of the PILC working group document "Advice to Subnet=20 Designers."

The IESG will provide advice as to the next process=20 steps.  They could
include doing the work in PILC, possibly = requiring=20 rechartering,
holding a BoF, creating a new working group, or = possibly just=20 an
individual RFC submission.  For the moment, the discussion = should=20 take
place on the PILC mail list.  Subscription instructions are = available
through the working group charter page at
http://www.i= etf.org/html.charters/pilc-charter.html. =20 Should the work
take place in a seperate working group, naturally a = new=20 mailing list
will be formed.

--aaron (for aaron and=20 carl)

Postscript

In the wireless directorate meeting (of = chairs of=20 wireless-related working
groups, it was suggested that besides = advising link=20 designers, we should
also consider an advisory document to upper = layers on=20 how to handle L2
information.

------=_NextPart_000_003B_01C1DB2C.FE2A3EF0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 19:58:03 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20305 for ; Wed, 3 Apr 2002 19:58:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11498; Wed, 3 Apr 2002 16:57:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18479; Wed, 3 Apr 2002 16:57:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g340unKL012013 for ; Wed, 3 Apr 2002 16:56:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g340unIF012012 for mobile-ip-dist; Wed, 3 Apr 2002 16:56:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g340ukKL012005 for ; Wed, 3 Apr 2002 16:56:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18315 for ; Wed, 3 Apr 2002 16:56:50 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05386 for ; Wed, 3 Apr 2002 17:56:49 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id <2FW6NMZ5>; Wed, 3 Apr 2002 19:54:37 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] minutes from Minneapolis Date: Wed, 3 Apr 2002 19:54:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thanks to George Tsirtsis again for recording the minutes: IP Routing for Wireless/Mobile Hosts WG (mobileip) Tuesday, March 19 at 0900-1130 =============================== CHAIR: Basavaraj Patil, Phil Roberts Minute Taker: George Tsirtsis 1. Agenda Bashing, Basavaraj Document status Discussion about FMIPv4/v6. There is no progress at the moment. There was some interoperability test for FMIPv6 2. Registration Revocation in MobileIP The speaker solicits interest for the draft. Some private discussion has taken place but not much in the public domain. Show of hands for support of this work was requested. Someone from 3GPP2 stated that this is one way of doing this but there are other ways too. A few people showed interest so the work will go ahead 3. Connectathlon Update, Samita -Mobile Ipv6 draft version 15. 10 participants No major problems were reported 3 implementations had support for authentication sub-option, no other security mechanism was tested Two Questions: How useful is the "refresh" field in BAck? Should this be dropped? Charlie: Suggest we make it an option since this is not always needed -FMIPv6 Handoff 2 implementations A number of issues will be sent to the mailing list by Alper Y. -MIPv4 6 implementations RFC3024 was implementated ut all missed the LPAS feature No major issues 4. Mobile IPv6 Discussion Phil R talked about MIPv6 security progress the last few months 4.1 MIPv6 Design Team - Jari Draft was sent to mailing list a couple of days ago -Pre16.txt is the actual spec, pre16.pdf describes the changes Draft version 17 will also be needed. Main changes are in section 4.4 and 5.1 There are now 5 messages needed but only 1.5 RTTs, 2 messages sent via two paths at the same time Hesham: is it still worth making BUAck mandatory? Jari: the issue will be taken into account Charlie: We need to specify how long does the MN need to wait for the messages coming back Francis: Verified/non-verified terminology should be used Charlie: Mobility Header should be called Next Header Type Erik: This may confuse because this is a terminal header for MIPv6. There is need for some text in the spec to clarify Vijay: Shouldn't the Home Address in BU is a parameter rather than fixed? Jari: maybe this is a good idea, take it off-line Jari: Discussion about retransmission strategies is needed Discussion about the nature of the security association between MN and CN. Francis: You need R-bit in the BU Erik & others: this is taken out in earlier spec Jari: Take it offline Hesham: To protect the CN from DoS attacks the CN runs in stateless mode. Isn't the MN vulnerable to the same attacks? The CN could be the bad guy Jari: Someone needs to remember something and the MN benefiots mostly from this Hesham: Yes but it is still a problem Erik: So what is the concern? Hesham: The CN can create state in the MN just by sending Binding Requests Jari: Very little you can do about this Erik: MNs could have intelligence to only do RO with CNs that make sense to do so Hesham: Some text about this would be useful. James: Have you done a stady on what the impact would be to create statefull CNs and stateless MNs as opposed to the other way around?? Someone: this is also allowed by the specs Charlie: Draft 16 is interim.no one should implement this. Draft 17 will be the real one Jari and Chairs: YES! Charlie: Are we really considering using IPSEC as the sole MN-CN BU auth mechanism? This is too heavy! Hesham: This maybe used instead of HoA test Jari: Maybe 4.2 Currently Open Issues in MIPv6 Base Spec Erik N for the Design Team -Many Editorial Issues -Max Binding Lifetimes should be defined (5min?) -State Tables for CN, MN -Better Terminology for "RR Procedure" COT/COTI/HOT/HOTI -Better names for message types Charlie: Need to make sure we allow static security configuration for special cases Thomas: Are you asking for the spec to say that the Bus can be secured by mechanisms outside this doc? Charlie: we should say which bytes MUST be protected but the way this is done should not be restricted. In the IETF we define ONE way of securing the Bus but this should not be presented as the only one. Someone: Agrees with Charlie More Open Issues: -Bit Method to prevent bidding down attacks Malinen: wants this method to be in a different RFC. There could be other methods of expressing the fact that you do not want to do RR. Lets get a few ways and pick one. Phil: This is a complex issue, There are arguments that this is needed in base spec Pekka H: when we do Security engineering as opposed to normal protocol specification we specify that we MUST NOT do something. This has to be in base spec. It is not possibly to put in different document something that prevents something in the Base spec from happening. Thomas: the Base spec needs to have code here so that all nodes supported otherwise it can never be used Bob H: Are you suggesting the bit will say do not do RR but will not say what to do instead. Isn't this an attack itself? Erik: Now all will do RR but when a new mechanism people will be able to use it. This is only for your own communication and does not affect others Bob H: Concerns about the idea to reserve bits in interface ID of the Ipv6 address space. Addresses are defined as global/local/unicast/mcast etc.This is a peculiar use of this and in the future we could have other ideas that need the same.This may not be a good path to take Malinen: There is need for this but the bit idea may not be the only one.Unclear at this stage Raj: Is it not possible to deprecate RR altogether in the future? Erik: You can not do that because it will have to be done in all nodes, all Internet Malinen: the same was done with going from MD5 to HMAC in MIPv4 Erik: Yes but that does not affect CNs! The IPv6 WG will discuss reserving bits for this in ther Ipv6 WG meeting in Thursday. We need to make the usage case in MIPv6 Issue: How and whether to authenticate the BA and BR Should we add a nonce in BU which will be returned by BA/BR? Is this enough? Vijay: For the BUAck you can use the same key you have for the BU. BR is different. Hesham: It is not different because the CN can only send a BR after a BU has been received Issue: Whether to authenticate to BM? The BM can be spoofed by off-path attackers, which would cause some more work but no ill effects Issue: Should HAO be used in the Home Registration or not? Issue: How to secure home registrations, use ESP or AH? Someone: If you use ESP how are you going to secure the CoA? Vijay: You need to repeate the CoA in the BU itself, can not rely on the source address of the packet Erik: Yes, that is right. Issue: Is it useful to have an SPI field in the packet It is not needed for RR but maybe could be added as an option by future mechanisms Charlie: We need to allow manual and other mechanisms but the SPI could be an option Issues will be sent to the mailing list for further discussion 5. LMM Requirements, Carl draft-ietf-mobileip-lmm-requirements-01.txt Suggestion to move on the requirements document to last call. Carl: Jari has one possibly new Security requirement James: We need one solution on this. Phil: Jari please post security requirements to the list. Also everyone check how the MIPv6 discussion affects this. 6. MIP/VPN Issues, Phil draft-adrangi-mobileip-nat-vpn-problem-stat-req-00.txt eFarid on VPN traversal for MIP Phil: Is this a problem the WG wants to solve? GeorgeT: The Work are needs to consider the larger picture i.e.: HA inside and outside of the firewall. Someone: This is definatelly an issue and needs to be resolved. Bob H: This is waist of WGs time. By the time this is really a problem you should be solving it with Ipv6 GeorgeT: This is also a problem for MIPv6 Someone: But then you do not have the NAT issue Phil: George should propose extended scope for the work the list maybe split between NAT and Firewall traversal. 7. NAT/NAPT Traversal, Henrik draft-ietf-mobileip-nat-traversal-00.txt Someone: There is at least one backwards compatibility issue Henrik: Yes we know about this and we can consider it. Phil: We will issue last call after the IETF 8. MIPv4/AAA Keys Open issues, Phil Phil: some issues seem have to been resolved. Only issue is re-authentication Charlie: all changes are in the last draft. Phil and Charlie agreed that the changes are small enough that no new last call will be needed. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 3 21:40:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22635 for ; Wed, 3 Apr 2002 21:40:00 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10184; Wed, 3 Apr 2002 19:39:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29022; Wed, 3 Apr 2002 18:39:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g342bZKL012412 for ; Wed, 3 Apr 2002 18:37:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g342bZP7012411 for mobile-ip-dist; Wed, 3 Apr 2002 18:37:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g342bWKL012404 for ; Wed, 3 Apr 2002 18:37:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06300 for ; Wed, 3 Apr 2002 18:37:31 -0800 (PST) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09628 for ; Wed, 3 Apr 2002 19:37:27 -0700 (MST) Received: from mail.ustc.edu.cn (mail.ustc.edu.cn [202.38.64.10]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id KAA18454 for ; Thu, 4 Apr 2002 10:33:04 +0800 Received: (qmail 11676 invoked by uid 1720); 4 Apr 2002 02:33:23 -0000 Date: Thu, 4 Apr 2002 10:33:23 +0800 (CST) From: Yanlin Peng X-X-Sender: To: Subject: [mobile-ip] Errors in fast-mipv6-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi,all I found some errors in draft-ietf-mobileip-fast-mipv6 -04.txt, such as mistaking F-BACK for F-BU in 3.1.3 and 3.1.8. Maybe there are still some errors in the rest of the draft that I didn't read. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 04:33:27 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07768 for ; Thu, 4 Apr 2002 04:33:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09596; Thu, 4 Apr 2002 01:33:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23278; Thu, 4 Apr 2002 01:32:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349UmKL013567 for ; Thu, 4 Apr 2002 01:30:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g349UlD9013566 for mobile-ip-dist; Thu, 4 Apr 2002 01:30:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g349UiKL013559 for ; Thu, 4 Apr 2002 01:30:44 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22797 for ; Thu, 4 Apr 2002 01:30:46 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21618 for ; Thu, 4 Apr 2002 01:30:22 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g349UO3G025344 for ; Thu, 4 Apr 2002 11:30:44 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 04 11:30:14 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 11:19:59 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC0C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Rajeev Koodli'" , Erik Nordmark Cc: "Hesham Soliman (ERA)" , "'James Kempf'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16 Date: Thu, 4 Apr 2002 11:04:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Rajeev, > To be more specific, > > - oldAR has means to trust CoA-1 => This *is* where my concerns are. What are these means that the AR and MN have to share trust that is equivalent to the MN - HA trust. To elaborate more, In MIPv6 there is no CoA test between the MN and HA because there is an underlying assumption that there is strong trust between the MN and HA which ties the MN's HoA to more than a device, i.e. if the MN mibehaves you know the guy and you would sue him! But this type of trust does not exist between the MN and the CN, hence the need for CoA test as well as the HoA test. So for the temp HA/AR what kind of trust exists and how? Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 08:22:56 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13117 for ; Thu, 4 Apr 2002 08:22:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23443; Thu, 4 Apr 2002 06:22:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21997; Thu, 4 Apr 2002 05:22:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34DLbKL014196 for ; Thu, 4 Apr 2002 05:21:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34DLbw0014195 for mobile-ip-dist; Thu, 4 Apr 2002 05:21:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34DLYKL014188 for ; Thu, 4 Apr 2002 05:21:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09460 for ; Thu, 4 Apr 2002 05:21:37 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19781 for ; Thu, 4 Apr 2002 06:21:35 -0700 (MST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with ESMTP id g34DPI1U030009; Thu, 4 Apr 2002 15:25:19 +0200 From: "Henrik Levkowetz" To: , Subject: RE: [mobile-ip] NAT traversal question from Minneapolis Date: Thu, 4 Apr 2002 15:21:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3CA213BF.EC4AA3ED@cisco.com> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Milind, Thank you for these good comments. I've made some clarifications to the draft as a result, and hope to post a new version today. More comments inline: Milind wrote: > Hi Henrik, > > It was me. I had a doubt in backward compatibility for the > draft. The scenario I am considering is similar to first > item in section 4.6.1. Consider HA doesn't support NAT draft and > skips the UDP Tunnel Request Extension with U bit set. HA will > accept the registration assuming authentication etc. is good. > So there is ambiguity in following places which I think should > be addressed in the draft. > > (1) Per Sec 3.1.1: Since HA accepted the RRQ, MN is expecting UDP > Reply extension, but the HA never sent one. MN's behavior should > be made clear in this case. HA will not send failed RRQ with > code 129. Right. In this situation the MN has to use standard IPIP tunnelling, or give up. It MUST NOT use UDP tunnelling. If UDP tunnelling is absolutely needed, the result is no connectivity. > > (2) If MN is not behind a NAT, HA will set proper tunnel and Mobile > IP will work. Hence MN should work in this case also. Yes, right. > > (3) Sec. 3.2 - Description of F flag: Will this flag be set only > when U bit was set and NAT was not detected? How about NAT was > detected and U bit was set? This flag will not be set in this > case? In other words, is this flag set in response to U bit > in RRQ, irrespective of NAT detection? The F flag should be set when the tunnel has been forced, irrespective of the detection of a NAT or not. I've clarified this point in the new text. Best regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 09:03:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14728 for ; Thu, 4 Apr 2002 09:03:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13910; Thu, 4 Apr 2002 07:03:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05788; Thu, 4 Apr 2002 06:03:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34E2eKL014313 for ; Thu, 4 Apr 2002 06:02:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34E2dwn014312 for mobile-ip-dist; Thu, 4 Apr 2002 06:02:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34E2aKL014305 for ; Thu, 4 Apr 2002 06:02:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20657 for ; Thu, 4 Apr 2002 06:02:39 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13406 for ; Thu, 4 Apr 2002 07:02:38 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g34E2bs7020867 for ; Thu, 4 Apr 2002 16:02:37 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 04 16:02:35 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 15:52:20 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC18@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Cc: "'Erik Nordmark'" , "Hesham Soliman (ERA)" , "'James Kempf'" Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16 Date: Thu, 4 Apr 2002 16:02:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > [Rajeev:] I don't believe that with FMIPv6, there are > additional assumptions in this sense. The issue is > whether old AR has forwarded packets to/from CoA-1. > The question of whether that MN is "real" or bogus is > a separate identity proving issue. => But this identity proving is needed to authorise the F-BU right? > > => But the transfer is based on some information > > received from the MN. So while the 2 ARs trust > > each other, the MN might have fooled the first > > AR. So unless preventing the MN from fooling > > the first AR is within the context of MIP > > signalling, the ultimate security level will > > depend on the circumstances in each network > > and the nature of links ...etc. This is unlike > > the security level in the base spec, which > > makes very little assumption about the operation > > environment. > > > > [Rajeev:] Even if the MN could fool old AR to > believe that it is going to new AR, there is no > harm; the bad MN cannot bomb an innocent > node on new AR nor can it be fictitiously present > on the new link consuming resources. This is because > packets sent to CoA-2 goto new AR's proxy ND cache, which > is 1 or 2 packets big. => Well, I assume you're saying that because of the HI/HAck transfer? These messages were introduced to avoid DAD, however, the draft is very vague about whether the nAR will actually perform DAD on behalf of the MN. In fact section 6.1.1 says that if the AR doesn't then the MN may use the nCoA while performing DAD. Which essentially means that there is a chance that another node could already be using this address. And it also means that the nAR will not necessarily wait for anything from the MN before forwarding the traffic. Last time we discussed this in the DT (a long time ago) it was suggested that we don't mandate HI/HAck either but I haven't read rev -03 (or -04 which is the same thing) yet, so I don't know if this was made clearer. > > > Hmm - if the link bandwith at oldAR and newAR is X, can a > > > misbehaving > > > MN use up 2X of resources by pretenting to move to newAR > > > (consuming resources > > > at newAR by bombing) while in fact remaining at oldAR using > > > the resources. > > > > => That's exactly on of my concern. > > > > [Rajeev:] This is not possible with FMIPv6. Packets only > goto new AR's proxy ND cache. Besides, once FBU is sent, > old AR does not forward packets to MN. I described this in > some detail to Erik's message.. => So you're essentially saying that HI/Hack are always mandated? If so then we would have to mandate what the nAR should do (proxy NS ..etc) when it receives HI. There is also the chance that the MN might already move before the nAR sends an NS to verify the nCoA, and the MN might reply to that. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 10:09:33 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17972 for ; Thu, 4 Apr 2002 10:09:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04478; Thu, 4 Apr 2002 08:09:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01468; Thu, 4 Apr 2002 07:09:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34F8BKL014455 for ; Thu, 4 Apr 2002 07:08:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34F8APE014454 for mobile-ip-dist; Thu, 4 Apr 2002 07:08:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34F87KL014447 for ; Thu, 4 Apr 2002 07:08:07 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07807 for ; Thu, 4 Apr 2002 07:08:09 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19467 for ; Thu, 4 Apr 2002 07:07:34 -0800 (PST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id <2FW6NNLC>; Thu, 4 Apr 2002 10:05:49 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] FW: I-D ACTION:draft-johansson-mip-aaa-nai-00.txt Date: Thu, 4 Apr 2002 10:05:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1DBEA.3426D578" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1DBEA.3426D578 Content-Type: text/plain Hi folks, there was a request about this I forwarded to the list on Mar 23. It addresses a real problem that needs to be solved from the AAA working group. I propose we make this a WG draft, review it, and plan to go to working group last call for proposed standard right away. The AAA folks have a dependency on it. Comments? Phil -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, April 01, 2002 7:16 AM Cc: aaa-wg@merit.edu; mobile-ip@sunroof.eng.sun.com Subject: I-D ACTION:draft-johansson-mip-aaa-nai-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : AAA NAI for Mobile IPv4 Extension Author(s) : T. Johansson Filename : draft-johansson-mip-aaa-nai-00.txt Pages : 9 Date : 29-Mar-02 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple AAA servers the reauthentication request may not be received by the same AAAH as previous authentication requests. In order for the new AAAH to be able to forward the request to the correct HA it has to know the identity of the HA. This document defines an extension that enables the HA to pass its identity to the mobile node which can in turn pass it to the AAA server when changing point of attachment. This document specifies a NAI extension that can carry these NAIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-johansson-mip-aaa-nai-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-johansson-mip-aaa-nai-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C1DBEA.3426D578 Content-Type: message/rfc822 To: Subject: Date: Mon, 1 Apr 2002 09:45:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1DBEA.3426D578" ------_=_NextPart_002_01C1DBEA.3426D578 Content-Type: text/plain ------_=_NextPart_002_01C1DBEA.3426D578 Content-Type: application/octet-stream; name="ATT01075.txt" Content-Disposition: attachment; filename="ATT01075.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020329130817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-johansson-mip-aaa-nai-00.txt ------_=_NextPart_002_01C1DBEA.3426D578 Content-Type: message/external-body; site="internet-drafts"; dir="draft-johansson-mip-aaa-nai-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1DBEA.3426D578-- ------_=_NextPart_000_01C1DBEA.3426D578-- From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 11:21:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21127 for ; Thu, 4 Apr 2002 11:21:40 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17636; Thu, 4 Apr 2002 09:21:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22840; Thu, 4 Apr 2002 08:21:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34GKNKL014837 for ; Thu, 4 Apr 2002 08:20:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34GKN5V014836 for mobile-ip-dist; Thu, 4 Apr 2002 08:20:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34GKKKL014829 for ; Thu, 4 Apr 2002 08:20:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11740 for ; Thu, 4 Apr 2002 08:20:22 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA16777 for ; Thu, 4 Apr 2002 09:20:17 -0700 (MST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu Apr 4 11:19:57 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g34GK9o21642 for ; Thu, 4 Apr 2002 11:20:09 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA18046 for ; Thu, 4 Apr 2002 11:20:08 -0500 (EST) Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <1017877180.24852.56.camel@valjean> References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 04 Apr 2002 11:20:08 -0500 Message-Id: <1017937209.24852.68.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit One clarification: > If not, then how does the FA decide which challenge to delete and when > from the per-client "used challenges list"? Unless I am missing > something, this is the (very) expensive part of the procedure. This is true with challenge windows larger than 1. Luca From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 11:41:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22027 for ; Thu, 4 Apr 2002 11:41:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07097; Thu, 4 Apr 2002 09:41:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17987; Thu, 4 Apr 2002 08:41:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34GekKL014946 for ; Thu, 4 Apr 2002 08:40:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Gekc4014945 for mobile-ip-dist; Thu, 4 Apr 2002 08:40:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34GegKL014938 for ; Thu, 4 Apr 2002 08:40:42 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g34Gebx15232; Thu, 4 Apr 2002 18:40:37 +0200 (MEST) Date: Thu, 4 Apr 2002 18:40:15 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] parameters in draft v16 To: G.Tsirtsis@flarion.com Cc: mobile-ip@sunroof.eng.sun.com, Scott Corson , Vincent Park , Matt Impett Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Given the hope that MIPv6 will be with us for considerable time :-) we were > wondering if something better can be done for future compatibility. The > current spec only allows for skippable parameters. Wouldn't be useful to > also allow for non-skippable parameters? Since "parameters" are TLVs, one > could set aside 'Type' space for non-skippable parameters. If one of the > non-skippable parameters is received but not recognized the receiver should > send an error code indicating "unknown parameter". We currently have two methods for introducing incompatible changes (things where either the sender needs to know that the receiver doesn't support it): - use a new message type in the MH protocol Oops - the spec should say what a node does when receiving an unspecified type. Send an ICMP parameter problem seems like the right thing. - use the parameter/option echo mechanisms much like TCP SYN - SYN|ACK. If the receiver understands the option it includes the some option in the response (where a response is a HoT for a HoTI, a BA for a BU etc) I *think* those two mechanisms are sufficient for extensibility. IPv6 destination options have a skippable/non-skippable notion but IPv6 isn't a request/response protocol like MH or TCP. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 11:48:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22290 for ; Thu, 4 Apr 2002 11:48:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11673; Thu, 4 Apr 2002 09:48:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20184; Thu, 4 Apr 2002 08:48:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34GlrKL015031 for ; Thu, 4 Apr 2002 08:47:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34GlquJ015030 for mobile-ip-dist; Thu, 4 Apr 2002 08:47:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34GliKL015023 for ; Thu, 4 Apr 2002 08:47:44 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g34Glfx15972; Thu, 4 Apr 2002 18:47:42 +0200 (MEST) Date: Thu, 4 Apr 2002 18:47:19 +0200 (CEST) From: Erik Nordmark Subject: Re: [mobile-ip] Comments on Draft 16 To: Brian Haley Cc: mobile-ip@sunroof.eng.sun.com, erik.nordmark@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > So is there a better way to solve this problem? For manually keyed SAs > between a HA<->MN we could define a new sub-option that carries a timestamp > (like seconds since Mobile IPv6 became an RFC :), and the HA rejects BUs > with the timestamp out of a certain range. Of course this would require > synchronization, Something the design team talked about was to do essentially an RR check for home registrations when the sequence number isn't known. Thus the fresh cookie presented in the BU would indicate that the BU isn't a too old replay. That seems like a fair amount of complexity to add and the details haven't been worked out. So perhaps there is simpler a way to specify rules for handling sequence numbers for home registrations that have a small replay hole when manual keys are used, but do not have such a problem when IKE is used to create the IPsec SAs. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 11:57:49 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22596 for ; Thu, 4 Apr 2002 11:57:49 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25612; Thu, 4 Apr 2002 09:57:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23780; Thu, 4 Apr 2002 08:57:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34GubKL015114 for ; Thu, 4 Apr 2002 08:56:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34GubOK015113 for mobile-ip-dist; Thu, 4 Apr 2002 08:56:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34GuYKL015106 for ; Thu, 4 Apr 2002 08:56:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00862 for ; Thu, 4 Apr 2002 08:56:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06188 for ; Thu, 4 Apr 2002 09:56:29 -0700 (MST) 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 IAA02667; Thu, 4 Apr 2002 08:56:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34GuSM25205; Thu, 4 Apr 2002 08:56:28 -0800 X-mProtect: <200204041656> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhnePup; Thu, 04 Apr 2002 08:56:26 PST Message-ID: <3CAC85BA.54AF7F85@iprg.nokia.com> Date: Thu, 04 Apr 2002 08:56:26 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Luca Salgarelli CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Luca, Actually, I'm not so sure about the best way to answer your question. It is a good point. My original conception of this operation was that the foreign agent would have a _short_ list of recent acceptable challenges. That is easily checked when a mobile node sends a Registration Request. The challenges would be advertised, and available for use by multiple mobile nodes. Now it is also possible to have the challenge supplied as part of the Registration Reply, which is a good idea, but not "like" the other Challenges because a long time might pass before the challenge gets used. My guess is that the foreign agent now has to check in two places about the challenge for the mobile node. The challenge that was delivered with the Registration Reply would have to be stored per-mobile. That is not all that expensive. The other short list is not expensive. Together, I don't think they are all that expensive to maintain, even if the window size is greater than 1. Maybe the per-mobile challenge gets stored along with the other information in the visitor list. Perhaps the "window" size for per-mobile challenges is always implicitly 1, in contrast to the other generally advertised challenge values. What do you think about this? Regards, Charlie P. Luca Salgarelli wrote: > > Hello Charlie. > > > For each challenge used by a mobile node (multicast or not), > > the foreign agent needs to keep track of the mobile node's IP > > address and that challenge value. What is different? If a > > mobile node erroneously tries to re-use a value that is still > > being multicast, then it would be rejected, right? > > Right. But then the question is: does the FA have to keep the list of > used challenges for every client for the entire duration of their > session, and check against that list every registration request? I hope > not, right? > > If not, then how does the FA decide which challenge to delete and when > from the per-client "used challenges list"? Unless I am missing > something, this is the (very) expensive part of the procedure. > > If instead the FA sent challenges only in reg. replies and in unicast > advertisements, then the check becomes very simple: a challenge from a > client is valid only if it was either in the last unicast advertisement > or in the last reg. reply. Implementation becomes trivial: the FA just > has to keep two fields per client with the last two challenges issued to > that client. > > Does this make sense? > > Luca From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 12:02:51 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23012 for ; Thu, 4 Apr 2002 12:02:50 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21242; Thu, 4 Apr 2002 10:02:38 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24917; Thu, 4 Apr 2002 09:02:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34H1uKL015237 for ; Thu, 4 Apr 2002 09:01:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34H1tCk015236 for mobile-ip-dist; Thu, 4 Apr 2002 09:01:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34H1qKL015229 for ; Thu, 4 Apr 2002 09:01:52 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24744 for ; Thu, 4 Apr 2002 09:01:55 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14982 for ; Thu, 4 Apr 2002 09:01:54 -0800 (PST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 12:01:50 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCA6@ftmail> From: George Tsirtsis To: "'Erik Nordmark'" Cc: mobile-ip@sunroof.eng.sun.com, Scott Corson , Vincent Park , Matt Impett Subject: RE: [mobile-ip] parameters in draft v16 Date: Thu, 4 Apr 2002 12:01:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Thursday, April 04, 2002 5:40 PM To: G.Tsirtsis@flarion.com Cc: mobile-ip@sunroof.eng.sun.com; Scott Corson; Vincent Park; Matt Impett Subject: Re: [mobile-ip] parameters in draft v16 > Given the hope that MIPv6 will be with us for considerable time :-) we were > wondering if something better can be done for future compatibility. The > current spec only allows for skippable parameters. Wouldn't be useful to > also allow for non-skippable parameters? Since "parameters" are TLVs, one > could set aside 'Type' space for non-skippable parameters. If one of the > non-skippable parameters is received but not recognized the receiver should > send an error code indicating "unknown parameter". We currently have two methods for introducing incompatible changes (things where either the sender needs to know that the receiver doesn't support it): - use a new message type in the MH protocol Oops - the spec should say what a node does when receiving an unspecified type. Send an ICMP parameter problem seems like the right thing. GT> Yes, as the moment it only says that an error should be sent back...but not what kind of error. - use the parameter/option echo mechanisms much like TCP SYN - SYN|ACK. If the receiver understands the option it includes the some option in the response (where a response is a HoT for a HoTI, a BA for a BU etc) I *think* those two mechanisms are sufficient for extensibility. GT> OK, so you say that the sender of, for example a BU, with a future parameter extention sould get back a BAck which will include the same extension. If the extention is not included it means that it was not understood and ignored. The potential problem is that the BU was nevertheless accepted and thus a new binding was created. I am wondering if there is value in supporting extensions that unless accepted should force the receiver to *drop* rather than ignore the message and return an error. George From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 12:40:58 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24876 for ; Thu, 4 Apr 2002 12:40:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15775; Thu, 4 Apr 2002 10:40:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06375; Thu, 4 Apr 2002 09:40:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HdgKL015425 for ; Thu, 4 Apr 2002 09:39:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Hdgim015424 for mobile-ip-dist; Thu, 4 Apr 2002 09:39:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HddKL015417 for ; Thu, 4 Apr 2002 09:39:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06125 for ; Thu, 4 Apr 2002 09:39:42 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA03501 for ; Thu, 4 Apr 2002 10:39:40 -0700 (MST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu Apr 4 12:38:35 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g34Hc9k52503 for ; Thu, 4 Apr 2002 12:38:09 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA21068 for ; Thu, 4 Apr 2002 12:38:09 -0500 (EST) Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3CAC85BA.54AF7F85@iprg.nokia.com> References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 04 Apr 2002 12:38:08 -0500 Message-Id: <1017941889.24852.97.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Charlie. > My original conception of this operation was that the foreign > agent would have a _short_ list of recent acceptable challenges. > That is easily checked when a mobile node sends a Registration > Request. The challenges would be advertised, and available for > use by multiple mobile nodes. I think there is more to it than it appears. The spec says, rightfully, that the FA should make sure to check that a mobile does not reuse a previously used challenge. And this is the sticky point. To satisfy it, it is not enough for the FA to maintain a global list of "valid advertised challenges" only. It has to keep: 1) A global windowed list of valid advertised challenges 2) A per-mobile list of the last challenge sent in a reply as you say, but also: 3) A *per-mobile* list of recently used challenges from (1) Now, (1) is not a problem because it should be short. Same for (2) because it is always composed of one entry only -- as you suggested, I agree that the window of the challenges sent in replies should always be '1'. I have problems with (3), if the window is larger than one. As the mobile uses challenges from advertisements, we have to add them to (3). But we don't want (3) to grow indefinitely, so we want to delete the ones that were already there and that we don't possibly need anymore. To select the ones that can be safely deleted, we would have to check them against the current values in (1), and delete from (3) the ones that are not present in (1). But this operation starts to become increasingly expensive, even for windows of two or three. Furthermore, we will probably also have to keep (3) alive even after the mobile de-registers, to make sure that an attacker does not replay a request that used one of the still valid challenges values that this mobile recently used (and that therefore is in (3)). Now, it could be that there is another less expensive (and less complex to explain!) way of having challenges sent with multicast advertisements, a challenge-window greater than 1, and satisfy the requirement of making sure that a challenge has not been already used by a mobile. But I really cannot think of another one different than the above. What do you think? Luca > Now it is also possible to have the challenge supplied as part > of the Registration Reply, which is a good idea, but not "like" > the other Challenges because a long time might pass before the > challenge gets used. > > My guess is that the foreign agent now has to check in two > places about the challenge for the mobile node. The challenge > that was delivered with the Registration Reply would have to > be stored per-mobile. That is not all that expensive. The > other short list is not expensive. Together, I don't think > they are all that expensive to maintain, even if the window > size is greater than 1. Maybe the per-mobile challenge gets > stored along with the other information in the visitor list. > Perhaps the "window" size for per-mobile challenges is always > implicitly 1, in contrast to the other generally advertised > challenge values. > > What do you think about this? > > Regards, > Charlie P. > > > > Luca Salgarelli wrote: > > > > Hello Charlie. > > > > > For each challenge used by a mobile node (multicast or not), > > > the foreign agent needs to keep track of the mobile node's IP > > > address and that challenge value. What is different? If a > > > mobile node erroneously tries to re-use a value that is still > > > being multicast, then it would be rejected, right? > > > > Right. But then the question is: does the FA have to keep the list of > > used challenges for every client for the entire duration of their > > session, and check against that list every registration request? I hope > > not, right? > > > > If not, then how does the FA decide which challenge to delete and when > > from the per-client "used challenges list"? Unless I am missing > > something, this is the (very) expensive part of the procedure. > > > > If instead the FA sent challenges only in reg. replies and in unicast > > advertisements, then the check becomes very simple: a challenge from a > > client is valid only if it was either in the last unicast advertisement > > or in the last reg. reply. Implementation becomes trivial: the FA just > > has to keep two fields per client with the last two challenges issued to > > that client. > > > > Does this make sense? > > > > Luca From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 12:51:50 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28156 for ; Thu, 4 Apr 2002 12:51:46 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27665; Thu, 4 Apr 2002 10:51:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09574; Thu, 4 Apr 2002 09:51:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HohKL015579 for ; Thu, 4 Apr 2002 09:50:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34HogfM015578 for mobile-ip-dist; Thu, 4 Apr 2002 09:50:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34HodKL015570 for ; Thu, 4 Apr 2002 09:50:39 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12580 for ; Thu, 4 Apr 2002 09:50:42 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26979 for ; Thu, 4 Apr 2002 10:50:42 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g34HofI23396 for ; Thu, 4 Apr 2002 09:50:41 -0800 (PST) Message-ID: <016601c1dc01$031fd3a0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] FW: I-D ACTION:draft-johansson-mip-aaa-nai-00.txt Date: Thu, 4 Apr 2002 09:49:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Agree. jak ----- Original Message ----- From: "Phil Roberts" To: Sent: Thursday, April 04, 2002 7:05 AM Subject: [mobile-ip] FW: I-D ACTION:draft-johansson-mip-aaa-nai-00.txt > > Hi folks, > > there was a request about this I forwarded to the list on Mar 23. It > addresses > a real problem that needs to be solved from the AAA working group. I > propose we > make this a WG draft, review it, and plan to go to working group last call > for > proposed standard right away. The AAA folks have a dependency on it. > > Comments? > Phil > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, April 01, 2002 7:16 AM > Cc: aaa-wg@merit.edu; mobile-ip@sunroof.eng.sun.com > Subject: I-D ACTION:draft-johansson-mip-aaa-nai-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : AAA NAI for Mobile IPv4 Extension > Author(s) : T. Johansson > Filename : draft-johansson-mip-aaa-nai-00.txt > Pages : 9 > Date : 29-Mar-02 > > When a mobile node moves between two foreign networks it has to be > reauthenticated. If the home network has multiple AAA servers the > reauthentication request may not be received by the same AAAH as previous > authentication requests. In order for the new AAAH to be able to forward the > request to the correct HA it has to know the identity of the HA. This > document defines an extension that enables the HA to pass its identity to > the mobile node which can in turn pass it to the AAA server when changing > point of attachment. This document specifies a NAI extension that can carry > these NAIs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, type > "cd internet-drafts" and then > "get draft-johansson-mip-aaa-nai-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-johansson-mip-aaa-nai-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 13:04:33 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28611 for ; Thu, 4 Apr 2002 13:04:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24464; Thu, 4 Apr 2002 10:04:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17655; Thu, 4 Apr 2002 10:04:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34I2MKL015721 for ; Thu, 4 Apr 2002 10:02:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34I2MRB015720 for mobile-ip-dist; Thu, 4 Apr 2002 10:02:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34I2IKL015713 for ; Thu, 4 Apr 2002 10:02:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16957 for ; Thu, 4 Apr 2002 10:02:21 -0800 (PST) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04124 for ; Thu, 4 Apr 2002 11:02:20 -0700 (MST) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id UAA27415; Thu, 4 Apr 2002 20:02:18 +0200 (MET DST) Date: Thu, 4 Apr 2002 20:02:18 +0200 (MET DST) Message-Id: <200204041802.UAA27415@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: mobile-ip@sunroof.eng.sun.com CC: mobile-ip@sunroof.eng.sun.com In-reply-to: <1017941889.24852.97.camel@valjean> (message from Luca Salgarelli on 04 Apr 2002 12:38:08 -0500) Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941889.24852.97.camel@valjean> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Furthermore, we will probably also have to keep (3) alive even after the mobile de-registers, to make sure that an attacker does not replay a request that used one of the still valid challenges values that this mobile recently used (and that therefore is in (3)). But the elements of list (3) don't have to be retained longer than the time period when these challenges are valid. Thus when a given challenge is removed from (1) it can be removed from all lists of type (3) {if the resulting list is empty, then the mobile is well and truely gone, so the list can be removed altogether.} Of course by actually just extending the element of list (1) to include a list indicating which mobile(s) has(have) used this particular challenge - then you don't even have to search during the delete operation - you remove the challenge element (1) and all of records of the mobiles which have used this challenge. Since this challenge is now invalid, there is no reason to keep it or any records of who used it; as clearly _any_ use of this challenge is invalid. Chip From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 13:21:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29796 for ; Thu, 4 Apr 2002 13:21:06 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02666; Thu, 4 Apr 2002 11:20:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24134; Thu, 4 Apr 2002 10:20:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IJrKL015887 for ; Thu, 4 Apr 2002 10:19:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34IJrgw015886 for mobile-ip-dist; Thu, 4 Apr 2002 10:19:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IJoKL015879 for ; Thu, 4 Apr 2002 10:19:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17691 for ; Thu, 4 Apr 2002 10:19:51 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02078 for ; Thu, 4 Apr 2002 11:19:50 -0700 (MST) 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 KAA08217; Thu, 4 Apr 2002 10:19:50 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34IJnr03404; Thu, 4 Apr 2002 10:19:49 -0800 X-mProtect: <200204041819> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8or92S; Thu, 04 Apr 2002 10:19:47 PST Message-ID: <3CAC9944.1226516D@iprg.nokia.com> Date: Thu, 04 Apr 2002 10:19:48 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gerald Maguire CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941889.24852.97.camel@valjean> <200204041802.UAA27415@dumburken.it.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit HI Chip, Gerald Maguire wrote: > > But the elements of list (3) don't have to be retained longer than the > time period when these challenges are valid. Thus when a given > challenge is removed from (1) it can be removed from all lists of type > (3) {if the resulting list is empty, then the mobile is well and > truely gone, so the list can be removed altogether.} I don't remember any such time period. The Challenge Window is purely based on the number of distinct Challenges offered, and not on when they were offered. Plus, it *might* be considered useful that the mobile node can always have a usable challenge available to it, without delay, even if the challenge was offered at some much earlier point in the past -- as long as it was never used. If you think there should be some time limit after which a Challenge can no longer be used, then that is something more which isn't in the current specification -- and which would need to go through working group call again, at least according to my understanding. Or else, if it's already in there, then I guess I just missed it (not to mention forgot about putting it there in the first place!) -- but I don't think it's there. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 13:33:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03217 for ; Thu, 4 Apr 2002 13:33:51 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09719; Thu, 4 Apr 2002 11:33:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29678; Thu, 4 Apr 2002 10:33:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IWmKL016116 for ; Thu, 4 Apr 2002 10:32:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34IWlgs016115 for mobile-ip-dist; Thu, 4 Apr 2002 10:32:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IWiKL016108 for ; Thu, 4 Apr 2002 10:32:44 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01966 for ; Thu, 4 Apr 2002 10:32:46 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16147 for ; Thu, 4 Apr 2002 10:32:45 -0800 (PST) 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 KAA09103; Thu, 4 Apr 2002 10:32:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34IWhF25979; Thu, 4 Apr 2002 10:32:43 -0800 X-mProtect: <200204041832> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCDX2f4; Thu, 04 Apr 2002 10:32:40 PST Message-ID: <3CAC9C48.FE18975A@iprg.nokia.com> Date: Thu, 04 Apr 2002 10:32:40 -0800 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: mobile-ip@sunroof.eng.sun.com CC: "'Rajeev Koodli'" , "'Erik Nordmark'" , "Hesham Soliman (ERA)" , "'James Kempf'" Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6AC18@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Hesham, "Hesham Soliman (ERA)" wrote: > > => Well, I assume you're saying that because of > the HI/HAck transfer? These messages were introduced > to avoid DAD, however, the draft is very vague about > whether the nAR will actually perform DAD on behalf > of the MN. In fact section 6.1.1 says that if the AR > doesn't then the MN may use the nCoA while performing > DAD. Which essentially means that there is a chance > that another node could already be using this address. > And it also means that the nAR will not necessarily > wait for anything from the MN before forwarding the > traffic. > Last time we discussed this in the DT (a long time ago) > it was suggested that we don't mandate HI/HAck either > but I haven't read rev -03 (or -04 which is the same > thing) yet, so I don't know if this was made clearer. The way I read the drafts, HI/HACK messages are a MUST since draft -01. The HI message always contains both the oldCoA and newCoA. If the newAR is not able to determine that the newCoA is unique on the new link, it sets up a host route for the oldCoA. It also says newCoA is invalid in both the HACK (to the oldAR) and NAACK (to the MN). The MN can continue using the oldCoA on the new link Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 13:37:54 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03491 for ; Thu, 4 Apr 2002 13:37:53 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23708; Thu, 4 Apr 2002 11:37:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01606; Thu, 4 Apr 2002 10:37:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IalKL016282 for ; Thu, 4 Apr 2002 10:36:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Ial0B016281 for mobile-ip-dist; Thu, 4 Apr 2002 10:36:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IahKL016267 for ; Thu, 4 Apr 2002 10:36:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09330 for ; Thu, 4 Apr 2002 10:36:45 -0800 (PST) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05524 for ; Thu, 4 Apr 2002 11:36:43 -0700 (MST) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id UAA27498; Thu, 4 Apr 2002 20:36:38 +0200 (MET DST) Date: Thu, 4 Apr 2002 20:36:38 +0200 (MET DST) Message-Id: <200204041836.UAA27498@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: charliep@iprg.nokia.com CC: mobile-ip@sunroof.eng.sun.com In-reply-to: <3CAC9944.1226516D@iprg.nokia.com> (charliep@iprg.nokia.com) Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941889.24852.97.camel@valjean> <200204041802.UAA27415@dumburken.it.kth.se> <3CAC9944.1226516D@iprg.nokia.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I don't suggest that the challenge window element necessarily has to be removed based on time, but there must be some reason you remove them (otherwise it would not be a Window). At the point that you remove the challenge from the list of valid challenges (i.e., this challenges now falls outside the Challenge Window), then this challenge is no longer valid for anyone to use. Hence the record of anyone having used it is no longer relevant, because no one can use this challenge. Since there can be no problems due to a replay - since the challenge is invalid, there is no need to store any information concerning who has or has not used this challenge. Chip From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 13:42:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03686 for ; Thu, 4 Apr 2002 13:42:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26537; Thu, 4 Apr 2002 11:42:16 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03634; Thu, 4 Apr 2002 10:42:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IfXKL016483 for ; Thu, 4 Apr 2002 10:41:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34IfXcp016482 for mobile-ip-dist; Thu, 4 Apr 2002 10:41:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34IfTKL016473 for ; Thu, 4 Apr 2002 10:41:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04187 for ; Thu, 4 Apr 2002 10:41:31 -0800 (PST) Received: from mothers.student.bth.se (mothers.student.bth.se [194.47.133.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14420 for ; Thu, 4 Apr 2002 11:41:29 -0700 (MST) Received: from loonquawl.rby.hk-r.se (loonquawl [194.47.133.108]) by mothers.student.bth.se (8.10.2+Sun/8.10.2) with ESMTP id g34IfSx19193 for ; Thu, 4 Apr 2002 20:41:28 +0200 (MEST) Received: from localhost (t98pth@localhost) by loonquawl.rby.hk-r.se (8.10.2+Sun/8.10.2) with ESMTP id g34IfR508482 for ; Thu, 4 Apr 2002 20:41:27 +0200 (MEST) Date: Thu, 4 Apr 2002 20:41:27 +0200 (MEST) From: =?iso-8859-1?Q?P=E4r_Thor=E9n?= To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Seamless mobile connection to a internet from a MANET (IPv6) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id g34IfUKL016476 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit When connecting a MANET to a IPv6 internet, as defined in draft-wakikawa-manet-globalv6-00.txt (Global Connectivity for IPv6 Mobile Ad Hoc Networks), with a MobileIPv6 router (a node in the MANET), as in draft-ernst-mobileip-v6-network-00.txt (Mobile Networks Support in Mobile IPv6) through a access gateway/network, can one asume that connections to corresponding nodes outside the MANET can be provided seamless for all nodes in the MANET when changing the access gateway as in draft-ietf-seamoby-mm-problem-01.txt (SeaMoby Micro Mobility Problem Statement). And what is the advantage of using a MobileIPv6 Router instead of just using existing routingprotocols to update routing tables throught out the internet of the location of the MANET? regards, Pär From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 13:49:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03979 for ; Thu, 4 Apr 2002 13:49:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18548; Thu, 4 Apr 2002 11:49:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25818; Thu, 4 Apr 2002 10:49:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34ImFKL016609 for ; Thu, 4 Apr 2002 10:48:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34ImEpU016608 for mobile-ip-dist; Thu, 4 Apr 2002 10:48:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34ImBKL016601 for ; Thu, 4 Apr 2002 10:48:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25626 for ; Thu, 4 Apr 2002 10:48:13 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11599 for ; Thu, 4 Apr 2002 11:48:12 -0700 (MST) 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 KAA10300; Thu, 4 Apr 2002 10:48:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34ImAs27516; Thu, 4 Apr 2002 10:48:10 -0800 X-mProtect: <200204041848> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHQxWVc; Thu, 04 Apr 2002 10:48:08 PST Message-ID: <3CAC9FE9.ED2F6726@iprg.nokia.com> Date: Thu, 04 Apr 2002 10:48:09 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gerald Maguire CC: Mobile IP Working Group Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941889.24852.97.camel@valjean> <200204041802.UAA27415@dumburken.it.kth.se> <3CAC9944.1226516D@iprg.nokia.com> <200204041836.UAA27498@dumburken.it.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello again Chip, You wrote: > I don't suggest that the challenge window element necessarily has to > be removed based on time, but there must be some reason you remove > them (otherwise it would not be a Window). It's called a window because it looks like a sliding window over the sequence of challenges, and leaves only the last N visible. Isn't that still a valid use of the terminology, irrespective of any time dimension? > At the point that you remove the challenge from the list of valid > challenges (i.e., this challenges now falls outside the Challenge > Window), then this challenge is no longer valid for anyone to use. > Hence the record of anyone having used it is no longer relevant, > because no one can use this challenge. Since there can be no problems > due to a replay - since the challenge is invalid, there is no need to > store any information concerning who has or has not used this challenge. I don't disagree with your statements, but I also don't think that having the mobile node use a Challenge from its last Registration Request introduces any replay vulnerability. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 14:16:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04799 for ; Thu, 4 Apr 2002 14:16:52 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13976; Thu, 4 Apr 2002 12:16:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03103; Thu, 4 Apr 2002 11:16:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JFmKL016851 for ; Thu, 4 Apr 2002 11:15:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34JFmTQ016850 for mobile-ip-dist; Thu, 4 Apr 2002 11:15:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JFjKL016843 for ; Thu, 4 Apr 2002 11:15:45 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13748 for ; Thu, 4 Apr 2002 11:15:47 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA12053 for ; Thu, 4 Apr 2002 11:15:37 -0800 (PST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu Apr 4 14:15:42 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g34JFFk61023 for ; Thu, 4 Apr 2002 14:15:16 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA25316 for ; Thu, 4 Apr 2002 14:15:15 -0500 (EST) Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3CAC918D.9418939D@iprg.nokia.com> References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941852.24852.94.camel@valjean> <3CAC918D.9418939D@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 04 Apr 2002 14:15:15 -0500 Message-Id: <1017947715.22420.110.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, please see comments inline. On Thu, 2002-04-04 at 12:46, Charles E. Perkins wrote: > Luca Salgarelli wrote: > > > > Hello Charlie. > > > > > My original conception of this operation was that the foreign > > > agent would have a _short_ list of recent acceptable challenges. > > > That is easily checked when a mobile node sends a Registration > > > Request. The challenges would be advertised, and available for > > > use by multiple mobile nodes. > > > > I think there is more to it than it appears. > > > > The spec says, rightfully, that the FA should make sure to check that a > > mobile does not reuse a previously used challenge. And this is the > > sticky point. To satisfy it, it is not enough for the FA to maintain a > > global list of "valid advertised challenges" only. It has to keep: > > > > 1) A global windowed list of valid advertised challenges > > 2) A per-mobile list of the last challenge sent in a reply > > > > as you say, but also: > > > > 3) A *per-mobile* list of recently used challenges from (1) > > > > Now, (1) is not a problem because it should be short. Same for (2) > > because it is always composed of one entry only -- as you suggested, I > > agree that the window of the challenges sent in replies should always be > > '1'. > > > > I have problems with (3), if the window is larger than one. As the > > mobile uses challenges from advertisements, we have to add them to (3). > > But we don't want (3) to grow indefinitely, so we want to delete the > > ones that were already there and that we don't possibly need anymore. > > What if we say that, if a mobile node uses a challenge from (1), that > challenge _replaces_ the challenge (if any) from (3). Thus, this > "invalidates" the option to use any challenge that was supplied from > a Registration Request. > > I don't think this would impose any hardship, and it would seemingly > eliminate the problem that you have identified. Hmmm, I am not sure you could do that. Let's analyze: (3) contains a list of challenges successfully used by a client in the recent past. (3), along with (1) and (2), are kept by the FA so that it can run the following checks when it receives a challenge C in a registration request: 1: if (C is not in (1)) and (C is not in (2)) 2: return UNKNOWN_CHALLENGE 3: else 4: if (C is in (3)) 5: return STALE_CHALLENGE 6: else 7: add C to (3) 8: proceed with processing of registration request Now, if I understand your suggestion correctly, you are saying that the FA at line 7 should replace the challenge C' (if any) that is already in (3). But this wouldn't work: if the window is larger than one, a malicious mobile could now replay the older request that contained C', and the FA would let it through. Am I misintrepreting your suggestion? Luca Charlie also wrote: > > Furthermore, we will probably also have to keep (3) alive even after the > > mobile de-registers, to make sure that an attacker does not replay a > > request that used one of the still valid challenges values that this > > mobile recently used (and that therefore is in (3)). > > After deregistration, from the above, this would not impose very much > additional hardship. In fact, even when there is nothing from (3), > the foreign agent should keep this information around. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 14:20:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05012 for ; Thu, 4 Apr 2002 14:20:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05074; Thu, 4 Apr 2002 12:20:38 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04256; Thu, 4 Apr 2002 11:20:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JJeKL016950 for ; Thu, 4 Apr 2002 11:19:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34JJejI016949 for mobile-ip-dist; Thu, 4 Apr 2002 11:19:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JJZKL016942 for ; Thu, 4 Apr 2002 11:19:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15877 for ; Thu, 4 Apr 2002 11:19:37 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA15608 for ; Thu, 4 Apr 2002 12:19:37 -0700 (MST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu Apr 4 14:19:48 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g34JJMk61549 for ; Thu, 4 Apr 2002 14:19:22 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA25562 for ; Thu, 4 Apr 2002 14:19:22 -0500 (EST) Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <200204041802.UAA27415@dumburken.it.kth.se> References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941889.24852.97.camel@valjean> <200204041802.UAA27415@dumburken.it.kth.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 04 Apr 2002 14:19:22 -0500 Message-Id: <1017947962.24852.114.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Chip. On Thu, 2002-04-04 at 13:02, Gerald Maguire wrote: > But the elements of list (3) don't have to be retained longer than the > time period when these challenges are valid. Thus when a given > challenge is removed from (1) it can be removed from all lists of type > (3) {if the resulting list is empty, then the mobile is well and > truely gone, so the list can be removed altogether.} This would definitely have scalability problems: now the FA every time it modifies the list of valid challenges, it has to go through the whole list of visitors to modify (3). Also: > Of course by actually just extending the element of list (1) to > include a list indicating which mobile(s) has(have) used this > particular challenge - then you don't even have to search during the > delete operation - you remove the challenge element (1) and all of > records of the mobiles which have used this challenge. I think that this could also lead to scalability problems: now the FA when it has to check for the validity of a challenge, it has to go through a [potentially long] list of mobile nodes to check against. Luca From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 14:44:14 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06118 for ; Thu, 4 Apr 2002 14:44:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03320; Thu, 4 Apr 2002 12:44:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24003; Thu, 4 Apr 2002 11:43:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34Jh4KL017158 for ; Thu, 4 Apr 2002 11:43:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Jh3jW017157 for mobile-ip-dist; Thu, 4 Apr 2002 11:43:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34Jh0KL017150 for ; Thu, 4 Apr 2002 11:43:00 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20908 for ; Thu, 4 Apr 2002 11:42:59 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21089 for ; Thu, 4 Apr 2002 11:42:59 -0800 (PST) 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 LAA14079; Thu, 4 Apr 2002 11:42:59 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34Jgwq12452; Thu, 4 Apr 2002 11:42:58 -0800 X-mProtect: <200204041942> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOvYvUJ; Thu, 04 Apr 2002 11:42:56 PST Message-ID: <3CACACC1.EC4DFECC@iprg.nokia.com> Date: Thu, 04 Apr 2002 11:42:57 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Luca Salgarelli CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941852.24852.94.camel@valjean> <3CAC918D.9418939D@iprg.nokia.com> <1017947715.22420.110.camel@valjean> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Luca Salgarelli wrote: >>> The spec says, rightfully, that the FA should make sure to check that a >>> mobile does not reuse a previously used challenge. And this is the >>> sticky point. To satisfy it, it is not enough for the FA to maintain a >>> global list of "valid advertised challenges" only. It has to keep: >>> >>> 1) A global windowed list of valid advertised challenges >>> 2) A per-mobile list of the last challenge sent in a reply >>> >>> as you say, but also: >>> >>> 3) A *per-mobile* list of recently used challenges from (1) I think I said the wrong thing. What if, when a mobile node uses a challenge from (1), it causes (2) to be nullified. Thus, if a mobile node uses one of the advertised challenges, it loses the option of (ever) using the challenge from a Registration Reply. Is this better? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 14:44:38 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06144 for ; Thu, 4 Apr 2002 14:44:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17543; Thu, 4 Apr 2002 12:44:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24224; Thu, 4 Apr 2002 11:44:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JhXKL017175 for ; Thu, 4 Apr 2002 11:43:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34JhXi9017174 for mobile-ip-dist; Thu, 4 Apr 2002 11:43:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JhSKL017160 for ; Thu, 4 Apr 2002 11:43:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21027 for ; Thu, 4 Apr 2002 11:43:30 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02913; Thu, 4 Apr 2002 12:43:30 -0700 (MST) 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 LAA14094; Thu, 4 Apr 2002 11:43:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34JhQF12917; Thu, 4 Apr 2002 11:43:26 -0800 X-mProtect: <200204041943> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdj7deeZ; Thu, 04 Apr 2002 11:43:24 PST Message-ID: <3CACACDD.F1DEBC3B@iprg.nokia.com> Date: Thu, 04 Apr 2002 11:43:25 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Erik Nordmark , "Hesham Soliman (ERA)" , "'James Kempf'" Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6AC0C@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I think it is useful to look at the issue more generally as binding CoA-1 to CoA-2 rather than viewing AR strictly as a temp HA. Now, we need to make sure that it is safe to bind these two together. For that, CoA-1: AR-1 has been forwarding packets to/from CoA-1. From an RR standpoint, there is a "trust" based on routing (specifically on-link forwarding). CoA-2: AR-2, which AR-1 trusts, is able to vouch that redirecting traffic to CoA-2 is safe. We need to ensure that these things are clearly spelled out in the specification. Some comments below in-line. Regards, "Hesham Soliman (ERA)" wrote: > Rajeev, > > > To be more specific, > > > > - oldAR has means to trust CoA-1 > > => This *is* where my concerns are. What > are these means that the AR and MN have to share > trust that is equivalent to the MN - HA trust. > Sorry, but by trust I meant that based on being able to forward packets to/from CoA-1. I elaborated this in the other previous e-mail. > > To elaborate more, In MIPv6 there is no CoA > test between the MN and HA because there is an > underlying assumption that there is strong trust > between the MN and HA which ties the MN's HoA > to more than a device, i.e. if the MN mibehaves > you know the guy and you would sue him! But, you don't have to map an AR to a temp HA and then look at the protocol. Treat this as a problem of binding CoA-1 to CoA-2. > > > But this type of trust does not exist between > the MN and the CN, hence the need for CoA test > as well as the HoA test. So for the temp HA/AR > what kind of trust exists and how? As I mentioned above, the fact that AR-1 has been forwarding packets to/from CoA-1 is the trust (that is analogous to trust assumed in RR) that you use. > > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 14:45:56 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06188 for ; Thu, 4 Apr 2002 14:45:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28178; Thu, 4 Apr 2002 12:45:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25082; Thu, 4 Apr 2002 11:45:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JiwKL017218 for ; Thu, 4 Apr 2002 11:44:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34JivvA017217 for mobile-ip-dist; Thu, 4 Apr 2002 11:44:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JirKL017204 for ; Thu, 4 Apr 2002 11:44:53 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02784 for ; Thu, 4 Apr 2002 11:44:55 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10416 for ; Thu, 4 Apr 2002 11:44:55 -0800 (PST) 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 LAA14192; Thu, 4 Apr 2002 11:44:54 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34Jirx15963; Thu, 4 Apr 2002 11:44:53 -0800 X-mProtect: <200204041944> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6sCvEg; Thu, 04 Apr 2002 11:44:52 PST Message-ID: <3CACAD34.D947BE38@iprg.nokia.com> Date: Thu, 04 Apr 2002 11:44:52 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com, "'Erik Nordmark'" , "'James Kempf'" Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6AC18@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > [Rajeev:] I don't believe that with FMIPv6, there are > > additional assumptions in this sense. The issue is > > whether old AR has forwarded packets to/from CoA-1. > > The question of whether that MN is "real" or bogus is > > a separate identity proving issue. > > => But this identity proving is needed to authorise > the F-BU right? Not really! With a CN, a MN does not prove its identity. It only convinces the CN that it owns the CoA and HoA using the common trust on routing infrastructure. Thus, to authorize a BU, you don't need to prove the MN's identity; it suffices to prove that the MN legitimately (in the routing sense) owns the addresses in question. BTW, this crucial point is also the basis of short-lived BSAs using RR. A CN does not need to authenticate _who_ owns the addresses as long as it can be sufficiently sure that it is dealing with the same entity it did previously. > > [Rajeev:] Even if the MN could fool old AR to > > believe that it is going to new AR, there is no > > harm; the bad MN cannot bomb an innocent > > node on new AR nor can it be fictitiously present > > on the new link consuming resources. This is because > > packets sent to CoA-2 goto new AR's proxy ND cache, which > > is 1 or 2 packets big. > > => Well, I assume you're saying that because of > the HI/HAck transfer? These messages were introduced > to avoid DAD, however, the draft is very vague about > whether the nAR will actually perform DAD on behalf > of the MN. In fact section 6.1.1 says that if the AR > doesn't then the MN may use the nCoA while performing > DAD. Which essentially means that there is a chance > that another node could already be using this address. > And it also means that the nAR will not necessarily > wait for anything from the MN before forwarding the > traffic. > Last time we discussed this in the DT (a long time ago) > it was suggested that we don't mandate HI/HAck either > but I haven't read rev -03 (or -04 which is the same > thing) yet, so I don't know if this was made clearer. > This draft has undergone revisions :-) In version-4, - HI/HAck must be mandatory "..At the same time the oAR MUST send the HI message to the nAR, .." "..The nAR then MUST respond with a HACK, indicating .." - AR-2 must ensure that CoA-2 is unique. "Upon receipt of the HI message, the nAR MUST first establish whether the nCoA is a valid address on its subnet, performing checks to ensure that it is not a duplicate. If the nCoA is legal and acceptable to the nAR, the nAR MUST add the nCoA to the Neighbor Cache for a short time period so it can defend it" - AR-2 maintains proxy ND cache until the MN declares its presence on AR-2 (using NA). Text in above bullet can be made more specific to say proxy ND cache. > > > > > [Rajeev:] This is not possible with FMIPv6. Packets only > > goto new AR's proxy ND cache. Besides, once FBU is sent, > > old AR does not forward packets to MN. I described this in > > some detail to Erik's message.. > > => So you're essentially saying that HI/Hack are always > mandated? If so then we would have to mandate what > the nAR should do (proxy NS ..etc) when it receives > HI. There is also the chance that the MN might already > move before the nAR sends an NS to verify the nCoA, > and the MN might reply to that. > The last point is good. The MN would send an F-NA if it has not received an F-BAck, without receiving which, the MN must not assume that it already has CoA-2. So, it must not respond to NS from AR-2. The latest version of the draft should have this information. I also did some analysis of scenarios last year (cf. posting dated Mar 13, 2001). You might want to have a look at both. In any case, I agree that the draft needs a lot of editing, in addition to clearly spelling out security considerations in binding CoA-1 to CoA-2. Seems like I will have my hands full :-) Regards, -Rajeev > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 14:49:40 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06259 for ; Thu, 4 Apr 2002 14:49:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00131; Thu, 4 Apr 2002 12:49:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26318; Thu, 4 Apr 2002 11:49:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JmhKL017433 for ; Thu, 4 Apr 2002 11:48:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34JmhVV017432 for mobile-ip-dist; Thu, 4 Apr 2002 11:48:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JmdKL017425 for ; Thu, 4 Apr 2002 11:48:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11241 for ; Thu, 4 Apr 2002 11:48:41 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06160 for ; Thu, 4 Apr 2002 12:48:41 -0700 (MST) 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 LAA14671; Thu, 4 Apr 2002 11:48:41 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34JmeT29526; Thu, 4 Apr 2002 11:48:40 -0800 X-mProtect: <200204041948> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlww5FW; Thu, 04 Apr 2002 11:48:38 PST Message-ID: <3CACAE17.8073CB65@iprg.nokia.com> Date: Thu, 04 Apr 2002 11:48:39 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Luca Salgarelli CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941852.24852.94.camel@valjean> <3CAC918D.9418939D@iprg.nokia.com> <1017947715.22420.110.camel@valjean> <3CACACC1.EC4DFECC@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello again, One further clarification: If a mobile node uses an advertised challenge, it loses the option of ever using the last challenge from a Registration Reply, but not the option of using future such challenges. The latter additional restriction could have been a possible interpretation of my suggestion in the text below. Regards, Charlie P. "Charles E. Perkins" wrote: > > Luca Salgarelli wrote: > > >>> The spec says, rightfully, that the FA should make sure to check that a > >>> mobile does not reuse a previously used challenge. And this is the > >>> sticky point. To satisfy it, it is not enough for the FA to maintain a > >>> global list of "valid advertised challenges" only. It has to keep: > >>> > >>> 1) A global windowed list of valid advertised challenges > >>> 2) A per-mobile list of the last challenge sent in a reply > >>> > >>> as you say, but also: > >>> > >>> 3) A *per-mobile* list of recently used challenges from (1) > > I think I said the wrong thing. What if, when a mobile node uses > a challenge from (1), it causes (2) to be nullified. Thus, if a > mobile node uses one of the advertised challenges, it loses the option > of (ever) using the challenge from a Registration Reply. > > Is this better? > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 14:53:53 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06393 for ; Thu, 4 Apr 2002 14:53:53 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09299; Thu, 4 Apr 2002 12:53:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28133; Thu, 4 Apr 2002 11:53:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JqIKL017552 for ; Thu, 4 Apr 2002 11:52:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34JqH80017551 for mobile-ip-dist; Thu, 4 Apr 2002 11:52:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34JqEKL017544 for ; Thu, 4 Apr 2002 11:52:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23074 for ; Thu, 4 Apr 2002 11:52:17 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA21577 for ; Thu, 4 Apr 2002 12:52:16 -0700 (MST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu Apr 4 14:51:15 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g34JpSo42456 for ; Thu, 4 Apr 2002 14:51:28 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA27576 for ; Thu, 4 Apr 2002 14:51:28 -0500 (EST) Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3CACACC1.EC4DFECC@iprg.nokia.com> References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941852.24852.94.camel@valjean> <3CAC918D.9418939D@iprg.nokia.com> <1017947715.22420.110.camel@valjean> <3CACACC1.EC4DFECC@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 04 Apr 2002 14:51:28 -0500 Message-Id: <1017949888.24852.128.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > >>> The spec says, rightfully, that the FA should make sure to check that a > >>> mobile does not reuse a previously used challenge. And this is the > >>> sticky point. To satisfy it, it is not enough for the FA to maintain a > >>> global list of "valid advertised challenges" only. It has to keep: > >>> > >>> 1) A global windowed list of valid advertised challenges > >>> 2) A per-mobile list of the last challenge sent in a reply > >>> > >>> as you say, but also: > >>> > >>> 3) A *per-mobile* list of recently used challenges from (1) > > I think I said the wrong thing. What if, when a mobile node uses > a challenge from (1), it causes (2) to be nullified. Thus, if a > mobile node uses one of the advertised challenges, it loses the option > of (ever) using the challenge from a Registration Reply. > > Is this better? Unfortunately, probably not. The problem is not the relationship between (1) and (2). The problem is keeping track of which mobile used which challenge *from the list of challenges sent in broadcast advertisements*. To repeat, the way (1), (2) and (3) should be used (in my opinion) is the following: 1: if (C is not in (1)) and (C is not in (2)) 2: return UNKNOWN_CHALLENGE 3: else 4: if (C is in (3)) 5: return STALE_CHALLENGE 6: else 7: add C to (3) 8: proceed with processing of registration request So, in light of this, I don't think your suggestion would work. If we want to abstract it, the problem is caused by the fact that broadcast challenges are seen by all mobiles, but the check on who used them must be done on a per-mobile basis. I am sure protocol theorists could formalize the problem much better than I do. Luca From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 15:19:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07219 for ; Thu, 4 Apr 2002 15:19:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24403; Thu, 4 Apr 2002 13:18:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06980; Thu, 4 Apr 2002 12:18:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34KHiKL017772 for ; Thu, 4 Apr 2002 12:17:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34KHi27017771 for mobile-ip-dist; Thu, 4 Apr 2002 12:17:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34KHfKL017764 for ; Thu, 4 Apr 2002 12:17:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19462 for ; Thu, 4 Apr 2002 12:17:43 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20813 for ; Thu, 4 Apr 2002 12:17:43 -0800 (PST) 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 MAA17003; Thu, 4 Apr 2002 12:17:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34KHgR09362; Thu, 4 Apr 2002 12:17:42 -0800 X-mProtect: <200204042017> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhKcB8o; Thu, 04 Apr 2002 12:17:41 PST Message-ID: <3CACB4E5.41517CE2@iprg.nokia.com> Date: Thu, 04 Apr 2002 12:17:41 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Luca Salgarelli CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941852.24852.94.camel@valjean> <3CAC918D.9418939D@iprg.nokia.com> <1017947715.22420.110.camel@valjean> <3CACACC1.EC4DFECC@iprg.nokia.com> <1017949888.24852.128.camel@valjean> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello again Luca, I am not totally sure I see the problem, but one improvement would be to reduce the amount of searching and list management. So, we could say that: - If mobile uses an advertised challenge, it can no longer use the Reply challenge, nor any previously advertised challenge. - The foreign agent has to remember the last challenge used by the mobile node, and an ordered list of recently advertised challenges. If I apply this to your algorithm: > 1: if (C is not in (1)) and (C is not in (2)) > 2: return UNKNOWN_CHALLENGE /* so far, no problems, right...? */ > 3: else > 4: if (C is in (3)) /* Here, maybe if (C "not-later-than" "last-challenge") */ > 5: return STALE_CHALLENGE > 6: else > 7: add C to (3) /* Here, maybe C <-- "last-challenge"; (assignment) */ > 8: proceed with processing of registration request Is this better? Regards, Charlie P. Luca Salgarelli wrote: > > > >>> The spec says, rightfully, that the FA should make sure to check that a > > >>> mobile does not reuse a previously used challenge. And this is the > > >>> sticky point. To satisfy it, it is not enough for the FA to maintain a > > >>> global list of "valid advertised challenges" only. It has to keep: > > >>> > > >>> 1) A global windowed list of valid advertised challenges > > >>> 2) A per-mobile list of the last challenge sent in a reply > > >>> > > >>> as you say, but also: > > >>> > > >>> 3) A *per-mobile* list of recently used challenges from (1) > > > > I think I said the wrong thing. What if, when a mobile node uses > > a challenge from (1), it causes (2) to be nullified. Thus, if a > > mobile node uses one of the advertised challenges, it loses the option > > of (ever) using the challenge from a Registration Reply. > > > > Is this better? > > Unfortunately, probably not. The problem is not the relationship between > (1) and (2). The problem is keeping track of which mobile used which > challenge *from the list of challenges sent in broadcast > advertisements*. > > To repeat, the way (1), (2) and (3) should be used (in my opinion) is > the following: > > 1: if (C is not in (1)) and (C is not in (2)) > 2: return UNKNOWN_CHALLENGE > 3: else > 4: if (C is in (3)) > 5: return STALE_CHALLENGE > 6: else > 7: add C to (3) > 8: proceed with processing of registration request > > So, in light of this, I don't think your suggestion would work. > > If we want to abstract it, the problem is caused by the fact that > broadcast challenges are seen by all mobiles, but the check on who used > them must be done on a per-mobile basis. I am sure protocol theorists > could formalize the problem much better than I do. > > Luca From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 16:18:19 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09088 for ; Thu, 4 Apr 2002 16:18:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05675; Thu, 4 Apr 2002 13:17:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03387; Thu, 4 Apr 2002 13:17:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34LFwKL017962 for ; Thu, 4 Apr 2002 13:15:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34LFwHt017961 for mobile-ip-dist; Thu, 4 Apr 2002 13:15:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34LFsKL017954 for ; Thu, 4 Apr 2002 13:15:54 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g34LFvg07753 for ; Thu, 4 Apr 2002 16:15:57 -0500 (EST) Date: Thu, 4 Apr 2002 16:16:53 -0500 (EST) From: "Steven M. Glass" Subject: [mobile-ip] Reply-All behaviour change To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mobile-ip list responders, This Monday, 8 April, we should have the 'reply-all' behaviour of the list fixed in that 'reply-all' will send messages to the original sender in addition to the list (plus any CCs, of course). As a byproduct of this change, 'reply' will NOT respond to the list, and will ONLY send your reply to the original sender. I've selected Monday as the swap-day so if there are any problems they won't happen over the weekend. If you notice any strange behaviour as a result of the change (that is weird artifacts of a 'reply-all' you've made), please let me know. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 16:47:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10038 for ; Thu, 4 Apr 2002 16:47:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26653; Thu, 4 Apr 2002 14:47:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06380; Thu, 4 Apr 2002 13:47:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34LkhKL018119 for ; Thu, 4 Apr 2002 13:46:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34Lkh56018118 for mobile-ip-dist; Thu, 4 Apr 2002 13:46:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34LkfKL018111 for ; Thu, 4 Apr 2002 13:46:41 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12641 for ; Thu, 4 Apr 2002 16:46:44 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA25440 for mobile-ip@sunroof.eng.sun.com; Thu, 4 Apr 2002 16:47:40 -0500 (EST) Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34LWaKL018069 for ; Thu, 4 Apr 2002 13:32:36 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g34LWdg09150 for ; Thu, 4 Apr 2002 16:32:39 -0500 (EST) Date: Thu, 4 Apr 2002 16:33:35 -0500 (EST) From: "Steven M. Glass" Subject: [mobile-ip] Large attachment rant To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I really feel I need to ask this again - please, please, please don't send attachments to the list. Even if it's less than 40K, it's going into the archives, and taking up space. If your email is over 40K the only place it's going is into the owner-mobile-ip inbox, and I can't in good conscience approve these. The IESG draft editor announces drafts, and provides web-pointers because it's the correct way to distribute your documents. People who are interested will download them. If you don't have your own corner of the web to put them on, by all means attach them to any/all interested parties via _CC_ methods, not via an automated distribution to nearly 1700 subscribers. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 16:49:14 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10093 for ; Thu, 4 Apr 2002 16:49:14 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27465; Thu, 4 Apr 2002 14:49:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07196; Thu, 4 Apr 2002 13:48:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34LmJKL018152 for ; Thu, 4 Apr 2002 13:48:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34LmIhW018148 for mobile-ip-dist; Thu, 4 Apr 2002 13:48:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34LmFKL018140 for ; Thu, 4 Apr 2002 13:48:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20973 for ; Thu, 4 Apr 2002 13:48:18 -0800 (PST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14415 for ; Thu, 4 Apr 2002 14:48:18 -0700 (MST) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g34LmH212354 for ; Thu, 4 Apr 2002 16:48:17 -0500 (EST) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA25938; Thu, 4 Apr 2002 16:48:14 -0500 (EST) Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA25930; Thu, 4 Apr 2002 16:48:13 -0500 (EST) Message-ID: <3CACCA1E.72AFA8D0@lucent.com> Date: Thu, 04 Apr 2002 16:48:14 -0500 From: Erik Anderlind X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941852.24852.94.camel@valjean> <3CAC918D.9418939D@iprg.nokia.com> <1017947715.22420.110.camel@valjean> <3CACACC1.EC4DFECC@iprg.nokia.com> <1017949888.24852.128.camel@valjean> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Luca, Why don't you just maintain a time stamped list of when FA changed advertisment. Same advertisement used for all mobiles. If there is a mobile request, check the global list which chalenge to use. In practice would only need to store a couple of values. ...Erik Luca Salgarelli wrote: > > > >>> The spec says, rightfully, that the FA should make sure to check that a > > >>> mobile does not reuse a previously used challenge. And this is the > > >>> sticky point. To satisfy it, it is not enough for the FA to maintain a > > >>> global list of "valid advertised challenges" only. It has to keep: > > >>> > > >>> 1) A global windowed list of valid advertised challenges > > >>> 2) A per-mobile list of the last challenge sent in a reply > > >>> > > >>> as you say, but also: > > >>> > > >>> 3) A *per-mobile* list of recently used challenges from (1) > > > > I think I said the wrong thing. What if, when a mobile node uses > > a challenge from (1), it causes (2) to be nullified. Thus, if a > > mobile node uses one of the advertised challenges, it loses the option > > of (ever) using the challenge from a Registration Reply. > > > > Is this better? > > Unfortunately, probably not. The problem is not the relationship between > (1) and (2). The problem is keeping track of which mobile used which > challenge *from the list of challenges sent in broadcast > advertisements*. > > To repeat, the way (1), (2) and (3) should be used (in my opinion) is > the following: > > 1: if (C is not in (1)) and (C is not in (2)) > 2: return UNKNOWN_CHALLENGE > 3: else > 4: if (C is in (3)) > 5: return STALE_CHALLENGE > 6: else > 7: add C to (3) > 8: proceed with processing of registration request > > So, in light of this, I don't think your suggestion would work. > > If we want to abstract it, the problem is caused by the fact that > broadcast challenges are seen by all mobiles, but the check on who used > them must be done on a per-mobile basis. I am sure protocol theorists > could formalize the problem much better than I do. > > Luca From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 17:28:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11174 for ; Thu, 4 Apr 2002 17:28:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09793; Thu, 4 Apr 2002 15:28:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01953; Thu, 4 Apr 2002 14:28:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34MRNKL018644 for ; Thu, 4 Apr 2002 14:27:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34MRM9f018643 for mobile-ip-dist; Thu, 4 Apr 2002 14:27:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34MRJKL018636 for ; Thu, 4 Apr 2002 14:27:19 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00143 for ; Thu, 4 Apr 2002 14:27:21 -0800 (PST) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13189 for ; Thu, 4 Apr 2002 14:27:21 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34MRI620727 for ; Thu, 4 Apr 2002 14:27:18 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 15:48:52 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB6F@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues Date: Thu, 4 Apr 2002 15:48:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC22.80509CD0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DC22.80509CD0 Content-Type: text/plain; charset="iso-8859-1" Hello all; I think this an implementation specific issue. However, FA keeps track of the following challenges: 1. Broadcast & unicast with a default window of 2 - per Mobile. 2. Challenge in last Registration Reply message, ONLY one - per Mobile. 3. List of USED "STALE" challenges (minimum 1 & maximum is implementation specific) - per Mobile. Earlier, I suggested to introduce a USED_CHALLENGE_WINDOW but Charlie had a better idea by leaving this open to implementation specific. RFC3012-bis section 1.1 Terminology : " previously used challenge Any challenge that has been used by the mobile node in a Registration Request message and accepted by the Foreign Agent as a valid challenge by relaying or generating a corresponding Registration Reply message. stale challenge Same as "previously used challenge". The Foreign Agent may not be able to keep records for all stale challenges. " It is clear that the FA has the option to track all stale challenges or only ONE. Luca; Please see one comment in line about the algorithm you presented. Regards; Ahmad Muhanna > -----Original Message----- > From: Luca Salgarelli [mailto:salga@bell-labs.com] > Sent: Thursday, April 04, 2002 1:15 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues > > > Charlie, > > please see comments inline. > > On Thu, 2002-04-04 at 12:46, Charles E. Perkins wrote: > > Luca Salgarelli wrote: > > > > > > Hello Charlie. > > > > > > > My original conception of this operation was that the foreign > > > > agent would have a _short_ list of recent acceptable challenges. > > > > That is easily checked when a mobile node sends a Registration > > > > Request. The challenges would be advertised, and available for > > > > use by multiple mobile nodes. > > > > > > I think there is more to it than it appears. > > > > > > The spec says, rightfully, that the FA should make sure > to check that a > > > mobile does not reuse a previously used challenge. And this is the > > > sticky point. To satisfy it, it is not enough for the FA > to maintain a > > > global list of "valid advertised challenges" only. It has to keep: > > > > > > 1) A global windowed list of valid advertised challenges > > > 2) A per-mobile list of the last challenge sent in a reply > > > > > > as you say, but also: > > > > > > 3) A *per-mobile* list of recently used challenges from (1) > > > > > > Now, (1) is not a problem because it should be short. Same for (2) > > > because it is always composed of one entry only -- as you > suggested, I > > > agree that the window of the challenges sent in replies > should always be > > > '1'. > > > > > > I have problems with (3), if the window is larger than one. As the > > > mobile uses challenges from advertisements, we have to > add them to (3). > > > But we don't want (3) to grow indefinitely, so we want to > delete the > > > ones that were already there and that we don't possibly > need anymore. > > > > What if we say that, if a mobile node uses a challenge from > (1), that > > challenge _replaces_ the challenge (if any) from (3). Thus, this > > "invalidates" the option to use any challenge that was supplied from > > a Registration Request. > > > > I don't think this would impose any hardship, and it would seemingly > > eliminate the problem that you have identified. > > Hmmm, I am not sure you could do that. Let's analyze: (3) contains a > list of challenges successfully used by a client in the recent past. > (3), along with (1) and (2), are kept by the FA so that it can run the > following checks when it receives a challenge C in a registration > request: > > 1: if (C is not in (1)) and (C is not in (2)) > 2: return UNKNOWN_CHALLENGE > 3: else > 4: if (C is in (3)) > 5: return STALE_CHALLENGE No challenge will ever come here. Any challenge classified as STALE_CHALLENGE is a challenge which does not exist in (1) nor in (2). Then you will always get UNKNOWN_CHALLENGE. you need to modify line 1 to: if (C is not in (1)) and (C is not in (2)) and (C is not in (3)) and keep the rest as is. > 6: else > 7: add C to (3) > 8: proceed with processing of registration request > > Now, if I understand your suggestion correctly, you are > saying that the > FA at line 7 should replace the challenge C' (if any) that is > already in > (3). > > But this wouldn't work: if the window is larger than one, a malicious > mobile could now replay the older request that contained C', > and the FA > would let it through. > > Am I misintrepreting your suggestion? > > Luca > > Charlie also wrote: > > > Furthermore, we will probably also have to keep (3) alive > even after the > > > mobile de-registers, to make sure that an attacker does > not replay a > > > request that used one of the still valid challenges > values that this > > > mobile recently used (and that therefore is in (3)). > > > > After deregistration, from the above, this would not impose > very much > > additional hardship. In fact, even when there is nothing from (3), > > the foreign agent should keep this information around. > > > > Regards, > > Charlie P. > > > ------_=_NextPart_001_01C1DC22.80509CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012-bis: compatibility issues

Hello all;
I think this an implementation specific = issue.

However, FA keeps track of the following = challenges:
1. Broadcast & unicast with a default window of = 2 - per Mobile.
2. Challenge in last Registration Reply message, = ONLY one - per Mobile.
3. List of USED "STALE" challenges = (minimum 1 & maximum is implementation specific) - per = Mobile.

Earlier, I suggested to introduce a = USED_CHALLENGE_WINDOW but Charlie had a better idea by leaving this = open to implementation specific.

RFC3012-bis section 1.1 Terminology :
"
      previously used = challenge
          &nb= sp;    Any challenge that has been used by the mobile = node in a
          &nb= sp;    Registration Request message and accepted by the = Foreign
          &nb= sp;    Agent as a valid challenge by relaying or = generating a
          &nb= sp;    corresponding Registration Reply message.

      stale challenge
          &nb= sp;    Same as "previously used = challenge".  The Foreign Agent
          &nb= sp;    may not be able to keep records for all stale = challenges.
"
It is clear that the FA has the option to track all = stale challenges or only ONE.


Luca;
Please see one comment in line about the algorithm = you presented.


Regards;
Ahmad Muhanna


> -----Original Message-----
> From: Luca Salgarelli [mailto:salga@bell-labs.com]
> Sent: Thursday, April 04, 2002 1:15 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] RFC3012-bis: = compatibility issues
>
>
> Charlie,
>
> please see comments inline.
>
> On Thu, 2002-04-04 at 12:46, Charles E. Perkins = wrote:
> > Luca Salgarelli wrote:
> > >
> > > Hello Charlie.
> > >
> > > > My original conception of this = operation was that the foreign
> > > > agent would have a _short_ list = of recent acceptable challenges.
> > > > That is easily checked when a = mobile node sends a Registration
> > > > Request.  The challenges = would be advertised, and available for
> > > > use by multiple mobile = nodes.
> > >
> > > I think there is more to it than it = appears.
> > >
> > > The spec says, rightfully, that the = FA should make sure
> to check that a
> > > mobile does not reuse a previously = used challenge. And this is the
> > > sticky point. To satisfy it, it is = not enough for the FA
> to maintain a
> > > global list of "valid advertised = challenges" only. It has to keep:
> > >
> > > 1) A global windowed list of valid = advertised challenges
> > > 2) A per-mobile list of the last = challenge sent in a reply
> > >
> > > as you say, but also:
> > >
> > > 3) A *per-mobile* list of recently = used challenges from (1)
> > >
> > > Now, (1) is not a problem because it = should be short. Same for (2)
> > > because it is always composed of one = entry only -- as you
> suggested, I
> > > agree that the window of the = challenges sent in replies
> should always be
> > > '1'.
> > >
> > > I have problems with (3), if the = window is larger than one. As the
> > > mobile uses challenges from = advertisements, we have to
> add them to (3).
> > > But we don't want (3) to grow = indefinitely, so we want to
> delete the
> > > ones that were already there and that = we don't possibly
> need anymore.
> >
> > What if we say that, if a mobile node uses = a challenge from
> (1), that
> > challenge _replaces_ the challenge (if = any) from (3).  Thus, this
> > "invalidates" the option to use = any challenge that was supplied from
> > a Registration Request.
> >
> > I don't think this would impose any = hardship, and it would seemingly
> > eliminate the problem that you have = identified.
>
> Hmmm, I am not sure you could do that. Let's = analyze: (3) contains a
> list of challenges successfully used by a = client in the recent past.
> (3), along with (1) and (2), are kept by the FA = so that it can run the
> following checks when it receives a challenge C = in a registration
> request:
>
> 1: if (C is not in (1)) and (C is not in = (2))
> 2:    return = UNKNOWN_CHALLENGE
> 3: else
> 4:    if (C is in (3))
> 5:        = return STALE_CHALLENGE

No challenge will ever come here. Any challenge = classified as STALE_CHALLENGE is
a challenge which does not exist in (1) nor in (2). = Then you will always get UNKNOWN_CHALLENGE.

you need to modify line 1 to:
if (C is not in (1)) and (C is not in (2)) and (C is = not in (3))

and keep the rest as is.

> 6: else
> 7:    add C to (3)
> 8:    proceed with processing of = registration request
>
> Now, if I understand your suggestion correctly, = you are
> saying that the
> FA at line 7 should replace the challenge C' = (if any) that is
> already in
> (3).
>
> But this wouldn't work: if the window is larger = than one, a malicious
> mobile could now replay the older request that = contained C',
> and the FA
> would let it through.
>
> Am I misintrepreting your suggestion?
>
> Luca
>
> Charlie also wrote:
> > > Furthermore, we will probably also = have to keep (3) alive
> even after the
> > > mobile de-registers, to make sure = that an attacker does
> not replay a
> > > request that used one of the still = valid challenges
> values that this
> > > mobile recently used (and that = therefore is in (3)).
> >
> > After deregistration, from the above, this = would not impose
> very much
> > additional hardship.  In fact, even = when there is nothing from (3),
> > the foreign agent should keep this = information around.
> >
> > Regards,
> > Charlie P.
>
>
>

------_=_NextPart_001_01C1DC22.80509CD0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 17:57:30 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11945 for ; Thu, 4 Apr 2002 17:57:30 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23822; Thu, 4 Apr 2002 15:57:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09526; Thu, 4 Apr 2002 14:57:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34MuIKL018776 for ; Thu, 4 Apr 2002 14:56:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34MuImR018775 for mobile-ip-dist; Thu, 4 Apr 2002 14:56:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34MuFKL018768 for ; Thu, 4 Apr 2002 14:56:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09319 for ; Thu, 4 Apr 2002 14:56:17 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA08539 for ; Thu, 4 Apr 2002 14:56:16 -0800 (PST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Apr 4 17:55:04 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g34MtHk82135 for ; Thu, 4 Apr 2002 17:55:17 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA05752 for ; Thu, 4 Apr 2002 17:55:16 -0500 (EST) Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3CACB4E5.41517CE2@iprg.nokia.com> References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941852.24852.94.camel@valjean> <3CAC918D.9418939D@iprg.nokia.com> <1017947715.22420.110.camel@valjean> <3CACACC1.EC4DFECC@iprg.nokia.com> <1017949888.24852.128.camel@valjean> <3CACB4E5.41517CE2@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 04 Apr 2002 17:55:16 -0500 Message-Id: <1017960916.30437.53.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Charlie. On Thu, 2002-04-04 at 15:17, Charles E. Perkins wrote: > Hello again Luca, > > I am not totally sure I see the problem, but one improvement > would be to reduce the amount of searching and list management. > So, we could say that: > > - If mobile uses an advertised challenge, it can no longer use > the Reply challenge, nor any previously advertised challenge. I think that even a subset of this would at least limit the scalability problems: - If a mobile uses an advertised challenge, it can no longer use any previously advertised challenges. I think the addition of the following text at the end of the last paragraph on page 5 of draft-ietf-mobileip-rfc3012bis-01 should reflect this: The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in last Registration Reply issued to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. If the Challenge is not one of the recently advertised values, the foreign Agent SHOULD send a Registration Reply with Code value UNKNOWN_CHALLENGE (see section 10). In addition, if the Challenge is one of the recently advertised values, but was issued before a Challenge already used by the Mobile Node, the Foreign Agent SHOULD send a Registration Reply with code value STALE_CHALLENGE. What do you think? Thanks Luca > > - The foreign agent has to remember the last challenge used > by the mobile node, and an ordered list of recently advertised > challenges. > > If I apply this to your algorithm: > > > 1: if (C is not in (1)) and (C is not in (2)) > > 2: return UNKNOWN_CHALLENGE > > /* so far, no problems, right...? */ > > > 3: else > > 4: if (C is in (3)) > > /* Here, maybe if (C "not-later-than" "last-challenge") */ > > > 5: return STALE_CHALLENGE > > 6: else > > 7: add C to (3) > > /* Here, maybe C <-- "last-challenge"; (assignment) */ > > > 8: proceed with processing of registration request > > Is this better? > > Regards, > Charlie P. > > > > Luca Salgarelli wrote: > > > > > >>> The spec says, rightfully, that the FA should make sure to check that a > > > >>> mobile does not reuse a previously used challenge. And this is the > > > >>> sticky point. To satisfy it, it is not enough for the FA to maintain a > > > >>> global list of "valid advertised challenges" only. It has to keep: > > > >>> > > > >>> 1) A global windowed list of valid advertised challenges > > > >>> 2) A per-mobile list of the last challenge sent in a reply > > > >>> > > > >>> as you say, but also: > > > >>> > > > >>> 3) A *per-mobile* list of recently used challenges from (1) > > > > > > I think I said the wrong thing. What if, when a mobile node uses > > > a challenge from (1), it causes (2) to be nullified. Thus, if a > > > mobile node uses one of the advertised challenges, it loses the option > > > of (ever) using the challenge from a Registration Reply. > > > > > > Is this better? > > > > Unfortunately, probably not. The problem is not the relationship between > > (1) and (2). The problem is keeping track of which mobile used which > > challenge *from the list of challenges sent in broadcast > > advertisements*. > > > > To repeat, the way (1), (2) and (3) should be used (in my opinion) is > > the following: > > > > 1: if (C is not in (1)) and (C is not in (2)) > > 2: return UNKNOWN_CHALLENGE > > 3: else > > 4: if (C is in (3)) > > 5: return STALE_CHALLENGE > > 6: else > > 7: add C to (3) > > 8: proceed with processing of registration request > > > > So, in light of this, I don't think your suggestion would work. > > > > If we want to abstract it, the problem is caused by the fact that > > broadcast challenges are seen by all mobiles, but the check on who used > > them must be done on a per-mobile basis. I am sure protocol theorists > > could formalize the problem much better than I do. > > > > Luca From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 18:04:11 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12100 for ; Thu, 4 Apr 2002 18:04:11 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26447; Thu, 4 Apr 2002 16:04:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04253; Thu, 4 Apr 2002 15:03:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34N3GKL018882 for ; Thu, 4 Apr 2002 15:03:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34N3GiD018881 for mobile-ip-dist; Thu, 4 Apr 2002 15:03:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34N3DKL018874 for ; Thu, 4 Apr 2002 15:03:13 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11387 for ; Thu, 4 Apr 2002 15:03:15 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23867 for ; Thu, 4 Apr 2002 15:03:15 -0800 (PST) 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 PAA26677 for ; Thu, 4 Apr 2002 15:03:14 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34N3Da21879 for ; Thu, 4 Apr 2002 15:03:13 -0800 X-mProtect: <200204042303> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddXC3lj; Thu, 04 Apr 2002 15:03:11 PST Message-ID: <3CACDBBB.446FEEC6@iprg.nokia.com> Date: Thu, 04 Apr 2002 15:03:24 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues References: <1017868954.22420.36.camel@valjean> <3CAB84AC.EA65291B@iprg.nokia.com> <1017877180.24852.56.camel@valjean> <3CAC85BA.54AF7F85@iprg.nokia.com> <1017941852.24852.94.camel@valjean> <3CAC918D.9418939D@iprg.nokia.com> <1017947715.22420.110.camel@valjean> <3CACACC1.EC4DFECC@iprg.nokia.com> <1017949888.24852.128.camel@valjean> <3CACB4E5.41517CE2@iprg.nokia.com> <1017960916.30437.53.camel@valjean> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Luca, This is fine with me. If there are no other objections, I'll put it into the soon-to-be reissued RFC3012bis. Regards, Charlie P. Luca Salgarelli wrote: > Hello Charlie. > > On Thu, 2002-04-04 at 15:17, Charles E. Perkins wrote: > > Hello again Luca, > > > > I am not totally sure I see the problem, but one improvement > > would be to reduce the amount of searching and list management. > > So, we could say that: > > > > - If mobile uses an advertised challenge, it can no longer use > > the Reply challenge, nor any previously advertised challenge. > > I think that even a subset of this would at least limit the scalability > problems: > > - If a mobile uses an advertised challenge, it can no longer use > any previously advertised challenges. > > I think the addition of the following text at the end of the last > paragraph on page 5 of draft-ietf-mobileip-rfc3012bis-01 should reflect > this: > > The Foreign Agent MUST NOT accept any Challenge in the Registration > Request unless it was offered in last Registration Reply issued > to the Mobile Node, or else advertised as one of the last > CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > immediately preceding Agent advertisements. If the Challenge is > not one of the recently advertised values, the foreign Agent SHOULD > send a Registration Reply with Code value UNKNOWN_CHALLENGE (see > section 10). In addition, if the Challenge is one of > the recently advertised values, but was issued before a Challenge > already used by the Mobile Node, the Foreign Agent SHOULD send a > Registration Reply with code value STALE_CHALLENGE. > > What do you think? > > Thanks > Luca > > > > > - The foreign agent has to remember the last challenge used > > by the mobile node, and an ordered list of recently advertised > > challenges. > > > > If I apply this to your algorithm: > > > > > 1: if (C is not in (1)) and (C is not in (2)) > > > 2: return UNKNOWN_CHALLENGE > > > > /* so far, no problems, right...? */ > > > > > 3: else > > > 4: if (C is in (3)) > > > > /* Here, maybe if (C "not-later-than" "last-challenge") */ > > > > > 5: return STALE_CHALLENGE > > > 6: else > > > 7: add C to (3) > > > > /* Here, maybe C <-- "last-challenge"; (assignment) */ > > > > > 8: proceed with processing of registration request > > > > Is this better? > > > > Regards, > > Charlie P. > > > > > > > > Luca Salgarelli wrote: > > > > > > > >>> The spec says, rightfully, that the FA should make sure to check that a > > > > >>> mobile does not reuse a previously used challenge. And this is the > > > > >>> sticky point. To satisfy it, it is not enough for the FA to maintain a > > > > >>> global list of "valid advertised challenges" only. It has to keep: > > > > >>> > > > > >>> 1) A global windowed list of valid advertised challenges > > > > >>> 2) A per-mobile list of the last challenge sent in a reply > > > > >>> > > > > >>> as you say, but also: > > > > >>> > > > > >>> 3) A *per-mobile* list of recently used challenges from (1) > > > > > > > > I think I said the wrong thing. What if, when a mobile node uses > > > > a challenge from (1), it causes (2) to be nullified. Thus, if a > > > > mobile node uses one of the advertised challenges, it loses the option > > > > of (ever) using the challenge from a Registration Reply. > > > > > > > > Is this better? > > > > > > Unfortunately, probably not. The problem is not the relationship between > > > (1) and (2). The problem is keeping track of which mobile used which > > > challenge *from the list of challenges sent in broadcast > > > advertisements*. > > > > > > To repeat, the way (1), (2) and (3) should be used (in my opinion) is > > > the following: > > > > > > 1: if (C is not in (1)) and (C is not in (2)) > > > 2: return UNKNOWN_CHALLENGE > > > 3: else > > > 4: if (C is in (3)) > > > 5: return STALE_CHALLENGE > > > 6: else > > > 7: add C to (3) > > > 8: proceed with processing of registration request > > > > > > So, in light of this, I don't think your suggestion would work. > > > > > > If we want to abstract it, the problem is caused by the fact that > > > broadcast challenges are seen by all mobiles, but the check on who used > > > them must be done on a per-mobile basis. I am sure protocol theorists > > > could formalize the problem much better than I do. > > > > > > Luca From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 18:11:31 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12298 for ; Thu, 4 Apr 2002 18:11:30 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26493; Thu, 4 Apr 2002 15:11:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06594; Thu, 4 Apr 2002 15:11:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34NAIKL018989 for ; Thu, 4 Apr 2002 15:10:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g34NAIaH018988 for mobile-ip-dist; Thu, 4 Apr 2002 15:10:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g34NAFKL018981 for ; Thu, 4 Apr 2002 15:10:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14164 for ; Thu, 4 Apr 2002 15:10:17 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA29609 for ; Thu, 4 Apr 2002 16:10:16 -0700 (MST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Apr 4 18:08:58 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g34N9Bk83179 for ; Thu, 4 Apr 2002 18:09:11 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA06132 for ; Thu, 4 Apr 2002 18:09:11 -0500 (EST) Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCB6F@zrc2c013.us.nortel.com> References: <6B49EDFE974BD51197D70002A56079D801AFCB6F@zrc2c013.us.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 04 Apr 2002 18:09:11 -0500 Message-Id: <1017961751.30436.64.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ahmad. > RFC3012-bis section 1.1 Terminology : > " > previously used challenge > Any challenge that has been used by the mobile node in a > Registration Request message and accepted by the Foreign > Agent as a valid challenge by relaying or generating a > corresponding Registration Reply message. > > stale challenge > Same as "previously used challenge". The Foreign Agent > may not be able to keep records for all stale challenges. > " > It is clear that the FA has the option to track all stale challenges or only > ONE. > Well, I think that the last sentence is a problem in RFC3012-bis. I actually didn't notice it before, so thanks fore pointing that out. If we allow an FA not to keep track of all stale challenges, than I think we are opening a security hole. Imagine this scenario: let's have an FA that keeps a challenge-window of 3. It sends advertisements every 60 seconds. In the past 180 seconds it has sent challenges C1, C2 and C3, in that order. Now legitimate Mobile Node MN sends sends registration request R1 including challenge C2. It gets accepted. A little later MN sends registration request R2 including challenge C3. Now, if the FA does not keep track of both C2 and C3 *per mobile*, let's say it only keeps the last used value (C3), we have a problem. A malicious Mobile Node MAL can replay R1, and it will get accepted, since it is in the valid window, and it is not stale, at least not to the knowledge of the FA. So I think that we should either mandate that FAs MUST keep a valid list of stale challenges, or we introduce the change that Charlie suggested, i.e. if a client uses a challenge from an advertisement, it cannot use any challenges issued in previous advertisements, no matter if they are in the valid window. Cheers Luca > > Luca; > Please see one comment in line about the algorithm you presented. > > > Regards; > Ahmad Muhanna > > > > -----Original Message----- > > From: Luca Salgarelli [mailto:salga@bell-labs.com] > > Sent: Thursday, April 04, 2002 1:15 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues > > > > > > Charlie, > > > > please see comments inline. > > > > On Thu, 2002-04-04 at 12:46, Charles E. Perkins wrote: > > > Luca Salgarelli wrote: > > > > > > > > Hello Charlie. > > > > > > > > > My original conception of this operation was that the foreign > > > > > agent would have a _short_ list of recent acceptable challenges. > > > > > That is easily checked when a mobile node sends a Registration > > > > > Request. The challenges would be advertised, and available for > > > > > use by multiple mobile nodes. > > > > > > > > I think there is more to it than it appears. > > > > > > > > The spec says, rightfully, that the FA should make sure > > to check that a > > > > mobile does not reuse a previously used challenge. And this is the > > > > sticky point. To satisfy it, it is not enough for the FA > > to maintain a > > > > global list of "valid advertised challenges" only. It has to keep: > > > > > > > > 1) A global windowed list of valid advertised challenges > > > > 2) A per-mobile list of the last challenge sent in a reply > > > > > > > > as you say, but also: > > > > > > > > 3) A *per-mobile* list of recently used challenges from (1) > > > > > > > > Now, (1) is not a problem because it should be short. Same for (2) > > > > because it is always composed of one entry only -- as you > > suggested, I > > > > agree that the window of the challenges sent in replies > > should always be > > > > '1'. > > > > > > > > I have problems with (3), if the window is larger than one. As the > > > > mobile uses challenges from advertisements, we have to > > add them to (3). > > > > But we don't want (3) to grow indefinitely, so we want to > > delete the > > > > ones that were already there and that we don't possibly > > need anymore. > > > > > > What if we say that, if a mobile node uses a challenge from > > (1), that > > > challenge _replaces_ the challenge (if any) from (3). Thus, this > > > "invalidates" the option to use any challenge that was supplied from > > > a Registration Request. > > > > > > I don't think this would impose any hardship, and it would seemingly > > > eliminate the problem that you have identified. > > > > Hmmm, I am not sure you could do that. Let's analyze: (3) contains a > > list of challenges successfully used by a client in the recent past. > > (3), along with (1) and (2), are kept by the FA so that it can run the > > following checks when it receives a challenge C in a registration > > request: > > > > 1: if (C is not in (1)) and (C is not in (2)) > > 2: return UNKNOWN_CHALLENGE > > 3: else > > 4: if (C is in (3)) > > 5: return STALE_CHALLENGE > > No challenge will ever come here. Any challenge classified as > STALE_CHALLENGE is > a challenge which does not exist in (1) nor in (2). Then you will always get > UNKNOWN_CHALLENGE. > > you need to modify line 1 to: > if (C is not in (1)) and (C is not in (2)) and (C is not in (3)) > > and keep the rest as is. > > > 6: else > > 7: add C to (3) > > 8: proceed with processing of registration request > > > > Now, if I understand your suggestion correctly, you are > > saying that the > > FA at line 7 should replace the challenge C' (if any) that is > > already in > > (3). > > > > But this wouldn't work: if the window is larger than one, a malicious > > mobile could now replay the older request that contained C', > > and the FA > > would let it through. > > > > Am I misintrepreting your suggestion? > > > > Luca > > > > Charlie also wrote: > > > > Furthermore, we will probably also have to keep (3) alive > > even after the > > > > mobile de-registers, to make sure that an attacker does > > not replay a > > > > request that used one of the still valid challenges > > values that this > > > > mobile recently used (and that therefore is in (3)). > > > > > > After deregistration, from the above, this would not impose > > very much > > > additional hardship. In fact, even when there is nothing from (3), > > > the foreign agent should keep this information around. > > > > > > Regards, > > > Charlie P. > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 20:36:45 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14689 for ; Thu, 4 Apr 2002 20:36:44 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09065; Thu, 4 Apr 2002 18:36:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20427; Thu, 4 Apr 2002 17:36:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g351ZdKL019569 for ; Thu, 4 Apr 2002 17:35:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g351Zccu019568 for mobile-ip-dist; Thu, 4 Apr 2002 17:35:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g351ZZKL019561 for ; Thu, 4 Apr 2002 17:35:35 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g351Zdg24531 for ; Thu, 4 Apr 2002 20:35:39 -0500 (EST) Date: Thu, 4 Apr 2002 20:36:36 -0500 (EST) From: "Steven M. Glass" Subject: [mobile-ip] Issue with IPdst in FA reply when MN home address is 0.0.0.0 To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: As long as we're republishing 3220 anyway... The scenario in question is limited to a non-colocated MN registering with a home address of 0.0.0.0 via a foreign agent. In question is the address the FA uses when sending a registration reply to said MN. My understanding of section 3.7.2.3 (and 3.7.3.2 which refers to using the same rules as section 3.7.2.3) is: 1) - FA rejecting the registration request -> the registration reply is sent to 255.255.255.255 2) - FA forwarding a registration reply from the HA -> a) - if the registration reply contains a non-0 Home addr the FA forwards the reply to the [assigned] home addr b) - if the registration reply contains a home addr of 0.0.0.0, the FA forwards the reply to 255.255.255.255 If that's the correct understanding to have, then my question is directed at 2a above: Why doesn't this behave like bootP, DHCP, etc, and ALWAYS send the reply to 255.255.255.255? Since in all cases the MN doesn't know what address to listen for, making it consistent seems to me to be the right thing to do. I confess to having to read the section something like 3 times to not mis-read it - so what am I missing? Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 22:07:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16653 for ; Thu, 4 Apr 2002 22:07:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28629; Thu, 4 Apr 2002 20:06:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26490; Thu, 4 Apr 2002 19:06:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3535lKL019960 for ; Thu, 4 Apr 2002 19:05:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g3535kWA019959 for mobile-ip-dist; Thu, 4 Apr 2002 19:05:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3535hKL019952 for ; Thu, 4 Apr 2002 19:05:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17508 for ; Thu, 4 Apr 2002 19:05:45 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28237 for ; Thu, 4 Apr 2002 20:05:44 -0700 (MST) 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 TAA10453; Thu, 4 Apr 2002 19:05:44 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3535ic23864; Thu, 4 Apr 2002 19:05:44 -0800 X-mProtect: <200204050305> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOm77NZ; Thu, 04 Apr 2002 19:05:42 PST Message-ID: <3CAD148D.4791EE97@iprg.nokia.com> Date: Thu, 04 Apr 2002 19:05:49 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: t98pth@student.bth.se CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Seamless mobile connection to a internet from a MANET (IPv6) References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Pdr Thorin wrote: > When connecting a MANET to a IPv6 internet, as defined in > draft-wakikawa-manet-globalv6-00.txt (Global Connectivity for IPv6 Mobile > Ad Hoc Networks), with a MobileIPv6 router (a node in the MANET), as in > draft-ernst-mobileip-v6-network-00.txt (Mobile Networks Support in Mobile > IPv6) through a access gateway/network, can one asume that connections to > corresponding nodes outside the MANET can be provided seamless for all > nodes in the MANET when changing the access gateway as in > draft-ietf-seamoby-mm-problem-01.txt (SeaMoby Micro Mobility Problem > Statement). I think it is possible for the connections to be seamless, but that isn't trivially the case. You may have all the problems which are already in evidence within [seamoby]. But to answer your main question, yes the idea is that movement within the MANET is not visible to the correspondent node. Unless, of course, the care-of address changes and the mobile node delivers a Binding Update to the correspondent node. > And what is the advantage of using a MobileIPv6 Router instead of just > using existing routingprotocols to update routing tables throught out the > internet of the location of the MANET? If I understand this question, the Internet Gateway is already presumed to use other routing protocols to update local routing tables. The part that is special is how the Gateway advertises the prefix to the nodes in the ad hoc network, not the part on the Internet side. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 4 22:35:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17838 for ; Thu, 4 Apr 2002 22:35:09 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04931; Thu, 4 Apr 2002 20:34:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01792; Thu, 4 Apr 2002 19:34:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g353XnKL020122 for ; Thu, 4 Apr 2002 19:33:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g353Xnl6020121 for mobile-ip-dist; Thu, 4 Apr 2002 19:33:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g353XkKL020114 for ; Thu, 4 Apr 2002 19:33:46 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01701 for ; Thu, 4 Apr 2002 19:33:49 -0800 (PST) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00234 for ; Thu, 4 Apr 2002 19:33:48 -0800 (PST) Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2A7395D030; Fri, 5 Apr 2002 12:33:46 +0900 (JST) Date: Fri, 05 Apr 2002 12:33:34 +0900 (JST) Message-Id: <20020405.123334.103969984.ernst@sfc.wide.ad.jp> To: mobile-ip@sunroof.eng.sun.com, t98pth@student.bth.se Subject: Re: [mobile-ip] Seamless mobile connection to a internet from a MANET (IPv6) From: Thierry Ernst In-Reply-To: References: X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g353XlKL020115 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit From: Pär Thorén > When connecting a MANET to a IPv6 internet, as defined in > draft-wakikawa-manet-globalv6-00.txt (Global Connectivity for IPv6 Mobile > Ad Hoc Networks), with a MobileIPv6 router (a node in the MANET), as in > draft-ernst-mobileip-v6-network-00.txt (Mobile Networks Support in Mobile > IPv6) through a access gateway/network, can one asume that connections to Pär, Let me point out that my draft draft-ernst-mobileip-v6-network-00.txt has NOTHING to do with Ad-Hoc networking. It is dealing with networks in motion, i.e. an entire network that changes its point of attachment to the Internet, whereas what you are talking about is an ad-hoc network connected to the Internet. The former does not imply the latter, and the latter does not imply the former either. BTW, draft-ernst-mobileip-v6-network-00.txt has expired for 3 months now but is unfortunately still on the IETF web site. It has been replaced recently by the following 2 drafts: draft-ernst-monet-terminology-00.txt draft-ernst-monet-requirements-00.txt And, at the first place you where probably speaking about draft-ernst-mobileip-v6-network-03.txt, which has definitely nothing to do with ad-hoc network since it is only dealing about fixed nodes connected to a mobile router, which changes its AR to the Internet. For more information, see: http://www.nal.motlabs.com/monet/ There is a long history about the confusion between MONET and MANET and the archives of this mailing list. Thierry. > corresponding nodes outside the MANET can be provided seamless for all > nodes in the MANET when changing the access gateway as in > draft-ietf-seamoby-mm-problem-01.txt (SeaMoby Micro Mobility Problem > Statement). > > And what is the advantage of using a MobileIPv6 Router instead of just > using existing routingprotocols to update routing tables throught out the > internet of the location of the MANET? From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 04:18:05 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00513 for ; Fri, 5 Apr 2002 04:18:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21055; Fri, 5 Apr 2002 02:17:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03163; Fri, 5 Apr 2002 01:17:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359GaKL020765 for ; Fri, 5 Apr 2002 01:16:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g359GapK020764 for mobile-ip-dist; Fri, 5 Apr 2002 01:16:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359GWKL020757 for ; Fri, 5 Apr 2002 01:16:32 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21970; Fri, 5 Apr 2002 01:16:35 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-225.France.Sun.COM [129.157.212.225]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g359GWL03398; Fri, 5 Apr 2002 01:16:33 -0800 (PST) Message-ID: <3CAD6B20.AE67F7FE@sun.com> Date: Fri, 05 Apr 2002 11:15:13 +0200 From: gabriel montenegro X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] [Fwd: Using "a bit" as a protection against bidding down / for some thing else] Content-Type: multipart/mixed; boundary="------------BC146800C9727EC73522DAAB" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------BC146800C9727EC73522DAAB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There's been a thread on IPng related to MIPv6. We've just submitted a draft related to this thread. I attach the relevant message. -gabriel --------------BC146800C9727EC73522DAAB Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from engmail1.Eng.Sun.COM (engmail1.Eng.Sun.COM [129.146.1.13]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g359CmL03343 for ; Fri, 5 Apr 2002 01:12:48 -0800 (PST) Received: from sunmail2.Sun.COM (sunmail2.EBay.Sun.COM [129.150.166.10]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21402 for ; Fri, 5 Apr 2002 01:12:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1.Eng.Sun.COM [129.146.1.13]) by sunmail2.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id BAA25925 for ; Fri, 5 Apr 2002 01:13:14 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21397; Fri, 5 Apr 2002 01:12:47 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-225.France.Sun.COM [129.157.212.225]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g359CfL03339; Fri, 5 Apr 2002 01:12:41 -0800 (PST) Message-ID: <3CAD6A39.EFD1FEF0@sun.com> Date: Fri, 05 Apr 2002 11:11:21 +0200 From: gabriel montenegro Reply-To: gab@sun.com X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: Keith Moore , Pekka Nikander , "Hesham Soliman (ERA)" , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Using "a bit" as a protection against bidding down / for some thing else References: <200204041940.g34JeKZ20905@astro.cs.utk.edu> <3CACA556.9030007@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jari Arkko wrote: > It's probably best > to get the mentioned draft out, and deal with all the points that > have been raised, and then get back to the issue. I just submitted the draft: Abstract Mobile IPv6 uses "return routability" to secure route optimization. Even after using this procedure, there are residual threats for which other stronger methods provide protection. Since these are optional, and return routability is the default, an attacker may engage in "bidding down" attacks. These attacks aim at coercing participants in Mobile IPv6 route optimization to forgo the stronger methods for the default return routability. This document discusses what the participants in route optimization can do to deter or alleviate bidding down attacks: the "step down" procedure for the mobile node and the "bit method" at the correspondent node. Before the official announcement you can also find it at: http://www.piuha.net/~jarkko/publications/mipv6/draft-montenegro-mipv6sec-bit-method-00.txt tnx, -gabriel --------------BC146800C9727EC73522DAAB-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 04:46:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00828 for ; Fri, 5 Apr 2002 04:46:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01307; Fri, 5 Apr 2002 02:46:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08974; Fri, 5 Apr 2002 01:46:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359j9KL020906 for ; Fri, 5 Apr 2002 01:45:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g359j8Fq020905 for mobile-ip-dist; Fri, 5 Apr 2002 01:45:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g359j4KL020898 for ; Fri, 5 Apr 2002 01:45:04 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g359ivx21928; Fri, 5 Apr 2002 11:44:58 +0200 (MEST) Date: Fri, 5 Apr 2002 11:00:46 +0200 (CEST) From: Erik Nordmark Subject: RE: [mobile-ip] parameters in draft v16 To: George Tsirtsis Cc: "'Erik Nordmark'" , mobile-ip@sunroof.eng.sun.com, Scott Corson , Vincent Park , Matt Impett In-Reply-To: "Your message with ID" <8C92E23A3E87FB479988285F9E22BE465ABCA6@ftmail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > GT> OK, so you say that the sender of, for example a BU, with a future > parameter extention sould get back a BAck which will include the same > extension. If the extention is not included it means that it was not > understood and ignored. The potential problem is that the BU was > nevertheless accepted and thus a new binding was created. I am wondering if > there is value in supporting extensions that unless accepted should force > the receiver to *drop* rather than ignore the message and return an error. If you don't want the BU to be processed unless the CN supports the new stuff you'll end up doing an extra roundtrip in that case. So it would be ok to define a new "BUnew" MH type for this purpose, get the error back, and fallback to the "BU" MH type. If you want to avoid the extra roundtrip and are using RR then the HoTI/HoT can be used to exchange the capabilities i.e. the MN can find out whether the CN supports the new functionality. So I don't see what a "mandatory option" notion would add here. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 07:22:07 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02661 for ; Fri, 5 Apr 2002 07:22:07 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA29410; Fri, 5 Apr 2002 04:21:55 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10084; Fri, 5 Apr 2002 04:21:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35CL2KL021257 for ; Fri, 5 Apr 2002 04:21:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35CL2Gp021256 for mobile-ip-dist; Fri, 5 Apr 2002 04:21:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35CKxKL021249 for ; Fri, 5 Apr 2002 04:20:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20898 for ; Fri, 5 Apr 2002 04:21:00 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28560 for ; Fri, 5 Apr 2002 05:21:00 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 07:20:58 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCB4@ftmail> From: George Tsirtsis To: "'Erik Nordmark'" Cc: mobile-ip@sunroof.eng.sun.com, Scott Corson , Vincent Park , Matt Impett Subject: RE: [mobile-ip] parameters in draft v16 Date: Fri, 5 Apr 2002 07:20:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik, What you say makes sense, a new MH type can be used with the same results to non-skippable parameters. So, I think it is fine...although it would still be good to define what kind of error is returned on unrecognized MH Type, as you mentioned earlier. Thanks George -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Friday, April 05, 2002 10:01 AM To: George Tsirtsis Cc: 'Erik Nordmark'; mobile-ip@sunroof.eng.sun.com; Scott Corson; Vincent Park; Matt Impett Subject: RE: [mobile-ip] parameters in draft v16 > GT> OK, so you say that the sender of, for example a BU, with a future > parameter extention sould get back a BAck which will include the same > extension. If the extention is not included it means that it was not > understood and ignored. The potential problem is that the BU was > nevertheless accepted and thus a new binding was created. I am wondering if > there is value in supporting extensions that unless accepted should force > the receiver to *drop* rather than ignore the message and return an error. If you don't want the BU to be processed unless the CN supports the new stuff you'll end up doing an extra roundtrip in that case. So it would be ok to define a new "BUnew" MH type for this purpose, get the error back, and fallback to the "BU" MH type. If you want to avoid the extra roundtrip and are using RR then the HoTI/HoT can be used to exchange the capabilities i.e. the MN can find out whether the CN supports the new functionality. So I don't see what a "mandatory option" notion would add here. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 08:27:24 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04023 for ; Fri, 5 Apr 2002 08:27:24 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08213; Fri, 5 Apr 2002 05:27:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02334; Fri, 5 Apr 2002 05:27:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35DOxKL021445 for ; Fri, 5 Apr 2002 05:24:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35DOxfZ021444 for mobile-ip-dist; Fri, 5 Apr 2002 05:24:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35DOuKL021437 for ; Fri, 5 Apr 2002 05:24:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01955 for ; Fri, 5 Apr 2002 05:24:58 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04738 for ; Fri, 5 Apr 2002 06:24:57 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g35DOus7005339 for ; Fri, 5 Apr 2002 15:24:56 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 05 15:23:11 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTBMQV>; Fri, 5 Apr 2002 15:23:11 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC35@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Rajeev Koodli'" , "Hesham Soliman (ERA)" Cc: mobile-ip@sunroof.eng.sun.com, "'Erik Nordmark'" , "'James Kempf'" Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16 Date: Fri, 5 Apr 2002 15:23:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > "Hesham Soliman (ERA)" wrote: > > > > [Rajeev:] I don't believe that with FMIPv6, there are > > > additional assumptions in this sense. The issue is > > > whether old AR has forwarded packets to/from CoA-1. > > > The question of whether that MN is "real" or bogus is > > > a separate identity proving issue. > > > > => But this identity proving is needed to authorise > > the F-BU right? > > Not really! With a CN, a MN does not prove its > identity. It only convinces the CN that it owns the CoA > and HoA using the common trust on routing infrastructure. > Thus, to authorize a BU, you don't need to prove the MN's > identity; it suffices to prove that the MN legitimately (in the > routing sense) owns the addresses in question. => Of course. The relevant identity here is the MN's address(es). > > BTW, this crucial point is also the basis of short-lived BSAs > using RR. A CN does not need to authenticate _who_ owns the > addresses as long as it can be sufficiently sure that it is dealing > with the same entity it did previously. => Yes, so the same question, how does the MN prove this to the oAR? > This draft has undergone revisions :-) In version-4, > > - HI/HAck must be mandatory > "..At the same time the oAR MUST send the HI message to the nAR, .." > "..The nAR then MUST respond with a HACK, indicating .." > > - AR-2 must ensure that CoA-2 is unique. > "Upon receipt of the HI message, the nAR MUST first > establish whether > the nCoA is a valid address on its subnet, performing checks to > ensure that it is not a duplicate. If the nCoA is legal and > acceptable to the nAR, the nAR MUST add the nCoA to the Neighbor > Cache for a short time period so it can defend it" > > - AR-2 maintains proxy ND cache until the MN > declares its presence on AR-2 (using NA). Text in > above bullet can be made more specific to say proxy ND cache. => So I wonder what 6.1.1 is doing in the draft? Also if AR-2 is doing these checks (MUST), then is there a generic way that it can use to do that without extending the handover time? I mean without DAD. I know there is lots of handwaving about this, but I always thought that if we mandate something for all nodes in a transaction, we have to show at least one way of achieving this. > > > [Rajeev:] This is not possible with FMIPv6. Packets only > > > goto new AR's proxy ND cache. Besides, once FBU is sent, > > > old AR does not forward packets to MN. I described this in > > > some detail to Erik's message.. > > > > => So you're essentially saying that HI/Hack are always > > mandated? If so then we would have to mandate what > > the nAR should do (proxy NS ..etc) when it receives > > > HI. There is also the chance that the MN might already > > move before the nAR sends an NS to verify the nCoA, > > and the MN might reply to that. > > > > The last point is good. The MN would send an F-NA if it has > not received an F-BAck, without receiving which, the MN > must not assume that it already has CoA-2. So, it must not > respond to NS from AR-2. > The latest version of the draft should have this information. > I also did some analysis of scenarios last year > (cf. posting dated Mar 13, 2001). You might want to have > a look at both. > > In any case, I agree that the draft needs a lot of editing, in > addition to clearly spelling out security considerations in > binding CoA-1 to CoA-2. Seems like I will have my hands > full :-) => Yep! Hesham > > Regards, > > -Rajeev > > > > > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 09:54:56 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06380 for ; Fri, 5 Apr 2002 09:54:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24239; Fri, 5 Apr 2002 07:54:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19006; Fri, 5 Apr 2002 06:54:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35EqjKL021621 for ; Fri, 5 Apr 2002 06:52:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35EqjH5021620 for mobile-ip-dist; Fri, 5 Apr 2002 06:52:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35EqgKL021613 for ; Fri, 5 Apr 2002 06:52:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20102 for ; Fri, 5 Apr 2002 06:52:43 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23312 for ; Fri, 5 Apr 2002 07:52:42 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g35Eqfs7015342 for ; Fri, 5 Apr 2002 16:52:41 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 05 16:52:40 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTBRC8>; Fri, 5 Apr 2002 16:52:40 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC3B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Seamless mobile connection to a internet from a M ANET (IPv6) Date: Fri, 5 Apr 2002 16:52:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g35EqgKL021614 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > And what is the advantage of using a MobileIPv6 Router > instead of just > using existing routingprotocols to update routing tables > throught out the > internet of the location of the MANET? => If the pool of addresses within the MANET belongs (topologically) to the same domain (of the fixed network), then the advantage is route aggregation with the local domain. If the prefix of the MANET belongs to another domain, then the advantage is route aggregation within the Internet. Hesham > > > regards, > Pär > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 10:17:36 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07072 for ; Fri, 5 Apr 2002 10:17:35 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00288; Fri, 5 Apr 2002 07:17:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22752; Fri, 5 Apr 2002 07:17:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35FFtKL021791 for ; Fri, 5 Apr 2002 07:15:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35FFt5l021790 for mobile-ip-dist; Fri, 5 Apr 2002 07:15:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35FFqKL021783 for ; Fri, 5 Apr 2002 07:15:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26320 for ; Fri, 5 Apr 2002 07:15:49 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13876 for ; Fri, 5 Apr 2002 08:15:48 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 10:15:47 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE4602363F@ftmail> From: Matt Impett To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Issue with IPdst in FA reply when MN home address is 0.0.0.0 Date: Fri, 5 Apr 2002 10:15:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Snip from RFC 2131, section 4.1 "Constructing and Sending DHCP messages": "Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address." As you can see, DHCP will actually try to send replies unicast to the address that is being assigned, exactly how MIP is designed. However, if you read a little further in RFC 2131 (DHCP), it describes that some hosts may not have the ability to receive IP packets sent to addresses they don't yet have. Therefore, they have built in a flag in the DHCPDISCOVER message which requests that the server broadcast the replies back. I don't really know if such hosts exist, but if so I guess they will not work with MIP address assignment?? matt > -----Original Message----- > From: Steven M. Glass [mailto:Steven.Glass@Sun.COM] > Sent: Thursday, April 04, 2002 8:37 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Issue with IPdst in FA reply when MN home address > is 0.0.0.0 > > > As long as we're republishing 3220 anyway... > > The scenario in question is limited to a non-colocated MN > registering with > a home address of 0.0.0.0 via a foreign agent. In question > is the address the > FA uses when sending a registration reply to said MN. > > My understanding of section 3.7.2.3 (and 3.7.3.2 which > refers to using the > same rules as section 3.7.2.3) is: > > 1) - FA rejecting the registration request -> > the registration reply is sent to 255.255.255.255 > > 2) - FA forwarding a registration reply from the HA -> > a) - if the registration reply contains a non-0 Home addr > the FA forwards the reply to the [assigned] home addr > > b) - if the registration reply contains a home addr of > 0.0.0.0, the FA forwards the reply to 255.255.255.255 > > If that's the correct understanding to have, then my > question is directed > at 2a above: > > Why doesn't this behave like bootP, DHCP, etc, and > ALWAYS send the reply > to 255.255.255.255? Since in all cases the MN doesn't know > what address to > listen for, making it consistent seems to me to be the right > thing to do. I > confess to having to read the section something like 3 times > to not mis-read > it - so what am I missing? > > Cheers, > Steve > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 11:20:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08723 for ; Fri, 5 Apr 2002 11:20:00 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16966; Fri, 5 Apr 2002 09:19:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12142; Fri, 5 Apr 2002 08:19:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35GIoKL021982 for ; Fri, 5 Apr 2002 08:18:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35GIoS6021981 for mobile-ip-dist; Fri, 5 Apr 2002 08:18:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35GIjKL021974 for ; Fri, 5 Apr 2002 08:18:45 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00482 for ; Fri, 5 Apr 2002 08:18:48 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00024 for ; Fri, 5 Apr 2002 08:18:47 -0800 (PST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g35GMO4b021239; Fri, 5 Apr 2002 18:22:24 +0200 From: "Henrik Levkowetz" To: Cc: "Phil Roberts" , "Basavaraj Patil" , "Sami Vaarala" Subject: [mobile-ip] draft-ietf-mobileip-nat-traversal-02.txt Date: Fri, 5 Apr 2002 18:18:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I've just submitted a new version of the MIPv4 NAT traversal draft. Thanks to Milind Kulkarni, whose questions prompted several of the clarifications incorporated in this version. Until officially announced, it is available at http://www.levkowetz.com/pub/id/draft-ietf-mobileip-nat-traversal-02.txt There is also an unpaginated version marked with changebars from the -01 draft to the -02 draft available as http://www.levkowetz.com/pub/id/changes-draft-ietf-mobileip-nat-traversal-01..2.txt The changes are: - Added a clarification in 3.1.1 regarding the behaviour of an MN which receives an answer from a HA which does not support NAT traversal - Added references to other sections in section 3.1.2 which introduces the 'R' flag of the UDP Tunnel Request Extension - Added a clarifying 'always' in the first para of section 3.2 - Reworded description of 'F' flag in section 3.2, to make it clearer - Changed SHOULD to MUST for the format of keepalive messages used with 'R' bit registrations (co-located care-of address registered through an FA) in section 4.4 - Added a restriction on sending UDP Tunnel Request Extension in the 'R' bit case as last para of section 4.4 - Added restrictions on the HA when setting up the forward tunnel in the 'R' bit case - Added a clarification to the last error case in section 4.6.1 - Added a section 4.10 with background material for the 'R' bit case. - Added a paragraph to the Security Considerations regarding the forward tunnel setup in the 'R' bit case. - Fixed some typos Regards, Henrik -- Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ Ah! this azure sky! The colour makes my heart jump and my spirit fly. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 11:49:05 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09509 for ; Fri, 5 Apr 2002 11:49:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21809; Fri, 5 Apr 2002 09:48:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08686; Fri, 5 Apr 2002 08:48:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35GluKL022145 for ; Fri, 5 Apr 2002 08:47:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35Gluo0022144 for mobile-ip-dist; Fri, 5 Apr 2002 08:47:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35GlrKL022137 for ; Fri, 5 Apr 2002 08:47:53 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08407 for ; Fri, 5 Apr 2002 08:47:55 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08702; Fri, 5 Apr 2002 08:47:55 -0800 (PST) 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 IAA07336; Fri, 5 Apr 2002 08:47:54 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35GlqK02095; Fri, 5 Apr 2002 08:47:52 -0800 X-mProtect: <200204051647> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtEyfHW; Fri, 05 Apr 2002 08:47:50 PST Message-ID: <3CADD537.DB00A28@iprg.nokia.com> Date: Fri, 05 Apr 2002 08:47:51 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com, "'Erik Nordmark'" , "'James Kempf'" Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6AC35@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, "Hesham Soliman (ERA)" wrote: > > > > > > BTW, this crucial point is also the basis of short-lived BSAs > > using RR. A CN does not need to authenticate _who_ owns the > > addresses as long as it can be sufficiently sure that it is dealing > > with the same entity it did previously. > > => Yes, so the same question, how does the MN > prove this to the oAR? > > The same way RR does. AR-1 has received/sent packets from/to CoA-1. In fact, the association is even stronger here; AR-1 is the router for packets to/from CoA-1. > > This draft has undergone revisions :-) In version-4, > > > > - HI/HAck must be mandatory > > "..At the same time the oAR MUST send the HI message to the nAR, .." > > "..The nAR then MUST respond with a HACK, indicating .." > > > > - AR-2 must ensure that CoA-2 is unique. > > "Upon receipt of the HI message, the nAR MUST first > > establish whether > > the nCoA is a valid address on its subnet, performing checks to > > ensure that it is not a duplicate. If the nCoA is legal and > > acceptable to the nAR, the nAR MUST add the nCoA to the Neighbor > > Cache for a short time period so it can defend it" > > > > - AR-2 maintains proxy ND cache until the MN > > declares its presence on AR-2 (using NA). Text in > > above bullet can be made more specific to say proxy ND cache. > > => So I wonder what 6.1.1 is doing in the draft? > Also if AR-2 is doing these checks (MUST), then > is there a generic way that it can use to do that > without extending the handover time? > I mean without DAD. I know there is lots of handwaving > about this, but I always thought that if we mandate > something for all nodes in a transaction, we have > to show at least one way of achieving this. > I have to take a look at 6.1.1.. Regarding DAD, I am open for suggestions. Regards, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 12:10:16 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10310 for ; Fri, 5 Apr 2002 12:10:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13853; Fri, 5 Apr 2002 10:10:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16317; Fri, 5 Apr 2002 09:09:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35H92KL022365 for ; Fri, 5 Apr 2002 09:09:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35H91c5022364 for mobile-ip-dist; Fri, 5 Apr 2002 09:09:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35H8wKL022357 for ; Fri, 5 Apr 2002 09:08:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15674 for ; Fri, 5 Apr 2002 09:09:01 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02652 for ; Fri, 5 Apr 2002 10:09:00 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35H8tT29508 for ; Fri, 5 Apr 2002 11:08:55 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXVJD0F>; Fri, 5 Apr 2002 11:08:58 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB7D@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues Date: Fri, 5 Apr 2002 11:08:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCC4.8FE53AF0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCC4.8FE53AF0 Content-Type: text/plain; charset="iso-8859-1" Hello Luca; Let us agree on the following: 1. The problem is of tracking the used challenges from the broadcast list (visible to all Mobile Nodes). 2. Tracking all other per-mobile challenges (e.g. in RRP, in unicast advertisement) is not a problem as long as we track a minimum of one challenge of these per mobile. I believe that having a USED_CHALLENGE_WINDOW of a value of CHALLENGE_WINDOW + 1 will make this work perfectly, with one condition: The USED_CHALLENGE_WINDOW have two types: one of the size of the CHALLENGE_WINDOW for tracking the Broadcast challenges and one of the size of 1 to track the used challenges of everything else. This will eliminate the suggestion of preventing the Mobile from using certain Challenges. What do you think? Regards; Ahmad Muhanna > -----Original Message----- > From: Luca Salgarelli [mailto:salga@bell-labs.com] > Sent: Thursday, April 04, 2002 5:09 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues > > > Hello Ahmad. > > > RFC3012-bis section 1.1 Terminology : > > " > > previously used challenge > > Any challenge that has been used by the > mobile node in a > > Registration Request message and accepted by > the Foreign > > Agent as a valid challenge by relaying or > generating a > > corresponding Registration Reply message. > > > > stale challenge > > Same as "previously used challenge". The > Foreign Agent > > may not be able to keep records for all > stale challenges. > > " > > It is clear that the FA has the option to track all stale > challenges or only > > ONE. > > > > Well, I think that the last sentence is a problem in RFC3012-bis. I > actually didn't notice it before, so thanks fore pointing that out. If > we allow an FA not to keep track of all stale challenges, than I think > we are opening a security hole. > > Imagine this scenario: let's have an FA that keeps a > challenge-window of > 3. It sends advertisements every 60 seconds. In the past 180 > seconds it > has sent challenges C1, C2 and C3, in that order. > > Now legitimate Mobile Node MN sends sends registration request R1 > including challenge C2. It gets accepted. A little later MN sends > registration request R2 including challenge C3. > > Now, if the FA does not keep track of both C2 and C3 *per > mobile*, let's > say it only keeps the last used value (C3), we have a problem. A > malicious Mobile Node MAL can replay R1, and it will get > accepted, since > it is in the valid window, and it is not stale, at least not to the > knowledge of the FA. > > So I think that we should either mandate that FAs MUST keep a > valid list > of stale challenges, or we introduce the change that Charlie > suggested, > i.e. if a client uses a challenge from an advertisement, it cannot use > any challenges issued in previous advertisements, no matter > if they are > in the valid window. > > Cheers > Luca > > > > > Luca; > > Please see one comment in line about the algorithm you presented. > > > > > > Regards; > > Ahmad Muhanna > > > > > > > -----Original Message----- > > > From: Luca Salgarelli [mailto:salga@bell-labs.com] > > > Sent: Thursday, April 04, 2002 1:15 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues > > > > > > > > > Charlie, > > > > > > please see comments inline. > > > > > > On Thu, 2002-04-04 at 12:46, Charles E. Perkins wrote: > > > > Luca Salgarelli wrote: > > > > > > > > > > Hello Charlie. > > > > > > > > > > > My original conception of this operation was that > the foreign > > > > > > agent would have a _short_ list of recent > acceptable challenges. > > > > > > That is easily checked when a mobile node sends a > Registration > > > > > > Request. The challenges would be advertised, and > available for > > > > > > use by multiple mobile nodes. > > > > > > > > > > I think there is more to it than it appears. > > > > > > > > > > The spec says, rightfully, that the FA should make sure > > > to check that a > > > > > mobile does not reuse a previously used challenge. > And this is the > > > > > sticky point. To satisfy it, it is not enough for the FA > > > to maintain a > > > > > global list of "valid advertised challenges" only. It > has to keep: > > > > > > > > > > 1) A global windowed list of valid advertised challenges > > > > > 2) A per-mobile list of the last challenge sent in a reply > > > > > > > > > > as you say, but also: > > > > > > > > > > 3) A *per-mobile* list of recently used challenges from (1) > > > > > > > > > > Now, (1) is not a problem because it should be short. > Same for (2) > > > > > because it is always composed of one entry only -- as you > > > suggested, I > > > > > agree that the window of the challenges sent in replies > > > should always be > > > > > '1'. > > > > > > > > > > I have problems with (3), if the window is larger > than one. As the > > > > > mobile uses challenges from advertisements, we have to > > > add them to (3). > > > > > But we don't want (3) to grow indefinitely, so we want to > > > delete the > > > > > ones that were already there and that we don't possibly > > > need anymore. > > > > > > > > What if we say that, if a mobile node uses a challenge from > > > (1), that > > > > challenge _replaces_ the challenge (if any) from (3). > Thus, this > > > > "invalidates" the option to use any challenge that was > supplied from > > > > a Registration Request. > > > > > > > > I don't think this would impose any hardship, and it > would seemingly > > > > eliminate the problem that you have identified. > > > > > > Hmmm, I am not sure you could do that. Let's analyze: (3) > contains a > > > list of challenges successfully used by a client in the > recent past. > > > (3), along with (1) and (2), are kept by the FA so that > it can run the > > > following checks when it receives a challenge C in a registration > > > request: > > > > > > 1: if (C is not in (1)) and (C is not in (2)) > > > 2: return UNKNOWN_CHALLENGE > > > 3: else > > > 4: if (C is in (3)) > > > 5: return STALE_CHALLENGE > > > > No challenge will ever come here. Any challenge classified as > > STALE_CHALLENGE is > > a challenge which does not exist in (1) nor in (2). Then > you will always get > > UNKNOWN_CHALLENGE. > > > > you need to modify line 1 to: > > if (C is not in (1)) and (C is not in (2)) and (C is not in (3)) > > > > and keep the rest as is. > > > > > 6: else > > > 7: add C to (3) > > > 8: proceed with processing of registration request > > > > > > Now, if I understand your suggestion correctly, you are > > > saying that the > > > FA at line 7 should replace the challenge C' (if any) that is > > > already in > > > (3). > > > > > > But this wouldn't work: if the window is larger than one, > a malicious > > > mobile could now replay the older request that contained C', > > > and the FA > > > would let it through. > > > > > > Am I misintrepreting your suggestion? > > > > > > Luca > > > > > > Charlie also wrote: > > > > > Furthermore, we will probably also have to keep (3) alive > > > even after the > > > > > mobile de-registers, to make sure that an attacker does > > > not replay a > > > > > request that used one of the still valid challenges > > > values that this > > > > > mobile recently used (and that therefore is in (3)). > > > > > > > > After deregistration, from the above, this would not impose > > > very much > > > > additional hardship. In fact, even when there is > nothing from (3), > > > > the foreign agent should keep this information around. > > > > > > > > Regards, > > > > Charlie P. > > > > > > > > > > > > ------_=_NextPart_001_01C1DCC4.8FE53AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] RFC3012-bis: compatibility issues

Hello Luca;

Let us agree on the following:

1. The problem is of tracking the used challenges = from the broadcast list (visible to all Mobile Nodes).
2. Tracking all other per-mobile challenges (e.g. in = RRP, in unicast advertisement) is not a
problem as long as we track a minimum of one = challenge of these per mobile.

I believe that having a USED_CHALLENGE_WINDOW of a = value of CHALLENGE_WINDOW + 1
will make this work perfectly, with one = condition:

The USED_CHALLENGE_WINDOW have two types:
one of the size of the CHALLENGE_WINDOW for tracking = the Broadcast challenges
and one of the size of 1 to track the used = challenges of everything else.

This will eliminate the suggestion of preventing the = Mobile from using certain Challenges.

What do you think?

Regards;
Ahmad Muhanna


> -----Original Message-----
> From: Luca Salgarelli [mailto:salga@bell-labs.com]
> Sent: Thursday, April 04, 2002 5:09 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] RFC3012-bis: = compatibility issues
>
>
> Hello Ahmad.
>
> > RFC3012-bis section 1.1 Terminology = :
> > "
> >       = previously used challenge
> = >           &n= bsp;    Any challenge that has been used by the
> mobile node in a
> = >           &n= bsp;    Registration Request message and accepted by =
> the Foreign
> = >           &n= bsp;    Agent as a valid challenge by relaying or =
> generating a
> = >           &n= bsp;    corresponding Registration Reply message.
> >
> >       stale = challenge
> = >           &n= bsp;    Same as "previously used = challenge".  The
> Foreign Agent
> = >           &n= bsp;    may not be able to keep records for all
> stale challenges.
> > "
> > It is clear that the FA has the option to = track all stale
> challenges or only
> > ONE.
> >
>
> Well, I think that the last sentence is a = problem in RFC3012-bis. I
> actually didn't notice it before, so thanks = fore pointing that out. If
> we allow an FA not to keep track of all stale = challenges, than I think
> we are opening a security hole.
>
> Imagine this scenario: let's have an FA that = keeps a
> challenge-window of
> 3. It sends advertisements every 60 seconds. In = the past 180
> seconds it
> has sent challenges C1, C2 and C3, in that = order.
>
> Now legitimate Mobile Node MN sends sends = registration request R1
> including challenge C2. It gets accepted. A = little later MN sends
> registration request R2 including challenge = C3.
>
> Now, if the FA does not keep track of both C2 = and C3 *per
> mobile*, let's
> say it only keeps the last used value (C3), we = have a problem. A
> malicious Mobile Node MAL can replay R1, and it = will get
> accepted, since
> it is in the valid window, and it is not stale, = at least not to the
> knowledge of the FA.
>
> So I think that we should either mandate that = FAs MUST keep a
> valid list
> of stale challenges, or we introduce the change = that Charlie
> suggested,
> i.e. if a client uses a challenge from an = advertisement, it cannot use
> any challenges issued in previous = advertisements, no matter
> if they are
> in the valid window.
>
> Cheers
> Luca
>
> >
> > Luca;
> > Please see one comment in line about the = algorithm you presented.
> >
> >
> > Regards;
> > Ahmad Muhanna
> >
> >
> > > -----Original Message-----
> > > From: Luca Salgarelli [mailto:salga@bell-labs.com]
> > > Sent: Thursday, April 04, 2002 1:15 = PM
> > > To: = mobile-ip@sunroof.eng.sun.com
> > > Subject: Re: [mobile-ip] RFC3012-bis: = compatibility issues
> > >
> > >
> > > Charlie,
> > >
> > > please see comments inline.
> > >
> > > On Thu, 2002-04-04 at 12:46, Charles = E. Perkins wrote:
> > > > Luca Salgarelli wrote:
> > > > >
> > > > > Hello Charlie.
> > > > >
> > > > > > My original conception = of this operation was that
> the foreign
> > > > > > agent would have a = _short_ list of recent
> acceptable challenges.
> > > > > > That is easily checked = when a mobile node sends a
> Registration
> > > > > > Request.  The = challenges would be advertised, and
> available for
> > > > > > use by multiple mobile = nodes.
> > > > >
> > > > > I think there is more to it = than it appears.
> > > > >
> > > > > The spec says, rightfully, = that the FA should make sure
> > > to check that a
> > > > > mobile does not reuse a = previously used challenge.
> And this is the
> > > > > sticky point. To satisfy = it, it is not enough for the FA
> > > to maintain a
> > > > > global list of "valid = advertised challenges" only. It
> has to keep:
> > > > >
> > > > > 1) A global windowed list = of valid advertised challenges
> > > > > 2) A per-mobile list of the = last challenge sent in a reply
> > > > >
> > > > > as you say, but = also:
> > > > >
> > > > > 3) A *per-mobile* list of = recently used challenges from (1)
> > > > >
> > > > > Now, (1) is not a problem = because it should be short.
> Same for (2)
> > > > > because it is always = composed of one entry only -- as you
> > > suggested, I
> > > > > agree that the window of = the challenges sent in replies
> > > should always be
> > > > > '1'.
> > > > >
> > > > > I have problems with (3), = if the window is larger
> than one. As the
> > > > > mobile uses challenges from = advertisements, we have to
> > > add them to (3).
> > > > > But we don't want (3) to = grow indefinitely, so we want to
> > > delete the
> > > > > ones that were already = there and that we don't possibly
> > > need anymore.
> > > >
> > > > What if we say that, if a mobile = node uses a challenge from
> > > (1), that
> > > > challenge _replaces_ the = challenge (if any) from (3). 
> Thus, this
> > > > "invalidates" the = option to use any challenge that was
> supplied from
> > > > a Registration Request.
> > > >
> > > > I don't think this would impose = any hardship, and it
> would seemingly
> > > > eliminate the problem that you = have identified.
> > >
> > > Hmmm, I am not sure you could do = that. Let's analyze: (3)
> contains a
> > > list of challenges successfully used = by a client in the
> recent past.
> > > (3), along with (1) and (2), are kept = by the FA so that
> it can run the
> > > following checks when it receives a = challenge C in a registration
> > > request:
> > >
> > > 1: if (C is not in (1)) and (C is not = in (2))
> > > 2:    return = UNKNOWN_CHALLENGE
> > > 3: else
> > > 4:    if (C is in = (3))
> > > = 5:        return = STALE_CHALLENGE
> >
> > No challenge will ever come here. Any = challenge classified as
> > STALE_CHALLENGE is
> > a challenge which does not exist in (1) = nor in (2). Then
> you will always get
> > UNKNOWN_CHALLENGE.
> >
> > you need to modify line 1 to:
> > if (C is not in (1)) and (C is not in (2)) = and (C is not in (3))
> >
> > and keep the rest as is.
> >
> > > 6: else
> > > 7:    add C to = (3)
> > > 8:    proceed with = processing of registration request
> > >
> > > Now, if I understand your suggestion = correctly, you are
> > > saying that the
> > > FA at line 7 should replace the = challenge C' (if any) that is
> > > already in
> > > (3).
> > >
> > > But this wouldn't work: if the window = is larger than one,
> a malicious
> > > mobile could now replay the older = request that contained C',
> > > and the FA
> > > would let it through.
> > >
> > > Am I misintrepreting your = suggestion?
> > >
> > > Luca
> > >
> > > Charlie also wrote:
> > > > > Furthermore, we will = probably also have to keep (3) alive
> > > even after the
> > > > > mobile de-registers, to = make sure that an attacker does
> > > not replay a
> > > > > request that used one of = the still valid challenges
> > > values that this
> > > > > mobile recently used (and = that therefore is in (3)).
> > > >
> > > > After deregistration, from the = above, this would not impose
> > > very much
> > > > additional hardship.  In = fact, even when there is
> nothing from (3),
> > > > the foreign agent should keep = this information around.
> > > >
> > > > Regards,
> > > > Charlie P.
> > >
> > >
> > >
>
>
>

------_=_NextPart_001_01C1DCC4.8FE53AF0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 14:09:25 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13736 for ; Fri, 5 Apr 2002 14:09:25 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16973; Fri, 5 Apr 2002 11:09:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14273; Fri, 5 Apr 2002 11:09:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35J8DKL022821 for ; Fri, 5 Apr 2002 11:08:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35J8Dgx022820 for mobile-ip-dist; Fri, 5 Apr 2002 11:08:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35J89KL022810 for ; Fri, 5 Apr 2002 11:08:09 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g35J8Ag12469 for ; Fri, 5 Apr 2002 14:08:10 -0500 (EST) Date: Fri, 5 Apr 2002 14:09:06 -0500 (EST) From: "Steven M. Glass" Subject: RE: [mobile-ip] Issue with IPdst in FA reply when MN home address is 0.0.0.0 To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <8C92E23A3E87FB479988285F9E22BE4602363F@ftmail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is my concern (that and I like to see things more consistent across related cases, and for easier implementation reasons). I do NOT want to see a bit in the registration request to indicate "please broadcast my registration reply with an address assignment back to me". My guess is the reason secion 3.7.2.3 is worded the way it is may have something to do with the misnomer that broadcast@L3 means you broadcast@L2. You can broadcast@L3 with a unicast L2 (and thereby also not force your MN to support pomiscuity at L3). One key reason to not broadcast L2 is that it wakes sleeping clients (not nice if your battery powered, smart radio management issues aside). Anyway, I'd like to see this changed so that the FA *always* sends registration replies to 255.255.255.255 in response to registration requests with IPsrc = 0.0.0.0. Does anyone else have any thoughts? Cheers, Steve > Snip from RFC 2131, section 4.1 "Constructing and Sending DHCP messages": > > "Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, > DHCPACK and DHCPNAK messages directly to the client using uicast delivery. > The IP destination address (in the IP header) is set to the DHCP 'yiaddr' > address and the link-layer destination address is set to the DHCP 'chaddr' > address." > > As you can see, DHCP will actually try to send replies unicast to the > address that is being assigned, exactly how MIP is designed. However, if > you read a little further in RFC 2131 (DHCP), it describes that some hosts > may not have the ability to receive IP packets sent to addresses they don't > yet have. Therefore, they have built in a flag in the DHCPDISCOVER message > which requests that the server broadcast the replies back. > > I don't really know if such hosts exist, but if so I guess they will not > work with MIP address assignment?? > > matt > > -----Original Message----- > > From: Steven M. Glass [mailto:Steven.Glass@Sun.COM] > > Sent: Thursday, April 04, 2002 8:37 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Issue with IPdst in FA reply when MN home address > > is 0.0.0.0 > > > > > > As long as we're republishing 3220 anyway... > > > > The scenario in question is limited to a non-colocated MN > > registering with > > a home address of 0.0.0.0 via a foreign agent. In question > > is the address the > > FA uses when sending a registration reply to said MN. > > > > My understanding of section 3.7.2.3 (and 3.7.3.2 which > > refers to using the > > same rules as section 3.7.2.3) is: > > > > 1) - FA rejecting the registration request -> > > the registration reply is sent to 255.255.255.255 > > > > 2) - FA forwarding a registration reply from the HA -> > > a) - if the registration reply contains a non-0 Home addr > > the FA forwards the reply to the [assigned] home addr > > > > b) - if the registration reply contains a home addr of > > 0.0.0.0, the FA forwards the reply to 255.255.255.255 > > > > If that's the correct understanding to have, then my > > question is directed > > at 2a above: > > > > Why doesn't this behave like bootP, DHCP, etc, and > > ALWAYS send the reply > > to 255.255.255.255? Since in all cases the MN doesn't know > > what address to > > listen for, making it consistent seems to me to be the right > > thing to do. I > > confess to having to read the section something like 3 times > > to not mis-read > > it - so what am I missing? > > > > Cheers, > > Steve > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 5 14:14:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13890 for ; Fri, 5 Apr 2002 14:14:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07893; Fri, 5 Apr 2002 12:14:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17240; Fri, 5 Apr 2002 11:14:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35JDVKL023062 for ; Fri, 5 Apr 2002 11:13:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g35JDV8l023061 for mobile-ip-dist; Fri, 5 Apr 2002 11:13:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g35JDSKL023054 for ; Fri, 5 Apr 2002 11:13:28 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13657 for ; Fri, 5 Apr 2002 11:13:30 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01841 for ; Fri, 5 Apr 2002 11:13:30 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35JDms11575 for ; Fri, 5 Apr 2002 13:13:48 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 5 Apr 2002 13:13:27 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 13:12:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] URL to IETF53 Minutes and Slides Date: Fri, 5 Apr 2002 13:12:48 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12BB0@daebe007.NOE.Nokia.com> Thread-Topic: URL to IETF53 Minutes and Slides Thread-Index: AcHc1d+gUE7PMUifEdaxwAAAhj/HZA== To: X-OriginalArrivalTime: 05 Apr 2002 19:12:49.0155 (UTC) FILETIME=[E0407530:01C1DCD5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g35JDTKL023055 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, You can find the meeting minutes and slides of the Mobile IP WG meeting at IETF53 at : http://people.nokia.net/~patil/IETF53/MobileIP/ -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 7 18:34:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01535 for ; Sun, 7 Apr 2002 18:34:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07864; Sun, 7 Apr 2002 16:32:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01367; Sun, 7 Apr 2002 15:32:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g37MVPmF027526 for ; Sun, 7 Apr 2002 15:31:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g37MVOQL027525 for mobile-ip-dist; Sun, 7 Apr 2002 15:31:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g37MVMmF027518 for ; Sun, 7 Apr 2002 15:31:22 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02722 for ; Sun, 7 Apr 2002 15:31:23 -0700 (PDT) Received: from web14405.mail.yahoo.com (web14405.mail.yahoo.com [216.136.174.62]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA05452 for ; Sun, 7 Apr 2002 16:31:22 -0600 (MDT) Message-ID: <20020407223122.1437.qmail@web14405.mail.yahoo.com> Received: from [217.144.8.254] by web14405.mail.yahoo.com via HTTP; Sun, 07 Apr 2002 15:31:22 PDT Date: Sun, 7 Apr 2002 15:31:22 -0700 (PDT) From: ahmed riziq To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-514200051-1018218682=:99920" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --0-514200051-1018218682=:99920 Content-Type: text/plain; charset=us-ascii --------------------------------- Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax --0-514200051-1018218682=:99920 Content-Type: text/html; charset=us-ascii


Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax --0-514200051-1018218682=:99920-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 09:53:40 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23703 for ; Mon, 8 Apr 2002 09:53:39 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24505; Mon, 8 Apr 2002 07:53:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23792; Mon, 8 Apr 2002 06:52:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38DpQmF029188 for ; Mon, 8 Apr 2002 06:51:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38DpQ1s029187 for mobile-ip-dist; Mon, 8 Apr 2002 06:51:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38DpMmF029180 for ; Mon, 8 Apr 2002 06:51:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20990 for ; Mon, 8 Apr 2002 06:51:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04724 for ; Mon, 8 Apr 2002 07:51:15 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23588; Mon, 8 Apr 2002 09:51:11 -0400 (EDT) Message-Id: <200204081351.JAA23588@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-nat-traversal-02.txt Date: Mon, 08 Apr 2002 09:51:11 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IP NAT/NAPT Traversal using UDP Tunnelling Author(s) : H. Levkowetz, S. Vaarala Filename : draft-ietf-mobileip-nat-traversal-02.txt Pages : 29 Date : 05-Apr-02 Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-nat-traversal-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020405142900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-nat-traversal-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020405142900.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 10:26:12 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24975 for ; Mon, 8 Apr 2002 10:26:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16981; Mon, 8 Apr 2002 08:25:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28555; Mon, 8 Apr 2002 07:24:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38ENimF029358 for ; Mon, 8 Apr 2002 07:23:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38ENiti029356 for mobile-ip-dist; Mon, 8 Apr 2002 07:23:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38ENcmF029341 for ; Mon, 8 Apr 2002 07:23:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28384 for ; Mon, 8 Apr 2002 07:23:39 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA05013 for ; Mon, 8 Apr 2002 07:23:35 -0700 (PDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Apr 8 10:23:21 EDT 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g38EMro62496 for ; Mon, 8 Apr 2002 10:22:54 -0400 (EDT) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA21824 for ; Mon, 8 Apr 2002 10:22:53 -0400 (EDT) Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues From: Luca Salgarelli To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCB7D@zrc2c013.us.nortel.com> References: <6B49EDFE974BD51197D70002A56079D801AFCB7D@zrc2c013.us.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 08 Apr 2002 10:22:53 -0400 Message-Id: <1018275773.10231.14.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ahmad. On Fri, 2002-04-05 at 12:08, Ahmad Muhanna wrote: > Hello Luca; > > Let us agree on the following: > > 1. The problem is of tracking the used challenges from the broadcast list > (visible to all Mobile Nodes). > 2. Tracking all other per-mobile challenges (e.g. in RRP, in unicast > advertisement) is not a > problem as long as we track a minimum of one challenge of these per mobile. I agree. > I believe that having a USED_CHALLENGE_WINDOW of a value of CHALLENGE_WINDOW > + 1 > will make this work perfectly, with one condition: > > The USED_CHALLENGE_WINDOW have two types: > one of the size of the CHALLENGE_WINDOW for tracking the Broadcast > challenges > and one of the size of 1 to track the used challenges of everything else. > > This will eliminate the suggestion of preventing the Mobile from using > certain Challenges. > > What do you think? I don't think that this would work as expected. The problem is that this way the FA does not have any means of tracking the *order* in which the client uses the broadcast challenges, and this can lead to problems. For example, let's assume the system that you describe above is in place. Let's have a FA with challenge-window of 3. The FA issued challenges [A, B, C] as its most recent past three challenges (A is the oldest). A mobile uses first C, then B, then A, all in registration requests very close to each other. Its USE_CHALLENGE_WINDOW now looks like [C, B, A]: 'C' is going to be the first-out. Now the FA issues challenge 'D', and its valid window now looks like [B, C, D]. Let's assume that now the mobile uses challenge 'D': its USED_CHALLENGE_WINDOW now should look like [B, A, D]. And now you should see the problem: a malicious mobile could replay the request that used 'C' as the challenge: since it is in the valid window, and NOT in the USED_CHALLENGE_WINDOW of the mobile, the FA would accept it. I hope I was able to convince you (or else tire you to exhaustion with my complicated examples :-) that the way the draft is written now becomes very complex and expensive to implement, unless we introduce some sort of timing information together with the broadcast challenges that mobiles use. In my opinion, the most (or only) scalable way of doing this would be either to not send challenges in broadcast advertisements (my original suggestion), or to have a 'cut-off' challenge like Charlie suggested. Regards Luca From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 11:49:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27655 for ; Mon, 8 Apr 2002 11:49:56 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06249; Mon, 8 Apr 2002 09:49:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14602; Mon, 8 Apr 2002 08:49:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38FmHmF000230 for ; Mon, 8 Apr 2002 08:48:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38FmHYx000229 for mobile-ip-dist; Mon, 8 Apr 2002 08:48:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38FmEmF000220 for ; Mon, 8 Apr 2002 08:48:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20894 for ; Mon, 8 Apr 2002 08:48:16 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05573 for ; Mon, 8 Apr 2002 09:48:16 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38FmCD27838; Mon, 8 Apr 2002 10:48:13 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXVKRCT>; Mon, 8 Apr 2002 10:48:14 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB85@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip'" Cc: "'Luca Salgarelli'" Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues Date: Mon, 8 Apr 2002 10:48:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF14.C9E14C10" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF14.C9E14C10 Content-Type: text/plain; charset="iso-8859-1" Hello Luca, > > Hello Ahmad. > > On Fri, 2002-04-05 at 12:08, Ahmad Muhanna wrote: > > Hello Luca; > > > > Let us agree on the following: > > > > 1. The problem is of tracking the used challenges from the > broadcast list > > (visible to all Mobile Nodes). > > 2. Tracking all other per-mobile challenges (e.g. in RRP, in unicast > > advertisement) is not a > > problem as long as we track a minimum of one challenge of > these per mobile. > > I agree. > > > I believe that having a USED_CHALLENGE_WINDOW of a value of > CHALLENGE_WINDOW > > + 1 > > will make this work perfectly, with one condition: > > > > The USED_CHALLENGE_WINDOW have two types: > > one of the size of the CHALLENGE_WINDOW for tracking the Broadcast > > challenges > > and one of the size of 1 to track the used challenges of > everything else. > > > > This will eliminate the suggestion of preventing the Mobile > from using > > certain Challenges. > > > > What do you think? > > I don't think that this would work as expected. The problem > is that this > way the FA does not have any means of tracking the *order* in > which the > client uses the broadcast challenges, and this can lead to problems. > > For example, let's assume the system that you describe above is in > place. Let's have a FA with challenge-window of 3. The FA issued > challenges [A, B, C] as its most recent past three challenges > (A is the > oldest). > > A mobile uses first C, then B, then A, all in registration > requests very > close to each other. Its USE_CHALLENGE_WINDOW now looks like > [C, B, A]: > 'C' is going to be the first-out. > > Now the FA issues challenge 'D', and its valid window now > looks like [B, > C, D]. Let's assume that now the mobile uses challenge 'D': its > USED_CHALLENGE_WINDOW now should look like [B, A, D]. And now > you should > see the problem: a malicious mobile could replay the request that used > 'C' as the challenge: since it is in the valid window, and NOT in the > USED_CHALLENGE_WINDOW of the mobile, the FA would accept it. > I agree. > I hope I was able to convince you (or else tire you to exhaustion with > my complicated examples :-) that the way the draft is written now On the contrary, I very much appreciate your detailed examples and thoughts. However, I look at this problem as an implementation one. The suggestion of tying this to timestamp is one way of resolving it. In other words a proposal for solving an implementation issue, which I think, standard must avoid addressing. What about if someone came up with another idea to solve this problem. Why he needs to implement this one. > becomes very complex and expensive to implement, unless we introduce > some sort of timing information together with the broadcast challenges > that mobiles use. In my opinion, the most (or only) scalable way of > doing this would be either to not send challenges in broadcast > advertisements (my original suggestion), or to have a 'cut-off' > challenge like Charlie suggested. > > Regards > Luca > RFC3012 already made some restriction on the Mobile node to always use the challenge received in the latest agent advertisement, " sort of a timestamp" A Registration Reply from the Foreign Agent MAY include a new Challenge value (see section 3.3). The Mobile Node MAY use either the value found in the latest Advertisement, or the one found in the last Registration Reply from the Foreign Agent. This approach enables the Mobile Node to make use of the challenge without having to wait for advertisements. This could be interpreted that the FA SHOULD implement the same timestamp too. On the other hand, it leaves the door open for other creative ideas to address this issue and at the same time avoid any security weakness as you clearly identified. Now, if an implementation chose to have a CHALLENGE_WINDOW of 2, it becomes much easier to trace it through a list of used challenges rather than timestamp. What about a CHALLENGE_WINDOW of 1. Thanks; Ahmad ------_=_NextPart_001_01C1DF14.C9E14C10 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RFC3012-bis: compatibility issues

Hello Luca,

>
> Hello Ahmad.
>
> On Fri, 2002-04-05 at 12:08, Ahmad Muhanna wrote:
> > Hello Luca;
> >
> > Let us agree on the following:
> >
> > 1. The problem is of tracking the used challenges from the
> broadcast list
> > (visible to all Mobile Nodes).
> > 2. Tracking all other per-mobile challenges (e.g. in RRP, in unicast
> > advertisement) is not a
> > problem as long as we track a minimum of one challenge of
> these per mobile.
>
> I agree.
>
> > I believe that having a USED_CHALLENGE_WINDOW of a value of
> CHALLENGE_WINDOW
> > + 1
> > will make this work perfectly, with one condition:
> >
> > The USED_CHALLENGE_WINDOW have two types:
> > one of the size of the CHALLENGE_WINDOW for tracking the Broadcast
> > challenges
> > and one of the size of 1 to track the used challenges of
> everything else.
> >
> > This will eliminate the suggestion of preventing the Mobile
> from using
> > certain Challenges.
> >
> > What do you think?
>
> I don't think that this would work as expected. The problem
> is that this
> way the FA does not have any means of tracking the *order* in
> which the
> client uses the broadcast challenges, and this can lead to problems.
>
> For example, let's assume the system that you describe above is in
> place. Let's have a FA with challenge-window of 3. The FA issued
> challenges [A, B, C] as its most recent past three challenges
> (A is the
> oldest).
>
> A mobile uses first C, then B, then A, all in registration
> requests very
> close to each other. Its USE_CHALLENGE_WINDOW now looks like
> [C, B, A]:
> 'C' is going to be the first-out.
>
> Now the FA issues challenge 'D', and its valid window now
> looks like [B,
> C, D]. Let's assume that now the mobile uses challenge 'D': its
> USED_CHALLENGE_WINDOW now should look like [B, A, D]. And now
> you should
> see the problem: a malicious mobile could replay the request that used
> 'C' as the challenge: since it is in the valid window, and NOT in the
> USED_CHALLENGE_WINDOW of the mobile, the FA would accept it.
>
I agree.

> I hope I was able to convince you (or else tire you to exhaustion with
> my complicated examples :-) that the way the draft is written now

On the contrary, I very much appreciate your detailed examples and thoughts.
However, I look at this problem as an implementation one. The suggestion
of tying this to timestamp is one way of resolving it. In other words
a proposal for solving an implementation issue, which I think, standard must
avoid addressing. What about if someone came up with another idea to solve this
problem. Why he needs to implement this one.

> becomes very complex and expensive to implement, unless we introduce
> some sort of timing information together with the broadcast challenges
> that mobiles use. In my opinion, the most (or only) scalable way of
> doing this would be either to not send challenges in broadcast
> advertisements (my original suggestion), or to have a 'cut-off'
> challenge like Charlie suggested.
>
> Regards
> Luca
>

RFC3012 already made some restriction on the Mobile node to always use the
challenge received in the latest agent advertisement, " sort of a timestamp"

   A Registration Reply from the Foreign Agent MAY include a new
   Challenge value (see section 3.3).  The Mobile Node MAY use either
   the value found in the latest Advertisement, or the one found in
   the last Registration Reply from the Foreign Agent.  This approach
   enables the Mobile Node to make use of the challenge without having
   to wait for advertisements.

This could be interpreted that the FA SHOULD implement the same timestamp too.
On the other hand, it leaves the door open for other creative ideas to address this
issue and at the same time avoid any security weakness as you clearly identified.

Now, if an implementation chose to have a CHALLENGE_WINDOW of 2, it becomes
much easier to trace it through a list of used challenges rather than timestamp.

What about a CHALLENGE_WINDOW of 1.

Thanks;
Ahmad

------_=_NextPart_001_01C1DF14.C9E14C10-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 12:00:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28083 for ; Mon, 8 Apr 2002 12:00:25 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12449; Mon, 8 Apr 2002 10:00:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17099; Mon, 8 Apr 2002 09:00:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38FxEmF000362 for ; Mon, 8 Apr 2002 08:59:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38FxEmq000361 for mobile-ip-dist; Mon, 8 Apr 2002 08:59:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38FxBmF000354 for ; Mon, 8 Apr 2002 08:59:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16343 for ; Mon, 8 Apr 2002 08:59:13 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07951 for ; Mon, 8 Apr 2002 09:59:12 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38Fx8D02351; Mon, 8 Apr 2002 10:59:09 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXVKRVZ>; Mon, 8 Apr 2002 10:59:10 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB86@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Luca Salgarelli'" Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues Date: Mon, 8 Apr 2002 10:59:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF16.50BA8480" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF16.50BA8480 Content-Type: text/plain; charset="iso-8859-1" Hello Luca; One more point below, please. Hello Luca, > > Hello Ahmad. > > On Fri, 2002-04-05 at 12:08, Ahmad Muhanna wrote: > > Hello Luca; > > > > Let us agree on the following: > > > > 1. The problem is of tracking the used challenges from the > broadcast list > > (visible to all Mobile Nodes). > > 2. Tracking all other per-mobile challenges (e.g. in RRP, in unicast > > advertisement) is not a > > problem as long as we track a minimum of one challenge of > these per mobile. > > I agree. > > > I believe that having a USED_CHALLENGE_WINDOW of a value of > CHALLENGE_WINDOW > > + 1 > > will make this work perfectly, with one condition: > > > > The USED_CHALLENGE_WINDOW have two types: > > one of the size of the CHALLENGE_WINDOW for tracking the Broadcast > > challenges > > and one of the size of 1 to track the used challenges of > everything else. > > > > This will eliminate the suggestion of preventing the Mobile > from using > > certain Challenges. > > > > What do you think? > > I don't think that this would work as expected. The problem > is that this > way the FA does not have any means of tracking the *order* in > which the > client uses the broadcast challenges, and this can lead to problems. > > For example, let's assume the system that you describe above is in > place. Let's have a FA with challenge-window of 3. The FA issued > challenges [A, B, C] as its most recent past three challenges > (A is the > oldest). > > A mobile uses first C, then B, then A, all in registration > requests very > close to each other. Its USE_CHALLENGE_WINDOW now looks like > [C, B, A]: > 'C' is going to be the first-out. > > Now the FA issues challenge 'D', and its valid window now > looks like [B, > C, D]. Let's assume that now the mobile uses challenge 'D': its > USED_CHALLENGE_WINDOW now should look like [B, A, D]. And now > you should > see the problem: a malicious mobile could replay the request that used > 'C' as the challenge: since it is in the valid window, and NOT in the > USED_CHALLENGE_WINDOW of the mobile, the FA would accept it. > I agree. > I hope I was able to convince you (or else tire you to exhaustion with > my complicated examples :-) that the way the draft is written now On the contrary, I very much appreciate your detailed examples and thoughts. However, I look at this problem as an implementation one. The suggestion of tying this to timestamp is one way of resolving it. In other words a proposal for solving an implementation issue, which I think, standard must avoid addressing. What about if someone came up with another idea to solve this problem. Why he needs to implement this one. > becomes very complex and expensive to implement, unless we introduce > some sort of timing information together with the broadcast challenges > that mobiles use. In my opinion, the most (or only) scalable way of > doing this would be either to not send challenges in broadcast > advertisements (my original suggestion), or to have a 'cut-off' > challenge like Charlie suggested. > > Regards > Luca > RFC3012 already made some restriction on the Mobile node to always use the challenge received in the latest agent advertisement, " sort of a timestamp" A Registration Reply from the Foreign Agent MAY include a new Challenge value (see section 3.3). The Mobile Node MAY use either the value found in the latest Advertisement, or the one found in the last Registration Reply from the Foreign Agent. This approach enables the Mobile Node to make use of the challenge without having to wait for advertisements. Ahmad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If we agree on this. Then there should be no issue. Let us remember in all of the examples we used, we assumed that a standard compliant Mobile Node violate this rule and does not send the challenge received in the latest advertisement. What do you think? Thanks; Ahmad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This could be interpreted that the FA SHOULD implement the same timestamp too. On the other hand, it leaves the door open for other creative ideas to address this issue and at the same time avoid any security weakness as you clearly identified. Now, if an implementation chose to have a CHALLENGE_WINDOW of 2, it becomes much easier to trace it through a list of used challenges rather than timestamp. What about a CHALLENGE_WINDOW of 1. Thanks; Ahmad ------_=_NextPart_001_01C1DF16.50BA8480 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RFC3012-bis: compatibility issues

Hello Luca;
One more point below, please.


Hello Luca,
>
> Hello Ahmad.
>
> On Fri, 2002-04-05 at 12:08, Ahmad Muhanna wrote:
> > Hello Luca;
> >
> > Let us agree on the following:
> >
> > 1. The problem is of tracking the used challenges from the
> broadcast list
> > (visible to all Mobile Nodes).
> > 2. Tracking all other per-mobile challenges (e.g. in RRP, in unicast
> > advertisement) is not a
> > problem as long as we track a minimum of one challenge of
> these per mobile.
>
> I agree.
>
> > I believe that having a USED_CHALLENGE_WINDOW of a value of
> CHALLENGE_WINDOW
> > + 1
> > will make this work perfectly, with one condition:
> >
> > The USED_CHALLENGE_WINDOW have two types:
> > one of the size of the CHALLENGE_WINDOW for tracking the Broadcast
> > challenges
> > and one of the size of 1 to track the used challenges of
> everything else.
> >
> > This will eliminate the suggestion of preventing the Mobile
> from using
> > certain Challenges.
> >
> > What do you think?
>
> I don't think that this would work as expected. The problem
> is that this
> way the FA does not have any means of tracking the *order* in
> which the
> client uses the broadcast challenges, and this can lead to problems.
>
> For example, let's assume the system that you describe above is in
> place. Let's have a FA with challenge-window of 3. The FA issued
> challenges [A, B, C] as its most recent past three challenges
> (A is the
> oldest).
>
> A mobile uses first C, then B, then A, all in registration
> requests very
> close to each other. Its USE_CHALLENGE_WINDOW now looks like
> [C, B, A]:
> 'C' is going to be the first-out.
>
> Now the FA issues challenge 'D', and its valid window now
> looks like [B,
> C, D]. Let's assume that now the mobile uses challenge 'D': its
> USED_CHALLENGE_WINDOW now should look like [B, A, D]. And now
> you should
> see the problem: a malicious mobile could replay the request that used
> 'C' as the challenge: since it is in the valid window, and NOT in the
> USED_CHALLENGE_WINDOW of the mobile, the FA would accept it.
>
I agree.
> I hope I was able to convince you (or else tire you to exhaustion with
> my complicated examples :-) that the way the draft is written now
On the contrary, I very much appreciate your detailed examples and thoughts.
However, I look at this problem as an implementation one. The suggestion
of tying this to timestamp is one way of resolving it. In other words
a proposal for solving an implementation issue, which I think, standard must
avoid addressing. What about if someone came up with another idea to solve this
problem. Why he needs to implement this one.
> becomes very complex and expensive to implement, unless we introduce
> some sort of timing information together with the broadcast challenges
> that mobiles use. In my opinion, the most (or only) scalable way of
> doing this would be either to not send challenges in broadcast
> advertisements (my original suggestion), or to have a 'cut-off'
> challenge like Charlie suggested.
>
> Regards
> Luca
>
RFC3012 already made some restriction on the Mobile node to always use the
challenge received in the latest agent advertisement, " sort of a timestamp"
   A Registration Reply from the Foreign Agent MAY include a new
   Challenge value (see section 3.3).  The Mobile Node MAY use either
   the value found in the latest Advertisement, or the one found in
   the last Registration Reply from the Foreign Agent.  This approach
   enables the Mobile Node to make use of the challenge without having
   to wait for advertisements.

Ahmad
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If we agree on this. Then there should be no issue.
Let us remember in all of the examples we used, we assumed that a standard
compliant Mobile Node violate this rule and does not send the challenge received
in the latest advertisement.

What do you think?


Thanks;
Ahmad
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

This could be interpreted that the FA SHOULD implement the same timestamp too.
On the other hand, it leaves the door open for other creative ideas to address this
issue and at the same time avoid any security weakness as you clearly identified.
Now, if an implementation chose to have a CHALLENGE_WINDOW of 2, it becomes
much easier to trace it through a list of used challenges rather than timestamp.
What about a CHALLENGE_WINDOW of 1.
Thanks;
Ahmad

------_=_NextPart_001_01C1DF16.50BA8480-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 14:46:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02400 for ; Mon, 8 Apr 2002 14:46:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12932; Mon, 8 Apr 2002 12:45:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05039; Mon, 8 Apr 2002 11:45:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38IiCmF001077 for ; Mon, 8 Apr 2002 11:44:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38IiCPL001076 for mobile-ip-dist; Mon, 8 Apr 2002 11:44:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38IiAmF001069 for ; Mon, 8 Apr 2002 11:44:10 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29282 for ; Mon, 8 Apr 2002 14:44:11 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA27329 for mobile-ip@sunroof.eng.sun.com; Mon, 8 Apr 2002 14:45:08 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g363v9KL024655; Fri, 5 Apr 2002 19:57:09 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27456; Fri, 5 Apr 2002 19:57:12 -0800 (PST) From: kimyj@etri.re.kr Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11601; Fri, 5 Apr 2002 20:57:11 -0700 (MST) Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Apr 2002 12:55:11 +0900 Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC083184E1@cms1.etri.re.kr> To: ipng@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, members@ipv6forum.com, 6winit@cs.ucl.ac.uk, mobile-ip@sunroof.eng.sun.com Cc: jenylee@etri.re.kr Subject: [mobile-ip] Announcement of 2nd Global IPv6 Summit in Korea 2002 Date: Sat, 6 Apr 2002 12:55:06 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DD1E.D67C43F0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DD1E.D67C43F0 Content-Type: text/plain; charset="euc-kr" Folks, I have the honor to announce the 2nd Global IPv6 Summit in Korea 2002 to be held in Seoul July 11-12, 2002, at the previous week of the IETF meeting in Yokohama. The theme of the Summit is "The Next Step for IPv6 Technology, Deployment, and Business". As you know, IPv4 was successful until now but not enough for businesses in the future. IPv6 is a new Internet especially for businesses in the 21st century. Many people advocates IPv6 is READY, but some people not yet ! So, we would like to review the current status of IPv6 in the point of technology, deployment, and business and then discuss the next steps for IPv6. The first Global IPv6 Summit in Korea hosted during July 3-6, 2001 was a great success with over 400 attendants and 100 companies participating. (http://www.ipv6.or.kr/ipv6summit/) This year, the interest and atmosphere for IPv6 deployment are more mature than the last year, and more than 500 people are anticipated to attend. We will put up more information on agenda and others at our website in the next couple of days. http://www.ipv6.or.kr/summit/ If you want a presentation in the Summit, I would like to recomend that you should hurry up to contact us due to the limitation of presentation slots. program@ipv6.or.kr Finally, I would like to sincerely invite you to attend this IPv6 Summit. and join the discussions on IPv6 Best Regards, Yong-Jin Kim IPv6 Forum Korea, President ------_=_NextPart_001_01C1DD1E.D67C43F0 Content-Type: text/html; charset="euc-kr" Announcement of 2nd Global IPv6 Summit in Korea 2002

Folks,

I have the honor to announce the 2nd Global IPv6 Summit in Korea 2002
to be held in Seoul July 11-12, 2002, at the previous week of the IETF
meeting in Yokohama.

The theme of the Summit is
"The Next Step for IPv6 Technology, Deployment, and Business".

As you know,
IPv4 was successful until now but not enough for businesses in the future.
IPv6 is a new Internet especially for businesses in the 21st century.

Many people advocates IPv6 is READY, but some people not yet !
So, we would like to review the current status of IPv6
in the point of technology, deployment, and business
and then discuss the next steps for IPv6.

The first Global IPv6 Summit in Korea hosted during July 3-6, 2001 was a
great success with over 400 attendants and 100 companies participating.
 (http://www.ipv6.or.kr/ipv6summit/)

This year, the interest and atmosphere for IPv6 deployment
are more mature than the last year, and more than 500 people
are anticipated to attend.

We will put up more information on agenda and others at our
website in the next couple of days.

    http://www.ipv6.or.kr/summit/

If you want a presentation in the Summit,
I would like to recomend that you should hurry up
to contact us due to the limitation of presentation slots.

    program@ipv6.or.kr

Finally, I would like to sincerely invite you to attend this IPv6 Summit.
and join the discussions on IPv6

Best Regards,

Yong-Jin Kim
IPv6 Forum Korea, President

------_=_NextPart_001_01C1DD1E.D67C43F0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 14:50:43 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02529 for ; Mon, 8 Apr 2002 14:50:42 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01730; Mon, 8 Apr 2002 11:50:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06966; Mon, 8 Apr 2002 11:49:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38ImrmF001178 for ; Mon, 8 Apr 2002 11:48:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38ImrEn001177 for mobile-ip-dist; Mon, 8 Apr 2002 11:48:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38ImlmF001170 for ; Mon, 8 Apr 2002 11:48:47 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00988 for ; Mon, 8 Apr 2002 14:48:46 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA27335 for mobile-ip@sunroof.eng.sun.com; Mon, 8 Apr 2002 14:49:42 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g388FwmF028254; Mon, 8 Apr 2002 01:15:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21283; Mon, 8 Apr 2002 01:15:35 -0700 (PDT) Received: from nero.informatik.uni-wuerzburg.de (wi3x05.informatik.uni-wuerzburg.de [132.187.106.5]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04351; Mon, 8 Apr 2002 01:15:34 -0700 (PDT) Received: from PROMETHEUS (prometheus.informatik.uni-wuerzburg.de [132.187.106.139]) by nero.informatik.uni-wuerzburg.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with SMTP id g388EVH27984; Mon, 8 Apr 2002 10:14:31 +0200 Message-ID: <002201c1ded6$4d306770$8b6abb84@PROMETHEUS> From: "Kurt Tutschku" To: "mpls \(ietf\)" , "sigtran \(ietf\)" , "end2end \(irtf\)" , "ITC list" , "nsis \(ietf\)" , "cost 279" , "ppvpn \(ietf\)" , "University of Central Florida" , "ITG Fachtagung Messung, Modellierung und Bewertung" , "ITG 524" , "ITG 523" , "ITG 521" , "ipo \(ietf\)" , "tewg \(ietf\)" , "ippm \(ietf\)" , "mobileip \(ietf\)" , "manet \(ietf\)" , "nmrg \(irtf\)" , "rr \(irtf\)" , "ccamp \(ietf\)" , "ipv6 \(ietf\)" , "disman \(ietf\)" , =?iso-8859-1?Q?Paul_Schl=FCter?= , "Notker Gerlich" , "Hans Schwefel" , "Thomas Reim" , "Stefan Schneeberger" , "Michael Schopp" , "Franz Hartleb" , "Klaus Dolzer" , "Bart Sanders" , =?iso-8859-1?Q?Michael_S=F6llner?= , "Wolfgang Wagner" , "Walter Leonhardt" , "Norbert Rauh" , =?iso-8859-1?Q?Silvia_Sch=E4ffler?= , "Wolfgang Stegmann" , "Andreas Lamsa" , "Karl Heinz Allgeyer" , "Lothar Lux" , =?iso-8859-1?Q?Bernd_Schr=F6der?= , "Albert Weller" , =?iso-8859-1?Q?J=FCrgen_Tenckhoff?= , "Norbert Schultze" , =?iso-8859-1?Q?Norbert_Schl=FCter?= , "Laslo Slawitschka" , "Gabriel Zgunea" , "Bernhard Liesenfeld" , =?iso-8859-1?Q?J=FCrgen_Beyer?= , "Zhongrong Liu" , "Bernd Pfeiffer" , "Hans Barth" , "Wolf Mende" , "Wolfgang Urmoneit" , "Dieter Marger" , "Charles E. Perkins" , "Ake Arvidsson" , =?iso-8859-1?Q?Angelika_M=FCller?= , "Armin Heindl" , "Bo Friis Nielsen" , "Holger Hermanns" , "Jacques Resing" , "Jose Brazio" , "Stephen Hanly" , "Stefanie" , "Matthew Roughan" , "Reinhard German" , "Rudolf Mathar" , "Ulrich Herzog" , "Dieter Baum" , "Lothar Breuer" , "Marie-Ange Remiche" , "Markus Siegle" , "Nikhil Jain" , "Peter Taylor" , "Sem Borst" , "Ute Kohlhaas" Subject: [mobile-ip] Reminder 15th ITC Specialist Seminar on Internet Traffic Engineering and Traffic Management (ITC 2002) Date: Mon, 8 Apr 2002 10:20:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C1DEE7.058B2020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C1DEE7.058B2020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear colleagues, we kindly remind you of the upcoming Full Paper Submission Deadline on = April 22, 2002 and ask you to help us distributing the Call for Papers = in order to attract as many interested authors and participants as = possible. Thank you for your support Kurt Tutschku (We apologize for multiple copies you might have received.) -------------------------------------------------------------------------= - Call for Papers: 15th ITC Specialist Seminar "Internet Traffic = Engineering and Traffic Management"=20 = -------------------------------------------------------------------------= - Dear colleagues,=20 we'd like to announce proudly an upcoming ITC Specialist Seminar:=20 =20 15th ITC Specialist Seminar: Internet Traffic Engineering and Traffic = Management, July 22-24 2002, Wuerzburg, Germany.=20 The Technical Program Committee of the seminar is chaired by Prof. James = Roberts and Prof. Phuoc Tran-Gia We'd like to invite you to submit original full papers until April 22, = 2002. You will find a detailed Call for Papers at:=20 http://itc.informatik.uni-wuerzburg.de/=20 http://www.itcspecialistseminar.com/=20 Best Regards=20 Phuoc Tran-Gia (Seminar Co-Chair)=20 Jim Roberts (Seminar Co-Chair)=20 Kurt Tutschku (Organizing Committee Chair)=20 ------=_NextPart_000_001F_01C1DEE7.058B2020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear colleagues,
 
we kindly remind you of the upcoming = Full Paper=20 Submission Deadline on April 22, 2002 and ask you to help us = distributing the=20 Call for Papers in order to attract as many interested authors=20 and participants as possible.
 
Thank you for your support
Kurt Tutschku
 
(We apologize for multiple copies you = might have=20 received.)
 
----------------------------------------------------------------= ----------
Call=20 for Papers: 15th ITC Specialist Seminar "Internet Traffic Engineering = and=20 Traffic Management"=20
 ---------------------------------------------------------------= -----------
 
Dear colleagues,
 
we'd like to announce proudly an = upcoming ITC=20 Specialist Seminar:
  
15th ITC Specialist Seminar: = Internet=20 Traffic Engineering and Traffic Management, July 22-24 2002, Wuerzburg, = Germany.=20
 
The Technical Program Committee of the = seminar is=20 chaired by Prof. James Roberts and Prof. Phuoc Tran-Gia
 
We'd like to invite you to submit = original full=20 papers until April 22, 2002. You will find a detailed Call for Papers = at:=20
 
http://itc.informatik.un= i-wuerzburg.de/=20
http://www.itcspecialistsem= inar.com/=20
 
Best Regards
Phuoc Tran-Gia = (Seminar Co-Chair)=20
Jim Roberts (Seminar Co-Chair)
Kurt Tutschku (Organizing = Committee=20 Chair)
 
 
------=_NextPart_000_001F_01C1DEE7.058B2020-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 15:07:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03151 for ; Mon, 8 Apr 2002 15:07:48 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04986; Mon, 8 Apr 2002 13:07:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12094; Mon, 8 Apr 2002 12:07:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38J6PmF001418 for ; Mon, 8 Apr 2002 12:06:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38J6PAw001417 for mobile-ip-dist; Mon, 8 Apr 2002 12:06:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38J6NmF001410 for ; Mon, 8 Apr 2002 12:06:23 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06482 for ; Mon, 8 Apr 2002 15:06:26 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA27347 for mobile-ip@sunroof.eng.sun.com; Mon, 8 Apr 2002 15:07:22 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38GubmF000546 for ; Mon, 8 Apr 2002 09:56:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01576 for ; Mon, 8 Apr 2002 09:56:41 -0700 (PDT) Received: from amber.ccs.neu.edu (amber.ccs.neu.edu [129.10.116.51]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28873 for ; Mon, 8 Apr 2002 09:56:40 -0700 (PDT) Received: from CASABLANCA.ccs.neu.edu (casablanca.ccs.neu.edu [129.10.118.188]) by amber.ccs.neu.edu (Postfix) with ESMTP id A0DED1AA72 for ; Mon, 8 Apr 2002 12:56:39 -0400 (EDT) Message-Id: <5.0.2.1.0.20020408120556.02f3bbd8@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 08 Apr 2002 12:15:57 -0400 To: mobile-ip@sunroof.eng.sun.com From: "G. Noubir" Subject: [mobile-ip] CFP: Workshop on Wireless Security (in conjunction with MobiCom 2002) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 20, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 16:33:03 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05464 for ; Mon, 8 Apr 2002 16:32:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22745; Mon, 8 Apr 2002 13:32:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25059; Mon, 8 Apr 2002 13:32:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38KVGmF001643 for ; Mon, 8 Apr 2002 13:31:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38KVGP8001642 for mobile-ip-dist; Mon, 8 Apr 2002 13:31:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38KVDmF001635 for ; Mon, 8 Apr 2002 13:31:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06143 for ; Mon, 8 Apr 2002 13:31:16 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12810 for ; Mon, 8 Apr 2002 13:31:15 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g38KXWH17513 for ; Mon, 8 Apr 2002 15:33:42 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 8 Apr 2002 15:30:58 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 15:30:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Mon, 8 Apr 2002 15:30:37 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> Thread-Topic: WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Thread-Index: AcHfPDx2xbMj/ksBEdaxyAAAhj/HZA== To: X-OriginalArrivalTime: 08 Apr 2002 20:30:38.0047 (UTC) FILETIME=[3E5E16F0:01C1DF3C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g38KVDmF001636 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Folks, This is a WG last call for: Mobile IP Regional Registration - draft-ietf-mobileip-reg-tunnel-06.txt This draft is a standards track WG document. Please send in your comments by April 22nd, 2002 to the authors or to the WG discussion list. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 17:28:39 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06998 for ; Mon, 8 Apr 2002 17:28:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20815; Mon, 8 Apr 2002 15:28:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14778; Mon, 8 Apr 2002 14:28:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38LRDmF001962 for ; Mon, 8 Apr 2002 14:27:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38LRDcC001961 for mobile-ip-dist; Mon, 8 Apr 2002 14:27:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38LRAmF001954 for ; Mon, 8 Apr 2002 14:27:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14338 for ; Mon, 8 Apr 2002 14:27:11 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20177 for ; Mon, 8 Apr 2002 15:27:11 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38LR7D28325; Mon, 8 Apr 2002 16:27:08 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXVK8YC>; Mon, 8 Apr 2002 16:27:10 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB8C@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Luca Salgarelli'" , "'Charlie Perkins'" Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues Date: Mon, 8 Apr 2002 16:27:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF44.24163590" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF44.24163590 Content-Type: text/plain; charset="iso-8859-1" Hello Luca; > Luca Salgarelli wrote: > > The Foreign Agent MUST NOT accept any Challenge in the Registration > Request unless it was offered in last Registration Reply issued > to the Mobile Node, or else advertised as one of the last > CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > immediately preceding Agent advertisements. If the Challenge is > not one of the recently advertised values, the foreign Agent SHOULD > send a Registration Reply with Code value UNKNOWN_CHALLENGE (see > section 10). In addition, if the Challenge is one of > the recently advertised values, but was issued before a Challenge > already used by the Mobile Node, the Foreign Agent SHOULD send a > Registration Reply with code value STALE_CHALLENGE. > I think we at least need to apply Charlie suggestion as per Luca text. I have no problem with this text. Thanks; Ahmad ------_=_NextPart_001_01C1DF44.24163590 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RFC3012-bis: compatibility issues

Hello Luca;

> Luca Salgarelli wrote:
>
>    The Foreign Agent MUST NOT accept any Challenge in the Registration
>    Request unless it was offered in last Registration Reply issued
>    to the Mobile Node, or else advertised as one of the last
>    CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
>    immediately preceding Agent advertisements.  If the Challenge is
>    not one of the recently advertised values, the foreign Agent SHOULD
>    send a Registration Reply with Code value UNKNOWN_CHALLENGE (see
>    section 10).  <NEW TEXT> In addition, if the Challenge is one of
>    the recently advertised values, but was issued before a Challenge
>    already used by the Mobile Node, the Foreign Agent SHOULD send a
>    Registration Reply with code value STALE_CHALLENGE. </NEW TEXT>
>

I think we at least need to apply Charlie suggestion as per Luca text.
I have no problem with this text.

Thanks;
Ahmad

------_=_NextPart_001_01C1DF44.24163590-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 19:19:43 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09551 for ; Mon, 8 Apr 2002 19:19:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01691; Mon, 8 Apr 2002 17:19:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21693; Mon, 8 Apr 2002 16:19:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38NIQIA000363 for ; Mon, 8 Apr 2002 16:18:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g38NIP41000362 for mobile-ip-dist; Mon, 8 Apr 2002 16:18:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g38NIMIA000355 for ; Mon, 8 Apr 2002 16:18:22 -0700 (PDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g38MOgg13811 for ; Mon, 8 Apr 2002 18:24:42 -0400 (EDT) Date: Mon, 8 Apr 2002 18:25:40 -0400 (EDT) From: "Steven M. Glass" Reply-To: "Steven M. Glass" Subject: [mobile-ip] Testing the new headers To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Subject is content. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 8 20:51:17 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11581 for ; Mon, 8 Apr 2002 20:51:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02662; Mon, 8 Apr 2002 18:51:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04580; Mon, 8 Apr 2002 17:50:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g390nvIA000780 for ; Mon, 8 Apr 2002 17:49:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g390nvoF000779 for mobile-ip-dist; Mon, 8 Apr 2002 17:49:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g390nrIA000772 for ; Mon, 8 Apr 2002 17:49:54 -0700 (PDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g390ntg20995 for ; Mon, 8 Apr 2002 20:49:55 -0400 (EDT) Date: Mon, 8 Apr 2002 20:50:53 -0400 (EDT) From: "Steven M. Glass" Reply-To: "Steven M. Glass" Subject: [mobile-ip] headers fixed! To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Barring any unforseen bounce issues, it seems the header issue is resolved! reply: will only reply to the 'From' address (a.k.a. the sender). reply-all: will reply to the 'From', the list, and those CC:ed. Hopefully bounce-behavior is maintained. If you see any odd behavior as a result of one of your posts, please let me know. Thanks for your patience! Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 11:41:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09634 for ; Tue, 9 Apr 2002 11:41:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05015; Tue, 9 Apr 2002 09:41:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25751; Tue, 9 Apr 2002 08:40:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39FdcIA002022 for ; Tue, 9 Apr 2002 08:39:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39Fdbtu002021 for mobile-ip-dist; Tue, 9 Apr 2002 08:39:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39FdYIA002014 for ; Tue, 9 Apr 2002 08:39:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28996 for ; Tue, 9 Apr 2002 08:39:37 -0700 (PDT) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA15390 for ; Tue, 9 Apr 2002 09:39:36 -0600 (MDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Tue Apr 9 11:39:59 EDT 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g39FdWo59344; Tue, 9 Apr 2002 11:39:32 -0400 (EDT) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA00336; Tue, 9 Apr 2002 11:39:29 -0400 (EDT) Subject: Proposed changes to rfc3012bis [was: RE: [mobile-ip] RFC3012-bis: compatibility issues] From: Luca Salgarelli To: Ahmad Muhanna Cc: "'mobile-ip@sunroof.eng.sun.com'" , "'Charlie Perkins'" In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCB8C@zrc2c013.us.nortel.com> References: <6B49EDFE974BD51197D70002A56079D801AFCB8C@zrc2c013.us.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 Apr 2002 11:39:29 -0400 Message-Id: <1018366772.14738.32.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Charlie and Ahmad. After the discussion with Ahmad, and some more thinking on my part, I still think that what's now in rfc3012bis is prone to leaving security holes open. However, I do agree with Ahmad that *maybe* this should be just left to implementors, and we should not impose a strict limit to which challenges in challenge-window are valid as Charlie suggested. So what I would suggest is that we modify the text in rfc3012bis as follows, so that implementors can decide what to do about this problem, but we are at least sure that no security holes are left open. What do you think of the following changes: -------------- Page 2: Delete sentence. stale challenge Same as "previously used challenge". The Foreign Agent may not be able to keep records for all stale challenges. Delete last sentence. Text becomes: stale challenge Same as "previously used challenge". -------------- Page 6: Add new text. to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. If the Challenge is not one of the recently advertised values, the foreign Agent SHOULD send a Registration Reply with Code value UNKNOWN_CHALLENGE (see section 10). The Foreign Agent MUST keep records for all challenges used by a Mobile Node that are still in the valid CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep records for all such previously used challenges, the Foreign Agent MUST set its CHALLENGE_WINDOW to 1. ---------------- What do you think? Luca On Mon, 2002-04-08 at 17:27, Ahmad Muhanna wrote: > Hello Luca; > > > Luca Salgarelli wrote: > > > > The Foreign Agent MUST NOT accept any Challenge in the Registration > > Request unless it was offered in last Registration Reply issued > > to the Mobile Node, or else advertised as one of the last > > CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > > immediately preceding Agent advertisements. If the Challenge is > > not one of the recently advertised values, the foreign Agent SHOULD > > send a Registration Reply with Code value UNKNOWN_CHALLENGE (see > > section 10). In addition, if the Challenge is one of > > the recently advertised values, but was issued before a Challenge > > already used by the Mobile Node, the Foreign Agent SHOULD send a > > Registration Reply with code value STALE_CHALLENGE. > > > > I think we at least need to apply Charlie suggestion as per Luca text. > I have no problem with this text. > > Thanks; > Ahmad From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 11:53:36 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10112 for ; Tue, 9 Apr 2002 11:53:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07453; Tue, 9 Apr 2002 08:53:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29886; Tue, 9 Apr 2002 08:52:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39FqAIA002152 for ; Tue, 9 Apr 2002 08:52:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39FqAR2002151 for mobile-ip-dist; Tue, 9 Apr 2002 08:52:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39Fq7IA002144 for ; Tue, 9 Apr 2002 08:52:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01652 for ; Tue, 9 Apr 2002 08:52:10 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02583 for ; Tue, 9 Apr 2002 09:52:09 -0600 (MDT) 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 IAA22718; Tue, 9 Apr 2002 08:52:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39Fq8U30825; Tue, 9 Apr 2002 08:52:08 -0700 X-mProtect: <200204091552> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsjPzOf; Tue, 09 Apr 2002 08:52:06 PDT Message-ID: <3CB30E26.FFDB3D6@iprg.nokia.com> Date: Tue, 09 Apr 2002 08:52:06 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Luca Salgarelli CC: Ahmad Muhanna , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: Proposed changes to rfc3012bis [was: RE: [mobile-ip] RFC3012-bis:compatibility issues] References: <6B49EDFE974BD51197D70002A56079D801AFCB8C@zrc2c013.us.nortel.com> <1018366772.14738.32.camel@valjean> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Luca, I haven't reviewed every one of the e-mails on this subject, but I do have some comments on the proposed text: Luca Salgarelli wrote: > What do you think of the following changes: > > -------------- > Page 2: Delete sentence. > > stale challenge > Same as "previously used challenge". The Foreign Agent > may not be able to keep records for all stale challenges. > > Delete last sentence. Text becomes: > > stale challenge > Same as "previously used challenge". This is fine. > Page 6: Add new text. > to the Mobile Node, or else advertised as one of the last > CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > immediately preceding Agent advertisements. If the Challenge is > not one of the recently advertised values, the foreign Agent SHOULD > send a Registration Reply with Code value UNKNOWN_CHALLENGE (see > section 10). The Foreign Agent MUST keep records for all > challenges used by a Mobile Node that are still in the valid > CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep > records for all such previously used challenges, the Foreign Agent > MUST set its CHALLENGE_WINDOW to 1. This says that the foreign agent MUST do something. And then it says that if the foreign agent cannot do that thing, it MUST do something else. I prefer that the wording say exactly what the foreign agent MUST do. The mandate can be conditional, but we should not include language that describes what is to be done if a mandate is not met. That's contradictory, and opens up to question what is to be done if other mandates are not met. If mandates are not met, there is no repair. The implementation just is not compliant. In this case, I think the last sentence should be deleted. In subsequent text, it can be explained that setting CHALLENGE_WINDOW to 1 makes it easier to keep track of all "relevant" challenges. However, I would prefer that the window be typically set to at least 2 (not 1), because that will allow for much "better" protocol operation. Lastly, I don't think it is so bad to use the ordering property in order to limit storage requirements, but here is where I should go read the past e-mails to figure out all the issues. So, I would actually prefer this previous version: >>> The Foreign Agent MUST NOT accept any Challenge in the Registration >>> Request unless it was offered in last Registration Reply issued >>> to the Mobile Node, or else advertised as one of the last >>> CHALLENGE_WINDOW (see section 9) Challenge values inserted into the >>> immediately preceding Agent advertisements. If the Challenge is >>> not one of the recently advertised values, the foreign Agent SHOULD >>> send a Registration Reply with Code value UNKNOWN_CHALLENGE (see >>> section 10). In addition, if the Challenge is one of >>> the recently advertised values, but was issued before a Challenge >>> already used by the Mobile Node, the Foreign Agent SHOULD send a >>> Registration Reply with code value STALE_CHALLENGE. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 12:04:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10592 for ; Tue, 9 Apr 2002 12:04:03 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14022; Tue, 9 Apr 2002 10:03:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04294; Tue, 9 Apr 2002 09:02:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39G1aIA002506 for ; Tue, 9 Apr 2002 09:01:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39G1aEP002505 for mobile-ip-dist; Tue, 9 Apr 2002 09:01:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39G1WIA002498 for ; Tue, 9 Apr 2002 09:01:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11070 for ; Tue, 9 Apr 2002 09:01:36 -0700 (PDT) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09039 for ; Tue, 9 Apr 2002 10:01:34 -0600 (MDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with SMTP id g39G5A4b030315; Tue, 9 Apr 2002 18:05:10 +0200 From: "Fredrik Johansson" To: "MobileIP" , "AAA Listan" Subject: [mobile-ip] draft-johansson-mip-aaa-nai-01.txt Date: Tue, 9 Apr 2002 18:01:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi I have submitted a new version of the AAA NAI draft. Until officially announced, it is available at http://stargate.ipunplugged.com/ietf/draft-johansson-mip-aaa-nai-01.txt As always, comments appreciated /Fredrik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 12:08:56 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10757 for ; Tue, 9 Apr 2002 12:08:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23655; Tue, 9 Apr 2002 10:08:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05828; Tue, 9 Apr 2002 09:08:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39G7kIA002627 for ; Tue, 9 Apr 2002 09:07:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39G7kUC002626 for mobile-ip-dist; Tue, 9 Apr 2002 09:07:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39G7hIA002619 for ; Tue, 9 Apr 2002 09:07:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04637 for ; Tue, 9 Apr 2002 09:07:43 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14642 for ; Tue, 9 Apr 2002 09:07:43 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39G7T420904; Tue, 9 Apr 2002 11:07:29 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXVLKWA>; Tue, 9 Apr 2002 11:07:31 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB8F@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Luca Salgarelli'" Cc: "'mobile-ip@sunroof.eng.sun.com'" , "'Charlie Perkins'" Subject: RE: Proposed changes to rfc3012bis [was: RE: [mobile-ip] RFC3012- bis: compatibility issues] Date: Tue, 9 Apr 2002 11:07:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFE0.A65A5210" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DFE0.A65A5210 Content-Type: text/plain; charset="iso-8859-1" Hello Luca; Excellent. I think it is great and I agree with the text. However, please see the comment below. > > > Hello Charlie and Ahmad. > > After the discussion with Ahmad, and some more thinking on my part, I > still think that what's now in rfc3012bis is prone to leaving security > holes open. > > However, I do agree with Ahmad that *maybe* this should be > just left to > implementors, and we should not impose a strict limit to which > challenges in challenge-window are valid as Charlie suggested. > > So what I would suggest is that we modify the text in rfc3012bis as > follows, so that implementors can decide what to do about > this problem, > but we are at least sure that no security holes are left open. > > What do you think of the following changes: > > -------------- > Page 2: Delete sentence. > > stale challenge > Same as "previously used challenge". The Foreign Agent > may not be able to keep records for all stale > challenges. > > > Delete last sentence. Text becomes: > > stale challenge > Same as "previously used challenge". > I do not see why we need to remove this line. This addresses all kinds of stale challenges including those which are sent in the unicast advertisement and the Registration Reply. The most important point, I do not see any contradiction by leaving this line and your proposed text below. Basically, the below text allows what the deleted line suggest BUT put some restriction to avoid any security holes for one kind of challenges. What do you think? > -------------- > Page 6: Add new text. > to the Mobile Node, or else advertised as one of the last > CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > immediately preceding Agent advertisements. If the Challenge is > not one of the recently advertised values, the foreign Agent SHOULD > send a Registration Reply with Code value UNKNOWN_CHALLENGE (see > section 10). The Foreign Agent MUST keep records for all > challenges used by a Mobile Node that are still in the valid > CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep > records for all such previously used challenges, the Foreign Agent > MUST set its CHALLENGE_WINDOW to 1. > ---------------- Perfect!! I agree. > > What do you think? > > Luca > > On Mon, 2002-04-08 at 17:27, Ahmad Muhanna wrote: > > Hello Luca; > > > > > Luca Salgarelli wrote: > > > > > > The Foreign Agent MUST NOT accept any Challenge in the > Registration > > > Request unless it was offered in last Registration Reply issued > > > to the Mobile Node, or else advertised as one of the last > > > CHALLENGE_WINDOW (see section 9) Challenge values > inserted into the > > > immediately preceding Agent advertisements. If the > Challenge is > > > not one of the recently advertised values, the foreign > Agent SHOULD > > > send a Registration Reply with Code value > UNKNOWN_CHALLENGE (see > > > section 10). In addition, if the Challenge > is one of > > > the recently advertised values, but was issued before > a Challenge > > > already used by the Mobile Node, the Foreign Agent > SHOULD send a > > > Registration Reply with code value STALE_CHALLENGE. > > > > > > > I think we at least need to apply Charlie suggestion as per > Luca text. > > I have no problem with this text. > > > > Thanks; > > Ahmad > > > ------_=_NextPart_001_01C1DFE0.A65A5210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed changes to rfc3012bis [was: RE: [mobile-ip] = RFC3012-bis: compatibility issues]

Hello Luca;
Excellent.

I think it is great and I agree with the text.
However, please see the comment below.

>
>
> Hello Charlie and Ahmad.
>
> After the discussion with Ahmad, and some more = thinking on my part, I
> still think that what's now in rfc3012bis is = prone to leaving security
> holes open.
>
> However, I do agree with Ahmad that *maybe* = this should be
> just left to
> implementors, and we should not impose a strict = limit to which
> challenges in challenge-window are valid as = Charlie suggested.
>
> So what I would suggest is that we modify the = text in rfc3012bis as
> follows, so that implementors can decide what = to do about
> this problem,
> but we are at least sure that no security holes = are left open.
>
> What do you think of the following = changes:
>
> --------------
> Page 2: Delete sentence.
>
>       stale = challenge
>          = ;      Same as "previously used = challenge".  The Foreign Agent
>          = ;      may not be able to keep records for all = stale
> challenges.
>
>
> Delete last sentence. Text becomes:
>
>       stale = challenge
>          = ;      Same as "previously used = challenge".
>
I do not see why we need to remove this line. This = addresses all kinds of stale
challenges including those which are sent in the = unicast advertisement and
the Registration Reply.
The most important point, I do not see any = contradiction by leaving this line and your
proposed text below.
Basically, the below text allows what the deleted = line suggest BUT put some restriction
to avoid any security holes for one kind of = challenges.

What do you think?

> --------------
> Page 6: Add new text.
>    to the Mobile Node, or else = advertised as one of the last
>    CHALLENGE_WINDOW (see section = 9) Challenge values inserted into the
>    immediately preceding Agent = advertisements.  If the Challenge is
>    not one of the recently = advertised values, the foreign Agent SHOULD
>    send a Registration Reply = with Code value UNKNOWN_CHALLENGE (see
>    section 10). = <NEW-TEXT>The Foreign Agent MUST keep records for all
>    challenges used by a Mobile = Node that are still in the valid
>    CHALLENGE_WINDOW. In the = event that a Foreign Agent cannot keep
>    records for all such = previously used challenges, the Foreign Agent
>    MUST set its CHALLENGE_WINDOW = to 1.</NEW-TEXT>
> ----------------

Perfect!!
I agree.

>
> What do you think?
>
> Luca
>
> On Mon, 2002-04-08 at 17:27, Ahmad Muhanna = wrote:
> > Hello Luca;
> >
> > > Luca Salgarelli wrote:
> > >
> > >    The Foreign Agent = MUST NOT accept any Challenge in the
> Registration
> > >    Request unless it = was offered in last Registration Reply issued
> > >    to the Mobile Node, = or else advertised as one of the last
> > >    CHALLENGE_WINDOW = (see section 9) Challenge values
> inserted into the
> > >    immediately = preceding Agent advertisements.  If the
> Challenge is
> > >    not one of the = recently advertised values, the foreign
> Agent SHOULD
> > >    send a Registration = Reply with Code value
> UNKNOWN_CHALLENGE (see
> > >    section 10).  = <NEW TEXT> In addition, if the Challenge
> is one of
> > >    the recently = advertised values, but was issued before
> a Challenge
> > >    already used by the = Mobile Node, the Foreign Agent
> SHOULD send a
> > >    Registration Reply = with code value STALE_CHALLENGE. </NEW TEXT>
> > >
> >
> > I think we at least need to apply Charlie = suggestion as per
> Luca text.
> > I have no problem with this text.
> >
> > Thanks;
> > Ahmad
>
>
>

------_=_NextPart_001_01C1DFE0.A65A5210-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 12:16:14 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10976 for ; Tue, 9 Apr 2002 12:16:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22158; Tue, 9 Apr 2002 10:16:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07740; Tue, 9 Apr 2002 09:15:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39GELIA002715 for ; Tue, 9 Apr 2002 09:14:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39GELVq002714 for mobile-ip-dist; Tue, 9 Apr 2002 09:14:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39GEIIA002707 for ; Tue, 9 Apr 2002 09:14:18 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06662 for ; Tue, 9 Apr 2002 09:14:21 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA21123 for ; Tue, 9 Apr 2002 10:14:20 -0600 (MDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Tue Apr 9 12:13:18 EDT 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g39GDZo63150; Tue, 9 Apr 2002 12:13:35 -0400 (EDT) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA01976; Tue, 9 Apr 2002 12:13:35 -0400 (EDT) Subject: Re: Proposed changes to rfc3012bis [was: RE: [mobile-ip] RFC3012-bis:compatibility issues] From: Luca Salgarelli To: "Charles E. Perkins" Cc: Ahmad Muhanna , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: <3CB30E26.FFDB3D6@iprg.nokia.com> References: <6B49EDFE974BD51197D70002A56079D801AFCB8C@zrc2c013.us.nortel.com> <1018366772.14738.32.camel@valjean> <3CB30E26.FFDB3D6@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 09 Apr 2002 12:13:34 -0400 Message-Id: <1018368815.14897.51.camel@valjean> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Charlie. Please see comments inline. > > Page 6: Add new text. > > to the Mobile Node, or else advertised as one of the last > > CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > > immediately preceding Agent advertisements. If the Challenge is > > not one of the recently advertised values, the foreign Agent SHOULD > > send a Registration Reply with Code value UNKNOWN_CHALLENGE (see > > section 10). The Foreign Agent MUST keep records for all > > challenges used by a Mobile Node that are still in the valid > > CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep > > records for all such previously used challenges, the Foreign Agent > > MUST set its CHALLENGE_WINDOW to 1. > > This says that the foreign agent MUST do something. And then it says > that if the foreign agent cannot do that thing, it MUST do something > else. > > I prefer that the wording say exactly what the foreign agent MUST do. > The mandate can be conditional, but we should not include language > that describes what is to be done if a mandate is not met. That's > contradictory, and opens up to question what is to be done if other > mandates are not met. I agree. But: > If mandates are not met, there is no repair. The implementation just > is not compliant. > > In this case, I think the last sentence should be deleted. In subsequent > text, it can be explained that setting CHALLENGE_WINDOW to 1 makes it > easier to keep track of all "relevant" challenges. However, I would > prefer that the window be typically set to at least 2 (not 1), because > that will allow for much "better" protocol operation. > > Lastly, I don't think it is so bad to use the ordering property in > order to limit storage requirements, but here is where I should go > read the past e-mails to figure out all the issues. The issue Ahmad brought up, and that made me think more, is that we are not sure that somebody will not find a way of keeping track of all the relevant challenges in a scalable way, so this should be really left to implementors. In addition, re-thinking about the implementation of your suggested mechanism, I think it could become relatively expensive as well, since its computational complexity grows with increasing CHALLENGE_WINDOW. And the problem is that the text I originally proposed would mandate that for everybody. How about this variant of my 2nd text: section 10). The Foreign Agent SHOULD keep records for all challenges used by a Mobile Node that are still in the valid CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep records for all such previously used challenges, the Foreign Agent MUST set its CHALLENGE_WINDOW to 1. Again, this would leave the door open to implementors to decide which road they want to take, without limiting everybody to put a limit on the order in which clients have to use challenges. Luca > So, I would > actually prefer this previous version: > > >>> The Foreign Agent MUST NOT accept any Challenge in the Registration > >>> Request unless it was offered in last Registration Reply issued > >>> to the Mobile Node, or else advertised as one of the last > >>> CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > >>> immediately preceding Agent advertisements. If the Challenge is > >>> not one of the recently advertised values, the foreign Agent SHOULD > >>> send a Registration Reply with Code value UNKNOWN_CHALLENGE (see > >>> section 10). In addition, if the Challenge is one of > >>> the recently advertised values, but was issued before a Challenge > >>> already used by the Mobile Node, the Foreign Agent SHOULD send a > >>> Registration Reply with code value STALE_CHALLENGE. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 12:30:33 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11407 for ; Tue, 9 Apr 2002 12:30:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16990; Tue, 9 Apr 2002 09:30:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11180; Tue, 9 Apr 2002 09:30:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39GT2IA002845 for ; Tue, 9 Apr 2002 09:29:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39GT2fm002844 for mobile-ip-dist; Tue, 9 Apr 2002 09:29:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39GSxIA002837 for ; Tue, 9 Apr 2002 09:28:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10931 for ; Tue, 9 Apr 2002 09:29:02 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07986 for ; Tue, 9 Apr 2002 10:29:02 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39GSj424296; Tue, 9 Apr 2002 11:28:45 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXVLLJC>; Tue, 9 Apr 2002 11:28:45 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB91@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Luca Salgarelli'" , "Charles E. Perkins" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: Proposed changes to rfc3012bis [was: RE: [mobile-ip] RFC3012 -bis:compatibility issues] Date: Tue, 9 Apr 2002 11:28:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFE3.9BCC1CE0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DFE3.9BCC1CE0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie and Luca; I am sorry for my earlier email. I did send it before reading Charlie comments. I although agree with Charlie about deleting the last sentence of the proposed text by Luca. The Foreign Agent SHOULD keep records for all challenges used by a Mobile Node that are still in the valid CHALLENGE_WINDOW. I believe including the above text alone is what we need. This is good to prevent any security holes. Now: implementors are free to comply with this restriction the way they find fit. My previous comments is still valid for keeping the following text intact. stale challenge Same as "previously used challenge". The Foreign Agent may not be able to keep records for all stale challenges. What do you think? Ahmad > > > Hello Charlie. > > Please see comments inline. > > > > Page 6: Add new text. > > > to the Mobile Node, or else advertised as one of the last > > > CHALLENGE_WINDOW (see section 9) Challenge values > inserted into the > > > immediately preceding Agent advertisements. If the > Challenge is > > > not one of the recently advertised values, the foreign > Agent SHOULD > > > send a Registration Reply with Code value > UNKNOWN_CHALLENGE (see > > > section 10). The Foreign Agent MUST keep > records for all > > > challenges used by a Mobile Node that are still in the valid > > > CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep > > > records for all such previously used challenges, the > Foreign Agent > > > MUST set its CHALLENGE_WINDOW to 1. > > > > This says that the foreign agent MUST do something. And > then it says > > that if the foreign agent cannot do that thing, it MUST do something > > else. > > > > I prefer that the wording say exactly what the foreign > agent MUST do. > > The mandate can be conditional, but we should not include language > > that describes what is to be done if a mandate is not met. That's > > contradictory, and opens up to question what is to be done if other > > mandates are not met. > > I agree. But: > > > If mandates are not met, there is no repair. The > implementation just > > is not compliant. > > > > In this case, I think the last sentence should be deleted. > In subsequent > > text, it can be explained that setting CHALLENGE_WINDOW to > 1 makes it > > easier to keep track of all "relevant" challenges. However, I would > > prefer that the window be typically set to at least 2 (not > 1), because > > that will allow for much "better" protocol operation. > > > > Lastly, I don't think it is so bad to use the ordering property in > > order to limit storage requirements, but here is where I should go > > read the past e-mails to figure out all the issues. > > The issue Ahmad brought up, and that made me think more, is > that we are > not sure that somebody will not find a way of keeping track of all the > relevant challenges in a scalable way, so this should be > really left to > implementors. > > In addition, re-thinking about the implementation of your suggested > mechanism, I think it could become relatively expensive as well, since > its computational complexity grows with increasing > CHALLENGE_WINDOW. And > the problem is that the text I originally proposed would mandate that > for everybody. > > How about this variant of my 2nd text: > > section 10). The Foreign Agent SHOULD keep > records for all > challenges used by a Mobile Node that are still in the valid > CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep > records for all such previously used challenges, the Foreign Agent > MUST set its CHALLENGE_WINDOW to 1. > > Again, this would leave the door open to implementors to decide which > road they want to take, without limiting everybody to put a > limit on the > order in which clients have to use challenges. > > Luca > > > So, I would > > actually prefer this previous version: > > > > >>> The Foreign Agent MUST NOT accept any Challenge in > the Registration > > >>> Request unless it was offered in last Registration > Reply issued > > >>> to the Mobile Node, or else advertised as one of the last > > >>> CHALLENGE_WINDOW (see section 9) Challenge values > inserted into the > > >>> immediately preceding Agent advertisements. If the > Challenge is > > >>> not one of the recently advertised values, the > foreign Agent SHOULD > > >>> send a Registration Reply with Code value > UNKNOWN_CHALLENGE (see > > >>> section 10). In addition, if the > Challenge is one of > > >>> the recently advertised values, but was issued > before a Challenge > > >>> already used by the Mobile Node, the Foreign Agent > SHOULD send a > > >>> Registration Reply with code value STALE_CHALLENGE. > > > > > Regards, > > Charlie P. > > ------_=_NextPart_001_01C1DFE3.9BCC1CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed changes to rfc3012bis [was: RE: [mobile-ip] = RFC3012-bis:compatibility issues]

Hello Charlie and Luca;

I am sorry for my earlier email. I did send it before = reading Charlie comments.
I although agree with Charlie about deleting the = last sentence of the proposed
text by Luca.

        <NEW-TEXT>The Foreign Agent SHOULD keep records for = all
        challenges = used by a Mobile Node that are still in the valid
        = CHALLENGE_WINDOW.<NEW-TEXT>

I believe including the above text alone is what we = need. This is good to prevent
any security holes.
Now: implementors are free to comply with this = restriction the way they find fit.

My previous comments is still valid for keeping the = following text intact.
       =20
      stale = challenge
          &nb= sp;    Same as "previously used = challenge".  The Foreign Agent
          &nb= sp;    may not be able to keep records for all stale = challenges.

What do you think?

Ahmad

>
>
> Hello Charlie.
>
> Please see comments inline.
>
> > > Page 6: Add new text.
> > >    to the Mobile Node, = or else advertised as one of the last
> > >    CHALLENGE_WINDOW = (see section 9) Challenge values
> inserted into the
> > >    immediately = preceding Agent advertisements.  If the
> Challenge is
> > >    not one of the = recently advertised values, the foreign
> Agent SHOULD
> > >    send a Registration = Reply with Code value
> UNKNOWN_CHALLENGE (see
> > >    section 10). = <NEW-TEXT>The Foreign Agent MUST keep
> records for all
> > >    challenges used by = a Mobile Node that are still in the valid
> > >    CHALLENGE_WINDOW. = In the event that a Foreign Agent cannot keep
> > >    records for all = such previously used challenges, the
> Foreign Agent
> > >    MUST set its = CHALLENGE_WINDOW to 1.</NEW-TEXT>
> >
> > This says that the foreign agent MUST do = something.  And
> then it says
> > that if the foreign agent cannot do that = thing, it MUST do something
> > else.
> >
> > I prefer that the wording say exactly what = the foreign
> agent MUST do.
> > The mandate can be conditional, but we = should not include language
> > that describes what is to be done if a = mandate is not met.  That's
> > contradictory, and opens up to question = what is to be done if other
> > mandates are not met.
>
> I agree. But:
>
> > If mandates are not met, there is no = repair.  The
> implementation just
> > is not compliant.
> >
> > In this case, I think the last sentence = should be deleted. 
> In subsequent
> > text, it can be explained that setting = CHALLENGE_WINDOW to
> 1 makes it
> > easier to keep track of all = "relevant" challenges.  However, I would
> > prefer that the window be typically set to = at least 2 (not
> 1), because
> > that will allow for much = "better" protocol operation.
> >
> > Lastly, I don't think it is so bad to use = the ordering property in
> > order to limit storage requirements, but = here is where I should go
> > read the past e-mails to figure out all = the issues.
>
> The issue Ahmad brought up, and that made me = think more, is
> that we are
> not sure that somebody will not find a way of = keeping track of all the
> relevant challenges in a scalable way, so this = should be
> really left to
> implementors.
>
> In addition, re-thinking about the = implementation of your suggested
> mechanism, I think it could become relatively = expensive as well, since
> its computational complexity grows with = increasing
> CHALLENGE_WINDOW. And
> the problem is that the text I originally = proposed would mandate that
> for everybody.
>
> How about this variant of my 2nd text:
>
>     section 10). = <NEW-TEXT>The Foreign Agent SHOULD keep
> records for all
>     challenges used by a = Mobile Node that are still in the valid
>     CHALLENGE_WINDOW. In = the event that a Foreign Agent cannot keep
>     records for all such = previously used challenges, the Foreign Agent
>     MUST set its = CHALLENGE_WINDOW to 1.</NEW-TEXT>
>
> Again, this would leave the door open to = implementors to decide which
> road they want to take, without limiting = everybody to put a
> limit on the
> order in which clients have to use = challenges.
>
> Luca
>
> > So, I would
> > actually prefer this previous = version:
> >
> > >>>    The Foreign = Agent MUST NOT accept any Challenge in
> the Registration
> > >>>    Request = unless it was offered in last Registration
> Reply issued
> > >>>    to the = Mobile Node, or else advertised as one of the last
> > >>>    = CHALLENGE_WINDOW (see section 9) Challenge values
> inserted into the
> > >>>    immediately = preceding Agent advertisements.  If the
> Challenge is
> > >>>    not one of = the recently advertised values, the
> foreign Agent SHOULD
> > >>>    send a = Registration Reply with Code value
> UNKNOWN_CHALLENGE (see
> > >>>    section = 10).  <NEW TEXT> In addition, if the
> Challenge is one of
> > >>>    the = recently advertised values, but was issued
> before a Challenge
> > >>>    already = used by the Mobile Node, the Foreign Agent
> SHOULD send a
> > >>>    = Registration Reply with code value STALE_CHALLENGE.
> </NEW TEXT>
> >
> > Regards,
> > Charlie P.
>
>

------_=_NextPart_001_01C1DFE3.9BCC1CE0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 13:02:20 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12191 for ; Tue, 9 Apr 2002 13:02:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24218; Tue, 9 Apr 2002 10:02:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22436; Tue, 9 Apr 2002 10:01:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39H0tIA003016 for ; Tue, 9 Apr 2002 10:00:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39H0ti0003015 for mobile-ip-dist; Tue, 9 Apr 2002 10:00:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39H0qIA003008 for ; Tue, 9 Apr 2002 10:00:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22031 for ; Tue, 9 Apr 2002 10:00:56 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06328 for ; Tue, 9 Apr 2002 10:00:55 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AD4276A901 for ; Tue, 9 Apr 2002 20:00:48 +0300 (EEST) Message-ID: <3CB3109A.1070002@piuha.net> Date: Tue, 09 Apr 2002 19:02:34 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #1: Suboptions needed? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The design team is trying to resolve all remaining issues in the MIPv6 specification. A series of e-mails will be sent to the list that explain the issue and the proposed resolution. The resolutions go to draft-17 if there is no big controversy about it. As these issues are expected to be smaller than the major design decisions taken earlier this year it is perhaps sufficient to respond to these mails only if you don't agree with the proposal i.e. silence means consensus. The current issue list is at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html I'll be completing the issue list over the next few days. I have also tried to include a few issues that we have talked about in the mailing list and appear to have a consensus on already for the purposes of keeping track of things. And now to the first issue. Background: Draft 16 moved BUs and other messages away from the IPv6 DO header. Earlier drafts had suboptions such as the Alternate Care-of Address suboption which in draft 16 are now under the messages. A single option remains in draft 16, the HAO. Draft 16 still retains the possibility to have 'suboptions' in this option. Question: Does it make sense to keep suboptions just for HAO? There are currently no suboptions in HAO. Most of the uses for what used to be called suboptions can now be handled using a similar mechanism inside the Mobility Header. Proposal: Remove suboptions from Draft 17. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 13:20:24 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12671 for ; Tue, 9 Apr 2002 13:20:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01281; Tue, 9 Apr 2002 11:20:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29312; Tue, 9 Apr 2002 10:20:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HJ6IA003137 for ; Tue, 9 Apr 2002 10:19:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39HJ67i003136 for mobile-ip-dist; Tue, 9 Apr 2002 10:19:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HJ3IA003129 for ; Tue, 9 Apr 2002 10:19:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02086 for ; Tue, 9 Apr 2002 10:19:05 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10463 for ; Tue, 9 Apr 2002 11:19:04 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3E4586A901 for ; Tue, 9 Apr 2002 20:18:58 +0300 (EEST) Message-ID: <3CB314DC.6090300@piuha.net> Date: Tue, 09 Apr 2002 19:20:44 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #2: replay protection and nvm usage References: <3CB3109A.1070002@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit There seems to be consensus about this but I'll send an issue item about this just to document what's going on. Background: Draft 16 included a requirement that HAs must keep BU sequence numbers in non-volatile storage to prevent replays. Folks on the list questioned this in two ways: First, draft 15 already had a resynchronization procedure (which didn't provide replay protection but allowed loss of state). Second, building a replay protection scheme to manually keyed IPsec was seen as a bad alternative to using a key management protocol or building better replay protection to manually keyed IPsec. Note also that MIPv6 must provide ordering support since IPsec replay protection doesn't guarantee ordering, just prevents replays. Therefore, the Sequence# field is needed in the BUs in any case. Question: Pick one for replay protection: 1. Require IPsec + IKE. No replay problem. 2. Require at least IPsec, but keep IKE as optional. Don't add any features for replay protection. Folks who don't use IKE will suffer from the replay vulnerability. 3. Require at least IPsec, optional IKE but add an application layer feature for replay protection to prevent replays if you happened to not have IKE. This was the draft 16 approach. 4. Require at least IPSec and a TBD light weight key management scheme, perhaps optional IKE in some cases. No application layer features. Replay protection works perfectly for everyone. Proposal: Solution 2, but described in a way that makes it clear to implementers that replay attacks become possible only if manual keying is used and state loss can happen. Don't state any specific key management mechanism. Text. Text in 4.5.4: IPsec can provide replay protection only when dynamic security association establishment is used. This may not always be possible, and manual keying would be preferred in some cases. IPsec also does not guarantee correct ordering of packets, only that they have not been replayed. Because of this, Mobile IPv6 provides its own mechanism inside the Binding Update and Acknowledgement messages. A sequence number field is used to ensure correct ordering. If the mobile node reboots and forgets its current sequence number, the home agent uses the status value 141 (Sequence number out of window, see Section X.X) to inform the mobile node of the use of an improper sequence number. Note that the the sequence number mechanism provides also a weak form of replay protection. However, if a home agent reboots and loses its state regarding the sequence numbers, replay attacks become possible. If the home agent is vulnerable to this, the use of a key management mechanism together with IPsec can be used to prevent replay attacks. A sliding window scheme is used for the sequence numbers. Therefore the protection against replays and reordering attacks without a key management mechanism works when the attacker remembers up to a maximum of 2**15 Binding Updates. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 13:21:17 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12755 for ; Tue, 9 Apr 2002 13:21:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28848; Tue, 9 Apr 2002 10:20:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29897; Tue, 9 Apr 2002 10:20:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HK9IA003157 for ; Tue, 9 Apr 2002 10:20:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39HK9Et003156 for mobile-ip-dist; Tue, 9 Apr 2002 10:20:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HK5IA003149 for ; Tue, 9 Apr 2002 10:20:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02620 for ; Tue, 9 Apr 2002 10:20:07 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA29889 for ; Tue, 9 Apr 2002 11:20:07 -0600 (MDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id <2GCFAZ7Z>; Tue, 9 Apr 2002 19:19:35 +0200 Received: from pdico (p-dico.rd.francetelecom.fr [10.193.165.17]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2GC6S3ZN; Tue, 9 Apr 2002 19:19:31 +0200 From: "Jean-Michel COMBES" To: , Subject: Issues Format [Was : RE: [mobile-ip] Unresolved issue #1: Suboptions needed?] Date: Tue, 9 Apr 2002 19:19:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CB3109A.1070002@piuha.net> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jari, very nice idea !!!!!!! Good work too :-) BTW, just a comment : would it be possible to indicate for each issue (even if the issue is closed, ie. accepted/rejected) what is the context/problem and how is it resolved ? It is just to avoid to see again the same problem in one or two years ... Best regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 -----Message d'origine----- De : Jari Arkko [mailto:jari.arkko@piuha.net] Envoye : mardi 9 avril 2002 18:03 A : mobile-ip@sunroof.eng.sun.com Objet : [mobile-ip] Unresolved issue #1: Suboptions needed? The design team is trying to resolve all remaining issues in the MIPv6 specification. A series of e-mails will be sent to the list that explain the issue and the proposed resolution. The resolutions go to draft-17 if there is no big controversy about it. As these issues are expected to be smaller than the major design decisions taken earlier this year it is perhaps sufficient to respond to these mails only if you don't agree with the proposal i.e. silence means consensus. The current issue list is at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html I'll be completing the issue list over the next few days. I have also tried to include a few issues that we have talked about in the mailing list and appear to have a consensus on already for the purposes of keeping track of things. And now to the first issue. Background: Draft 16 moved BUs and other messages away from the IPv6 DO header. Earlier drafts had suboptions such as the Alternate Care-of Address suboption which in draft 16 are now under the messages. A single option remains in draft 16, the HAO. Draft 16 still retains the possibility to have 'suboptions' in this option. Question: Does it make sense to keep suboptions just for HAO? There are currently no suboptions in HAO. Most of the uses for what used to be called suboptions can now be handled using a similar mechanism inside the Mobility Header. Proposal: Remove suboptions from Draft 17. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 13:25:41 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12999 for ; Tue, 9 Apr 2002 13:25:40 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03494; Tue, 9 Apr 2002 11:25:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02375; Tue, 9 Apr 2002 10:25:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HNoIA003324 for ; Tue, 9 Apr 2002 10:23:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39HNo9t003323 for mobile-ip-dist; Tue, 9 Apr 2002 10:23:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HNkIA003316 for ; Tue, 9 Apr 2002 10:23:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01322 for ; Tue, 9 Apr 2002 10:23:48 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14942 for ; Tue, 9 Apr 2002 11:23:42 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g39HNXA32391; Tue, 9 Apr 2002 19:23:33 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA22131; Tue, 9 Apr 2002 19:23:34 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g39HNXn15091; Tue, 9 Apr 2002 19:23:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204091723.g39HNXn15091@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #1: Suboptions needed? In-reply-to: Your message of Tue, 09 Apr 2002 19:02:34 +0300. <3CB3109A.1070002@piuha.net> Date: Tue, 09 Apr 2002 19:23:33 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Proposal: Remove suboptions from Draft 17. => AGREE Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 13:27:48 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13064 for ; Tue, 9 Apr 2002 13:27:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00771; Tue, 9 Apr 2002 10:27:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03555; Tue, 9 Apr 2002 10:27:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HQaIA003444 for ; Tue, 9 Apr 2002 10:26:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39HQZsj003442 for mobile-ip-dist; Tue, 9 Apr 2002 10:26:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HQWIA003432 for ; Tue, 9 Apr 2002 10:26:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03002 for ; Tue, 9 Apr 2002 10:26:34 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00607 for ; Tue, 9 Apr 2002 10:26:33 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4324B6A901; Tue, 9 Apr 2002 20:26:27 +0300 (EEST) Message-ID: <3CB3169D.5040007@piuha.net> Date: Tue, 09 Apr 2002 19:28:13 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Jean-Michel COMBES Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: Issues Format [Was : RE: [mobile-ip] Unresolved issue #1: Suboptions needed?] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jean-Michel COMBES wrote: > BTW, just a comment : would it be possible to indicate for each issue (even > if the issue is closed, ie. accepted/rejected) what is the context/problem > and how is it resolved ? > It is just to avoid to see again the same problem in one or two years ... The intention is to update the descriptions (the issue.txt files) as we decide something, whatever that decision is. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 13:35:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13330 for ; Tue, 9 Apr 2002 13:35:45 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21525; Tue, 9 Apr 2002 11:35:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09382; Tue, 9 Apr 2002 10:35:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HXhIA003704 for ; Tue, 9 Apr 2002 10:33:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39HXgJA003703 for mobile-ip-dist; Tue, 9 Apr 2002 10:33:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HXaIA003696 for ; Tue, 9 Apr 2002 10:33:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08838 for ; Tue, 9 Apr 2002 10:33:39 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03453 for ; Tue, 9 Apr 2002 10:33:38 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g39HXWq6029411; Tue, 9 Apr 2002 10:33:32 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABK34378; Tue, 9 Apr 2002 10:30:45 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA15993; Tue, 9 Apr 2002 10:33:32 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15539.9708.92656.81670@thomasm-u1.cisco.com> Date: Tue, 9 Apr 2002 10:33:32 -0700 (PDT) To: jari.arkko@piuha.net Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #2: replay protection and nvm usage In-Reply-To: <3CB314DC.6090300@piuha.net> References: <3CB3109A.1070002@piuha.net> <3CB314DC.6090300@piuha.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 2. Require at least IPsec, but keep IKE as optional. Don't add > any features for replay protection. Folks who don't use IKE > will suffer from the replay vulnerability. Content-Transfer-Encoding: 7bit Agree. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 13:41:32 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13721 for ; Tue, 9 Apr 2002 13:41:32 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03723; Tue, 9 Apr 2002 10:41:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11174; Tue, 9 Apr 2002 10:41:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HeNIA003842 for ; Tue, 9 Apr 2002 10:40:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39HeMGW003841 for mobile-ip-dist; Tue, 9 Apr 2002 10:40:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HeJIA003834 for ; Tue, 9 Apr 2002 10:40:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21094 for ; Tue, 9 Apr 2002 10:40:22 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA12664 for ; Tue, 9 Apr 2002 11:40:21 -0600 (MDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id <2GCFA5DW>; Tue, 9 Apr 2002 19:38:42 +0200 Received: from pdico (p-dico.rd.francetelecom.fr [10.193.165.17]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2GC6S3Z6; Tue, 9 Apr 2002 19:38:36 +0200 From: "Jean-Michel COMBES" To: , Subject: RE: [mobile-ip] Unresolved issue #2: replay protection and nvm usage Date: Tue, 9 Apr 2002 19:38:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CB314DC.6090300@piuha.net> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit agree France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 Text. Text in 4.5.4: IPsec can provide replay protection only when dynamic security association establishment is used. This may not always be possible, and manual keying would be preferred in some cases. IPsec also does not guarantee correct ordering of packets, only that they have not been replayed. Because of this, Mobile IPv6 provides its own mechanism inside the Binding Update and Acknowledgement messages. A sequence number field is used to ensure correct ordering. If the mobile node reboots and forgets its current sequence number, the home agent uses the status value 141 (Sequence number out of window, see Section X.X) to inform the mobile node of the use of an improper sequence number. Note that the the sequence number mechanism provides also a weak form of replay protection. However, if a home agent reboots and loses its state regarding the sequence numbers, replay attacks become possible. If the home agent is vulnerable to this, the use of a key management mechanism together with IPsec can be used to prevent replay attacks. A sliding window scheme is used for the sequence numbers. Therefore the protection against replays and reordering attacks without a key management mechanism works when the attacker remembers up to a maximum of 2**15 Binding Updates. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 13:51:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14086 for ; Tue, 9 Apr 2002 13:51:57 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01338; Tue, 9 Apr 2002 11:51:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13787; Tue, 9 Apr 2002 10:51:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HoQIA003954 for ; Tue, 9 Apr 2002 10:50:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39HoQAd003953 for mobile-ip-dist; Tue, 9 Apr 2002 10:50:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HoNIA003946 for ; Tue, 9 Apr 2002 10:50:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06804 for ; Tue, 9 Apr 2002 10:50:25 -0700 (PDT) Received: from ocelot.cs.odu.edu (ocelot.cs.odu.edu [128.82.4.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29483 for ; Tue, 9 Apr 2002 11:50:22 -0600 (MDT) Received: from dilbert.cs.odu.edu (dilbert.cs.odu.edu [128.82.4.66]) by ocelot.cs.odu.edu (8.10.1/8.10.1) with ESMTP id g39Hn1O13731; Tue, 9 Apr 2002 13:49:01 -0400 (EDT) Received: from localhost (hamid@localhost) by dilbert.cs.odu.edu (8.11.6+Sun/8.9.1) with ESMTP id g39Ho0l18580; Tue, 9 Apr 2002 13:50:00 -0400 (EDT) X-Authentication-Warning: dilbert.cs.odu.edu: hamid owned process doing -bs Date: Tue, 9 Apr 2002 13:50:00 -0400 (EDT) From: Ayman A Abdel Hamid To: Mobile IP mailing list at Sun cc: Ayman A Abdel Hamid Subject: [mobile-ip] regional registration MIPv4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, I have a question about internet draft Mobile IPv4 Regional Registration draft-ietf-mobileip-reg-tunnel-06.txt in section B.2 handling Binding Updates and B.3 regional registration assume the following scenario GFA / RFA3 / RFA0 / \ RFA1 RFA2 / \ FA1 FA2 the MH is handing off regionally from FA2 to FA1 (cross-over FA is RFA0), then according to my understanding MH uses PFANE and FA1 sends a BU to FA2 with coa FA1. In this case FA2 relays the BU upwards to RFA2 with coa FA2, which does the same and relays it to RFA0 with coa RFA2. now if this message reaches RFA0 before the registration request from the new path, RFA0 relays the BU to RFA3 with coa RFA0. in this case RFA0 and maybe (RFA3,GFA) will mistakingly delete their visitor list entry for MH and replace it with a binding cache entry. The same can happen if this is a home registration which is actually a local handoff. Is my analysis right? The draft specifies the following in section B.2 "In the unlikely event that the crossover FA receives the Binding Update before it receives the Registration Request, it doesn't know that it is the crossover FA yet, and therefore relays the Binding Update to the next Foreign Agent. When the crossover FA later receives the Registration Request, it will know that it is the crossover FA, and will send a Binding Acknowledge message to the mobile node (via the old route). The foreign agents above the crossover FA in the hierarchy that also got the Binding Update will see that the Binding Update does not supply any new care-of address information. so they and will ignore the Binding Update." The condition that "the coa supplied by the BU from child RFA to father RFA is the same as the coa stored in the visitor list entry" is satisfied for all RFAs in the old path? and later in B.3 "The Previous Foreign Agent Notification Extension, Binding Updates and Binding Acknowledge messages are used for Regional Registrations in the same way as for Home Registrations." so the draft is stating that the handling is the same whether it is a home or regional registration although the processing is OK for the Home registration (even if RFAs replace the visitor list entries with binding caches, the MH is renewing his home binding anyway) , the same processing is not applicable to regional registration (if my analysis is right). Am i missing something? regards, From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 13:59:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14317 for ; Tue, 9 Apr 2002 13:59:05 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23754; Tue, 9 Apr 2002 11:58:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16002; Tue, 9 Apr 2002 10:58:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HvXIA004088 for ; Tue, 9 Apr 2002 10:57:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39HvXB3004087 for mobile-ip-dist; Tue, 9 Apr 2002 10:57:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39HvUIA004080 for ; Tue, 9 Apr 2002 10:57:30 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13805 for ; Tue, 9 Apr 2002 10:57:32 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22850 for ; Tue, 9 Apr 2002 11:57:31 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4A9AB6A901 for ; Tue, 9 Apr 2002 20:57:25 +0300 (EEST) Message-ID: <3CB31DDF.9090902@piuha.net> Date: Tue, 09 Apr 2002 19:59:11 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <3CB3109A.1070002@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Background: Binding acks and requests could be spoofed, potentially leading the MN to lose understanding of what the status of its BCE on the CN is or to create unnecessary bindings. On the other hand, not very powerful mechanisms are available to authenticate the CN. Current RR does not authenticate CN at all; the BAs could come from anywhere in the Internet. Also, there are other attacks against RO that we can't protect against and that cause correct but useless bindings. Question: Should we have some protection for BAs and BRs? Are there any situations any more where a BR is required without a BCE being established earlier? Proposal: A simple cookie scheme allows us to verify that the replies come from the path towards the CN. This appears to close some potential attacks at very little cost; CNs don't become more stateful and no additional messages are needed. Text: Updated RR description below. The RR signaling happens as follows: 1a. MN(HoA) -> CN: HoTI(HoA, C0) 1b. MN(CoA) -> CN: CoTI(CoA, C1) 2a. CN -> MN(HoA): HoT(C0, K0, j) 2b. CN -> MN(CoA): CoT(C1, K1, i) 3. MN(CoA) -> CN: BU(HoA, CoA, C2, MAC, j, i) 4. CN -> MN(CoA): BA(MAC) 5. CN -> MN(HoA): BR(MAC) Here the notation Node1 -> Node2: Message(Par1, ...) denotes Node1 sending a message Message to Node2. The message has parameters Par1, ... An address following the node name Node1(Address) implies that the given address of the node is used. A home address implies the message is routed through the home agent and a care-of address implies the message is routed directly. Messages 1a and 1b are sent simultaneously, as are messages 2a and 2b. Message 3 actually creates a binding, and message 4 is optional. Message 5 is also optional and is sent later when the binding is about to expire. Due to the simultaneous sending of messages, the Return Routability procedure completes in 1.5 roundtrips excluding the acknowledgement message. The messages are described in more detail below: 1a. HoTI (Home Test Init) Message: When a mobile nodes wants to perform route optimization it sends a HoTI message to the correspondent node in order to initiate the return routability verification for the Home Address. MN(HoA) -> CN: HoA, C0 This message tells the mobile node's home address to the correspondent node. The mobile node also sends along cookie C0 that the correspondent node must return later, along with its own cookie that it generates based on the home address. The HoTI message is reverse tunneled through the Home Agent. 1b. CoTI (Care-of Test Init) Message: When a mobile nodes wants to perform route optimization it sends a CoTI message to the correspondent node in order to initiate the return routability verification for the care-of Address. MN(CoA) -> CN: CoA, C1 The second message is sent in parallel with the first one. It tells the correspondent node the mobile node's care-of address. The mobile node also sends along cookie C1 that the correspondent node must return later, along with its own cookie that it generates based on the care-of address. The CoTI message is sent directly to the correspondent node. 2a. HoT (Home Test) Message: This message is sent in response to a HoTI message. CN -> MN(HoA): C0, K0, j When the correspondent node receives the HoTI message, it generates a cookie K0 as follows: K0 = MAC_Kcn(HoA | Nj) The cookie and the value j are sent to the mobile node via the Home Agent; it is an assumption of the protocol that the home agent - mobile node route is secure. K0 also acts as a challenge to test that the mobile can receive messages sent to its home address. Kcn is used in the production of K0 in order to allow the correspondent node to verify that the cookies used later really came from itself, without forcing the correspondent node to remember a list of all cookies it has handed out. Cookie C0 from the mobile node is returned as well in the HoT message, to ensure that the message comes from someone on the path towards the correspondent node. The index j is carried along in the protocol to allow the CN to later efficiently find the nonce value Nj that it used in creating this cookie. The notation used here is as follows. MAC\_K(m) denotes a message authentication code computed on message m with key K. H(m) denotes a hash of message m. HMAC SHA1 function~\cite{rfc2104}\cite{fips1801} is used to compute the message authentication code, and SHA1 function~\cite{fips1801} is used to compute the hash. The final ``0'' inside the MAC function is a 32-bit integer used to distinguish home and care-of cookies from each other. 2b. CoT (Care-of Test) Message: This message is sent in response to a CoTI message. CN -> MN(CoA): C1, K1, i The correspondent also sends a challenge to the mobile's care-of address. When the correspondent node receives the CoTI message, it generates a cookie K1 as follows: K1 = MAC_Kcn(CoA | Ni) The cookie and the value i are sent directly to the mobile node. The final 1 inside the MAC function is a 32-bit integer, again used for distinguishing home and care-of cookies from each other. Cookie C1 from the mobile node is returned as well, to ensure that the message comes from someone on the path towards the correspondent node. Again, an index is sent along the cookie in order to identify the used nonce Ni. Note that i and j are likely to be the same in HoT and CoT messages, except when nonce values happen to have changed between the reception of HoT and the CoT messages. 3. BU (Binding Update) Message: When the MN has received both the HoT and CoT it has the cookies necessary to send the Binding Update. MN(CoA) -> CN: HoA, CoA, C2, MAC_Kbu(BU | HoA | CoA | C2), j, i, ... The mobile node hashes together the challenges to form a session key (Kbu), and then uses this session key to authenticate a binding update. Kbu = H(K0 | K1) The message contains j and i, so that the correspondent knows which value of Nj and Ni to use to recompute the session key. "BU" is the content of the Binding Update message, excluding (1) the IP header, (2) any extension headers between the IP header the Mobility Header, and (3) the Authenticator field inside the Binding Update. The result of the MAC_Kbu function is used as the Authenticator field in the Binding Update. The three dots represent all the remaining (not security related) information in the message. A cookie C2 is sent along to ensure that the acknowledgement sent later will come from someone on the path towards the correspondent node. Once the correspondent node has verified the MAC, it can create a binding cache entry for the mobile. 4. BA (Binding Acknowledgement) Message: The Binding Update is optionally acknowledged by the correspondent node. CN -> MN(CoA): MAC_Kbu(BA | HoA | CoA | C2), ... The correspondent node uses the same key (Kbu) to authenticate a binding acknowledgement. "BA" is the content of the Binding Acknowledgement message, excluding (1) the IP header, (2) any extension headers between the IP header the Mobility Header, and (3) the Authenticator field inside the Binding Acknowledgement. The result of the MAC_Kbu function is used as the Authenticator field in the Binding Acknowledgement. The three dots represent all the remaining (not security related) information in the message. 5. BR (Binding Request) Message: The correspondent node can optionally request a binding to be refreshed using the Binding Request message. This message can be authenticated using C2 from the Binding Update, and the Kbu that was created earlier. CN -> MN(HoA): MAC_Kbu(BR | HoA | C2), ... "BR" is the content of the Binding Request message, excluding (1) the IP header, (2) any extension headers between the IP header the Mobility Header, and (3) the Authenticator field inside the Binding Request. The result of the MAC_Kbu function is used as the Authenticator field in the Binding Request. The three dots represent all the remaining (not security related) information in the message. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 14:37:55 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16109 for ; Tue, 9 Apr 2002 14:37:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17151; Tue, 9 Apr 2002 11:37:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24990; Tue, 9 Apr 2002 11:37:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39IaVIA004251 for ; Tue, 9 Apr 2002 11:36:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39IaVu5004250 for mobile-ip-dist; Tue, 9 Apr 2002 11:36:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39IaSIA004243 for ; Tue, 9 Apr 2002 11:36:28 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g39IaU35614834; Tue, 9 Apr 2002 11:36:30 -0700 (PDT) Message-Id: <200204091836.g39IaU35614834@jurassic.eng.sun.com> Date: Tue, 9 Apr 2002 11:38:47 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: [mobile-ip] Issue with IPdst in FA reply when MN home address is 0.0.0.0 To: mobile-ip@sunroof.eng.sun.com, Steven.Glass@Sun.COM Cc: charliep@iprg.nokia.com, samita@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7k2Nvh8r07297u/WX/zI9g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Anyway, I'd like to see this changed so that the FA *always* sends > registration replies to 255.255.255.255 in response to registration requests > with IPsrc = 0.0.0.0. > > Does anyone else have any thoughts? > > Cheers, > Steve > > > There was a mailing list discussion before SLC meeting regarding the topic when source address of the registration request is zero. As per that discussion, the question was whether the src addr of a MN MUST be 0.0.0.0 when it does not have a home-addr. Many discussion participants thought that there was no need that MN must use 0.0.0.0 source address. So the request was to change MUST to MAY or SHOULD. (note: MN may use any temporary address while asking for it's home address via NAI). section 3.6.1.1 in RFC3220 states: 3.6.1.1. IP Fields This section provides the specific rules by which mobile nodes pick values for the IP header fields of a Registration Request. IP Source Address: - When registering on a foreign network with a co-located care-of address, the IP source address MUST be the care-of address. - Otherwise, if the mobile node does not have a home address, the IP source address MUST be 0.0.0.0. - In all other circumstances, the IP source address MUST be the mobile node's home address. My question is if we mostly agree on the 'MUST' part of the second bullet item ? Does it make sense to change it to MAY or SHOULD ? Next, as it was already brought up that section 3.7.2.3 needs clarification. There is actually a conflict between section section 3.4 destination address of IP header of RegReply field and dst addr described in section 3.7.2.3. Section 3.4 states: Destination Address Copied from the source address of the Registration Request to which the agent is replying Section 3.7.2.3 says: IP Destination Address If the Registration Reply is generated by the Foreign Agent in order to reject a mobile node's Registration Request, and the Registration Request contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Request. Otherwise, if the Registration Reply is received from the Home Agent, and contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Reply. Otherwise, the IP Destination Address of the Registration Reply is set to be 255.255.255.255. Again, 3.7.3.2. Forwarding Replies to the Mobile Node Specific fields within the IP header and the UDP header of the relayed Registration Reply are set according to the same rules specified in Section 3.7.2.3. So, I think, this gives an impression that the destination address of the RegReply to MN should always be set to the homeaddr field copied from the RegReply from HA. Note, that section 3.4 states the destination addr of IP header correctly. The destination addr of RegReply to MN should be set to the source address of the registration request (when source-addr of the reg-req is non-zero). Otherwise, an implementation may need to hack IP layer unncessarily to receive reply packets to a home-addr even though it's interface is not configured for it. The current description in 3.7.2.3 will also pose problem for MN when it has to register through FA due to 'R' bit advertisement, i,e. source addr of MN (section 3.6.1.1): - When registering on a foreign network with a co-located care-of address, the IP source address MUST be the care-of address. Would the following text for section 3.7.2.3 fix the inconsitencies ? IP Destination Address If the Registration Reply is generated by the Foreign Agent in order to reject a mobile node's Registration Request, and the Registration Request contains a source Address which is not 0.0.0.0, then the IP Destination Address is copied from the IP source address field of the Registration Request. If the Registration Reply is received from the Home Agent, and the corresponding Registration Request contains a non-zero source address, then theIP Destination Address is copied from the source address field of the Registration Request. Otherwise, when the source address of the Registration request is 0.0.0.0 the IP Destination Address of the Registration Reply is set to be 255.255.255.255. The above text should cover the following scenarios: 1. When MN has home-addr as it's configured IP-addr 2. When MN has Co-located care-of-addr. 3. When MN has configured with home-addr, but the HA replied with a home-addr which is not equal to the currently configured one. 4. When MN does not have any IP address configured and uses 0.0.0.0 as it's source address of the registration request. 5. When MN does not have a home-addr, but acquires a temporary address in the local network and requests a homeaddr from homeagent (If we allow this case, actually this case is useful to prevent broadcast regReply, even though the L2addr could be the unicast one, but don't know if there is any security threat behind this). -Samita From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 15:14:00 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17565 for ; Tue, 9 Apr 2002 15:14:00 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25092; Tue, 9 Apr 2002 12:13:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08899; Tue, 9 Apr 2002 12:13:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JCOIA004447 for ; Tue, 9 Apr 2002 12:12:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39JCOAT004446 for mobile-ip-dist; Tue, 9 Apr 2002 12:12:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JCLIA004438 for ; Tue, 9 Apr 2002 12:12:21 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25312 for ; Tue, 9 Apr 2002 12:12:24 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06264 for ; Tue, 9 Apr 2002 13:12:23 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A05AC6A905 for ; Tue, 9 Apr 2002 22:12:17 +0300 (EEST) Message-ID: <3CB32F6B.8080806@piuha.net> Date: Tue, 09 Apr 2002 21:14:03 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #5: Alternate CoA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think this too has consensus, but here it is just in case: Background: Bombing vulnerabilities may open if Alternate CoA parameter can be used with address CoA2 and the RR authorization was performed on CoA1. Question: Should this vulnerability be closed? If it is closed by requiring the RR and Alternative CoA parameter to use the same CoA, will the remaining Alternative CoA be useful for FMIP, HMIP, and other MIPv6 extensions that may use it. Proposal: The vulnerability must be closed. It seems that the remaining Alternative CoA functionality is still useful. Further work is of course needed to ensure that MIPv6 extensions don't open new security vulnerabilities. Text: State the following under 5.1.7: The care-of address for the binding given in the Binding Update message is normally that which was received as the value in the Source Address field in the IPv6 header of the packet carrying the Binding Update message. However, a care-of address different from the Source Address MAY be specified by including an Alternate Care-of Address option in the Binding Update message. When such message is sent to the correspondent node, the Care-of Test Init and Care-of Test messages MUST have been performed for the address in the Alternate Care-of Address option (not the Source Address). The contents of the Nonce Indices and the Authenticator options MUST be based on information gained in this test. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 15:15:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17692 for ; Tue, 9 Apr 2002 15:15:12 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08007; Tue, 9 Apr 2002 13:15:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09321; Tue, 9 Apr 2002 12:14:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JE6IA004471 for ; Tue, 9 Apr 2002 12:14:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39JE6kU004470 for mobile-ip-dist; Tue, 9 Apr 2002 12:14:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JE2IA004463 for ; Tue, 9 Apr 2002 12:14:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05391 for ; Tue, 9 Apr 2002 12:14:05 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12872 for ; Tue, 9 Apr 2002 13:14:04 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A12066A901 for ; Tue, 9 Apr 2002 22:13:57 +0300 (EEST) Message-ID: <3CB32FCF.3070908@piuha.net> Date: Tue, 09 Apr 2002 21:15:43 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #6: Reuse of nonces Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Again an item which has consensus, but now there's some proposed text to go with it: Background: The RR method makes a routing test and expects the resulting authorization to apply for a certain amount of time. It has been asked whether a fast moving mobile node needs to apply all tests on all movements or not, and whether the results of [HC]oT{,I} could be reused. On the other hand we want to ensure that the correspondent nodes don't have to be stateful, so creating SAs based on [HC]oTI messages would be inappropriate? Also, deletion of BCEs at the CN side may in some implementations require that nonces used to create them be invalidated at the same time, so short-lived BCEs may cause it to be impossible to reuse a particular nonce. Question: Is the reuse functionality useful? How to provide it? Proposal: Require that CNs should (if possible) keep nonces 'alive' for a certain amount of time. During this time, the MN can reuse either HoA or CoA cookies as appropriate. This can be useful for fast movement (HoA cookie reuse) or multihomed host movement to a single interface (CoA cookie reuse). Text: Under 4.5.5: Before sending a Binding Update in Step 3, the mobile node has to wait for both the Home and Care-of Cookies to arrive. Due to resource limitations, rapid deletion of bindings, or reboots it can not be guaranteed that the cookies are still fresh and acceptable when the correspondent node uses them in the processing of the Binding Update. If the cookies have become too old, the correspondent replies with an an error code in the Binding Acknowledgement. The mobile node can then retry the Return Routability procedure. However, it is recommended that correspondent nodes try to keep these cookies acceptable at least MIN_COOKIE_LIFE seconds and SHOULD NOT allow them to be accepted beyond MAX_COOKIE_LIFE seconds. Given that the cookies are normally expected to be fresh for at least MIN_COOKIE_LIFE seconds, the mobile node MAY use them beyond a single run of the Return Routability procedure. A fast moving mobile node may reuse a recent Home Cookie from a correspondent node when moving to a new location, and just acquire a new Care-of Cookie to show routability in the new location. While this does not save roundtrips due to the parallel nature of the home and care-of return routability tests, the roundtrip through the home agent may be longer, and consequently this optimization is often useful. A mobile node that has multiple home addresses, may also use the same Care-of Cookie for Binding Updates concerning all of these addresses. And then under 8.4: In order to prevent replayed binding updates after a binding cache entry has been deleted the CN needs to make sure that the nonce indicies used to create the binding are no longer valid. This applies whether the binding is deleted due to it timing out (lifetime expiry) or being deleted explicitly by the MN. If a binding cache entry is logically deleted and either the home nonce index or the care-of nonce index used to create (or last update) the binding are still valid, the CN must behave as if it retains the state about the binding (including the sequence number) until at least one of the cookies has become too old. A possible way to implement this is to mark the binding cache entry so that it does not effect sending and receiving of packets, but so that it is found when a binding update is received. Another way is to mark the used nonces immediately too old. However, this method may cause some unnecessary failures and retries with ongoing Return Routability procedures with other mobile nodes. Furthermore, unless the mobile node has requested a Binding Acknowledgement, it is possible that this method may even cause an error in the RR procedure to go unnoticed, and data packets to be dropped through the use of the Home Address Option without an existing binding. The effect is similar to packet loss during the RR procedure, but may in certain circumstances significantly increase the problems. And finally under 11: MAX_COOKIE_LIFE 180 seconds MIN_COOKIE_LIFE 60 seconds MAX_RR_BINDING_LIFE 300 seconds ------------ Issue list at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 15:38:25 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18626 for ; Tue, 9 Apr 2002 15:38:25 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03393; Tue, 9 Apr 2002 13:38:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16090; Tue, 9 Apr 2002 12:37:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JXMIA004685 for ; Tue, 9 Apr 2002 12:33:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39JXMdh004684 for mobile-ip-dist; Tue, 9 Apr 2002 12:33:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JXJIA004677 for ; Tue, 9 Apr 2002 12:33:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02802 for ; Tue, 9 Apr 2002 12:33:23 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00810 for ; Tue, 9 Apr 2002 13:33:22 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 60CFD6A901 for ; Tue, 9 Apr 2002 22:33:21 +0300 (EEST) Message-ID: <3CB3345B.8020506@piuha.net> Date: Tue, 09 Apr 2002 21:35:07 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #13: SPI field References: <3CB32FCF.3070908@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Background: Draft 16 has an SPI field in the Authentication Data parameter. This field has existed in the draft since draft 14. However, in draft 16 it must be set to zero and the message is dropped if on receipt it contains something else. Even the potential semantics of the field are somewhat unclear. Is it going to be an algorithm identifier, or an IPsec-like dynamic entity? On the other hand, there is a need to signal other potential security schemes beyond RR in BUs, and how can we do this? Question: Should the SPI field be kept? Proposal: This SPI field doesn't seem very useful, remove it. For ability to provide other security mechanisms, the following building blocks can be used: - Flags in the RR or BU messages - New parameters in the RR or BU messages ------------ Issue list at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 15:55:20 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19388 for ; Tue, 9 Apr 2002 15:55:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27103; Tue, 9 Apr 2002 13:55:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10845; Tue, 9 Apr 2002 12:54:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JrGIA004817 for ; Tue, 9 Apr 2002 12:53:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39JrG3n004816 for mobile-ip-dist; Tue, 9 Apr 2002 12:53:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JrDIA004809 for ; Tue, 9 Apr 2002 12:53:13 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10259 for ; Tue, 9 Apr 2002 12:53:16 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26096 for ; Tue, 9 Apr 2002 13:53:15 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39JrB419965; Tue, 9 Apr 2002 14:53:11 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXVLQHD>; Tue, 9 Apr 2002 14:53:13 -0500 Message-ID: From: "Mohamed Khalil" To: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #13: SPI field Date: Tue, 9 Apr 2002 14:53:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E000.29C1E7C0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E000.29C1E7C0 Content-Type: text/plain; charset="iso-8859-1" Hi Jari, -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Tuesday, April 09, 2002 1:35 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] Unresolved issue #13: SPI field Background: Draft 16 has an SPI field in the Authentication Data parameter. This field has existed in the draft since draft 14. However, in draft 16 it must be set to zero and the message is dropped if on receipt it contains something else. Even the potential semantics of the field are somewhat unclear. Is it going to be an algorithm identifier, or an IPsec-like dynamic entity? On the other hand, there is a need to signal other potential security schemes beyond RR in BUs, and how can we do this? Question: Should the SPI field be kept? MK> I think it is useful to leave it for future security proposals. Also, I think we should remove the sentence "The Authentication Data parameter is valid only in the Binding Request, Binding Update, and Binding Acknowledgment messages." because this authentication data parameters might be used to authenticate some other future messages proposed by other drafts. Proposal: This SPI field doesn't seem very useful, remove it. For ability to provide other security mechanisms, the following building blocks can be used: - Flags in the RR or BU messages - New parameters in the RR or BU messages ------------ Issue list at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html ------_=_NextPart_001_01C1E000.29C1E7C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Unresolved issue #13: SPI field

Hi Jari,

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Tuesday, April 09, 2002 1:35 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: [mobile-ip] Unresolved issue #13: SPI = field


Background: Draft 16 has an SPI field in the = Authentication Data
parameter. This field has existed in the draft since = draft 14.
However, in draft 16 it must be set to zero and the = message is dropped
if on receipt it contains something else. Even the = potential semantics
of the field are somewhat unclear. Is it going to be = an algorithm
identifier, or an IPsec-like dynamic entity? On the = other hand, there
is a need to signal other potential security schemes = beyond RR in BUs,
and how can we do this?

Question: Should the SPI field be kept?

MK> I think it is useful to leave it for future = security proposals. Also, I think we should remove the sentence
"The Authentication Data parameter is valid = only in the Binding
   Request, Binding Update, and Binding = Acknowledgment messages."

because this authentication data parameters might be = used to authenticate some other future messages proposed by other = drafts.

Proposal: This SPI field doesn't seem very useful, = remove
it. For ability to provide other security = mechanisms, the
following building blocks can be used:
- Flags in the RR or BU messages
- New parameters in the RR or BU messages

------------
Issue list at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-= Issues.html


------_=_NextPart_001_01C1E000.29C1E7C0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 15:57:32 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19475 for ; Tue, 9 Apr 2002 15:57:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28528; Tue, 9 Apr 2002 13:57:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11875; Tue, 9 Apr 2002 12:57:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JuLIA004890 for ; Tue, 9 Apr 2002 12:56:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39JuKJT004889 for mobile-ip-dist; Tue, 9 Apr 2002 12:56:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39JuHIA004882 for ; Tue, 9 Apr 2002 12:56:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11601 for ; Tue, 9 Apr 2002 12:56:21 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00080 for ; Tue, 9 Apr 2002 13:56:20 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g39JuHON013737; Tue, 9 Apr 2002 12:56:17 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABK38626; Tue, 9 Apr 2002 12:53:30 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA16020; Tue, 9 Apr 2002 12:56:17 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15539.18273.63950.211462@thomasm-u1.cisco.com> Date: Tue, 9 Apr 2002 12:56:17 -0700 (PDT) To: jari.arkko@piuha.net Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #13: SPI field In-Reply-To: <3CB3345B.8020506@piuha.net> References: <3CB32FCF.3070908@piuha.net> <3CB3345B.8020506@piuha.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko writes: > Proposal: This SPI field doesn't seem very useful, remove > it. Agree. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 16:10:01 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20316 for ; Tue, 9 Apr 2002 16:10:01 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04940; Tue, 9 Apr 2002 14:09:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16969; Tue, 9 Apr 2002 13:09:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39K8rIA005127 for ; Tue, 9 Apr 2002 13:08:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39K8rlk005126 for mobile-ip-dist; Tue, 9 Apr 2002 13:08:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39K8oIA005119 for ; Tue, 9 Apr 2002 13:08:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24301 for ; Tue, 9 Apr 2002 13:08:53 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09809 for ; Tue, 9 Apr 2002 14:08:52 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g39K8qq6008184 for ; Tue, 9 Apr 2002 13:08:52 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-141.cisco.com [128.107.163.141]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACN54877; Tue, 9 Apr 2002 13:08:50 -0700 (PDT) Message-ID: <3CB34A52.75717476@cisco.com> Date: Tue, 09 Apr 2002 13:08:50 -0700 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue with IPdst in FA reply when MN home address is 0.0.0.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Steven M. Glass" wrote: > This is my concern (that and I like to see things more consistent across > related cases, and for easier implementation reasons). I do NOT want to see a > bit in the registration request to indicate "please broadcast my registration > reply with an address assignment back to me". Right. > My guess is the reason secion > 3.7.2.3 is worded the way it is may have something to do with the misnomer > that broadcast@L3 means you broadcast@L2. You can broadcast@L3 with a unicast > L2 (and thereby also not force your MN to support pomiscuity at L3). One key > reason to not broadcast L2 is that it wakes sleeping clients (not nice if your > battery powered, smart radio management issues aside). > Right. > > Anyway, I'd like to see this changed so that the FA *always* sends > registration replies to 255.255.255.255 in response to registration requests > with IPsrc = 0.0.0.0. > > Does anyone else have any thoughts? > I agree. :) Kent From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 16:14:54 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20605 for ; Tue, 9 Apr 2002 16:14:54 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10030; Tue, 9 Apr 2002 14:14:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18706; Tue, 9 Apr 2002 13:14:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KD7IA005225 for ; Tue, 9 Apr 2002 13:13:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39KD7Tg005224 for mobile-ip-dist; Tue, 9 Apr 2002 13:13:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KD4IA005217 for ; Tue, 9 Apr 2002 13:13:04 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25464 for ; Tue, 9 Apr 2002 13:13:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00144 for ; Tue, 9 Apr 2002 13:13:07 -0700 (PDT) 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 NAA09604; Tue, 9 Apr 2002 13:13:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39KD6E19226; Tue, 9 Apr 2002 13:13:06 -0700 X-mProtect: <200204092013> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKMndJY; Tue, 09 Apr 2002 13:13:04 PDT Message-ID: <3CB34B51.81741EBA@iprg.nokia.com> Date: Tue, 09 Apr 2002 13:13:05 -0700 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: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #2: replay protection and nvm usage References: <3CB3109A.1070002@piuha.net> <3CB314DC.6090300@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The proposal looks good. AGREE Vijay Jari Arkko wrote: > > There seems to be consensus about this but I'll send an > issue item about this just to document what's going on. > > Background: Draft 16 included a requirement that HAs must > keep BU sequence numbers in non-volatile storage to prevent > replays. Folks on the list questioned this in two ways: First, > draft 15 already had a resynchronization procedure (which didn't > provide replay protection but allowed loss of state). Second, > building a replay protection scheme to manually keyed IPsec > was seen as a bad alternative to using a key management protocol > or building better replay protection to manually keyed IPsec. > Note also that MIPv6 must provide ordering support since IPsec > replay protection doesn't guarantee ordering, just prevents > replays. Therefore, the Sequence# field is needed in the BUs > in any case. > > Question: Pick one for replay protection: > 1. Require IPsec + IKE. No replay problem. > 2. Require at least IPsec, but keep IKE as optional. Don't add > any features for replay protection. Folks who don't use IKE > will suffer from the replay vulnerability. > 3. Require at least IPsec, optional IKE but add an application > layer feature for replay protection to prevent replays if > you happened to not have IKE. This was the draft 16 approach. > 4. Require at least IPSec and a TBD light weight key management > scheme, perhaps optional IKE in some cases. No application > layer features. Replay protection works perfectly for everyone. > > Proposal: Solution 2, but described in a way that makes it > clear to implementers that replay attacks become possible only > if manual keying is used and state loss can happen. Don't state > any specific key management mechanism. > > Text. Text in 4.5.4: > IPsec can provide replay protection only when dynamic > security association establishment is used. This may not always be > possible, and manual keying would be preferred in some cases. IPsec > also does not guarantee correct ordering of packets, only that they > have not been replayed. Because of this, Mobile IPv6 provides its own > mechanism inside the Binding Update and Acknowledgement messages. A > sequence number field is used to ensure correct ordering. If the > mobile node reboots and forgets its current sequence number, the home > agent uses the status value 141 (Sequence number out of window, see > Section X.X) to inform the mobile node of the use of an > improper sequence number. > > Note that the the sequence number mechanism provides also a weak form > of replay protection. However, if a home agent reboots and loses its > state regarding the sequence numbers, replay attacks become possible. > If the home agent is vulnerable to this, the use of a key management > mechanism together with IPsec can be used to prevent replay attacks. > > A sliding window scheme is used for the sequence numbers. Therefore > the protection against replays and reordering attacks without a key > management mechanism works when the attacker remembers up to a maximum > of 2**15 Binding Updates. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 16:18:20 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20742 for ; Tue, 9 Apr 2002 16:18:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08499; Tue, 9 Apr 2002 13:17:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20242; Tue, 9 Apr 2002 13:17:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KHBIA005344 for ; Tue, 9 Apr 2002 13:17:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39KHBnL005343 for mobile-ip-dist; Tue, 9 Apr 2002 13:17:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KH7IA005333 for ; Tue, 9 Apr 2002 13:17:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06557 for ; Tue, 9 Apr 2002 13:17:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16111 for ; Tue, 9 Apr 2002 13:17:11 -0700 (PDT) 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 NAA09918; Tue, 9 Apr 2002 13:17:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39KHAH24550; Tue, 9 Apr 2002 13:17:10 -0700 X-mProtect: <200204092017> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkXD7yj; Tue, 09 Apr 2002 13:17:08 PDT Message-ID: <3CB34C45.8DC78F26@iprg.nokia.com> Date: Tue, 09 Apr 2002 13:17:09 -0700 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: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field References: <3CB32FCF.3070908@piuha.net> <3CB3345B.8020506@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Please leave it in there. Vijay Jari Arkko wrote: > > Background: Draft 16 has an SPI field in the Authentication Data > parameter. This field has existed in the draft since draft 14. > However, in draft 16 it must be set to zero and the message is dropped > if on receipt it contains something else. Even the potential semantics > of the field are somewhat unclear. Is it going to be an algorithm > identifier, or an IPsec-like dynamic entity? On the other hand, there > is a need to signal other potential security schemes beyond RR in BUs, > and how can we do this? > > Question: Should the SPI field be kept? > > Proposal: This SPI field doesn't seem very useful, remove > it. For ability to provide other security mechanisms, the > following building blocks can be used: > - Flags in the RR or BU messages > - New parameters in the RR or BU messages > > ------------ > Issue list at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 16:25:11 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21129 for ; Tue, 9 Apr 2002 16:25:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15552; Tue, 9 Apr 2002 14:24:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22966; Tue, 9 Apr 2002 13:24:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KNtIA005507 for ; Tue, 9 Apr 2002 13:23:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39KNtr7005506 for mobile-ip-dist; Tue, 9 Apr 2002 13:23:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KNqIA005499 for ; Tue, 9 Apr 2002 13:23:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22683 for ; Tue, 9 Apr 2002 13:23:56 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28336 for ; Tue, 9 Apr 2002 14:23:56 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 9 Apr 2002 13:23:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E004.7864012E" Subject: RE: [mobile-ip] Unresolved issue #13: SPI field Date: Tue, 9 Apr 2002 13:23:54 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E634AA8@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Unresolved issue #13: SPI field Thread-Index: AcHf/mPnOigk5DPATW+4rUPoaPRKngABeswg From: "Mohan Parthasarathy" To: , X-OriginalArrivalTime: 09 Apr 2002 20:23:55.0131 (UTC) FILETIME=[789FBCB0:01C1E004] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C1E004.7864012E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please remove it. -mohan > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Tuesday, April 09, 2002 11:35 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] Unresolved issue #13: SPI field >=20 >=20 > Background: Draft 16 has an SPI field in the Authentication=20 > Data parameter. This field has existed in the draft since=20 > draft 14. However, in draft 16 it must be set to zero and the=20 > message is dropped if on receipt it contains something else.=20 > Even the potential semantics of the field are somewhat=20 > unclear. Is it going to be an algorithm identifier, or an=20 > IPsec-like dynamic entity? On the other hand, there is a need=20 > to signal other potential security schemes beyond RR in BUs,=20 > and how can we do this? >=20 > Question: Should the SPI field be kept? >=20 > Proposal: This SPI field doesn't seem very useful, remove > it. For ability to provide other security mechanisms, the=20 > following building blocks can be used: > - Flags in the RR or BU messages > - New parameters in the RR or BU messages >=20 > ------------ > Issue list at=20 > http://www.piuha.net/> ~jarkko/publications/mipv6/MIPv6-Issues.html >=20 >=20 >=20 ------_=_NextPart_001_01C1E004.7864012E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Unresolved issue #13: SPI field

Please remove it.

-mohan


> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] =
> Sent: Tuesday, April 09, 2002 11:35 AM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: [mobile-ip] Unresolved issue #13: SPI = field
>
>
> Background: Draft 16 has an SPI field in the = Authentication
> Data parameter. This field has existed in the = draft since
> draft 14. However, in draft 16 it must be set to = zero and the
> message is dropped if on receipt it contains = something else.
> Even the potential semantics of the field are = somewhat
> unclear. Is it going to be an algorithm = identifier, or an
> IPsec-like dynamic entity? On the other hand, = there is a need
> to signal other potential security schemes = beyond RR in BUs,
> and how can we do this?
>
> Question: Should the SPI field be kept?
>
> Proposal: This SPI field doesn't seem very = useful, remove
> it. For ability to provide other security = mechanisms, the
> following building blocks can be used:
> - Flags in the RR or BU messages
> - New parameters in the RR or BU messages
>
> ------------
> Issue list at
> http://www.piuha.net/> = ~jarkko/publications/mipv6/MIPv6-Issues.html
>
>
>

------_=_NextPart_001_01C1E004.7864012E-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 16:35:44 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21720 for ; Tue, 9 Apr 2002 16:35:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18334; Tue, 9 Apr 2002 14:35:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27334; Tue, 9 Apr 2002 13:35:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KY3IA005672 for ; Tue, 9 Apr 2002 13:34:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39KY3lq005671 for mobile-ip-dist; Tue, 9 Apr 2002 13:34:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KY0IA005664 for ; Tue, 9 Apr 2002 13:34:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26789 for ; Tue, 9 Apr 2002 13:34:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22539 for ; Tue, 9 Apr 2002 14:33:59 -0600 (MDT) 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 NAA10797; Tue, 9 Apr 2002 13:33:49 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39KXnB12595; Tue, 9 Apr 2002 13:33:49 -0700 X-mProtect: <200204092033> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0lCXWA; Tue, 09 Apr 2002 13:33:47 PDT Message-ID: <3CB3502B.DE671F63@iprg.nokia.com> Date: Tue, 09 Apr 2002 13:33:47 -0700 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: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #6: Reuse of nonces References: <3CB32FCF.3070908@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Agree with most of the text, except for section 11. The actual window of vulnerability is only MAX_RR_BINDING_LIFE (300 seconds). The MAX_COOKIE_LIFE does not add anything to the window of vulnerability. So why not make the MAX_COOKIE_LIFE also 300 seconds. lets assume an MN has initiated an RR test. An on-path attacker (CN-HA path) could get hold of K0. For him to launch to attack, he must generate a new K1 with his CoA and send a BU as soon as the CN has sent a BAck to the actual MN. If he does not do it immediately, the packets from the CN will keep going to the right MN. No harm done, till the attacker tries to use K0. And when the attacker does this, he is able to hijack connection for MAX_RR_BINDING_LIFE. Whatever the case, the MN would be vulnerable only for MAX_RR_BINDING_LIFE. So I suggest MAX_COOKIE_LIFE 300 seconds MIN_COOKIE_LIFE 60 seconds MAX_RR_BINDING_LIFE 300 seconds Vijay Jari Arkko wrote: > > Again an item which has consensus, but now there's some proposed > text to go with it: > > Background: The RR method makes a routing test and expects the > resulting authorization to apply for a certain amount of time. It has > been asked whether a fast moving mobile node needs to apply all tests > on all movements or not, and whether the results of [HC]oT{,I} could > be reused. On the other hand we want to ensure that the correspondent > nodes don't have to be stateful, so creating SAs based on [HC]oTI > messages would be inappropriate? Also, deletion of BCEs at the CN > side may in some implementations require that nonces used to create > them be invalidated at the same time, so short-lived BCEs may cause > it to be impossible to reuse a particular nonce. > > Question: Is the reuse functionality useful? How to provide it? > > Proposal: Require that CNs should (if possible) keep nonces 'alive' > for a certain amount of time. During this time, the MN can reuse > either HoA or CoA cookies as appropriate. This can be useful for fast > movement (HoA cookie reuse) or multihomed host movement to a single > interface (CoA cookie reuse). > > Text: Under 4.5.5: > > Before sending a Binding Update in Step 3, the mobile node has to wait > for both the Home and Care-of Cookies to arrive. Due to resource > limitations, rapid deletion of bindings, or reboots it can not be > guaranteed that the cookies are still fresh and acceptable when the > correspondent node uses them in the processing of the Binding Update. > If the cookies have become too old, the correspondent replies with an > an error code in the Binding Acknowledgement. The mobile node can then > retry the Return Routability procedure. However, it is recommended > that correspondent nodes try to keep these cookies acceptable at least > MIN_COOKIE_LIFE seconds and SHOULD NOT allow them to be accepted > beyond MAX_COOKIE_LIFE seconds. > > Given that the cookies are normally expected to be fresh for at least > MIN_COOKIE_LIFE seconds, the mobile node MAY use them beyond a single > run of the Return Routability procedure. A fast moving mobile node may > reuse a recent Home Cookie from a correspondent node when moving to a > new location, and just acquire a new Care-of Cookie to show > routability in the new location. While this does not save roundtrips > due to the parallel nature of the home and care-of return routability > tests, the roundtrip through the home agent may be longer, and > consequently this optimization is often useful. A mobile node that has > multiple home addresses, may also use the same Care-of Cookie for > Binding Updates concerning all of these addresses. > > And then under 8.4: > > In order to prevent replayed binding updates after a binding cache > entry has been deleted the CN needs to make sure that the nonce > indicies used to create the binding are no longer valid. This > applies whether the binding is deleted due to it timing out > (lifetime expiry) or being deleted explicitly by the MN. > > If a binding cache entry is logically deleted and either the home > nonce index or the care-of nonce index used to create (or last > update) the binding are still valid, the CN must behave as if it > retains the state about the binding (including the sequence number) > until at least one of the cookies has become too old. > > A possible way to implement this is to mark the binding cache entry > so that it does not effect sending and receiving of packets, but so > that it is found when a binding update is received. Another way is > to mark the used nonces immediately too old. However, this method > may cause some unnecessary failures and retries with ongoing Return > Routability procedures with other mobile nodes. Furthermore, unless > the mobile node has requested a Binding Acknowledgement, it is > possible that this method may even cause an error in the RR > procedure to go unnoticed, and data packets to be dropped through > the use of the Home Address Option without an existing binding. The > effect is similar to packet loss during the RR procedure, but may > in certain circumstances significantly increase the problems. > > And finally under 11: > > MAX_COOKIE_LIFE 180 seconds > MIN_COOKIE_LIFE 60 seconds > MAX_RR_BINDING_LIFE 300 seconds > > ------------ > Issue list at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 16:42:32 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21819 for ; Tue, 9 Apr 2002 16:42:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13625; Tue, 9 Apr 2002 13:42:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00161; Tue, 9 Apr 2002 13:42:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KfZIA005812 for ; Tue, 9 Apr 2002 13:41:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39KfZFr005811 for mobile-ip-dist; Tue, 9 Apr 2002 13:41:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39KfWIA005804 for ; Tue, 9 Apr 2002 13:41:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15400 for ; Tue, 9 Apr 2002 13:41:32 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09905 for ; Tue, 9 Apr 2002 13:41:31 -0700 (PDT) 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 NAA11241; Tue, 9 Apr 2002 13:41:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39KfUs24737; Tue, 9 Apr 2002 13:41:30 -0700 X-mProtect: <200204092041> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZtfMh3; Tue, 09 Apr 2002 13:41:28 PDT Message-ID: <3CB351F9.C364A24A@iprg.nokia.com> Date: Tue, 09 Apr 2002 13:41:29 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field References: <3CB32FCF.3070908@piuha.net> <3CB3345B.8020506@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jari, The SPI field has to be available, to allow for selection of the appropriate Binding Security Association to be used for calculations involving the authentication data. I think the potential semantics of the field are pretty clear. No one has, to my knowledge, suggested that the field be used as an algorithm identifier. It has always been just an index (as the name suggests). Alternatively, the SPI could be a field in the Binding Update and the Binding Acknowledgement messages. Regards, Charlie P. Jari Arkko wrote: > > Background: Draft 16 has an SPI field in the Authentication Data > parameter. This field has existed in the draft since draft 14. > However, in draft 16 it must be set to zero and the message is dropped > if on receipt it contains something else. Even the potential semantics > of the field are somewhat unclear. Is it going to be an algorithm > identifier, or an IPsec-like dynamic entity? On the other hand, there > is a need to signal other potential security schemes beyond RR in BUs, > and how can we do this? > > Question: Should the SPI field be kept? > > Proposal: This SPI field doesn't seem very useful, remove > it. For ability to provide other security mechanisms, the > following building blocks can be used: > - Flags in the RR or BU messages > - New parameters in the RR or BU messages > > ------------ > Issue list at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 9 17:36:26 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23839 for ; Tue, 9 Apr 2002 17:36:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08479; Tue, 9 Apr 2002 15:36:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07707; Tue, 9 Apr 2002 14:36:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39LZFIA006081 for ; Tue, 9 Apr 2002 14:35:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g39LZEje006080 for mobile-ip-dist; Tue, 9 Apr 2002 14:35:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g39LZBIA006073 for ; Tue, 9 Apr 2002 14:35:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18935 for ; Tue, 9 Apr 2002 14:35:14 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07943 for ; Tue, 9 Apr 2002 15:35:13 -0600 (MDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g39LZ4I18960; Tue, 9 Apr 2002 14:35:04 -0700 (PDT) Message-ID: <029f01c1e00e$2fd7a470$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: <3CB32F6B.8080806@piuha.net> Subject: Re: [mobile-ip] Unresolved issue #5: Alternate CoA Date: Tue, 9 Apr 2002 14:33:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit One minor nit: The current text leaves no space for alternative security mechanisms. Is this the intent, that is, would CoTI and CoT need to be done if a CGA-like mechanism was in use? The reason I'm asking is because the major interest in an alternate security mechanism is for better performance, since some of the intended uses are performance sensitive. jak ----- Original Message ----- From: "Jari Arkko" To: Sent: Tuesday, April 09, 2002 11:14 AM Subject: [mobile-ip] Unresolved issue #5: Alternate CoA > I think this too has consensus, but here it is just in case: > > Background: Bombing vulnerabilities may open if Alternate CoA > parameter can be used with address CoA2 and the RR authorization > was performed on CoA1. > > Question: Should this vulnerability be closed? If it is closed > by requiring the RR and Alternative CoA parameter to use the > same CoA, will the remaining Alternative CoA be useful for FMIP, > HMIP, and other MIPv6 extensions that may use it. > > Proposal: The vulnerability must be closed. It seems that > the remaining Alternative CoA functionality is still useful. > Further work is of course needed to ensure that MIPv6 extensions > don't open new security vulnerabilities. > > Text: State the following under 5.1.7: > The care-of address for the binding given in the Binding Update > message is normally that which was received as the value in the Source > Address field in the IPv6 header of the packet carrying the Binding > Update message. However, a care-of address different from the Source > Address MAY be specified by including an Alternate Care-of Address > option in the Binding Update message. When such message is sent to > the correspondent node, the Care-of Test Init and Care-of Test > messages MUST have been performed for the address in the Alternate > Care-of Address option (not the Source Address). The contents of > the Nonce Indices and the Authenticator options MUST be based on > information gained in this test. > > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 02:13:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12209 for ; Wed, 10 Apr 2002 02:13:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11229; Wed, 10 Apr 2002 00:13:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12893; Tue, 9 Apr 2002 23:12:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A6C1IA007088 for ; Tue, 9 Apr 2002 23:12:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3A6C1L0007087 for mobile-ip-dist; Tue, 9 Apr 2002 23:12:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A6BvIA007080 for ; Tue, 9 Apr 2002 23:11:58 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA16314 for ; Tue, 9 Apr 2002 23:12:01 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13057 for ; Wed, 10 Apr 2002 00:12:01 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <2PLAZMN4>; Wed, 10 Apr 2002 02:12:00 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C37321@ftmail> From: "Alan O'Neill" To: "'eva.gustafsson@ericsson.com'" , "'annika.jonsson@ericsson.com'" , "'charliep@iprg.nokia.com'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] IPv4 regional registration Date: Wed, 10 Apr 2002 02:11:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Reg Tun Authors, My detailed review of MIP Reg Tunneling has only just been completed and I have included a couple of issues and suggestions in the following draft which was submitted today. Modifications to Regional Tunneling In summary, I would like to see the Home Registration made more generic and powerful so that it can deal with disparate addressing plans between FA-GFA, and GFA-HA, to support dynamic HA allocation, and to generalise the extension names. This is to ensure the Home Registration can be used to route through a broader range of topologies and hierarchical MIP elements both related and unrelated to the Regional Registration requirements. The Regional Registration to the GFA is then left as the GFA specific messaging, alongside the GFA requirements for the processing and forwarding of the Home Registration. I hope that these changes do not compromise any of your requirements nor adversely affect any commercial dependencies on the progression of the RegTun spec. Regards, Alan. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 04:01:13 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13343 for ; Wed, 10 Apr 2002 04:01:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18885; Wed, 10 Apr 2002 02:01:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06273; Wed, 10 Apr 2002 01:00:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A7xoIA007312 for ; Wed, 10 Apr 2002 00:59:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3A7xomd007311 for mobile-ip-dist; Wed, 10 Apr 2002 00:59:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A7xlIA007304 for ; Wed, 10 Apr 2002 00:59:47 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23704 for ; Wed, 10 Apr 2002 00:59:49 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06522 for ; Wed, 10 Apr 2002 00:59:44 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3A7xfA09387; Wed, 10 Apr 2002 09:59:41 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA27944; Wed, 10 Apr 2002 09:59:41 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3A7xen17267; Wed, 10 Apr 2002 09:59:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204100759.g3A7xen17267@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #2: replay protection and nvm usage In-reply-to: Your message of Tue, 09 Apr 2002 19:20:44 +0300. <3CB314DC.6090300@piuha.net> Date: Wed, 10 Apr 2002 09:59:40 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Agree Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 04:05:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13450 for ; Wed, 10 Apr 2002 04:05:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20718; Wed, 10 Apr 2002 02:04:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07343; Wed, 10 Apr 2002 01:04:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A846IA007436 for ; Wed, 10 Apr 2002 01:04:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3A846e2007435 for mobile-ip-dist; Wed, 10 Apr 2002 01:04:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A842IA007425 for ; Wed, 10 Apr 2002 01:04:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25084 for ; Wed, 10 Apr 2002 01:04:04 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19960 for ; Wed, 10 Apr 2002 02:04:03 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3A840A09990; Wed, 10 Apr 2002 10:04:01 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA27990; Wed, 10 Apr 2002 10:04:01 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3A840n17303; Wed, 10 Apr 2002 10:04:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204100804.g3A840n17303@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #3: BA, BR authentication? In-reply-to: Your message of Tue, 09 Apr 2002 19:59:11 +0300. <3CB31DDF.9090902@piuha.net> Date: Wed, 10 Apr 2002 10:04:00 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Concern: BA from the HA MUST be protected. The text should be clarified: the proposal (which seems to be reasonnable) is about BA/BR from a common CN. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 04:14:15 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13570 for ; Wed, 10 Apr 2002 04:14:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15888; Wed, 10 Apr 2002 02:13:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09968; Wed, 10 Apr 2002 01:13:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8BcIA007628 for ; Wed, 10 Apr 2002 01:11:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3A8BcJo007626 for mobile-ip-dist; Wed, 10 Apr 2002 01:11:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8BYIA007615 for ; Wed, 10 Apr 2002 01:11:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26540 for ; Wed, 10 Apr 2002 01:11:37 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15020 for ; Wed, 10 Apr 2002 02:11:36 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3A8BTA11460; Wed, 10 Apr 2002 10:11:29 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA28108; Wed, 10 Apr 2002 10:11:29 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3A8BTn17357; Wed, 10 Apr 2002 10:11:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204100811.g3A8BTn17357@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #5: Alternate CoA In-reply-to: Your message of Tue, 09 Apr 2002 21:14:03 +0300. <3CB32F6B.8080806@piuha.net> Date: Wed, 10 Apr 2002 10:11:29 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Question: Should this vulnerability be closed? If it is closed by requiring the RR and Alternative CoA parameter to use the same CoA, will the remaining Alternative CoA be useful for FMIP, HMIP, and other MIPv6 extensions that may use it. => alternative CoA is the common way to repeat the CoA when the BU is protected by ESP so we really need it. BTW I don't believe in attacks using a fake CoA because the real Home Address will be in the RH in all packets/fragments so the only difference with a direct attack is the fake CoA adds a reflection... Text: State the following under 5.1.7: ... => agree Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 04:16:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13597 for ; Wed, 10 Apr 2002 04:16:40 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25239; Wed, 10 Apr 2002 02:16:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10661; Wed, 10 Apr 2002 01:16:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8FiIA007743 for ; Wed, 10 Apr 2002 01:15:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3A8FikO007742 for mobile-ip-dist; Wed, 10 Apr 2002 01:15:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8FeIA007735 for ; Wed, 10 Apr 2002 01:15:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27225 for ; Wed, 10 Apr 2002 01:15:38 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27051 for ; Wed, 10 Apr 2002 01:15:28 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3A8FPA12196; Wed, 10 Apr 2002 10:15:25 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA28160; Wed, 10 Apr 2002 10:15:25 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3A8FOn17409; Wed, 10 Apr 2002 10:15:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204100815.g3A8FOn17409@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field In-reply-to: Your message of Tue, 09 Apr 2002 21:35:07 +0300. <3CB3345B.8020506@piuha.net> Date: Wed, 10 Apr 2002 10:15:24 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Proposal: This SPI field doesn't seem very useful, remove it. => if nobody proposes a real use of it: agree. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 04:24:12 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13685 for ; Wed, 10 Apr 2002 04:24:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27582; Wed, 10 Apr 2002 02:23:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12034; Wed, 10 Apr 2002 01:23:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8MtIA007889 for ; Wed, 10 Apr 2002 01:22:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3A8MtxN007888 for mobile-ip-dist; Wed, 10 Apr 2002 01:22:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8MqIA007881 for ; Wed, 10 Apr 2002 01:22:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27141 for ; Wed, 10 Apr 2002 01:22:54 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27235 for ; Wed, 10 Apr 2002 02:22:53 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3A8McA13585; Wed, 10 Apr 2002 10:22:38 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA28254; Wed, 10 Apr 2002 10:22:38 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3A8Mcn17475; Wed, 10 Apr 2002 10:22:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204100822.g3A8Mcn17475@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: jari.arkko@piuha.net, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field In-reply-to: Your message of Tue, 09 Apr 2002 13:41:29 PDT. <3CB351F9.C364A24A@iprg.nokia.com> Date: Wed, 10 Apr 2002 10:22:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: The SPI field has to be available, to allow for selection of the appropriate Binding Security Association to be used for calculations involving the authentication data. => I believe we have to exhibit a scenario where multiple BSAs are useful before applying this argument. In IPsec the source address is not used in the SA lookup for incoming packets so a SPI is needed but the case of BSAs is a bit different. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 04:35:29 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13837 for ; Wed, 10 Apr 2002 04:35:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00282; Wed, 10 Apr 2002 02:29:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13420; Wed, 10 Apr 2002 01:29:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8SBIA008022 for ; Wed, 10 Apr 2002 01:28:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3A8SBLO008021 for mobile-ip-dist; Wed, 10 Apr 2002 01:28:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8S6IA008014 for ; Wed, 10 Apr 2002 01:28:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13028 for ; Wed, 10 Apr 2002 01:28:09 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16891 for ; Wed, 10 Apr 2002 02:28:07 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3A8S53G013846 for ; Wed, 10 Apr 2002 10:28:06 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Wed Apr 10 10:24:25 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 10:26:31 +0200 Message-ID: From: "Peter Grimstrup (TED)" To: "'Francis Dupont'" , jari.arkko@piuha.net Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #5: Alternate CoA Date: Wed, 10 Apr 2002 10:24:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Question/comment inline Peter > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: 10. april 2002 10:11 > To: jari.arkko@piuha.net > Cc: 'mobile-ip@sunroof.eng.sun.com' > Subject: Re: [mobile-ip] Unresolved issue #5: Alternate CoA > > > Question: Should this vulnerability be closed? If it is closed > by requiring the RR and Alternative CoA parameter to use the > same CoA, will the remaining Alternative CoA be useful for FMIP, > HMIP, and other MIPv6 extensions that may use it. > > => alternative CoA is the common way to repeat the CoA when the BU > is protected by ESP so we really need it. This is an argument to have a duplicate CoA field in the BU. Do you see any need to have an alternative CoA (different from the IP header source)? > BTW I don't believe in attacks using a fake CoA because the real Home > Address will be in the RH in all packets/fragments so the > only difference > with a direct attack is the fake CoA adds a reflection... > > Text: State the following under 5.1.7: > ... > > => agree > > Francis.Dupont@enst-bretagne.fr > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 04:46:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13931 for ; Wed, 10 Apr 2002 04:46:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28850; Wed, 10 Apr 2002 02:46:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17059; Wed, 10 Apr 2002 01:46:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8jWIA008173 for ; Wed, 10 Apr 2002 01:45:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3A8jWaB008172 for mobile-ip-dist; Wed, 10 Apr 2002 01:45:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3A8jSIA008165 for ; Wed, 10 Apr 2002 01:45:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29855 for ; Wed, 10 Apr 2002 01:45:31 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28488 for ; Wed, 10 Apr 2002 02:45:30 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3A8jQ616742; Wed, 10 Apr 2002 10:45:26 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA28556; Wed, 10 Apr 2002 10:45:26 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3A8jPn17818; Wed, 10 Apr 2002 10:45:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204100845.g3A8jPn17818@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Peter Grimstrup (TED)" cc: jari.arkko@piuha.net, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #5: Alternate CoA In-reply-to: Your message of Wed, 10 Apr 2002 10:24:29 +0200. Date: Wed, 10 Apr 2002 10:45:25 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > Question: Should this vulnerability be closed? If it is closed > by requiring the RR and Alternative CoA parameter to use the > same CoA, will the remaining Alternative CoA be useful for FMIP, > HMIP, and other MIPv6 extensions that may use it. > > => alternative CoA is the common way to repeat the CoA when the BU > is protected by ESP so we really need it. This is an argument to have a duplicate CoA field in the BU. => I agree that duplicated is not different but as soon as only one of the two CoAs matters there is no reason to enforce they are the same, i.e. the "alternative CoA" is an elegant way to solve both the duplication and alternative issues. Do you see any need to have an alternative CoA (different from the IP header source)? => in the past I heavily used the alternative CoA for deregistration (using the unregistered home link-local address as the real source of the deregistration packet (BU where CoA == Home Address)). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 08:16:15 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16355 for ; Wed, 10 Apr 2002 08:16:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA07665; Wed, 10 Apr 2002 05:14:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23865; Wed, 10 Apr 2002 05:14:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ACDJIA008501 for ; Wed, 10 Apr 2002 05:13:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ACDJcN008500 for mobile-ip-dist; Wed, 10 Apr 2002 05:13:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ACDFIA008493 for ; Wed, 10 Apr 2002 05:13:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23722 for ; Wed, 10 Apr 2002 05:13:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA04681 for ; Wed, 10 Apr 2002 06:13:15 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16125; Wed, 10 Apr 2002 08:13:05 -0400 (EDT) Message-Id: <200204101213.IAA16125@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-johansson-mip-aaa-nai-01.txt Date: Wed, 10 Apr 2002 08:13:05 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : AAA NAI for Mobile IPv4 Extension Author(s) : T. Johansson, F. Johansson Filename : draft-johansson-mip-aaa-nai-01.txt Pages : 8 Date : 09-Apr-02 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple AAA servers the reauthentication request may not be received by the same AAAH as previous authentication requests. In order for the new AAAH to be able to forward the request to the correct HA it has to know the identity of the HA. This document defines an extension that enables the HA to pass its identity to the mobile node which can in turn pass it to the AAA server when changing point of attachment. This document specifies a NAI extension that can carry these NAIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-johansson-mip-aaa-nai-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-johansson-mip-aaa-nai-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020409132327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-johansson-mip-aaa-nai-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-johansson-mip-aaa-nai-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020409132327.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 11:24:11 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22123 for ; Wed, 10 Apr 2002 11:24:10 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03858; Wed, 10 Apr 2002 09:22:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28159; Wed, 10 Apr 2002 08:22:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AFLfIA008906 for ; Wed, 10 Apr 2002 08:21:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AFLfUD008905 for mobile-ip-dist; Wed, 10 Apr 2002 08:21:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AFLbIA008898 for ; Wed, 10 Apr 2002 08:21:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27997 for ; Wed, 10 Apr 2002 08:21:39 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22829 for ; Wed, 10 Apr 2002 09:21:38 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5C9496A901 for ; Wed, 10 Apr 2002 18:21:32 +0300 (EEST) Message-ID: <3CB44AD6.6050906@piuha.net> Date: Wed, 10 Apr 2002 17:23:18 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #15: Site local addresses and tunnel protection Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Background: Link-local addresses can not be used as home addresses. However, site-local addresses can be used. Draft 16 has a mandatory tunnel outer IP - currently known location check to verify that the tunneled packets at least come from the right IP source. Draft 16 has also an optional ESP usage for the tunneled packets. It has been questioned whether the checking mechanism is sufficient when site-local addresses are used, as it might allow e.g. on-link attackers to send site-local packets to the home network. Question: Is there a threat? If yes, should we (a) warn about it or (b) mandate some additional security mechanisms such as ESP to be used in this case? Without considering the security aspects, does MIPv6 fully work with site-local addresses? For instance, is the lack of a zone id a problem, as asked in the mailing list? Proposal: There is a threat in the sense that administrators must be aware of the implications of allowing site-local home addresses. Document the danger and recommended security precautions in the Security Considerations section. Text: Binding updates to the home agents are secure and when receiving tunneled traffic the home agent verifies the outer IP address corresponds to the current location of the mobile node. This prevents attacks where the attacker is controlled by ingress filtering, as well as attacks where the attacker does not know the current care-of address of the mobile node. Attackers who know the care-of address and are not controlled by ingress filtering could still send traffic through the home agent. This includes attackers on the same local link as the mobile node is currently on. But such attackers could also send spoofed packets without using a tunnel. It is possible to use IPsec ESP to protect payload packets tunneled to the mobile node and back. While this specification does not mandate the use of ESP, its use is recommended to protect the payload communications against attackers on the path between the home agent and the current location of the mobile node. When site local home address are used, reverse tunneling can be used to send site local traffic from another location. Administrators should be aware of this when allowing such home addresses. In particular, the outer IP address check described above is not sufficient against all attackers and the use of encrypted tunnels is particularly useful for this kind of home addresses. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 11:25:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22140 for ; Wed, 10 Apr 2002 11:25:03 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03857; Wed, 10 Apr 2002 09:22:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28152; Wed, 10 Apr 2002 08:22:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AFLEIA008896 for ; Wed, 10 Apr 2002 08:21:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AFLEPu008895 for mobile-ip-dist; Wed, 10 Apr 2002 08:21:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AFLBIA008888 for ; Wed, 10 Apr 2002 08:21:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16045 for ; Wed, 10 Apr 2002 08:21:13 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19785 for ; Wed, 10 Apr 2002 08:21:12 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2F0236A901 for ; Wed, 10 Apr 2002 18:21:06 +0300 (EEST) Message-ID: <3CB44ABB.7090700@piuha.net> Date: Wed, 10 Apr 2002 17:22:51 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #14: RR ESP protection keyword References: <200204100822.g3A8Mcn17475@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit This issue was brought up earlier (21/3) by Vijay on the mailing list. Background: Section 9.6 of draft 16 requires that the home agents MUST use IPsec ESP to protect RR packets between itself and the mobile node. Encryption of the RR packets provides protection against attackers along this path, e.g. those on the mobile node's current LAN. Question: There are multiple questions: - Must it be a MUST, should it be a SHOULD or may it even be a MAY? - Is this a MUST implement or a MUST use? - If it does not have to be used all the time, how is the will to use this signaled, and does it need to be signaled? Proposal: The keyword should apply to implementation, not use. In particular situations users may want to turn this off. For interoperability reasons, a MUST implement would be desireable. This does not appear to cause much additional implementation effort since ESP (or AH) is already necessary for home registration protection. Finally, IPsec SPD controls the use of IPsec so this should be a sufficient mechanism for controlling this feature. Adding a MIPv6 specific flag in the BUs, for instance, to signal the desires of the MN to the HA in this matter might complicate the implementation by requiring additional co-operation between IPsec and MIPv6 stack parts. Text: New contents of 9.6 The Return Routability procedure described in Section X.X.X assumes that the confidentiality of the HoTI and HoT messages is protected as it is tunneled from the home agent to the mobile node. Therefore, the home agent MUST support IPsec ESP for the protection of RR packets. Support for a non-null encryption transform MUST be available. It isn't necessary (or even possible) to distinguish between different kinds of RR packets in this case. The use of ESP for RR protection is optional and controlled by configuration of the IPsec Security Policy Database both at the mobile node and at the home agent. As described earlier, the Binding Update and Binding Acknowledgement messages already need protection even if they are not tunneled. As these messages employ the Mobility Header in a similar manner to the RR messages, one way to set up the Security Policy Database is to protect all traffic to the mobile node and back with IPsec ESP if the protocol in the packet is Mobility Header. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 11:50:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23070 for ; Wed, 10 Apr 2002 11:50:45 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14668; Wed, 10 Apr 2002 09:47:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03637; Wed, 10 Apr 2002 08:47:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AFkBIA009150 for ; Wed, 10 Apr 2002 08:46:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AFkBvx009149 for mobile-ip-dist; Wed, 10 Apr 2002 08:46:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AFk8IA009142 for ; Wed, 10 Apr 2002 08:46:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03411 for ; Wed, 10 Apr 2002 08:46:10 -0700 (PDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07247 for ; Wed, 10 Apr 2002 09:46:08 -0600 (MDT) Received: from there (lothlorien.cwc.nus.edu.sg [172.16.3.239] (may be forged)) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id XAA05754 for ; Wed, 10 Apr 2002 23:45:00 +0800 (SGT) Message-Id: <200204101545.XAA05754@cwcsun41.cwc.nus.edu.sg> Content-Type: text/plain; charset="utf-8" From: Parijat Mishra Reply-To: parijat@cwc.nus.edu.sg Organization: CWC To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field Date: Wed, 10 Apr 2002 23:54:42 +0800 X-Mailer: KMail [version 1.3] References: <3CB32FCF.3070908@piuha.net> <3CB3345B.8020506@piuha.net> <3CB351F9.C364A24A@iprg.nokia.com> In-Reply-To: <3CB351F9.C364A24A@iprg.nokia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Wednesday 10 April 2002 04:41, Charles E. Perkins wrote: > The SPI field has to be available, to allow for selection of > the appropriate Binding Security Association to be used for > calculations involving the authentication data. I think what Jari meant was if the SPI is to be used for selecting BSAs then why is the only legal value defined as 0, and why must implementations discard messages containing other values? I mean, how would one select one of many BSA's if the only BSA one can specify is BSA 0. -- Parijat From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 12:54:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25091 for ; Wed, 10 Apr 2002 12:54:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26372; Wed, 10 Apr 2002 10:53:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17386; Wed, 10 Apr 2002 09:53:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AGqHIA009524 for ; Wed, 10 Apr 2002 09:52:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AGqHEL009523 for mobile-ip-dist; Wed, 10 Apr 2002 09:52:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AGqDIA009516 for ; Wed, 10 Apr 2002 09:52:13 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17182 for ; Wed, 10 Apr 2002 09:52:15 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10419 for ; Wed, 10 Apr 2002 09:52:15 -0700 (PDT) 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 JAA02381; Wed, 10 Apr 2002 09:52:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3AGqEh24573; Wed, 10 Apr 2002 09:52:14 -0700 X-mProtect: <200204101652> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5xo1f3; Wed, 10 Apr 2002 09:52:12 PDT Message-ID: <3CB46DBD.51854223@iprg.nokia.com> Date: Wed, 10 Apr 2002 09:52:13 -0700 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: parijat@cwc.nus.edu.sg CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field References: <3CB32FCF.3070908@piuha.net> <3CB3345B.8020506@piuha.net> <3CB351F9.C364A24A@iprg.nokia.com> <200204101545.XAA05754@cwcsun41.cwc.nus.edu.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The text needs to change to say that the SPI field is ignored. Vijay Parijat Mishra wrote: > > On Wednesday 10 April 2002 04:41, Charles E. Perkins wrote: > > The SPI field has to be available, to allow for selection of > > the appropriate Binding Security Association to be used for > > calculations involving the authentication data. > > I think what Jari meant was if the SPI is to be used for selecting > BSAs then why is the only legal value defined as 0, and why must > implementations discard messages containing other values? I mean, > how would one select one of many BSA's if the only BSA one can > specify is BSA 0. > > -- > Parijat From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 13:00:49 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25240 for ; Wed, 10 Apr 2002 13:00:48 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05338; Wed, 10 Apr 2002 09:59:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17888; Wed, 10 Apr 2002 09:59:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AGwwIA009645 for ; Wed, 10 Apr 2002 09:58:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AGwwc9009644 for mobile-ip-dist; Wed, 10 Apr 2002 09:58:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AGwsIA009637 for ; Wed, 10 Apr 2002 09:58:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17654 for ; Wed, 10 Apr 2002 09:58:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29649 for ; Wed, 10 Apr 2002 10:58:57 -0600 (MDT) 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 JAA02807; Wed, 10 Apr 2002 09:58:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3AGwtw03060; Wed, 10 Apr 2002 09:58:55 -0700 X-mProtect: <200204101658> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkWNTE4; Wed, 10 Apr 2002 09:58:53 PDT Message-ID: <3CB46F4E.1BFA8E4E@iprg.nokia.com> Date: Wed, 10 Apr 2002 09:58:54 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli CC: parijat@cwc.nus.edu.sg, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field References: <3CB32FCF.3070908@piuha.net> <3CB3345B.8020506@piuha.net> <3CB351F9.C364A24A@iprg.nokia.com> <200204101545.XAA05754@cwcsun41.cwc.nus.edu.sg> <3CB46DBD.51854223@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Vijay, I agree with this, except that it should say that the SPI field SHOULD be ignored. The intention is that all implementations should ignore it unless they have a very specific reason not to do so -- as I understand to be the semantics of "SHOULD". The specific reason to do so would be if a correspondent node had alternative Binding Security Associations, established by any means sufficient to authenticate data supplied with the particular binding cache management message to be authenticated. The specific means could be by way of proprietary or military-oriented key establishment protocols. Regards, Charlie P. Vijay Devarapalli wrote: > > The text needs to change to say that the SPI field is ignored. > > Vijay > > Parijat Mishra wrote: > > > > On Wednesday 10 April 2002 04:41, Charles E. Perkins wrote: > > > The SPI field has to be available, to allow for selection of > > > the appropriate Binding Security Association to be used for > > > calculations involving the authentication data. > > > > I think what Jari meant was if the SPI is to be used for selecting > > BSAs then why is the only legal value defined as 0, and why must > > implementations discard messages containing other values? I mean, > > how would one select one of many BSA's if the only BSA one can > > specify is BSA 0. > > > > -- > > Parijat From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 13:22:55 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25848 for ; Wed, 10 Apr 2002 13:22:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03690; Wed, 10 Apr 2002 11:22:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27011; Wed, 10 Apr 2002 10:22:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AHLhIA009801 for ; Wed, 10 Apr 2002 10:21:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AHLhTQ009800 for mobile-ip-dist; Wed, 10 Apr 2002 10:21:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AHLeIA009793 for ; Wed, 10 Apr 2002 10:21:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25136 for ; Wed, 10 Apr 2002 10:21:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12684 for ; Wed, 10 Apr 2002 11:21:40 -0600 (MDT) 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 KAA04656; Wed, 10 Apr 2002 10:21:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3AHLd112084; Wed, 10 Apr 2002 10:21:39 -0700 X-mProtect: <200204101721> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnvJWIk; Wed, 10 Apr 2002 10:21:37 PDT Message-ID: <3CB474A1.3A5E468@iprg.nokia.com> Date: Wed, 10 Apr 2002 10:21:37 -0700 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: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #14: RR ESP protection keyword References: <200204100822.g3A8Mcn17475@givry.rennes.enst-bretagne.fr> <3CB44ABB.7090700@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The text looks good. But I still think a flag in the BU is good. This is to let the MN dynamically turn on/off ESP protection for tunneled RR messages. for Example if (link == public WLAN) turn on ESP for tunneled RR messages if (link == cellular link) turn off ESP for tunneled RR messages regards Vijay Jari Arkko wrote: > > This issue was brought up earlier (21/3) by Vijay on the mailing > list. > > Background: Section 9.6 of draft 16 requires that the home > agents MUST use IPsec ESP to protect RR packets between > itself and the mobile node. Encryption of the RR packets > provides protection against attackers along this path, e.g. > those on the mobile node's current LAN. > > Question: There are multiple questions: > - Must it be a MUST, should it be a SHOULD or > may it even be a MAY? > - Is this a MUST implement or a MUST use? > - If it does not have to be used all the time, > how is the will to use this signaled, and does > it need to be signaled? > > Proposal: The keyword should apply to implementation, not use. In > particular situations users may want to turn this off. For > interoperability reasons, a MUST implement would be desireable. This > does not appear to cause much additional implementation effort since > ESP (or AH) is already necessary for home registration protection. > Finally, IPsec SPD controls the use of IPsec so this should be a > sufficient mechanism for controlling this feature. Adding a MIPv6 > specific flag in the BUs, for instance, to signal the desires of the > MN to the HA in this matter might complicate the implementation by > requiring additional co-operation between IPsec and MIPv6 stack parts. > > Text: New contents of 9.6 > > The Return Routability procedure described in Section X.X.X assumes > that the confidentiality of the HoTI and HoT messages is protected as > it is tunneled from the home agent to the mobile node. Therefore, the > home agent MUST support IPsec ESP for the protection of RR > packets. Support for a non-null encryption transform MUST be > available. It isn't necessary (or even possible) to distinguish > between different kinds of RR packets in this case. > > The use of ESP for RR protection is optional and controlled by > configuration of the IPsec Security Policy Database both at the mobile > node and at the home agent. > > As described earlier, the Binding Update and Binding Acknowledgement > messages already need protection even if they are not tunneled. As > these messages employ the Mobility Header in a similar manner to the > RR messages, one way to set up the Security Policy Database is to > protect all traffic to the mobile node and back with IPsec ESP if the > protocol in the packet is Mobility Header. From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 13:30:26 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26040 for ; Wed, 10 Apr 2002 13:30:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17251; Wed, 10 Apr 2002 11:27:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29329; Wed, 10 Apr 2002 10:27:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AHREIA009933 for ; Wed, 10 Apr 2002 10:27:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AHREfv009932 for mobile-ip-dist; Wed, 10 Apr 2002 10:27:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AHRBIA009925 for ; Wed, 10 Apr 2002 10:27:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26554 for ; Wed, 10 Apr 2002 10:27:12 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15864 for ; Wed, 10 Apr 2002 11:27:11 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4D7AD6A901; Wed, 10 Apr 2002 20:27:10 +0300 (EEST) Message-ID: <3CB46848.5010508@piuha.net> Date: Wed, 10 Apr 2002 19:28:56 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #14: RR ESP protection keyword References: <200204100822.g3A8Mcn17475@givry.rennes.enst-bretagne.fr> <3CB44ABB.7090700@piuha.net> <3CB474A1.3A5E468@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > The text looks good. But I still think a flag in the BU is > good. This is to let the MN dynamically turn on/off ESP > protection for tunneled RR messages. I'm not sure it's worth the complexity it brings. A flag is a small thing, but implies complexity at the other end, and on turning on/off things. Ideally, we shouldn't have to integrate the MIPv6 and IPSec code too much. Furthermore, it isn't clear to me that turning of the protection saves so much that it would force us to think about ways to make the turning on/off easier. It's symmetric crypto for a very short message. It's probably faster than some of the MAC operations for RR... Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 13:48:45 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26720 for ; Wed, 10 Apr 2002 13:48:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18904; Wed, 10 Apr 2002 10:47:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14580; Wed, 10 Apr 2002 10:47:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AHkQIA010093 for ; Wed, 10 Apr 2002 10:46:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AHkQbT010092 for mobile-ip-dist; Wed, 10 Apr 2002 10:46:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AHkNIA010085 for ; Wed, 10 Apr 2002 10:46:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10231 for ; Wed, 10 Apr 2002 10:46:24 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17804 for ; Wed, 10 Apr 2002 11:46:23 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3AHkMs7014631 for ; Wed, 10 Apr 2002 19:46:22 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 10 19:46:21 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281W5VL>; Wed, 10 Apr 2002 19:46:21 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: jari.arkko@piuha.net Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #14: RR ESP protection keyword Date: Wed, 10 Apr 2002 19:44:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Text: New contents of 9.6 > > The Return Routability procedure described in Section X.X.X assumes > that the confidentiality of the HoTI and HoT messages is protected as > it is tunneled from the home agent to the mobile node. Therefore, the > home agent MUST support IPsec ESP for the protection of RR > packets. Support for a non-null encryption transform MUST be > available. It isn't necessary (or even possible) to distinguish > between different kinds of RR packets in this case. > > The use of ESP for RR protection is optional and controlled by > configuration of the IPsec Security Policy Database both at the mobile > node and at the home agent. > > As described earlier, the Binding Update and Binding Acknowledgement > messages already need protection even if they are not tunneled. As > these messages employ the Mobility Header in a similar manner to the > RR messages, one way to set up the Security Policy Database is to > protect all traffic to the mobile node and back with IPsec ESP if the > protocol in the packet is Mobility Header. Don't you need to specify whether the ESP should be deployed in tunnel or in transport mode in the SPD ? As I understand you, ESP transport mode should be used for the BU/BAck whereas the RR should be covered by ESP tunnel mode, how can they then be covered by the same SP ? Karen From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 14:01:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27320 for ; Wed, 10 Apr 2002 14:01:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24020; Wed, 10 Apr 2002 11:00:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19722; Wed, 10 Apr 2002 11:00:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AHxRIA010267 for ; Wed, 10 Apr 2002 10:59:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AHxQj0010266 for mobile-ip-dist; Wed, 10 Apr 2002 10:59:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AHxNIA010259 for ; Wed, 10 Apr 2002 10:59:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11197 for ; Wed, 10 Apr 2002 10:59:25 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02344 for ; Wed, 10 Apr 2002 11:59:24 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 221286A901; Wed, 10 Apr 2002 20:59:23 +0300 (EEST) Message-ID: <3CB46FD5.4060307@piuha.net> Date: Wed, 10 Apr 2002 20:01:09 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #6: Reuse of nonces References: <3CB32FCF.3070908@piuha.net> <3CB3502B.DE671F63@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Agree with most of the text, except for section 11. Excellent. > The actual window of vulnerability is only > MAX_RR_BINDING_LIFE (300 seconds). The MAX_COOKIE_LIFE > does not add anything to the window of vulnerability. So > why not make the MAX_COOKIE_LIFE also 300 seconds. MAX_COOKIE_LIFE determines the window between the time you had to be able to send/receive the RR messages and the sending of the BU. For most attacks that I can think of, the time the BU is sent is the start of the attack. The BU might even be sent from somewhere else than the claimed location of the MN. The attack lasts upto MAX_RR_BINDING_LIFE seconds. In some attacks, such as the bombing attack, the effects of the attack concentrate on the beginning of the binding's lifetime. There's also another aspect that is related to the cookie lifetimes. The CNs are expected to at least try keeping the cookies alive for MAX_COOKIE_LIFE seconds. Increasing the value might make it harder to deal with deleted BCE entries on a busy server (if you delete an entry, you have to either invalidate the cookie at the same time or remember the entry for some additional time). But, let's face it that none of us knows exactly the right times for RR. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 14:02:52 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27373 for ; Wed, 10 Apr 2002 14:02:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08301; Wed, 10 Apr 2002 11:01:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20318; Wed, 10 Apr 2002 11:01:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AI0fIA010293 for ; Wed, 10 Apr 2002 11:00:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AI0fZU010292 for mobile-ip-dist; Wed, 10 Apr 2002 11:00:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AI0bIA010285 for ; Wed, 10 Apr 2002 11:00:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07156 for ; Wed, 10 Apr 2002 11:00:39 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11160 for ; Wed, 10 Apr 2002 12:00:38 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3AI0b3G010198 for ; Wed, 10 Apr 2002 20:00:37 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Wed Apr 10 20:00:36 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 20:00:36 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #14: RR ESP protection keyword ( Replay) Date: Wed, 10 Apr 2002 19:58:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The majority of my mail got lost on the way. Hereby the full version (I hope). > > > > > > Text: New contents of 9.6 > > > > The Return Routability procedure described in Section X.X.X assumes > > that the confidentiality of the HoTI and HoT messages is > protected as > > it is tunneled from the home agent to the mobile node. > Therefore, the > > home agent MUST support IPsec ESP for the protection of RR > > packets. Support for a non-null encryption transform MUST be > > available. It isn't necessary (or even possible) to distinguish > > between different kinds of RR packets in this case. > > > > The use of ESP for RR protection is optional and controlled by > > configuration of the IPsec Security Policy Database both at > the mobile > > node and at the home agent. > > > > As described earlier, the Binding Update and Binding > Acknowledgement > > messages already need protection even if they are not tunneled. As > > these messages employ the Mobility Header in a similar > manner to the > > RR messages, one way to set up the Security Policy Database is to > > protect all traffic to the mobile node and back with IPsec > ESP if the > > protocol in the packet is Mobility Header. > > > Don't you need to specify whether the ESP should be deployed > in tunnel or in transport mode > in the SPD ? As I understand you, ESP transport mode should > be used for the BU/BAck whereas the RR should > be covered by ESP tunnel mode, how can they then be covered > by the same SP ? > > > Karen > Karen From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 14:20:06 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28090 for ; Wed, 10 Apr 2002 14:20:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15283; Wed, 10 Apr 2002 11:18:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27075; Wed, 10 Apr 2002 11:18:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AIHqIA010591 for ; Wed, 10 Apr 2002 11:17:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AIHq82010590 for mobile-ip-dist; Wed, 10 Apr 2002 11:17:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AIHnIA010583 for ; Wed, 10 Apr 2002 11:17:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18962 for ; Wed, 10 Apr 2002 11:17:50 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12019 for ; Wed, 10 Apr 2002 12:17:49 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9A6116A901; Wed, 10 Apr 2002 21:17:48 +0300 (EEST) Message-ID: <3CB47427.4090702@piuha.net> Date: Wed, 10 Apr 2002 20:19:35 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #5: Alternate CoA References: <200204100845.g3A8jPn17818@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > Do you see any need to have an alternative CoA (different from the > IP header source)? > > => in the past I heavily used the alternative CoA for deregistration > (using the unregistered home link-local address as the real source > of the deregistration packet (BU where CoA == Home Address)). This should work as long as the deregistration contains a "proof" that it has been sent by the right MN, i.e. the RR home cookie and a care-of cookie both for the same address. Come to think of it, should we allow a BU with just the home cookie if the CoA is HoA? Or change the cookie calculation rules so that they are the same for both HoT and CoT... I'm not sure about the security aspects though. This might create some new attacks and at least I haven't analyzed this before. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 14:24:15 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28277 for ; Wed, 10 Apr 2002 14:24:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16958; Wed, 10 Apr 2002 11:22:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28638; Wed, 10 Apr 2002 11:22:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AIMGIA010711 for ; Wed, 10 Apr 2002 11:22:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AIMGdD010710 for mobile-ip-dist; Wed, 10 Apr 2002 11:22:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AIMDIA010703 for ; Wed, 10 Apr 2002 11:22:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20058 for ; Wed, 10 Apr 2002 11:22:15 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23899 for ; Wed, 10 Apr 2002 12:22:14 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DEC836A901; Wed, 10 Apr 2002 21:22:07 +0300 (EEST) Message-ID: <3CB4752A.8030806@piuha.net> Date: Wed, 10 Apr 2002 20:23:54 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #5: Alternate CoA References: <3CB32F6B.8080806@piuha.net> <029f01c1e00e$2fd7a470$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > One minor nit: The current text leaves no space for alternative security > mechanisms. Is this the intent, that is, would CoTI and CoT need to be > done if a CGA-like mechanism was in use? Yes, and this would also apply to the "military key management mechanism" that Charlie brought up. Indeed, the text should be clarified that the this and possibly some other requirements apply only if the RR scheme is used. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 14:27:26 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28420 for ; Wed, 10 Apr 2002 14:27:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04456; Wed, 10 Apr 2002 11:26:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00384; Wed, 10 Apr 2002 11:26:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AIPQIA010841 for ; Wed, 10 Apr 2002 11:25:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AIPQoB010840 for mobile-ip-dist; Wed, 10 Apr 2002 11:25:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AIPNIA010833 for ; Wed, 10 Apr 2002 11:25:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29997 for ; Wed, 10 Apr 2002 11:25:25 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21049 for ; Wed, 10 Apr 2002 12:25:24 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6210F6A901; Wed, 10 Apr 2002 21:25:18 +0300 (EEST) Message-ID: <3CB475E8.7040804@piuha.net> Date: Wed, 10 Apr 2002 20:27:04 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <200204100804.g3A840n17303@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > Concern: BA from the HA MUST be protected. The text should be clarified: > the proposal (which seems to be reasonnable) is about BA/BR from a > common CN. Agreed. I believe the text was under a section dealing with MN - CN bindings already, so it is perhaps already ok. Otherwise let me know. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 15:16:12 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00083 for ; Wed, 10 Apr 2002 15:16:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06843; Wed, 10 Apr 2002 12:14:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22654; Wed, 10 Apr 2002 12:14:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AJE1IA011160 for ; Wed, 10 Apr 2002 12:14:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AJE0Pm011159 for mobile-ip-dist; Wed, 10 Apr 2002 12:14:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AJDvIA011152 for ; Wed, 10 Apr 2002 12:13:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22135 for ; Wed, 10 Apr 2002 12:14:00 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22994 for ; Wed, 10 Apr 2002 12:13:59 -0700 (PDT) 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 MAA11823; Wed, 10 Apr 2002 12:13:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3AJDve06050; Wed, 10 Apr 2002 12:13:57 -0700 X-mProtect: <200204101913> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLL5Ch1; Wed, 10 Apr 2002 12:13:55 PDT Message-ID: <3CB48EF4.EB01C189@iprg.nokia.com> Date: Wed, 10 Apr 2002 12:13:56 -0700 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: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #14: RR ESP protection keyword References: <200204100822.g3A8Mcn17475@givry.rennes.enst-bretagne.fr> <3CB44ABB.7090700@piuha.net> <3CB474A1.3A5E468@iprg.nokia.com> <3CB46848.5010508@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Vijay Devarapalli wrote: > > > The text looks good. But I still think a flag in the BU is > > good. This is to let the MN dynamically turn on/off ESP > > protection for tunneled RR messages. > > I'm not sure it's worth the complexity it brings. A flag is > a small thing, but implies complexity at the other end, and > on turning on/off things. Ideally, we shouldn't have to integrate > the MIPv6 and IPSec code too much. This integration is a simple call from MIPv6 code to the IPSec code to instantiate a manually created ESP SA (in tunnel mode). And MIPv6 code removes this SA when ESP tunnel protection is to be turned off. I dont think it is too complicated. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 16:08:48 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01552 for ; Wed, 10 Apr 2002 16:08:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16567; Wed, 10 Apr 2002 14:08:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12247; Wed, 10 Apr 2002 13:08:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AK7MIA011497 for ; Wed, 10 Apr 2002 13:07:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AK7LLU011496 for mobile-ip-dist; Wed, 10 Apr 2002 13:07:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AK7IIA011489 for ; Wed, 10 Apr 2002 13:07:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10965 for ; Wed, 10 Apr 2002 13:07:21 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25480 for ; Wed, 10 Apr 2002 13:07:21 -0700 (PDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3AK7LI08478 for ; Wed, 10 Apr 2002 13:07:21 -0700 (PDT) Message-ID: <016d01c1e0cb$18775060$7e6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Wed, 10 Apr 2002 13:04:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit This isn't security related, but I think it is something that *must* be fixed before the MIPv6 goes to RFC. Page 47 of RFC 2461 states that a router MUST delay a response to a RA solicitation by a random number between 0 and MAX_RA_DELAY_TIME seconds. This seems to have been put in to avoid flooding the local subnet with responses when a bunch of hosts come up at once. However, this is fatal for MIPv6 handover performance. Consider a wireless link layer technology in which the MN gets a trigger when the link comes up, and sends out a solicitation for RA in order to get a new CoA. If the router abides by 2461, the handover will be delayed by some random amount, delaying the MN getting its traffic. Ideally, we could insert some text into the MIPv6 spec saying that this behavior needs to be modified for routers that are handling wireless links, but this would be somewhat counter to the trend in MIPv6 of integrating MIP more tightly with standard IPv6 mechanisms. Alternatively, we could do a separate draft that modified the text in RFC 2461 to make the random delay behavior a SHOULD, or add rate limiting behavior instead (i.e. make the random delay behavior be a function of the incoming SolRA rate). jak From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 17:09:35 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02728 for ; Wed, 10 Apr 2002 17:09:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17068; Wed, 10 Apr 2002 14:08:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02877; Wed, 10 Apr 2002 14:08:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AL65IA011943 for ; Wed, 10 Apr 2002 14:06:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AL65ne011942 for mobile-ip-dist; Wed, 10 Apr 2002 14:06:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AL62IA011935 for ; Wed, 10 Apr 2002 14:06:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02123 for ; Wed, 10 Apr 2002 14:05:48 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06306 for ; Wed, 10 Apr 2002 15:05:46 -0600 (MDT) 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 OAA17721; Wed, 10 Apr 2002 14:05:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3AL5gs16092; Wed, 10 Apr 2002 14:05:42 -0700 X-mProtect: <200204102105> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTOsAMe; Wed, 10 Apr 2002 14:05:39 PDT Message-ID: <3CB4A924.695C8145@iprg.nokia.com> Date: Wed, 10 Apr 2002 14:05:40 -0700 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: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #6: Reuse of nonces References: <3CB32FCF.3070908@piuha.net> <3CB3502B.DE671F63@iprg.nokia.com> <3CB46FD5.4060307@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Vijay Devarapalli wrote: > > > Agree with most of the text, except for section 11. > > Excellent. > > > The actual window of vulnerability is only > > MAX_RR_BINDING_LIFE (300 seconds). The MAX_COOKIE_LIFE > > does not add anything to the window of vulnerability. So > > why not make the MAX_COOKIE_LIFE also 300 seconds. > > MAX_COOKIE_LIFE determines the window between the time > you had to be able to send/receive the RR messages and the > sending of the BU. For most attacks that I can think of, the > time the BU is sent is the start of the attack. The above is an important point. An attacker sending the BU is the start of the attack. > The BU might even > be sent from somewhere else than the claimed location of the MN. > The attack lasts upto MAX_RR_BINDING_LIFE seconds. And only upto to MAX_RR_BINDING_LIFE seconds. > In some attacks, > such as the bombing attack, the effects of the attack concentrate > on the beginning of the binding's lifetime. Either way the MAX_COOKIE_LIFE does not increase the duration of attack. So thats why I said MAX_COOKIE_LIFE does not add to the vulnerability. > There's also another aspect that is related to the cookie > lifetimes. The CNs are expected to at least try keeping the > cookies alive for MAX_COOKIE_LIFE seconds. Increasing the > value might make it harder to deal with deleted BCE entries > on a busy server (if you delete an entry, you have to either > invalidate the cookie at the same time or remember the entry for > some additional time). This is true. But at the same time, see from the MN's side. A cookie lifetime of 300 seconds is very different from a cookie lifetime of 180 seconds. If a mobile node (on an average) moves every 200 seconds, it cant reuse the cookie (just an example :-). It has to run RR everytime it moves. > But, let's face it that none of us knows exactly the right > times for RR. So lets go with 300 seconds. It atleast improves the handoff performance for a longer duration without causing any additional harm. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 18:03:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03736 for ; Wed, 10 Apr 2002 18:03:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19295; Wed, 10 Apr 2002 16:03:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07048; Wed, 10 Apr 2002 15:03:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AM2IIA012249 for ; Wed, 10 Apr 2002 15:02:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AM2Iqu012248 for mobile-ip-dist; Wed, 10 Apr 2002 15:02:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AM2EIA012241 for ; Wed, 10 Apr 2002 15:02:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22447 for ; Wed, 10 Apr 2002 15:02:15 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27838 for ; Wed, 10 Apr 2002 16:02:15 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3ALmoq6027179; Wed, 10 Apr 2002 14:48:50 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABK66526; Wed, 10 Apr 2002 14:46:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA16367; Wed, 10 Apr 2002 14:48:48 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15540.45888.635085.850937@thomasm-u1.cisco.com> Date: Wed, 10 Apr 2002 14:48:48 -0700 (PDT) To: "Charles E. Perkins" Cc: Vijay Devarapalli , parijat@cwc.nus.edu.sg, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field In-Reply-To: <3CB46F4E.1BFA8E4E@iprg.nokia.com> References: <3CB32FCF.3070908@piuha.net> <3CB3345B.8020506@piuha.net> <3CB351F9.C364A24A@iprg.nokia.com> <200204101545.XAA05754@cwcsun41.cwc.nus.edu.sg> <3CB46DBD.51854223@iprg.nokia.com> <3CB46F4E.1BFA8E4E@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit We don't need to allocate bits for people to make non-standard protocols. There are a million other ways they can achieve that. Charles E. Perkins writes: > Hello Vijay, > > I agree with this, except that it should say that > the SPI field SHOULD be ignored. The intention is that > all implementations should ignore it unless they have > a very specific reason not to do so -- as I understand > to be the semantics of "SHOULD". > > The specific reason to do so would be if a correspondent > node had alternative Binding Security Associations, > established by any means sufficient to authenticate > data supplied with the particular binding cache management > message to be authenticated. > > The specific means could be by way of proprietary or > military-oriented key establishment protocols. > > Regards, > Charlie P. > > > Vijay Devarapalli wrote: > > > > The text needs to change to say that the SPI field is ignored. > > > > Vijay > > > > Parijat Mishra wrote: > > > > > > On Wednesday 10 April 2002 04:41, Charles E. Perkins wrote: > > > > The SPI field has to be available, to allow for selection of > > > > the appropriate Binding Security Association to be used for > > > > calculations involving the authentication data. > > > > > > I think what Jari meant was if the SPI is to be used for selecting > > > BSAs then why is the only legal value defined as 0, and why must > > > implementations discard messages containing other values? I mean, > > > how would one select one of many BSA's if the only BSA one can > > > specify is BSA 0. > > > > > > -- > > > Parijat From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 18:09:02 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03829 for ; Wed, 10 Apr 2002 18:09:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22091; Wed, 10 Apr 2002 16:08:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09344; Wed, 10 Apr 2002 15:08:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AM89IA012400 for ; Wed, 10 Apr 2002 15:08:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AM88Tl012399 for mobile-ip-dist; Wed, 10 Apr 2002 15:08:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AM85IA012392 for ; Wed, 10 Apr 2002 15:08:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24699 for ; Wed, 10 Apr 2002 15:08:07 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21694 for ; Wed, 10 Apr 2002 16:08:07 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3AM7qMY010127; Wed, 10 Apr 2002 15:07:52 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABK67119; Wed, 10 Apr 2002 15:05:05 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA16372; Wed, 10 Apr 2002 15:07:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15540.47031.779273.516004@thomasm-u1.cisco.com> Date: Wed, 10 Apr 2002 15:07:51 -0700 (PDT) To: jari.arkko@piuha.net Cc: Vijay Devarapalli , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #14: RR ESP protection keyword In-Reply-To: <3CB46848.5010508@piuha.net> References: <200204100822.g3A8Mcn17475@givry.rennes.enst-bretagne.fr> <3CB44ABB.7090700@piuha.net> <3CB474A1.3A5E468@iprg.nokia.com> <3CB46848.5010508@piuha.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, I'm really confused. This seems rather complicated on the face of it, but is there a possibility that this could be expressed in the SDP instead? Ie, select only MIP/HA traffic for the SA but allow other traffic through untouched? That seems to do the same thing from what I can tell. Mike Jari Arkko writes: > Vijay Devarapalli wrote: > > > The text looks good. But I still think a flag in the BU is > > good. This is to let the MN dynamically turn on/off ESP > > protection for tunneled RR messages. > > > I'm not sure it's worth the complexity it brings. A flag is > a small thing, but implies complexity at the other end, and > on turning on/off things. Ideally, we shouldn't have to integrate > the MIPv6 and IPSec code too much. > > Furthermore, it isn't clear to me that turning of the protection > saves so much that it would force us to think about ways to make > the turning on/off easier. It's symmetric crypto for a very short > message. It's probably faster than some of the MAC operations for > RR... > > Jari > > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 18:13:22 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03914 for ; Wed, 10 Apr 2002 18:13:21 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19690; Wed, 10 Apr 2002 15:13:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11018; Wed, 10 Apr 2002 15:12:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AMCBIA012537 for ; Wed, 10 Apr 2002 15:12:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3AMCB7N012536 for mobile-ip-dist; Wed, 10 Apr 2002 15:12:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3AMC7IA012529 for ; Wed, 10 Apr 2002 15:12:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26310 for ; Wed, 10 Apr 2002 15:12:09 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08886 for ; Wed, 10 Apr 2002 15:12:09 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3AMC4ON023739; Wed, 10 Apr 2002 15:12:04 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABK67248; Wed, 10 Apr 2002 15:09:16 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA16375; Wed, 10 Apr 2002 15:12:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15540.47283.208080.47333@thomasm-u1.cisco.com> Date: Wed, 10 Apr 2002 15:12:03 -0700 (PDT) To: "Karen E Nielsen (TED)" Cc: jari.arkko@piuha.net, "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #14: RR ESP protection keyword In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Karen E Nielsen (TED) writes: > Don't you need to specify whether the ESP should be deployed in tunnel or in transport mode > in the SPD ? As I understand you, ESP transport mode should be used for the BU/BAck whereas the RR should > be covered by ESP tunnel mode, how can they then be covered by the same SP ? This is a good observation. I think we meet the security and flexibility requirements if we make transport mode for the MN/HA a MUST, but allow the use of an ipsec HA/MN tunnel as well (MAY/SHOULD). Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 10 21:02:48 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06317 for ; Wed, 10 Apr 2002 21:02:48 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00413; Wed, 10 Apr 2002 19:02:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01202; Wed, 10 Apr 2002 18:02:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B11LIA013070 for ; Wed, 10 Apr 2002 18:01:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3B11KuD013069 for mobile-ip-dist; Wed, 10 Apr 2002 18:01:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B11HIA013062 for ; Wed, 10 Apr 2002 18:01:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00742 for ; Wed, 10 Apr 2002 18:01:19 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12666 for ; Wed, 10 Apr 2002 19:01:18 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KGFO4K6I1C90QL3I@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 11 Apr 2002 11:00:18 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 40A75201AC; Thu, 11 Apr 2002 00:57:26 +0000 (/etc/localtime) Received: from eng.monash.edu.au (brettpc.eng.monash.edu.au [130.194.252.100]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 6C38B2076C; Thu, 11 Apr 2002 10:22:30 +1000 (EST) Date: Thu, 11 Apr 2002 11:22:23 +1100 From: Brett Pentland Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality X-Sender: "Brett Pentland" To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com Message-id: <3CB4D73F.A0B8E1B1@eng.monash.edu.au> Organization: CTIE - Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en]C-CCK-MCD monwin/024 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <016d01c1e0cb$18775060$7e6015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi, We have also been looking at MIPv6 handover performance where the new network information needs to be discovered after the layer two handover has taken place and this section 6.2.6 of RFC 2461 certainly seems to be a stumbling block. If, as James suggests, the point of delaying the RA is to avoid flooding when a large number of hosts come up at once, then perhaps a flag could be added to the RS that requests an immediate RA. I guess it may be a bit late in the day to go changing packet formats, however. Can anyone say if this was the sole reason for the RA delay or were there other design considerations that brought about its existance? Regards, Brett. James Kempf wrote: > > This isn't security related, but I think it is something that *must* be > fixed before the MIPv6 goes to RFC. > > Page 47 of RFC 2461 states that a router MUST delay a response to a RA > solicitation by a random number between 0 and MAX_RA_DELAY_TIME seconds. > This seems to have been put in to avoid flooding the local subnet with > responses when a bunch of hosts come up at once. > > However, this is fatal for MIPv6 handover performance. Consider a > wireless link layer technology in which the MN gets a trigger when the > link comes up, and sends out a solicitation for RA in order to get a new > CoA. If the router abides by 2461, the handover will be delayed by some > random amount, delaying the MN getting its traffic. > > Ideally, we could insert some text into the MIPv6 spec saying that this > behavior needs to be modified for routers that are handling wireless > links, but this would be somewhat counter to the trend in MIPv6 of > integrating MIP more tightly with standard IPv6 mechanisms. > Alternatively, we could do a separate draft that modified the text in > RFC 2461 to make the random delay behavior a SHOULD, or add rate > limiting behavior instead (i.e. make the random delay behavior be a > function of the incoming SolRA rate). > > jak -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brett Pentland brett.pentland@eng.monash.edu.au CTIE - Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering PO Box 35, Monash University, VIC, 3800, Australia Phone : +61 3 9905-5245 Fax : +61 3 9905-5358 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 00:39:36 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11485 for ; Thu, 11 Apr 2002 00:39:35 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09043; Wed, 10 Apr 2002 22:39:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA02386; Wed, 10 Apr 2002 21:38:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B4c2IA013476 for ; Wed, 10 Apr 2002 21:38:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3B4c2J3013475 for mobile-ip-dist; Wed, 10 Apr 2002 21:38:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B4bwIA013468 for ; Wed, 10 Apr 2002 21:37:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18424 for ; Wed, 10 Apr 2002 21:38:00 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA18554 for ; Wed, 10 Apr 2002 22:37:59 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 087D56A901; Thu, 11 Apr 2002 07:37:58 +0300 (EEST) Message-ID: <3CB5057F.3010102@piuha.net> Date: Thu, 11 Apr 2002 06:39:43 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: Vijay Devarapalli , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #14: RR ESP protection keyword References: <200204100822.g3A8Mcn17475@givry.rennes.enst-bretagne.fr> <3CB44ABB.7090700@piuha.net> <3CB474A1.3A5E468@iprg.nokia.com> <3CB46848.5010508@piuha.net> <15540.47031.779273.516004@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Jari, > > I'm really confused. This seems rather complicated > on the face of it, but is there a possibility that > this could be expressed in the SDP instead? Ie, > select only MIP/HA traffic for the SA but allow > other traffic through untouched? That seems to do > the same thing from what I can tell. Yes, that was my proposal. See second text paragraph at http://www.piuha.net/~jarkko/publications/mipv6/issues/issue14.txt Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 03:52:42 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21617 for ; Thu, 11 Apr 2002 03:52:42 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08503; Thu, 11 Apr 2002 01:52:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26564; Thu, 11 Apr 2002 00:52:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B7pFIA013920 for ; Thu, 11 Apr 2002 00:51:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3B7pFJr013919 for mobile-ip-dist; Thu, 11 Apr 2002 00:51:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B7pCIA013912 for ; Thu, 11 Apr 2002 00:51:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26413 for ; Thu, 11 Apr 2002 00:51:14 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10674 for ; Thu, 11 Apr 2002 01:51:13 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3B7pC3G028306 for ; Thu, 11 Apr 2002 09:51:12 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Thu Apr 11 09:49:26 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Apr 2002 09:49:27 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'Michael Thomas'" Cc: jari.arkko@piuha.net, "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #14: RR ESP protection keyword Date: Thu, 11 Apr 2002 09:49:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This of course mean that the IPSEC selectors should be able to scan the Mobility Header Type field (RR HOT is MH type 3, BU is MH type 5 etc.) Does anyone see a problem with this ? Karen > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 11. april 2002 00:12 > To: Karen E Nielsen (TED) > Cc: jari.arkko@piuha.net; 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Unresolved issue #14: RR ESP > protection keyword > > > Karen E Nielsen (TED) writes: > > Don't you need to specify whether the ESP should be > deployed in tunnel or in transport mode > > in the SPD ? As I understand you, ESP transport mode > should be used for the BU/BAck whereas the RR should > > be covered by ESP tunnel mode, how can they then be > covered by the same SP ? > > This is a good observation. I think we meet the > security and flexibility requirements if we > make transport mode for the MN/HA a MUST, but > allow the use of an ipsec HA/MN tunnel as well > (MAY/SHOULD). > > Mike > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 04:15:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21924 for ; Thu, 11 Apr 2002 04:15:21 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17858; Thu, 11 Apr 2002 02:15:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29913; Thu, 11 Apr 2002 01:14:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8ApIA014135 for ; Thu, 11 Apr 2002 01:10:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3B8AmVg014134 for mobile-ip-dist; Thu, 11 Apr 2002 01:10:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8AhIA014127 for ; Thu, 11 Apr 2002 01:10:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29490 for ; Thu, 11 Apr 2002 01:10:45 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07003 for ; Thu, 11 Apr 2002 01:10:45 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3B8Ace27560; Thu, 11 Apr 2002 10:10:38 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12021; Thu, 11 Apr 2002 10:10:38 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3B8AbT04774; Thu, 11 Apr 2002 10:10:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204110810.g3B8AbT04774@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #5: Alternate CoA In-reply-to: Your message of Wed, 10 Apr 2002 20:19:35 +0300. <3CB47427.4090702@piuha.net> Date: Thu, 11 Apr 2002 10:10:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > Do you see any need to have an alternative CoA (different from the > IP header source)? > > => in the past I heavily used the alternative CoA for deregistration > (using the unregistered home link-local address as the real source > of the deregistration packet (BU where CoA == Home Address)). This should work as long as the deregistration contains a "proof" that it has been sent by the right MN, i.e. the RR home cookie and a care-of cookie both for the same address. => (home) deregistration is with the HA so you have all the proofs you'd like with strong authentication, etc. Come to think of it, should we allow a BU with just the home cookie if the CoA is HoA? Or change the cookie calculation rules so that they are the same for both HoT and CoT... I'm not sure about the security aspects though. This might create some new attacks and at least I haven't analyzed this before. => binding deletion is a case a long/medium term BSA should make things simpler. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 04:15:59 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21971 for ; Thu, 11 Apr 2002 04:15:58 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19201; Thu, 11 Apr 2002 02:15:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00113; Thu, 11 Apr 2002 01:15:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8CjIA014145 for ; Thu, 11 Apr 2002 01:12:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3B8Cjp5014144 for mobile-ip-dist; Thu, 11 Apr 2002 01:12:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8CgIA014137 for ; Thu, 11 Apr 2002 01:12:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01170 for ; Thu, 11 Apr 2002 01:12:43 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01990 for ; Thu, 11 Apr 2002 01:12:42 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 676226A901; Thu, 11 Apr 2002 11:12:41 +0300 (EEST) Message-ID: <3CB537D3.8080308@piuha.net> Date: Thu, 11 Apr 2002 10:14:27 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Karen E Nielsen (TED)" Cc: "'Michael Thomas'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #14: RR ESP protection keyword References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree that the RR going through the HA and the home registration traffic can't be protected by the same SPD entry, as the mode is different. I don't think we need to scan the contents of the mobility header type field, though. One rule can specify what to do for HoA <-> HA: MH traffic and another rule for HoA <-> Any: MH traffic. If the rules are presented in this order, it should work. (Per RFC 2401, the SPD entries are ordered.) Jari Karen E Nielsen (TED) wrote: > This of course mean that the IPSEC selectors should be able to scan > the Mobility Header Type field (RR HOT is MH type 3, BU is MH type 5 etc.) > Does anyone see a problem with this ? > > Karen > > >>-----Original Message----- >>From: Michael Thomas [mailto:mat@cisco.com] >>Sent: 11. april 2002 00:12 >>To: Karen E Nielsen (TED) >>Cc: jari.arkko@piuha.net; 'mobile-ip@sunroof.eng.sun.com' >>Subject: RE: [mobile-ip] Unresolved issue #14: RR ESP >>protection keyword >> >> >>Karen E Nielsen (TED) writes: >> > Don't you need to specify whether the ESP should be >>deployed in tunnel or in transport mode >> > in the SPD ? As I understand you, ESP transport mode >>should be used for the BU/BAck whereas the RR should >> > be covered by ESP tunnel mode, how can they then be >>covered by the same SP ? >> >> This is a good observation. I think we meet the >> security and flexibility requirements if we >> make transport mode for the MN/HA a MUST, but >> allow the use of an ipsec HA/MN tunnel as well >> (MAY/SHOULD). From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 04:23:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22108 for ; Thu, 11 Apr 2002 04:23:51 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21438; Thu, 11 Apr 2002 02:23:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01676; Thu, 11 Apr 2002 01:23:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8MVIA014379 for ; Thu, 11 Apr 2002 01:22:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3B8MVXV014378 for mobile-ip-dist; Thu, 11 Apr 2002 01:22:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8MSIA014371 for ; Thu, 11 Apr 2002 01:22:28 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22681 for ; Thu, 11 Apr 2002 01:22:25 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10043 for ; Thu, 11 Apr 2002 01:22:18 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1D2FD6A901; Thu, 11 Apr 2002 11:22:12 +0300 (EEST) Message-ID: <3CB53A0E.6090507@piuha.net> Date: Thu, 11 Apr 2002 10:23:58 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: parijat@cwc.nus.edu.sg, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field References: <3CB32FCF.3070908@piuha.net> <3CB3345B.8020506@piuha.net> <3CB351F9.C364A24A@iprg.nokia.com> <200204101545.XAA05754@cwcsun41.cwc.nus.edu.sg> <3CB46DBD.51854223@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit If the SPI field is ignored, how does one signal to the other end that you are using some special, perhaps even proprietary, scheme to authorize BUs? It seems to me that you would have been forced to include a a flag or an extra option/parameter anyway, or? Jari Vijay Devarapalli wrote: > The text needs to change to say that the SPI field is ignored. > > Vijay > > Parijat Mishra wrote: > >>On Wednesday 10 April 2002 04:41, Charles E. Perkins wrote: >> > The SPI field has to be available, to allow for selection of >> > the appropriate Binding Security Association to be used for >> > calculations involving the authentication data. >> >>I think what Jari meant was if the SPI is to be used for selecting >>BSAs then why is the only legal value defined as 0, and why must >>implementations discard messages containing other values? I mean, >>how would one select one of many BSA's if the only BSA one can >>specify is BSA 0. >> >>-- >>Parijat >> > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 04:28:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22160 for ; Thu, 11 Apr 2002 04:28:51 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23470; Thu, 11 Apr 2002 02:28:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02559; Thu, 11 Apr 2002 01:28:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8RbIA014495 for ; Thu, 11 Apr 2002 01:27:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3B8Rbp1014494 for mobile-ip-dist; Thu, 11 Apr 2002 01:27:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8RYIA014487 for ; Thu, 11 Apr 2002 01:27:34 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04386 for ; Thu, 11 Apr 2002 01:27:36 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23879 for ; Thu, 11 Apr 2002 02:27:35 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3B8RY3G023905 for ; Thu, 11 Apr 2002 10:27:35 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 11 10:27:18 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281W7P1>; Thu, 11 Apr 2002 10:26:52 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'jari.arkko@piuha.net'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #14: RR ESP protection keyword Date: Thu, 11 Apr 2002 10:27:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I don't think we need to scan the contents of the mobility > header type field, > though. One rule can specify what to do for HoA <-> HA: MH > traffic and another > rule for HoA <-> Any: MH traffic. If the rules are presented > in this order, > it should work. (Per RFC 2401, the SPD entries are ordered.) > Yah, you're right (again). > Jari > Karen From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 04:34:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22260 for ; Thu, 11 Apr 2002 04:34:21 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26000; Thu, 11 Apr 2002 02:34:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03642; Thu, 11 Apr 2002 01:34:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8XGIA014631 for ; Thu, 11 Apr 2002 01:33:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3B8XGeN014630 for mobile-ip-dist; Thu, 11 Apr 2002 01:33:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8XDIA014623 for ; Thu, 11 Apr 2002 01:33:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05802 for ; Thu, 11 Apr 2002 01:33:15 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09922 for ; Thu, 11 Apr 2002 02:33:09 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3B8X1e30776; Thu, 11 Apr 2002 10:33:01 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12346; Thu, 11 Apr 2002 10:33:01 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3B8X0T04908; Thu, 11 Apr 2002 10:33:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204110833.g3B8X0T04908@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality In-reply-to: Your message of Wed, 10 Apr 2002 13:04:40 PDT. <016d01c1e0cb$18775060$7e6015ac@T23KEMPF> Date: Thu, 11 Apr 2002 10:33:00 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Page 47 of RFC 2461 states that a router MUST delay a response to a RA solicitation by a random number between 0 and MAX_RA_DELAY_TIME seconds. This seems to have been put in to avoid flooding the local subnet with responses when a bunch of hosts come up at once. => the explaination you give is for MAX_RTR_SOLICITATION_DELAY at page 56. The idea behind MAX_RA_DELAY_TIME is if there are more than one router on the link they will collide if they try to answer to the RS immediately. However, this is fatal for MIPv6 handover performance. => the whole idea to use RAs as beacons is fatal to many things, at least (in good cases at choice) prefix discovery and handoff performances. Consider a wireless link layer technology in which the MN gets a trigger when the link comes up, and sends out a solicitation for RA in order to get a new CoA. If the router abides by 2461, the handover will be delayed by some random amount, delaying the MN getting its traffic. => an elegant way to avoid the problem is to trigger the RA when the link comes up. This is what happens with PPP and usually the first RA is sent before the RS is received. Ideally, we could insert some text into the MIPv6 spec saying that this behavior needs to be modified for routers that are handling wireless links, but this would be somewhat counter to the trend in MIPv6 of integrating MIP more tightly with standard IPv6 mechanisms. => the real issue is the MIPv6 spec is not supposed to heavily change the standard IPv6 mechanims, especially without the IPv6 WG agreement. Alternatively, we could do a separate draft that modified the text in RFC 2461 to make the random delay behavior a SHOULD, or add rate limiting behavior instead (i.e. make the random delay behavior be a function of the incoming SolRA rate). => IMHO MIPv6 should not lead the neighbor discovery protocol away from its role and should rely on layer two mechanisms when performances become critical. And this should be dicussed in the IPv6 WG, not only here. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 04:47:27 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22400 for ; Thu, 11 Apr 2002 04:47:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16847; Thu, 11 Apr 2002 01:46:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20783; Thu, 11 Apr 2002 01:46:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8j9IA014791 for ; Thu, 11 Apr 2002 01:45:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3B8j99j014790 for mobile-ip-dist; Thu, 11 Apr 2002 01:45:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B8j6IA014783 for ; Thu, 11 Apr 2002 01:45:06 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05006 for ; Thu, 11 Apr 2002 01:45:08 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00698 for ; Thu, 11 Apr 2002 02:45:07 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 967D96A901; Thu, 11 Apr 2002 11:45:06 +0300 (EEST) Message-ID: <3CB53F6C.1020608@piuha.net> Date: Thu, 11 Apr 2002 10:46:52 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #6: Reuse of nonces References: <3CB32FCF.3070908@piuha.net> <3CB3502B.DE671F63@iprg.nokia.com> <3CB46FD5.4060307@piuha.net> <3CB4A924.695C8145@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Either way the MAX_COOKIE_LIFE does not increase the duration > of attack. So thats why I said MAX_COOKIE_LIFE does not add > to the vulnerability. Yes, but perhaps the duration of the attack is not the only consideration. Presumably you could drive around the city and collect cookies from vulnerable WLAN networks. If MAX_COOKIE_LIFE is long, you can do this longer, or drive slower ;-) Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 11:36:31 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00138 for ; Thu, 11 Apr 2002 11:36:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26628; Thu, 11 Apr 2002 09:35:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16580; Thu, 11 Apr 2002 08:35:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BFYkIA015406 for ; Thu, 11 Apr 2002 08:34:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BFYkQV015405 for mobile-ip-dist; Thu, 11 Apr 2002 08:34:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BFYhIA015398 for ; Thu, 11 Apr 2002 08:34:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16335 for ; Thu, 11 Apr 2002 08:34:45 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29500 for ; Thu, 11 Apr 2002 08:34:44 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3BFYe3G020794 for ; Thu, 11 Apr 2002 17:34:43 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 11 17:34:07 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTHY8M>; Thu, 11 Apr 2002 17:34:07 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC4C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #1: Suboptions needed? Date: Thu, 11 Apr 2002 17:34:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Question: Does it make sense to keep suboptions just for HAO? > There are currently no suboptions in HAO. Most of the uses for > what used to be called suboptions can now be handled using a > similar mechanism inside the Mobility Header. > > Proposal: Remove suboptions from Draft 17. => Agree. Hesham > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 11:55:27 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04081 for ; Thu, 11 Apr 2002 11:55:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08867; Thu, 11 Apr 2002 09:55:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21956; Thu, 11 Apr 2002 08:55:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BFsDIA015575 for ; Thu, 11 Apr 2002 08:54:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BFsD4d015574 for mobile-ip-dist; Thu, 11 Apr 2002 08:54:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BFsAIA015567 for ; Thu, 11 Apr 2002 08:54:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07190 for ; Thu, 11 Apr 2002 08:54:13 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25302 for ; Thu, 11 Apr 2002 08:54:12 -0700 (PDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3BFsAI22461; Thu, 11 Apr 2002 08:54:10 -0700 (PDT) Message-ID: <010b01c1e170$e4f961a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Brett Pentland" Cc: References: <016d01c1e0cb$18775060$7e6015ac@T23KEMPF> <3CB4D73F.A0B8E1B1@eng.monash.edu.au> Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Thu, 11 Apr 2002 08:52:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brett, This was suggested to me by someone in private email. I think we could quickly get a draft together and send it through IPNG recommending this approach. The issue is if we should have some text in the MIPv6 specification that requires the MN to set the bit when it solicits. This will result in a normative dependence on the draft about the bit, but, otherwise, the point might be missed by implementors, resulting in poor performance. jak ----- Original Message ----- From: "Brett Pentland" To: "James Kempf" Cc: Sent: Wednesday, April 10, 2002 5:22 PM Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > Hi, > > We have also been looking at MIPv6 handover performance where the new > network information needs to be discovered after the layer two handover has > taken place and this section 6.2.6 of RFC 2461 certainly seems to be a > stumbling block. > > If, as James suggests, the point of delaying the RA is to avoid flooding > when a large number of hosts come up at once, then perhaps a flag could be > added to the RS that requests an immediate RA. I guess it may be a bit late > in the day to go changing packet formats, however. > > Can anyone say if this was the sole reason for the RA delay or were there > other design considerations that brought about its existance? > > Regards, > Brett. > > James Kempf wrote: > > > > This isn't security related, but I think it is something that *must* be > > fixed before the MIPv6 goes to RFC. > > > > Page 47 of RFC 2461 states that a router MUST delay a response to a RA > > solicitation by a random number between 0 and MAX_RA_DELAY_TIME seconds. > > This seems to have been put in to avoid flooding the local subnet with > > responses when a bunch of hosts come up at once. > > > > However, this is fatal for MIPv6 handover performance. Consider a > > wireless link layer technology in which the MN gets a trigger when the > > link comes up, and sends out a solicitation for RA in order to get a new > > CoA. If the router abides by 2461, the handover will be delayed by some > > random amount, delaying the MN getting its traffic. > > > > Ideally, we could insert some text into the MIPv6 spec saying that this > > behavior needs to be modified for routers that are handling wireless > > links, but this would be somewhat counter to the trend in MIPv6 of > > integrating MIP more tightly with standard IPv6 mechanisms. > > Alternatively, we could do a separate draft that modified the text in > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > limiting behavior instead (i.e. make the random delay behavior be a > > function of the incoming SolRA rate). > > > > jak > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Brett Pentland brett.pentland@eng.monash.edu.au > CTIE - Centre for Telecommunications and Information Engineering > Department of Electrical and Computer Systems Engineering > PO Box 35, Monash University, VIC, 3800, Australia > Phone : +61 3 9905-5245 Fax : +61 3 9905-5358 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 12:11:27 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04704 for ; Thu, 11 Apr 2002 12:11:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25790; Thu, 11 Apr 2002 10:11:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25573; Thu, 11 Apr 2002 09:10:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BG9uIA015694 for ; Thu, 11 Apr 2002 09:09:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BG9u0M015693 for mobile-ip-dist; Thu, 11 Apr 2002 09:09:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BG9rIA015686 for ; Thu, 11 Apr 2002 09:09:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25309 for ; Thu, 11 Apr 2002 09:09:56 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24263 for ; Thu, 11 Apr 2002 09:09:55 -0700 (PDT) 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 JAA01646; Thu, 11 Apr 2002 09:09:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3BG9sp14764; Thu, 11 Apr 2002 09:09:54 -0700 X-mProtect: <200204111609> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpde09Pbh; Thu, 11 Apr 2002 09:09:52 PDT Message-ID: <3CB5B551.E1D9104D@iprg.nokia.com> Date: Thu, 11 Apr 2002 09:09:53 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #1: Suboptions needed? References: <3CB3109A.1070002@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Proposal: Remove suboptions from Draft 17. Agreed. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 12:55:44 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05869 for ; Thu, 11 Apr 2002 12:55:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20104; Thu, 11 Apr 2002 09:54:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27673; Thu, 11 Apr 2002 09:54:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BGrVIA015971 for ; Thu, 11 Apr 2002 09:53:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BGrUVN015970 for mobile-ip-dist; Thu, 11 Apr 2002 09:53:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BGrRIA015963 for ; Thu, 11 Apr 2002 09:53:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23089 for ; Thu, 11 Apr 2002 09:53:30 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21864 for ; Thu, 11 Apr 2002 10:53:30 -0600 (MDT) 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 JAA04340; Thu, 11 Apr 2002 09:53:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3BGrSb04443; Thu, 11 Apr 2002 09:53:28 -0700 X-mProtect: <200204111653> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduLOfVb; Thu, 11 Apr 2002 09:53:27 PDT Message-ID: <3CB5BF87.3AA865A4@iprg.nokia.com> Date: Thu, 11 Apr 2002 09:53:27 -0700 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: jari.arkko@piuha.net CC: parijat@cwc.nus.edu.sg, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #13: SPI field References: <3CB32FCF.3070908@piuha.net> <3CB3345B.8020506@piuha.net> <3CB351F9.C364A24A@iprg.nokia.com> <200204101545.XAA05754@cwcsun41.cwc.nus.edu.sg> <3CB46DBD.51854223@iprg.nokia.com> <3CB53A0E.6090507@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > If the SPI field is ignored, how does one signal to the other end that > you are using some special, perhaps even proprietary, scheme to authorize > BUs? It seems to me that you would have been forced to include a > a flag or an extra option/parameter anyway, or? Could be done in many ways. Maybe a flag in the BU is enough. Or local configuration in a bunch of nodes. Vijay > > Jari > > Vijay Devarapalli wrote: > > > The text needs to change to say that the SPI field is ignored. > > > > Vijay > > > > Parijat Mishra wrote: > > > >>On Wednesday 10 April 2002 04:41, Charles E. Perkins wrote: > >> > The SPI field has to be available, to allow for selection of > >> > the appropriate Binding Security Association to be used for > >> > calculations involving the authentication data. > >> > >>I think what Jari meant was if the SPI is to be used for selecting > >>BSAs then why is the only legal value defined as 0, and why must > >>implementations discard messages containing other values? I mean, > >>how would one select one of many BSA's if the only BSA one can > >>specify is BSA 0. > >> > >>-- > >>Parijat > >> > > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 12:56:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05916 for ; Thu, 11 Apr 2002 12:56:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00327; Thu, 11 Apr 2002 10:56:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07771; Thu, 11 Apr 2002 09:56:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BGtRIA016003 for ; Thu, 11 Apr 2002 09:55:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BGtR0s016002 for mobile-ip-dist; Thu, 11 Apr 2002 09:55:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BGtOIA015995 for ; Thu, 11 Apr 2002 09:55:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23797 for ; Thu, 11 Apr 2002 09:55:27 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22948 for ; Thu, 11 Apr 2002 10:55:26 -0600 (MDT) 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 JAA04461; Thu, 11 Apr 2002 09:55:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3BGtPV06729; Thu, 11 Apr 2002 09:55:25 -0700 X-mProtect: <200204111655> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0D9pxw; Thu, 11 Apr 2002 09:55:23 PDT Message-ID: <3CB5BFFB.3DB34BAF@iprg.nokia.com> Date: Thu, 11 Apr 2002 09:55:23 -0700 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: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #6: Reuse of nonces References: <3CB32FCF.3070908@piuha.net> <3CB3502B.DE671F63@iprg.nokia.com> <3CB46FD5.4060307@piuha.net> <3CB4A924.695C8145@iprg.nokia.com> <3CB53F6C.1020608@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Vijay Devarapalli wrote: > > > Either way the MAX_COOKIE_LIFE does not increase the duration > > of attack. So thats why I said MAX_COOKIE_LIFE does not add > > to the vulnerability. > > Yes, but perhaps the duration of the attack is not the only > consideration. Presumably you could drive around the city and > collect cookies from vulnerable WLAN networks. If MAX_COOKIE_LIFE > is long, you can do this longer, or drive slower ;-) I still dont see it. yes, the attacker can go around, collecting the cookies for a longer time. But no harm is done, till the attacker sends a BU to the CN. And after that happens, its the MAX_RR_BINDING_LIFE which comes into picture. What am I missing? Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 14:53:39 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09356 for ; Thu, 11 Apr 2002 14:53:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04431; Thu, 11 Apr 2002 11:52:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11663; Thu, 11 Apr 2002 11:52:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BIpEIA016795 for ; Thu, 11 Apr 2002 11:51:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BIpELG016794 for mobile-ip-dist; Thu, 11 Apr 2002 11:51:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BIpBIA016787 for ; Thu, 11 Apr 2002 11:51:11 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11281 for ; Thu, 11 Apr 2002 11:51:14 -0700 (PDT) Received: from zooty.lancs.ac.uk (zooty.lancs.ac.uk [148.88.16.231]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20514 for ; Thu, 11 Apr 2002 12:51:12 -0600 (MDT) Received: from mail.lancs.ac.uk ([148.88.1.10] helo=marl.lancs.ac.uk) by zooty.lancs.ac.uk with esmtp (Exim 3.34 #1) id 16vjf6-0001He-00 for mobile-ip@sunroof.eng.sun.com; Thu, 11 Apr 2002 19:51:12 +0100 Received: from egcsky000018.lancs.ac.uk ([148.88.156.247] helo=lancaster.ac.uk) by marl.lancs.ac.uk with esmtp (Exim 3.34 #1) id 16vjf5-000584-00 for mobile-ip@sunroof.eng.sun.com; Thu, 11 Apr 2002 19:51:11 +0100 Message-ID: <3CB5DB1F.90909@lancaster.ac.uk> Date: Thu, 11 Apr 2002 19:51:11 +0100 From: Manolis Sifalakis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us, el MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello all, I just finished reading some parts of the draft-ietf-mobileip-fast-mipv6-04 and I would like to ask some questions. My apologies in advance if these things have been discussed before but I joined the list only 4 days ago. 1. In Anticipated Handover Overview (3.1.1) it is understood that the oAR after sending the PrRtAdv message it waits for an F-BU request before starting to tunnel the traffic, destined for the oCoA, to the nCoA or the nAR. Q1. What happens if the MN delays to cross to the new link after sending the F-BU (since for a mobile host anything can easily happen to delay the link traversal)? Are the packets still delivered to the local link untill a L2 trigger appears or are they sent through the tunnel to the nCoA/nRA? Q2. Would it be too much of an overhead if the oAR trasmitted the packets both to the local link and through the tunnel for a while, till it receives an ACK that traversing has been completed? 2. Q. How can a MN or an oAR possibly have topoloical information of where they are heading to, so as to be able to trigger the fast handoff mechanism? 3. Q. Up untill section 3.5.2 in the document (that I read), there is nowhere mentioned that the aAR may be the HA. Instead it is constantly implied that the HA is different from the oAR or the aAR. Is that correct? If yes why? 4. Some typos, I suppose, in 3.1.1, 3.1.3, 3.1.8, are that F-BU is often used to mean F-BAck. If I have misanderstood and an AR can indeed send F-BUs to the MN, then the typo is in the description of the F-BU. Regards .Manolis From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 15:22:06 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10438 for ; Thu, 11 Apr 2002 15:22:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24749; Thu, 11 Apr 2002 12:20:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23011; Thu, 11 Apr 2002 12:20:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BJJeIA017035 for ; Thu, 11 Apr 2002 12:19:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BJJeNB017034 for mobile-ip-dist; Thu, 11 Apr 2002 12:19:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BJJbIA017027 for ; Thu, 11 Apr 2002 12:19:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19970 for ; Thu, 11 Apr 2002 12:19:39 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01737 for ; Thu, 11 Apr 2002 13:19:38 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F2ED76A901 for ; Thu, 11 Apr 2002 22:19:31 +0300 (EEST) Message-ID: <3CB5D41E.9070707@piuha.net> Date: Thu, 11 Apr 2002 21:21:18 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #16: Error message from an unknown MH Type Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit (By the way: If there are any issues that aren't listed on the page on the web site, please submit them to the mailing list. Solutions/text is good to have in addition to the problem description, but not necessary.) Background: Draft 16 states that an error should be given if an unknown MH Type is received. This error may be necessary in terms of diagnosing implementation problems, but it's main use is the ability to determine that the peer does not support some new extension that requires a new MH Type. However, draft 16 does not describe what kind of error can be given. It isn't clear that a Binding Acknowledgement can be used for this purpose as the error may not be given as a response to Binding Update and there isn't an appropriate error code yet. Furthermore, ICMP Parameter Problem does not have an error code that matches the semantics of this error. Question: Is this an important error to give? Should we define a new MH Type and message called Error that would contain an error code? Or should we use the Binding Ack message with a new error code? Proposal: We should just define a new error code under the Binding Ack message, and include the reception of this message in the state machines even when it is not a response to a Binding Update. Text: - 146 Unknown MH Type From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 15:22:46 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10518 for ; Thu, 11 Apr 2002 15:22:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15284; Thu, 11 Apr 2002 12:21:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23356; Thu, 11 Apr 2002 12:21:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BJKmIA017055 for ; Thu, 11 Apr 2002 12:20:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BJKlOS017054 for mobile-ip-dist; Thu, 11 Apr 2002 12:20:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BJKiIA017044 for ; Thu, 11 Apr 2002 12:20:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20247 for ; Thu, 11 Apr 2002 12:20:46 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02232 for ; Thu, 11 Apr 2002 13:20:45 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C792A6A904 for ; Thu, 11 Apr 2002 22:20:43 +0300 (EEST) Message-ID: <3CB5D466.5050209@piuha.net> Date: Thu, 11 Apr 2002 21:22:30 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #9: Terminology Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Background: Some of the MIPv6 terminology was changed in draft 16: - Some options inside an IPv6 DO became messages inside the Mobility Header - One option (HAO) was left inside the IPv6 DO - All suboptions inside options became parameters inside messages It isn't clear if these are the best terms. Also, draft 16 introduced a number of new mechanisms and concepts, some of which need to be talked about and referred to. These may need terms and abbreviations. For instance, we have the Return Routability (RR) mechanism and signaling exchange. RR itself encompasses a number of concepts, such as nonces, cookies, and nonce indices. A new message, Binding Missing was created, and the role of some existing messages has changed: Binding Request can no longer be used without an existing binding. It has been discussed that Binding Acknowledgement might also be used to respond in error situations relating to other messages than Binding Update. The role of the authentication fields has changed from draft 15. Question: What are the correct terms for these things? Do we have all necessary terms? Proposal: Message ======= The Mobile IPv6 protocol defines a number of messages that used in creating and managing bindings. The Mobility Header carries all these messages. Mobility Option (alt. Parameter) ================================ In order to allow optional fields that may not be needed in every use of any given Mobility Header, and to allow future extensions to the format of these messages to be defined, any of the Mobility Header messages defined in this document MAY include one or more options. Such options are included in the data portion of the message itself, after the fixed portion of the message data. Destination Option (alt. Option) ================================ Destination options are carried by the IPv6 Destination Options extension header. Mobile IPv6 defines one new destination option, the Home Address Destination Option. (Question: is this going to be too confusing, having too different types of options in the same specification?) RR Procedure ============ The Return Routability Procedure consists of the Home Test Init, Home Test, Care-of Test Init, and Care-of Test messages between the mobile node and the correspondent node. The RR Procedure is used to establish a suitable key for eventual BU authorization, based on cookies received from the correspondent node in these messages. Correspondent Binding Procedure (alt. BU Procedure) =================================================== The Correspondent Binding Procedure (CBP) consists of the RR Procedure, Binding Update message, and an optional Binding Acknowledgement message. Nonce (alt. something else?) ============================ Nonces are random numbers used internally by the correspondent node in the creation of cookies that will be later used for Binding Update authorization. The nonces are not specific to a mobile node, and are kept secret within the correspondent node, only used as one input in the creation of the cookies. The correspondent node should try to keep track of nonces up to MAX_COOKIE_LIFE seconds after their last use. Nonce Index =========== In the process of authorizing a Binding Update, the mobile node uses a particular set of cookies, which in turn have been produced using a particular set of nonces. For security reasons, neither the cookies or the nonces can appear in the Binding Update message. Given that multiple nonces may be in use simultaneously, the correspondent node has to decide which nonce to use in verifying the authorization. This decision can be made by sequentially trying all possible nonces, but for performance reasons the Nonce Index can be used to find the right nonce directly. Cookie ====== Cookies are cryptographically produced entities that are used by mobile nodes in the process of authorizing Binding Updates. Binding Missing =============== This is the Binding Missing message. Binding Refresh Request (alt. Binding Request) ============================================== This is the old Binding Request message. Authorization Data Option (alt. Authentication Data Option) =========================================================== This is the current Authentication Data Option. Authenticator ============= This is the MAC field in the Authorization Data Option. Binding Acknowledgment ====================== This is the response to a Binding Update, or to an unknown MH Type. From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 16:20:53 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12702 for ; Thu, 11 Apr 2002 16:20:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28093; Thu, 11 Apr 2002 13:19:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00652; Thu, 11 Apr 2002 13:19:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BKIgIA017485 for ; Thu, 11 Apr 2002 13:18:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BKIfLB017484 for mobile-ip-dist; Thu, 11 Apr 2002 13:18:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BKIcIA017477 for ; Thu, 11 Apr 2002 13:18:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20892 for ; Thu, 11 Apr 2002 13:18:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03629 for ; Thu, 11 Apr 2002 14:18:41 -0600 (MDT) 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 NAA19179; Thu, 11 Apr 2002 13:18:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3BKIds31372; Thu, 11 Apr 2002 13:18:39 -0700 X-mProtect: <200204112018> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdECKnhb; Thu, 11 Apr 2002 13:18:36 PDT Message-ID: <3CB5EF9D.425A83DD@iprg.nokia.com> Date: Thu, 11 Apr 2002 13:18:37 -0700 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: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #16: Error message from an unknown MH Type References: <3CB5D41E.9070707@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I dont think it is a good idea overloading the Binding Ack. So far Binding Ack has always been sent in response to a BU. Now you are changing it such that, it is also sent when the receiving side does not recognize a particular MH type. I would prefer going with the ICMP parameter prob (this has been the normal practice whenever you dont recognize something in the packet). Maybe define a new error code. Or live with it, since the ICMP parameter prob also points to the corresponding offending octet in the original packet. Vijay Jari Arkko wrote: > > (By the way: If there are any issues that aren't listed on the page > on the web site, please submit them to the mailing list. Solutions/text > is good to have in addition to the problem description, but not necessary.) > > Background: Draft 16 states that an error should be given if an > unknown MH Type is received. This error may be necessary in terms of > diagnosing implementation problems, but it's main use is the ability > to determine that the peer does not support some new extension that > requires a new MH Type. However, draft 16 does not describe what kind > of error can be given. It isn't clear that a Binding Acknowledgement > can be used for this purpose as the error may not be given as a > response to Binding Update and there isn't an appropriate error code > yet. Furthermore, ICMP Parameter Problem does not have an error code > that matches the semantics of this error. > > Question: Is this an important error to give? Should we define > a new MH Type and message called Error that would contain an > error code? Or should we use the Binding Ack message with a > new error code? > > Proposal: We should just define a new error code under the Binding Ack > message, and include the reception of this message in the state > machines even when it is not a response to a Binding Update. > > Text: > - 146 Unknown MH Type From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 16:37:13 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14376 for ; Thu, 11 Apr 2002 16:37:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07038; Thu, 11 Apr 2002 13:35:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06415; Thu, 11 Apr 2002 13:35:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BKZ4IA017642 for ; Thu, 11 Apr 2002 13:35:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BKZ30g017641 for mobile-ip-dist; Thu, 11 Apr 2002 13:35:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BKZ0IA017634 for ; Thu, 11 Apr 2002 13:35:00 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21742 for ; Thu, 11 Apr 2002 13:35:03 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29976 for ; Thu, 11 Apr 2002 14:35:03 -0600 (MDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3BKZ0I06690; Thu, 11 Apr 2002 13:35:00 -0700 (PDT) Message-ID: <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Manolis Sifalakis" , References: <3CB5DB1F.90909@lancaster.ac.uk> Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 Date: Thu, 11 Apr 2002 13:33:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 1. In Anticipated Handover Overview (3.1.1) it is understood that the > oAR after sending the PrRtAdv message it waits for an F-BU request > before starting to tunnel the traffic, destined for the oCoA, to the > nCoA or the nAR. > > Q1. What happens if the MN delays to cross to the new link after sending > the F-BU (since for a mobile host anything can easily happen to delay > the link traversal)? Are the packets still delivered to the local link > untill a L2 trigger appears or are they sent through the tunnel to the > nCoA/nRA? > If there is a L2 Link Down trigger on the old access router, this can be used to determine when to start tunneling. If no such trigger exists, the access router can either start tunneling immediately, in which case the mobile node will miss those packets sent before it moves, or it can bicast packets down the old link and the tunnel. > Q2. Would it be too much of an overhead if the oAR trasmitted the > packets both to the local link and through the tunnel for a while, till > it receives an ACK that traversing has been completed? > This has been proposed, but there are questions about the effect on the transport layer, though some people contend that the (IPR-encumbered) Eiffel draft will solve the problem. > > 2. Q. How can a MN or an oAR possibly have topoloical information of > where they are heading to, so as to be able to trigger the fast handoff > mechanism? > This comes as part of a Layer 2 trigger, and depends on the particulars of the Layer 2. For example, it is relatively easy to get this information on a cellular network. On a WLAN, the mobile knows its BSSID, this can be sent in the PrxyRtSol. The access router then needs to perform a kind of cross link RARP to find out the IP address. Seamoby is looking at a protocol to facilitate dynamic cross link RARP, but static configuration is always possible. > > 3. Q. Up untill section 3.5.2 in the document (that I read), there is > nowhere mentioned that the aAR may be the HA. Instead it is constantly > implied that the HA is different from the oAR or the aAR. Is that > correct? If yes why? > Would it make any change in the protocol description? > > 4. Some typos, I suppose, in 3.1.1, 3.1.3, 3.1.8, are that F-BU is often > used to mean F-BAck. If I have misanderstood and an AR can indeed send > F-BUs to the MN, then the typo is in the description of the F-BU. > It should probably be F-BAck. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 16:47:19 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14654 for ; Thu, 11 Apr 2002 16:47:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12634; Thu, 11 Apr 2002 13:46:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09935; Thu, 11 Apr 2002 13:46:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BKj9IA017760 for ; Thu, 11 Apr 2002 13:45:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BKj91N017759 for mobile-ip-dist; Thu, 11 Apr 2002 13:45:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BKj6IA017752 for ; Thu, 11 Apr 2002 13:45:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25243 for ; Thu, 11 Apr 2002 13:45:09 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05104 for ; Thu, 11 Apr 2002 14:45:08 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1F6E96A901; Thu, 11 Apr 2002 23:45:01 +0300 (EEST) Message-ID: <3CB5E828.40500@piuha.net> Date: Thu, 11 Apr 2002 22:46:48 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #16: Error message from an unknown MH Type References: <3CB5D41E.9070707@piuha.net> <3CB5EF9D.425A83DD@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I dont think it is a good idea overloading the Binding > Ack. So far Binding Ack has always been sent in response > to a BU. Now you are changing it such that, it is also > sent when the receiving side does not recognize a > particular MH type. > > I would prefer going with the ICMP parameter prob (this > has been the normal practice whenever you dont recognize > something in the packet). Maybe define a new error code. > Or live with it, since the ICMP parameter prob also points > to the corresponding offending octet in the original packet. I'd be fine with this also. RFC 2463 lists the Parameter Problem codes: 0 - erroneous header field encountere 1 - unrecognized Next Header type encountered 2 - unrecognized IPv6 option encountered 1 and 2 seem to be inappropriate. What about 0? A quick look at the usage of code 0 on e.g. wrong routing header type seems to match the usage here. So go for ICMP Parameter Problem and Code 0 instead? Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 18:41:14 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17875 for ; Thu, 11 Apr 2002 18:41:14 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28117; Thu, 11 Apr 2002 16:41:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27020; Thu, 11 Apr 2002 15:40:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BMddIA018003 for ; Thu, 11 Apr 2002 15:39:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BMdcZd018002 for mobile-ip-dist; Thu, 11 Apr 2002 15:39:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BMdZIA017995 for ; Thu, 11 Apr 2002 15:39:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22669 for ; Thu, 11 Apr 2002 15:39:38 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02440 for ; Thu, 11 Apr 2002 16:39:37 -0600 (MDT) 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 PAA03621; Thu, 11 Apr 2002 15:39:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3BMdap05781; Thu, 11 Apr 2002 15:39:36 -0700 X-mProtect: <200204112239> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrItowV; Thu, 11 Apr 2002 15:39:34 PDT Message-ID: <3CB610A7.FC9077CC@iprg.nokia.com> Date: Thu, 11 Apr 2002 15:39:35 -0700 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: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #16: Error message from an unknown MH Type References: <3CB5D41E.9070707@piuha.net> <3CB5EF9D.425A83DD@iprg.nokia.com> <3CB5E828.40500@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Vijay Devarapalli wrote: > > > I dont think it is a good idea overloading the Binding > > Ack. So far Binding Ack has always been sent in response > > to a BU. Now you are changing it such that, it is also > > sent when the receiving side does not recognize a > > particular MH type. > > > > I would prefer going with the ICMP parameter prob (this > > has been the normal practice whenever you dont recognize > > something in the packet). Maybe define a new error code. > > Or live with it, since the ICMP parameter prob also points > > to the corresponding offending octet in the original packet. > > I'd be fine with this also. RFC 2463 lists the Parameter Problem > codes: > > 0 - erroneous header field encountere > 1 - unrecognized Next Header type encountered > 2 - unrecognized IPv6 option encountered > > 1 and 2 seem to be inappropriate. What about 0? A quick > look at the usage of code 0 on e.g. wrong routing header > type seems to match the usage here. So go for ICMP Parameter > Problem and Code 0 instead? I wonder how much of an effort it is to define a new error code. If it is a big pain, I am fine with what you are suggesting (ICMP Parameter Problem with code 0). Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 19:32:46 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19998 for ; Thu, 11 Apr 2002 19:32:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08944; Thu, 11 Apr 2002 16:31:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23152; Thu, 11 Apr 2002 16:31:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BNU6IA018190 for ; Thu, 11 Apr 2002 16:30:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BNU66k018189 for mobile-ip-dist; Thu, 11 Apr 2002 16:30:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BNU2IA018182 for ; Thu, 11 Apr 2002 16:30:02 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g3BNU535248958; Thu, 11 Apr 2002 16:30:05 -0700 (PDT) Message-Id: <200204112330.g3BNU535248958@jurassic.eng.sun.com> Date: Thu, 11 Apr 2002 16:32:22 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Unresolved issue #16: Error message from an unknown MH Type To: jari.arkko@piuha.net, vijayd@IPRG.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8pVjR+pVUmTSqfx7Bnnc6w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > I would prefer going with the ICMP parameter prob (this > > has been the normal practice whenever you dont recognize > > something in the packet). Maybe define a new error code. > > Or live with it, since the ICMP parameter prob also points > > to the corresponding offending octet in the original packet. > > > I'd be fine with this also. RFC 2463 lists the Parameter Problem > codes: > > 0 - erroneous header field encountere > 1 - unrecognized Next Header type encountered > 2 - unrecognized IPv6 option encountered > > 1 and 2 seem to be inappropriate. What about 0? A quick > look at the usage of code 0 on e.g. wrong routing header > type seems to match the usage here. So go for ICMP Parameter > Problem and Code 0 instead? Although I agree that we are overloading BA if we are to use BA to send the error message: unknown MH type, but using ICMP Param problem with code = 0 , does not quite carry the proper semantics of "Unknown MH Type". So, the question is how important it is to know by the recepient that it is indeed an unknown MH type or does ICMP PARAM with code=0, (with a pointer to the nextheader field) is enough for this purpose ? In this context, we have a new issue to clarify here. Question: Should a CN implementation MUST support route optimization ? (now that by default, route optimization is not mandatory for mobile nodes ) a) If by any chance, we decide that a CN may optionally support route optimization for MobileIP, then a CN which does not support route optimization, MUST handle HoTI/CoTI messages and BU by sending an appropriate error message to MN. So, if we consider sending ICMP param in this case, the code should be 1 (unrecognized next header) to indicate that it does not support RO. b) If a CN MUST support route optimization, then the spec should clarify that. How about adding a subsection in section 7 to clarify "Requirements for IPv6 Correspondent nodes" ? I think, it's hard for a CN to distinguish when to send 'unrecognized next header' or 'erroneous header field' in the above cases. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 20:22:35 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21127 for ; Thu, 11 Apr 2002 20:22:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14179; Thu, 11 Apr 2002 18:22:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07964; Thu, 11 Apr 2002 17:22:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C0LCIA018334 for ; Thu, 11 Apr 2002 17:21:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3C0LCJi018333 for mobile-ip-dist; Thu, 11 Apr 2002 17:21:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C0L9IA018326 for ; Thu, 11 Apr 2002 17:21:09 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g3C0LC35258500; Thu, 11 Apr 2002 17:21:13 -0700 (PDT) Message-Id: <200204120021.g3C0LC35258500@jurassic.eng.sun.com> Date: Thu, 11 Apr 2002 17:23:29 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Unresolved issue #16: unrecognized MH To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3J4J0LYjK4+A/BiYiYnL9A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > b) If a CN MUST support route optimization, then the spec should > clarify that. How about adding a subsection in section 7 to > clarify "Requirements for IPv6 Correspondent nodes" ? > > The draft should also clarify that OLD IPv6 nodes (without Mobility support) should send 'mobility header unknown' message as an indication that they don't support CN functionality for MIPv6. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 20:29:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21529 for ; Thu, 11 Apr 2002 20:29:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11908; Thu, 11 Apr 2002 18:29:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09768; Thu, 11 Apr 2002 17:29:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C0StIA018460 for ; Thu, 11 Apr 2002 17:28:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3C0StLO018459 for mobile-ip-dist; Thu, 11 Apr 2002 17:28:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C0SqIA018452 for ; Thu, 11 Apr 2002 17:28:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09626 for ; Thu, 11 Apr 2002 17:28:55 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA20194 for ; Thu, 11 Apr 2002 18:28:51 -0600 (MDT) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel11.hp.com (Postfix) with ESMTP id B6F296006E0 for ; Thu, 11 Apr 2002 17:28:50 -0700 (PDT) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id RAA19269 for ; Thu, 11 Apr 2002 17:29:47 -0700 (PDT) Date: Thu, 11 Apr 2002 17:29:45 -0700 (PDT) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Mobile IP Working Group Subject: [mobile-ip] FA vs COA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, I have a couple simple questions wrt to registration via with co-located COA (R bit in advertisement). 1. If they share a SA, MUST the FA and HA include the FA-HA auth ext when exchanging control packets? 2. Can the FA request a HA-FA key if it does not have a SA with the HA, even though it is not the COA? thanks, Siva From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 20:47:29 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22047 for ; Thu, 11 Apr 2002 20:47:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09320; Thu, 11 Apr 2002 17:46:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16839; Thu, 11 Apr 2002 17:46:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C0jQIA018590 for ; Thu, 11 Apr 2002 17:45:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3C0jQId018589 for mobile-ip-dist; Thu, 11 Apr 2002 17:45:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C0jNIA018582 for ; Thu, 11 Apr 2002 17:45:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01883 for ; Thu, 11 Apr 2002 17:45:21 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25927 for ; Thu, 11 Apr 2002 18:45:20 -0600 (MDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KGH1U4J9ZK921I8S@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Fri, 12 Apr 2002 10:44:25 +1000 Received: from splat (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 4BF3A130007; Fri, 12 Apr 2002 00:43:56 +0000 (/etc/localtime) Received: from eng.monash.edu.au (brettpc.eng.monash.edu.au [130.194.252.100]) by splat.its.monash.edu.au (Postfix) with ESMTP id A2C21130012; Fri, 12 Apr 2002 10:37:24 +1000 (EST) Date: Fri, 12 Apr 2002 11:37:15 +1100 From: Brett Pentland Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality X-Sender: "Brett Pentland" To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com, Francis Dupont Message-id: <3CB62C3B.230F5800@eng.monash.edu.au> Organization: CTIE - Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en]C-CCK-MCD monwin/024 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <016d01c1e0cb$18775060$7e6015ac@T23KEMPF> <3CB4D73F.A0B8E1B1@eng.monash.edu.au> <010b01c1e170$e4f961a0$7e6015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, Francis, James Kempf wrote: > > Brett, > > This was suggested to me by someone in private email. I think we could > quickly get a draft together and > send it through IPNG recommending this approach. > > The issue is if we should have some text in the MIPv6 specification that > requires the MN to set the bit when it solicits. This will result in a > normative dependence on the draft about the bit, but, otherwise, the > point might be missed by implementors, resulting in poor performance. > > jak If a flag in the RS is the correct approach then yes, it would seem almost essential to have some reference to the technique in the MIPv6 specification for the reason you mentioned. In another email, Francis mentioned a technique of triggering an RA when an interface comes up. If this is a method of achieving the same result but without any change to the neighbour discovery protocol, then it may be better. Francis, perhaps you could elaborate on how a mobile node's interface coming up on a network could be made to trigger an RA from the router on that network without sending an RS (or a very similar packet). Regards, Brett. > > ----- Original Message ----- > From: "Brett Pentland" > To: "James Kempf" > Cc: > Sent: Wednesday, April 10, 2002 5:22 PM > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance > Fatality > > > Hi, > > > > We have also been looking at MIPv6 handover performance where the new > > network information needs to be discovered after the layer two > handover has > > taken place and this section 6.2.6 of RFC 2461 certainly seems to be a > > stumbling block. > > > > If, as James suggests, the point of delaying the RA is to avoid > flooding > > when a large number of hosts come up at once, then perhaps a flag > could be > > added to the RS that requests an immediate RA. I guess it may be a > bit late > > in the day to go changing packet formats, however. > > > > Can anyone say if this was the sole reason for the RA delay or were > there > > other design considerations that brought about its existance? > > > > Regards, > > Brett. > > > > James Kempf wrote: > > > > > > This isn't security related, but I think it is something that *must* > be > > > fixed before the MIPv6 goes to RFC. > > > > > > Page 47 of RFC 2461 states that a router MUST delay a response to a > RA > > > solicitation by a random number between 0 and MAX_RA_DELAY_TIME > seconds. > > > This seems to have been put in to avoid flooding the local subnet > with > > > responses when a bunch of hosts come up at once. > > > > > > However, this is fatal for MIPv6 handover performance. Consider a > > > wireless link layer technology in which the MN gets a trigger when > the > > > link comes up, and sends out a solicitation for RA in order to get a > new > > > CoA. If the router abides by 2461, the handover will be delayed by > some > > > random amount, delaying the MN getting its traffic. > > > > > > Ideally, we could insert some text into the MIPv6 spec saying that > this > > > behavior needs to be modified for routers that are handling wireless > > > links, but this would be somewhat counter to the trend in MIPv6 of > > > integrating MIP more tightly with standard IPv6 mechanisms. > > > Alternatively, we could do a separate draft that modified the text > in > > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > > limiting behavior instead (i.e. make the random delay behavior be a > > > function of the incoming SolRA rate). > > > > > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 11 22:05:51 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00464 for ; Thu, 11 Apr 2002 22:05:51 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08292; Thu, 11 Apr 2002 19:04:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08549; Thu, 11 Apr 2002 19:04:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C238IA018782 for ; Thu, 11 Apr 2002 19:03:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3C238AN018781 for mobile-ip-dist; Thu, 11 Apr 2002 19:03:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C236IA018774 for ; Thu, 11 Apr 2002 19:03:07 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10878 for ; Thu, 11 Apr 2002 22:03:08 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id WAA00217 for mobile-ip@sunroof.eng.sun.com; Thu, 11 Apr 2002 22:04:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3B04DIA012831 for ; Wed, 10 Apr 2002 17:04:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17932 for ; Wed, 10 Apr 2002 17:04:16 -0700 (PDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11851 for ; Wed, 10 Apr 2002 18:04:16 -0600 (MDT) Received: from blind (blind [128.111.49.140]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3B049O13153; Wed, 10 Apr 2002 17:04:09 -0700 (PDT) Date: Wed, 10 Apr 2002 17:04:09 -0700 (PDT) From: MobiHoc 2002 X-Sender: mobihoc@blind To: MobiHoc 2002 Subject: [mobile-ip] Mobihoc 2002: Early Registration Deadline Approaching! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Please note: The early registration deadline is *April 22nd*. Register now to guarantee the reduced registration fee! --------------------------------------------------------------------------- ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiHoc 2002 The Third ACM International Symposium on Mobile Ad Hoc Networking and Computing Lausanne, Switzerland June 9-11, 2002 http://www.acm.org/sigmobile/mobihoc/2002/ Sponsored by ACM SIGMOBILE http://www.acm.org/sigmobile/ MobiHoc 2002 is the third of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 in Long Beach, California, and now in 2002 in Lausanne, Switzerland. Topics of interest include all areas of mobile and wireless ad hoc networking (above the physical layer), ad hoc computing, and sensor networks. PAPERS: There will be approximately seven technical paper sessions on a wide range of ad hoc networking topics. The list of accepted papers can be found at http://www.acm.org/sigmobile/mobihoc/2002/program.html. Paper topics include routing, sensor networks, scalability, multicast, energy consumption, TCP, and priority scheduling. POSTERS: There will also be a poster session, describing innovative and recent research on ad hoc networks. TUTORIALS: This year there is a new component to MobiHoc: technical tutorials. On June 9th there will be two tutorials. "Design and Modeling of Medium Access Control Protocols for Wireless Ad Hoc Networks" will be held in the morning, and "Routing & Multicasting in Ad hoc Networks" will be held in the afternoon. HOTEL and REGISTRATION: Hotel information is currently available on-line, and the symposium is open for registration. Register by April 22, 2002 to get the early registration rates. IMPORTANT DATES: Early Registration Deadline: April 22, 2002 Tutorials: June 9, 2002 Conference: June 10-11, 2002 FOR MORE INFORMATION: Please visit the MobiHoc 2002 Home Page at http://www.acm.org/sigmobile/mobihoc/2002/ or send email to mobihoc@epfl.ch for any questions or for more information about the symposium. ORGANIZING COMMITTEE: General Chair Jean-Pierre Hubaux EPFL (CH) jean-pierre.hubaux@epfl.ch Program Co-Chairs J.J. Garcia-Luna-Aceves David B. Johnson Univ. California, Santa Cruz (US) Rice University (US) jj@cs.ucsc.edu dbj@cs.rice.edu Tutorials Co-Chairs Adam Wolisz Mario Gerla Technical Univ. of Berlin (DE) Univ. California, Los Angeles (US) wolisz@ee.tu-berlin.de gerla@cs.ucla.edu Finance Chair Local Arrangements Chair Rachid Guerraoui Silvia Giordano EPFL (CH) EPFL (CH) rachid.guerraoui@epfl.ch silvia.giordano@epfl.ch Publicity Chair Publication Chair Elizabeth M. Belding-Royer Robin Kravets Univ. Calif., Santa Barbara (US) Univ. Illinois, Urbana-Champaign (US) ebelding@cs.ucsb.edu rhk@cs.uiuc.edu Registration Chair Srdjan Capkun EPFL (CH) srdan.capkun@epfl.ch Steering Committee Andrew T. Campbell Charles E. Perkins J.J. Garcia-Luna-Aceves Ram Ramanathan Mario Gerla Martha Steenstrup Joseph P. Macker Nitin H. Vaidya ACM Program Director Ginger Ignatoff --------------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 12 05:39:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27599 for ; Fri, 12 Apr 2002 05:39:53 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09009; Fri, 12 Apr 2002 03:39:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06610; Fri, 12 Apr 2002 02:39:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C9cIIA019467 for ; Fri, 12 Apr 2002 02:38:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3C9cIvA019466 for mobile-ip-dist; Fri, 12 Apr 2002 02:38:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C9cFIA019459 for ; Fri, 12 Apr 2002 02:38:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01915 for ; Fri, 12 Apr 2002 02:38:18 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08404 for ; Fri, 12 Apr 2002 03:38:18 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3C9cG3G006529 for ; Fri, 12 Apr 2002 11:38:16 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Apr 12 11:36:41 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBT2Q5W>; Fri, 12 Apr 2002 11:36:41 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803C07D69@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Michael Thomas , jari.arkko@piuha.net Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #13: SPI field Date: Fri, 12 Apr 2002 11:36:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Agreed. Hesham > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, April 09, 2002 9:56 PM > To: jari.arkko@piuha.net > Cc: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] Unresolved issue #13: SPI field > > > Jari Arkko writes: > > Proposal: This SPI field doesn't seem very useful, remove > > it. > > Agree. > > Mike > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 12 05:47:54 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28458 for ; Fri, 12 Apr 2002 05:47:53 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12152; Fri, 12 Apr 2002 03:47:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07588; Fri, 12 Apr 2002 02:47:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C9krIA019626 for ; Fri, 12 Apr 2002 02:46:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3C9kqPH019625 for mobile-ip-dist; Fri, 12 Apr 2002 02:46:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3C9knIA019618 for ; Fri, 12 Apr 2002 02:46:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24043 for ; Fri, 12 Apr 2002 02:46:53 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22780 for ; Fri, 12 Apr 2002 03:46:52 -0600 (MDT) Received: from 192.168.57.15 (a2 [192.168.57.22]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id PAA07076 for ; Fri, 12 Apr 2002 15:01:55 +0530 From: "gaurav_puri98" Message-Id: <200204120931.PAA07076@WS0005.indiatimes.com> To: Reply-To: "gaurav_puri98" Subject: [mobile-ip] Performing DAD with 'S' bit not set Date: Fri, 12 Apr 2002 15:15:39 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20024125151539859484421" MIME-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --=_MAILER_ATTACH_BOUNDARY1_20024125151539859484421 Content-Type: text/plain; charset=us-ascii hello all, When a HA receives a BU with 'D' bitset and 'S' bit not set, then does HA have to perform DAD for each and every possible home address of MN(i.e . link local and global addresses using all the advertised prefixes) or doing it for link local will be sufficient? reagrds gaurav Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_20024125151539859484421 Content-Type: text/html; charset=us-ascii

hello all,

  When a HA receives a BU with 'D' bitset and 'S' bit not set, then does HA have to perform DAD for each and every possible home address of MN(i.e . link local and global addresses using all the advertised prefixes) or doing it for link local will be sufficient?

reagrds

gaurav 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_20024125151539859484421-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 12 09:01:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18384 for ; Fri, 12 Apr 2002 09:01:04 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21139; Fri, 12 Apr 2002 07:00:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01769; Fri, 12 Apr 2002 06:00:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CCxbIA020014 for ; Fri, 12 Apr 2002 05:59:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CCxbGc020013 for mobile-ip-dist; Fri, 12 Apr 2002 05:59:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CCxYIA020006 for ; Fri, 12 Apr 2002 05:59:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10110 for ; Fri, 12 Apr 2002 05:59:37 -0700 (PDT) Received: from lri.lri.fr (lri.lri.fr [129.175.15.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13221 for ; Fri, 12 Apr 2002 05:59:37 -0700 (PDT) Received: from lri.fr (lri [129.175.15.1]) by lri.lri.fr (8.11.6/jtpda-5.3.2) with ESMTP id g3CCxTF00573 for ; Fri, 12 Apr 2002 14:59:29 +0200 (MEST) Message-ID: <3CB6DA31.8A2D32C3@lri.fr> Date: Fri, 12 Apr 2002 14:59:29 +0200 From: Benzaid Mounir X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] Agent Advertisement Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, Does anyone know how it is possible to pick up the agent advertisement sent by the limited broadcast address (255.255.255.255 on wireless interface) from the loopback interface. Could you let me have some details about this, please. Thanks in advance best regards. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 12 17:53:55 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04971 for ; Fri, 12 Apr 2002 17:53:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17262; Fri, 12 Apr 2002 14:53:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22689; Fri, 12 Apr 2002 14:52:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CLpaIA021190 for ; Fri, 12 Apr 2002 14:51:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CLpa77021189 for mobile-ip-dist; Fri, 12 Apr 2002 14:51:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CLpXIA021182 for ; Fri, 12 Apr 2002 14:51:33 -0700 (PDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3CLpZg00677; Fri, 12 Apr 2002 17:51:35 -0400 (EDT) Date: Fri, 12 Apr 2002 17:52:33 -0400 (EDT) From: "Steven M. Glass" Reply-To: "Steven M. Glass" Subject: RE: [mobile-ip] Question about the I Bit in the Revocation Acknow ledgement Messag e To: Ahmad Muhanna Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <6B49EDFE974BD51197D70002A56079D801AFCBBF@zrc2c013.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Thanks for your reply. Not a problem! (I hope you don't mind, but I've forwarded a copy of this to the list mainly for archival reasons, but also to answer the more general audience). > I have been thinking about Registration Revocation for sometimes, now. > I like your approach, BUT I have been asking myself the following question: > > Why we do not think of something more secure and End-to-End between the HA > and the MN. Ahmad, Actually, there is (but it's not what you expect). Since there's a constraint in the base protocol that a home agent can't generate a 'registration request' that is NOT in response to a 'registration reply' it means that the MN will not be in a state to receive any registration messages. I don't want this to change, since it means a significant change in MN architecture. As I said, there is more secure end2end solution, and that is what happens after the revocation. If the FA notifies the MN its binding has been lost, or certainly when the binding would normally expire, the MN will [likely] attempt to reregister. If the Home domain revoked the registration, the home agent will respond that it is denying the registration with some error code, e.g. administratively prohibited, and that IS secure end2end with the HA-MN authenticator. The other thing to consider is if the FA revoked the registration, it may reply with an error [on the attempt to re-register], or it may simply not repond if that's the policy in the foriegn domain. The key thing here is the relationship between home and foreign policies, and we shouldn't design a revocation mechanism that shifts the balance between the two. As we get deeper in detail, local policies can be enforced to 'squeeze' the correct thing out of the other domain. E.g. if the MN wants to get revocation notifications directly, it should attempt to colocate, and will get revocation messages with the HA-MN authenticator. If, however, the foreign domain wants get these messages, it can set the 'R' bit to suggest the MN register through it (though enforcing it is a topological consideration beyond the scope of mobile ip, but simply preventing the MN from getting a topologically correct IPsrc address for the foreign subnet is sufficient). Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 12 18:01:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05180 for ; Fri, 12 Apr 2002 18:01:16 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19013; Fri, 12 Apr 2002 16:01:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24904; Fri, 12 Apr 2002 15:00:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CLxuIA021295 for ; Fri, 12 Apr 2002 14:59:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CLxthD021294 for mobile-ip-dist; Fri, 12 Apr 2002 14:59:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CLxsIA021287 for ; Fri, 12 Apr 2002 14:59:54 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03054 for ; Fri, 12 Apr 2002 17:59:56 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA00885 for mobile-ip@sunroof.eng.sun.com; Fri, 12 Apr 2002 18:00:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CIkdIA020857 for ; Fri, 12 Apr 2002 11:46:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19829 for ; Fri, 12 Apr 2002 11:46:42 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14503 for ; Fri, 12 Apr 2002 11:46:42 -0700 (PDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3CIkdl00466; Fri, 12 Apr 2002 13:46:39 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3CIkcX06224; Fri, 12 Apr 2002 13:46:38 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA14598; Fri, 12 Apr 2002 13:46:37 -0500 (CDT) Received: from ericberk107 ([138.85.159.127]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id NAA18520; Fri, 12 Apr 2002 13:46:36 -0500 (CDT) Message-ID: <009901c1e252$60606410$7f9f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "Mobile IP Working Group" Cc: , "'Tony Johansson'" References: Subject: [mobile-ip] confusing issue surrounding the 'R' bit in RFC 3220 Date: Fri, 12 Apr 2002 11:46:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello All, A few questions regarding the use of the 'R' bit with a mobile node using a co-located CoA: Section 2.1.1 states: " R Registration required. Registration with this foreign agent (or another foreign agent on this link) is required even when using a co-located care-of address." and section 2.4.1 states: " When the mobile node receives an Agent Advertisement with the 'R' bit set, the mobile node SHOULD register through the foreign agent, even when the mobile node might be able to acquire its own co-located care-of address. This feature is intended to allow sites to enforce visiting policies (such as accounting) which require exchanges of authorization. If formerly reserved bits require some kind of monitoring/enforcement at the foreign link, foreign agents implementing the new specification for the formerly reserved bits can set the 'R' bit. This has the effect of forcing the mobile node to register through the foreign agent, so the foreign agent could then monitor/enforce the policy." This brings up the following question: If a mobile has obtained a co-located CoA, and wishes to register through a FA who has set the 'R' bit in his agent advertisement, does the MN have to relinquish the co-located CoA (and instead use the FA as the CoA)? At first read, it would appear as though this is *not* necessary, which has brought up the following questions: Since we are using a co-located CoA (but still through a FA), is the FA-HA authentication extenstion used, and if so, how, since the MN is the endpoint of the MIP tunnel? Or is it that we actually end up with IP-in-IP-in-IP between the HA and FA, then IP-in-IP between the FA and MN, and the MN does the final decapsulation? (hope this question makes sense... :) Thanks, Kev & Tony From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 12 18:50:09 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06128 for ; Fri, 12 Apr 2002 18:50:09 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10737; Fri, 12 Apr 2002 15:49:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16747; Fri, 12 Apr 2002 15:49:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CMmPIA021622 for ; Fri, 12 Apr 2002 15:48:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CMmPtb021621 for mobile-ip-dist; Fri, 12 Apr 2002 15:48:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CMmMIA021614 for ; Fri, 12 Apr 2002 15:48:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05978 for ; Fri, 12 Apr 2002 15:48:26 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07419; Fri, 12 Apr 2002 16:48:25 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CMmOq11836; Fri, 12 Apr 2002 17:48:24 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TT7BK>; Fri, 12 Apr 2002 17:48:24 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCBC3@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Steven M. Glass'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Question about the I Bit in the Revocation Acknow ledgement Messag e Date: Fri, 12 Apr 2002 17:48:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E274.26CA2430" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E274.26CA2430 Content-Type: text/plain; charset="iso-8859-1" Hello Steve; Thanks a lot. Could you please see my comments inline. Thanks; Ahmad > > > > Thanks for your reply. > > Not a problem! (I hope you don't mind, but I've > forwarded a copy of this > to the list mainly for archival reasons, but also to answer > the more general > audience). > No problem at all. > > > I have been thinking about Registration Revocation for > sometimes, now. > > I like your approach, BUT I have been asking myself the > following question: > > > > Why we do not think of something more secure and End-to-End > between the HA > > and the MN. > > Ahmad, > > Actually, there is (but it's not what you expect). Since there's a > constraint in the base protocol that a home agent can't generate a > 'registration request' that is NOT in response to a > 'registration reply' it > means that the MN will not be in a state to receive any > registration messages. > I don't want this to change, since it means a significant change in MN > architecture. Well, does this mean that MN can not receive a MIP RRQ message or any kind of request. >As I said, there is more secure end2end > solution, and that is > what happens after the revocation. If the FA notifies the MN > its binding has > been lost, or certainly when the binding would normally > expire, the MN will > [likely] attempt to reregister. Would not be nice if we inform the MN why it lost its binding? It seems to me that we are using a mechanism that was meant to be rarely used, in case of rebooting the FA, to inform the MN that its registration is revoked. >If the Home domain revoked > the registration, > the home agent will respond that it is denying the > registration with some > error code, e.g. administratively prohibited, and that IS > secure end2end with > the HA-MN authenticator. The other thing to consider is if > the FA revoked the > registration, it may reply with an error [on the attempt to > re-register], or > it may simply not repond if that's the policy in the foriegn domain. > > The key thing here is the relationship between home and > foreign policies, > and we shouldn't design a revocation mechanism that shifts > the balance between > the two. As we get deeper in detail, local policies can be > enforced to > 'squeeze' the correct thing out of the other domain. E.g. if > the MN wants to > get revocation notifications directly, it should attempt to > colocate, and will > get revocation messages with the HA-MN authenticator. If, > however, the > foreign domain wants get these messages, it can set the 'R' > bit to suggest the > MN register through it (though enforcing it is a topological > consideration > beyond the scope of mobile ip, but simply preventing the MN > from getting a > topologically correct IPsrc address for the foreign subnet is > sufficient). > > Cheers, > Steve > > ------_=_NextPart_001_01C1E274.26CA2430 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Question about the I Bit in the Revocation Acknow ledgement Messag e

Hello Steve;
Thanks a lot.

Could you please see my comments inline.

Thanks;
Ahmad

>
>
> > Thanks for your reply.
>
>     Not a problem!  (I hope you don't mind, but I've
> forwarded a copy of this
> to the list mainly for archival reasons, but also to answer
> the more general
> audience).
>

No problem at all.

>
> > I have been thinking about Registration Revocation for
> sometimes, now.
> > I like your approach, BUT I have been asking myself the
> following question:
> >
> > Why we do not think of something more secure and End-to-End
> between the HA
> > and the MN.
>
>     Ahmad,
>
>    Actually, there is (but it's not what you expect).  Since there's a
> constraint in the base protocol that a home agent can't generate a
> 'registration request' that is NOT in response to a
> 'registration reply' it
> means that the MN will not be in a state to receive any
> registration messages.
> I don't want this to change, since it means a significant change in MN
> architecture. 

Well, does this mean that MN can not receive a MIP RRQ message or any kind of request.

>As I said, there is more secure end2end
> solution, and that is
> what happens after the revocation.  If the FA notifies the MN
> its binding has
> been lost, or certainly when the binding would normally
> expire, the MN will
> [likely] attempt to reregister. 

Would not be nice if we inform the MN why it lost its binding?
It seems to me that we are using a mechanism that was meant to be rarely used,
in case of rebooting the FA, to inform the MN that its registration is revoked.

>If the Home domain revoked
> the registration,
> the home agent will respond that it is denying the
> registration with some
> error code, e.g. administratively prohibited, and that IS
> secure end2end with
> the HA-MN authenticator.  The other thing to consider is if
> the FA revoked the
> registration, it may reply with an error [on the attempt to
> re-register], or
> it may simply not repond if that's the policy in the foriegn domain.
>
>     The key thing here is the relationship between home and
> foreign policies,
> and we shouldn't design a revocation mechanism that shifts
> the balance between
> the two.  As we get deeper in detail, local policies can be
> enforced to
> 'squeeze' the correct thing out of the other domain.  E.g. if
> the MN wants to
> get revocation notifications directly, it should attempt to
> colocate, and will
> get revocation messages with the HA-MN authenticator.  If,
> however, the
> foreign domain wants get these messages, it can set the 'R'
> bit to suggest the
> MN register through it (though enforcing it is a topological
> consideration
> beyond the scope of mobile ip, but simply preventing the MN
> from getting a
> topologically correct IPsrc address for the foreign subnet is
> sufficient).
>
>                               Cheers,
>                                   Steve
>
>

------_=_NextPart_001_01C1E274.26CA2430-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 12 19:48:26 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06997 for ; Fri, 12 Apr 2002 19:48:25 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21052; Fri, 12 Apr 2002 16:47:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26831; Fri, 12 Apr 2002 16:47:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CNkDIA022118 for ; Fri, 12 Apr 2002 16:46:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3CNkDkb022117 for mobile-ip-dist; Fri, 12 Apr 2002 16:46:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3CNk9IA022110 for ; Fri, 12 Apr 2002 16:46:10 -0700 (PDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3CNkCg06536; Fri, 12 Apr 2002 19:46:12 -0400 (EDT) Date: Fri, 12 Apr 2002 19:47:10 -0400 (EDT) From: "Steven M. Glass" Reply-To: "Steven M. Glass" Subject: RE: [mobile-ip] Question about the I Bit in the Revocation Acknow ledgement Messag e To: Ahmad Muhanna Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <6B49EDFE974BD51197D70002A56079D801AFCBC3@zrc2c013.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Ahmad, > > > > Actually, there is (but it's not what you expect). Since there's a > > constraint in the base protocol that a home agent can't generate a > > 'registration request' that is NOT in response to a > > 'registration reply' it > > means that the MN will not be in a state to receive any > > registration messages. > > I don't want this to change, since it means a significant change in MN > > architecture. > > Well, does this mean that MN can not receive a MIP RRQ message or any kind > of request. I presume you mean RRP, but at any rate it means the MN is likely to discard anything it does receive (of course depending on the implementation, but most I've seen use a state machine approach, and are only listenning when they're expecting a RRP). We could e.g. specify a different port for these messages, and have the FA relay them to the MN (note the colocated MN already gets these messages directly), but again this complicates both FA and MN the implementations. For the same functionality, I see it as unnecessary (see below). > >As I said, there is more secure end2end > > solution, and that is > > what happens after the revocation. If the FA notifies the MN > > its binding has > > been lost, or certainly when the binding would normally > > expire, the MN will > > [likely] attempt to reregister. > > Would not be nice if we inform the MN why it lost its binding? > It seems to me that we are using a mechanism that was meant to be rarely > used, > in case of rebooting the FA, to inform the MN that its registration is > revoked. Well, rarely used or not, it serves this communication purpose (without the 'why'). Yes, I'd prefer if the unicast 'I lost your binding' messages were secure, but someone could already forge these, and if they are forged, if the MN immediately reregisters, it'll get its registration back; this solution doesn't leave the MN more prone to these attacks. Note that there could be reasons for the FA or the HA to want the MN informed that its binding is lost, but not tell it why (e.g. a simple 'minimal information' approach, or perhaps 'feign outage', etc). [Re]using this mechanism does that initially, and if there's more information to be had by the MN, it gets provided at reregistration time. Note also that colocated MNs that support registration revocation can get the information directly from the HA, so if this is what you want, it's motivation to support colocation! There are usually multiple approaches to a solution, and I'm not sure this is something significantly lacking in this particular approach. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 12 20:41:37 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07445 for ; Fri, 12 Apr 2002 20:41:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23304; Fri, 12 Apr 2002 17:40:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18733; Fri, 12 Apr 2002 17:40:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3D0drIA022279 for ; Fri, 12 Apr 2002 17:39:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3D0drxd022278 for mobile-ip-dist; Fri, 12 Apr 2002 17:39:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3D0dnIA022271 for ; Fri, 12 Apr 2002 17:39:49 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18505 for ; Fri, 12 Apr 2002 17:39:52 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10243 for ; Fri, 12 Apr 2002 17:39:52 -0700 (PDT) Received: from AlperVAIO (dhcp115.docomolabs-usa.com [172.21.96.115]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3D0dnI12505; Fri, 12 Apr 2002 17:39:49 -0700 (PDT) Message-ID: <0c4501c1e282$be0af6e0$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Manolis Sifalakis" , References: <3CB5DB1F.90909@lancaster.ac.uk> Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 Date: Fri, 12 Apr 2002 17:32:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 3. Q. Up untill section 3.5.2 in the document (that I read), there is > nowhere mentioned that the aAR may be the HA. Instead it is constantly > implied that the HA is different from the oAR or the aAR. Is that > correct? If yes why? Nowhere in the draft it should it suggest that aAR is "the home agent of the MN for its home address". But note that, in order to provide "forwarding from previous care-of address" functionality, aAR/oAR has to implement home agent functionality. They act as a home agent for the oldCoA of the mobile node. oAR has to defend the oldCoA and tunnel packets sent to oldCoA to newCoA. alper From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 12 21:13:30 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07928 for ; Fri, 12 Apr 2002 21:13:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19697; Fri, 12 Apr 2002 18:12:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26413; Fri, 12 Apr 2002 18:12:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3D1BvIA022466 for ; Fri, 12 Apr 2002 18:11:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3D1BvX9022465 for mobile-ip-dist; Fri, 12 Apr 2002 18:11:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3D1BsIA022458 for ; Fri, 12 Apr 2002 18:11:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03341 for ; Fri, 12 Apr 2002 18:11:57 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10839 for ; Fri, 12 Apr 2002 19:11:56 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 18:11:55 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Apr 2002 18:11:55 -0700 Received: from red-msg-09.redmond.corp.microsoft.com ([157.54.12.7]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 18:11:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] Unresolved issue #3: BA, BR authentication? Date: Fri, 12 Apr 2002 18:11:55 -0700 Message-ID: Thread-Topic: [mobile-ip] Unresolved issue #3: BA, BR authentication? thread-index: AcHf8FS1LrEpz7yxSLiNudzJx7P5bgCjBC9Q From: "Tuomas Aura" To: Cc: X-OriginalArrivalTime: 13 Apr 2002 01:11:55.0280 (UTC) FILETIME=[33A27900:01C1E288] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3D1BsIA022459 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I do not like the BA/BR authentication. First, do they need to be authenticated? Second, the protocol is difficult to understand and analyze. But if BA/BR authentication is needed, this may be as good as it gets. > 1a. MN(HoA) -> CN: HoTI(HoA, C0) > 1b. MN(CoA) -> CN: CoTI(CoA, C1) > 2a. CN -> MN(HoA): HoT(C0, K0, j) > 2b. CN -> MN(CoA): CoT(C1, K1, i) > 3. MN(CoA) -> CN: BU(HoA, CoA, C2, MAC, j, i) > 4. CN -> MN(CoA): BA(MAC) > 5. CN -> MN(HoA): BR(MAC) > Kbu = H(K0 | K1) > CN -> MN(CoA): MAC_Kbu(BA | HoA | CoA | C2), > ... Note 1: I agree that something like this must be done if BA/BR are to be authenticated. Without the cookie exchange, an attacker could spoof messages 2a and 2b and thus could spoof the value of Kbu. Therefore, authenticating BA/BR with Kbu would not prove anything. Note 2: The cookie exchange in the above protocol solves the spoofing problem, at least to some extent. Messages 2a and 2b contain the cookies and are therefore difficult to spoof. Consequently, the attacker cannot easily spoof the value of Kbu. However, it will be difficult to explain exactly why the BA/BR authentication works and to quantify how strong it is compared to the BU authentication. For these reasons, I am not very fond of the above protocol. Unfortunately, I do not immediately see any alternative that would give the same security without adding complexity. Note 3: (rather theoretical) To get exactly the same strength of authentication for the BA/BR as for the BU, the BA/BR should be authenticated with MAC_Kba where Kba= H(C0 | C1), not with MAC_Kbu. Clearly, this is impossible if the stateless CN does not remember C0 and C1, or Kba. But there is a way around this. CN can remember C0 and C1 in the following way: 2a. CN -> MN(HoA): HoT(C0, K0, j, Blob0) 2b. CN -> MN(CoA): CoT(C1, K1, i, Blob1) 3. MN(CoA) -> CN: BU(HoA, CoA, C2, MAC, j, i, Blob0, Blob1) Blob0 = E_Kcn(C0); Blob1 = E_Kcn(C1) The correspondent encrypts C0 and C1 with the key Kcn, which is known only to itself and sends the encrypted blobs of data to MN. MN sends them back for decryption. (The freshness of the encrypted Blobs needs to be checked. I'm not sure what is the best method and whether it is necessary to add even more length to the messages). I do not seriously suggest this change, though. Jari's protocol is already complex enough. Rather, I would like to see it simplified, for example, by discarding the BA/BR authentication altogether. Note 4: The routing-based authentication of CN is not an inherently bad idea. This is different from CGA-based authentication, which simply does not work for the correspondent (unless the correspondent address is also required to be a CGA). Tuomas From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 14 12:21:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20143 for ; Sun, 14 Apr 2002 12:21:52 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28118; Sun, 14 Apr 2002 10:21:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02907; Sun, 14 Apr 2002 09:19:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3EGJ9IA024298 for ; Sun, 14 Apr 2002 09:19:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3EGJ9JI024297 for mobile-ip-dist; Sun, 14 Apr 2002 09:19:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3EGJ6IA024290 for ; Sun, 14 Apr 2002 09:19:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03293 for ; Sun, 14 Apr 2002 09:19:09 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10617 for ; Sun, 14 Apr 2002 09:19:08 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 880016A901; Sun, 14 Apr 2002 19:19:00 +0300 (EEST) Message-ID: <3CB9AC18.20205@piuha.net> Date: Sun, 14 Apr 2002 19:19:36 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Tuomas Aura Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tuomas, Thanks for commenting on this, I appreciate your view on this very much. Some discussion below: > I do not like the BA/BR authentication. First, do they need > to be authenticated? Second, the protocol is difficult to > understand and analyze. So, we need to figure out if there is a serious enough vulnerability without BA/BR authentication. The attack we had in mind was a DoS attack where the attacker bombs the MN with bogus HoTs or CoTs. In the plain RR protocol these can be sent from anywhere in the Internet, and the MN has no way of distinguishing them from each real ones. Granted, the attacker has to be sending these messages all the time unless he knows when RR is initiated. As a result of the attack, BU fails. This failure is though noticeable in the form of an error code in the BA. As a result, the MN may not get RO but at least it can still keep on doing bidirectional tunneling. In a more serious variant of the attack the attacker spoofs also successful BAs. If the MN happens to believe them, it starts RO while the real CN doesn't have a BCE, leading to at least some packets being blackholed. It may be possible to survive this given that there most likely isn't any forward progress on application layer and the BM messages keep coming to the MN. However, the MN may need some intelligence in getting out of the attack situation and staying with bidirectional tunneling while the attacker continues the attack. Is this serious enough? I'm not sure! > However, it will be difficult to explain exactly why the BA/BR > authentication works and to quantify how strong it is compared > to the BU authentication. The essence of RR is that nodes who are not on the CN-HA path can't get to the cookies and hence can't authenticate. The original intention of the BA/BR authentication was to produce a similar level of authentication for the responses. In other words, if you don't see the cookie from the MN you can't claim to be sending a response either. However, the basic RR protocol is complicated withe the Kcn and other details mainly due to the need to keep CN stateless. This isn't necessary when talking about responses to individual requests to the CN. > To get exactly the same strength of authentication for the > BA/BR as for the BU, the BA/BR should be authenticated with > MAC_Kba where Kba= H(C0 | C1), not with MAC_Kbu. How about this: we don't provide any authentication of the CN in the sense that all the messages be tied to each other in some manner. But we provide a simple send cookie - return cookie for each of the request - response pairs in the protocol. We also delete the MAC field from the BA and BR, and only keep the response cookie. This limits the attacks to those nodes who are on the path to see the cookies from the MN, but does not add any MAC calculations, encryption, or CN state requirements. Also, I think that would make CN and MN authentication separate, so analysis should be easier. Comments? Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 14 21:25:04 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24493 for ; Sun, 14 Apr 2002 21:25:04 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18827; Sun, 14 Apr 2002 19:24:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20680; Sun, 14 Apr 2002 18:23:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3F1MBIA024815 for ; Sun, 14 Apr 2002 18:22:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3F1MBun024814 for mobile-ip-dist; Sun, 14 Apr 2002 18:22:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3F1M8IA024807 for ; Sun, 14 Apr 2002 18:22:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA16088 for ; Sun, 14 Apr 2002 18:22:11 -0700 (PDT) From: kamela@mail.ustc.edu.cn Received: from mx1.ustc.edu.cn ([61.132.182.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA13049 for ; Sun, 14 Apr 2002 19:22:07 -0600 (MDT) Received: from mail.ustc.edu.cn (webmail.ustc.edu.cn [202.38.64.16]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id JAA04540; Mon, 15 Apr 2002 09:12:25 +0800 Received: from 202.38.75.75 (SquirrelMail authenticated user kamela) by webmail.ustc.edu.cn with HTTP; Mon, 15 Apr 2002 08:52:23 +0800 (CST) Message-ID: <64653.202.38.75.75.1018831943.squirrel@webmail.ustc.edu.cn> Date: Mon, 15 Apr 2002 08:52:23 +0800 (CST) Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 To: In-Reply-To: <3CB5DB1F.90909@lancaster.ac.uk> References: <3CB5DB1F.90909@lancaster.ac.uk> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: X-Mailer: SquirrelMail (version 1.2.0 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > Hello all, > > I just finished reading some parts of the > draft-ietf-mobileip-fast-mipv6-04 and I would like to ask some > questions. My apologies in advance if these things have been discussed > before but I joined the list only 4 days ago. > > > 1. In Anticipated Handover Overview (3.1.1) it is understood that the > oAR after sending the PrRtAdv message it waits for an F-BU request > before starting to tunnel the traffic, destined for the oCoA, to the > nCoA or the nAR. > > Q1. What happens if the MN delays to cross to the new link after > sending the F-BU (since for a mobile host anything can easily happen > to delay the link traversal)? Are the packets still delivered to the > local link untill a L2 trigger appears or are they sent through the > tunnel to the nCoA/nRA? I think it is decided by the L2 triggers you can get. If you can get L2-LD, sending packets via local link untill a L2 trigger can save bandwidth and cache. If you can not get L2-LD, you can only tunnel this packets to nAR. > > Q2. Would it be too much of an overhead if the oAR trasmitted the > packets both to the local link and through the tunnel for a while, till > it receives an ACK that traversing has been completed? > > > 2. Q. How can a MN or an oAR possibly have topoloical information of > where they are heading to, so as to be able to trigger the fast handoff > mechanism? > > > 3. Q. Up untill section 3.5.2 in the document (that I read), there is > nowhere mentioned that the aAR may be the HA. Instead it is constantly > implied that the HA is different from the oAR or the aAR. Is that > correct? If yes why? I think aAR and oAR do the HA function for aCoA or oCoA while they tunnel packets to mobile node. But they need not to do all the HA function. > > > 4. Some typos, I suppose, in 3.1.1, 3.1.3, 3.1.8, are that F-BU is > often used to mean F-BAck. If I have misanderstood and an AR can > indeed send F-BUs to the MN, then the typo is in the description of > the F-BU. I also think so. There are many clerical error? > > > > Regards > > .Manolis From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 14 22:03:07 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25772 for ; Sun, 14 Apr 2002 22:03:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29286; Sun, 14 Apr 2002 19:02:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21109; Sun, 14 Apr 2002 19:00:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3F1xpIA024955 for ; Sun, 14 Apr 2002 18:59:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3F1xpbb024954 for mobile-ip-dist; Sun, 14 Apr 2002 18:59:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3F1xmIA024947 for ; Sun, 14 Apr 2002 18:59:48 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23520 for ; Sun, 14 Apr 2002 18:59:51 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27679 for ; Sun, 14 Apr 2002 19:59:50 -0600 (MDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA05376 for ; Mon, 15 Apr 2002 10:59:49 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA01849; Mon, 15 Apr 2002 10:59:49 +0900 (JST) Date: Mon, 15 Apr 2002 10:59:31 +0900 (JST) Message-Id: <20020415.105931.77845727.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] backward compatibility From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I have a question about the backward(?) compatibility issue of MIP6. Some OSes are being shipped with a minimum CN function today. They understand HAO option and process it as described in the ID-15 or before. Now we have ID-16 (and soon ID-17), that prohibits processing HAO option without BCEs. The new draft doesn't mention how to handle the old MIP6 nodes, and of cource, the old MIP6 nodes know nothing about the new spec. They are potentially reflection attackers. How should we do? Can we just ignore them and wait the vendors to support new MIP6 features? --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 00:53:35 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28595 for ; Mon, 15 Apr 2002 00:53:30 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08589; Sun, 14 Apr 2002 21:52:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA21495; Sun, 14 Apr 2002 21:52:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3F4pvIA025223 for ; Sun, 14 Apr 2002 21:51:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3F4pvfu025222 for mobile-ip-dist; Sun, 14 Apr 2002 21:51:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3F4psIA025215 for ; Sun, 14 Apr 2002 21:51:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA02076 for ; Sun, 14 Apr 2002 21:51:57 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04884 for ; Sun, 14 Apr 2002 22:51:57 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3F3hcK15077; Sun, 14 Apr 2002 22:43:38 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3T4LN3>; Sun, 14 Apr 2002 22:43:46 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCBC5@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Steven M. Glass'" Cc: "'mobile-ip'" Subject: RE: [mobile-ip] Question about the I Bit in the Revocation Acknow ledgement Messag e Date: Sun, 14 Apr 2002 22:43:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E42F.BDCD0390" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E42F.BDCD0390 Content-Type: text/plain; charset="iso-8859-1" Hello Steve; Thanks again. But I am interested in keeping the discussion. I hope you do not mind. Ahmad > > > > Ahmad, > > > > > > Actually, there is (but it's not what you expect). > Since there's a > > > constraint in the base protocol that a home agent can't generate a > > > 'registration request' that is NOT in response to a > > > 'registration reply' it > > > means that the MN will not be in a state to receive any > > > registration messages. > > > I don't want this to change, since it means a significant > change in MN > > > architecture. > > > > Well, does this mean that MN can not receive a MIP RRQ > message or any kind > > of request. > > I presume you mean RRP, but at any rate it means the MN > is likely to > discard anything it does receive (of course depending on the > implementation, > but most I've seen use a state machine approach, and are only > listenning when > they're expecting a RRP). We could e.g. specify a different > port for these > messages, and have the FA relay them to the MN (note the > colocated MN already > gets these messages directly), but again this complicates > both FA and MN the > implementations. For the same functionality, I see it as > unnecessary (see > below). > I am sure that legacy MN is listenning when expecting RRP, ONLY. But MN could listen to for example some kind of Revocation request. It seems that the current approach requires the Co-located MN to do almost the same work as FA while it receives a secure information. However, MN registered with FA COA is not supposed to implement any thing but the messaging is not secure. I agree, if FA needs to forward a revocation request all the way to the MN, it would complicate the FA functionality a little bit more than what the current proposal has. However, there are two points that can be mentioned here: 1. This process is (relatively speaking) rarely used. In other words, It is not as expensinve as the MIP Registration. 2. The current approach requires the FA for example to remember those MN which are permanently revoked and this is very expensive for the FA to keep track with too. > > > >As I said, there is more secure end2end > > > solution, and that is > > > what happens after the revocation. If the FA notifies the MN > > > its binding has > > > been lost, or certainly when the binding would normally > > > expire, the MN will > > > [likely] attempt to reregister. > > > > Would not be nice if we inform the MN why it lost its binding? > > It seems to me that we are using a mechanism that was meant > to be rarely > > used, > > in case of rebooting the FA, to inform the MN that its > registration is > > revoked. > > Well, rarely used or not, it serves this communication > purpose (without > the 'why'). Yes, I'd prefer if the unicast 'I lost your > binding' messages > were secure, but someone could already forge these, and if > they are forged, if > the MN immediately reregisters, it'll get its registration > back; this solution > doesn't leave the MN more prone to these attacks. > > Note that there could be reasons for the FA or the HA to > want the MN > informed that its binding is lost, but not tell it why (e.g. > a simple 'minimal > information' approach, or perhaps 'feign outage', etc). > [Re]using this > mechanism does that initially, and if there's more > information to be had by > the MN, it gets provided at reregistration time. Note also > that colocated MNs > that support registration revocation can get the information > directly from the > HA, so if this is what you want, it's motivation to support > colocation! There > are usually multiple approaches to a solution, and I'm not > sure this is > something significantly lacking in this particular approach. > > Cheers, > Steve > I am sure it is a good idea to offer an end-to-end solution MN to HA which can be used for this revocation just as the co-located and may be those legacy MN can expect to recieve AA message with sequence number rolling back to 0 or they have the option to discard the message. Thanks, Ahmad ------_=_NextPart_001_01C1E42F.BDCD0390 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Question about the I Bit in the Revocation Acknow ledgement Messag e

Hello Steve;
Thanks again.

But I am interested in keeping the discussion.
I hope you do not mind.

Ahmad

>
> > >     Ahmad,
> > >
> > >    Actually, there is (but it's not what you expect). 
> Since there's a
> > > constraint in the base protocol that a home agent can't generate a
> > > 'registration request' that is NOT in response to a
> > > 'registration reply' it
> > > means that the MN will not be in a state to receive any
> > > registration messages.
> > > I don't want this to change, since it means a significant
> change in MN
> > > architecture. 
> >
> > Well, does this mean that MN can not receive a MIP RRQ
> message or any kind
> > of request.
>
>     I presume you mean RRP, but at any rate it means the MN
> is likely to
> discard anything it does receive (of course depending on the
> implementation,
> but most I've seen use a state machine approach, and are only
> listenning when
> they're expecting a RRP).  We could e.g. specify a different
> port for these
> messages, and have the FA relay them to the MN (note the
> colocated MN already
> gets these messages directly), but again this complicates
> both FA and MN the
> implementations.  For the same functionality, I see it as
> unnecessary (see
> below).
>

I am sure that legacy MN is listenning when expecting RRP, ONLY.
But MN could listen to for example some kind of Revocation request.
It seems that the current approach requires the Co-located MN to do
almost the same work as FA while it receives a secure information.
However, MN registered with FA COA is not supposed to implement
any thing but the messaging is not secure.

I agree, if FA needs to forward a revocation request all the way to the
MN, it would complicate the FA functionality a little bit more than what
the current proposal has.

However, there are two points that can be mentioned here:

1. This process is (relatively speaking) rarely used. In other words,
It is not as expensinve as the MIP Registration.
2. The current approach requires the FA for example to remember
those MN which are permanently revoked and this is very expensive
for the FA to keep track with too.

>
> > >As I said, there is more secure end2end
> > > solution, and that is
> > > what happens after the revocation.  If the FA notifies the MN
> > > its binding has
> > > been lost, or certainly when the binding would normally
> > > expire, the MN will
> > > [likely] attempt to reregister. 
> >
> > Would not be nice if we inform the MN why it lost its binding?
> > It seems to me that we are using a mechanism that was meant
> to be rarely
> > used,
> > in case of rebooting the FA, to inform the MN that its
> registration is
> > revoked.
>
>     Well, rarely used or not, it serves this communication
> purpose (without
> the 'why').  Yes, I'd prefer if the unicast 'I lost your
> binding' messages
> were secure, but someone could already forge these, and if
> they are forged, if
> the MN immediately reregisters, it'll get its registration
> back; this solution
> doesn't leave the MN more prone to these attacks.
>
>     Note that there could be reasons for the FA or the HA to
> want the MN
> informed that its binding is lost, but not tell it why (e.g.
> a simple 'minimal
> information' approach, or perhaps 'feign outage', etc). 
> [Re]using this
> mechanism does that initially, and if there's more
> information to be had by
> the MN, it gets provided at reregistration time.  Note also
> that colocated MNs
> that support registration revocation can get the information
> directly from the
> HA, so if this is what you want, it's motivation to support
> colocation!  There
> are usually multiple approaches to a solution, and I'm not
> sure this is
> something significantly lacking in this particular approach.
>
>                               Cheers,
>                                   Steve
>

I am sure it is a good idea to offer an end-to-end solution MN to HA which
can be used for this revocation just as the co-located and may be those
legacy MN can expect to recieve AA message with sequence number rolling back
to 0 or they have the option to discard the message.

Thanks,
Ahmad

------_=_NextPart_001_01C1E42F.BDCD0390-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 07:27:29 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12942 for ; Mon, 15 Apr 2002 07:27:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29590; Mon, 15 Apr 2002 04:26:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01558; Mon, 15 Apr 2002 04:26:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FBPnIA025846 for ; Mon, 15 Apr 2002 04:25:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FBPnCB025845 for mobile-ip-dist; Mon, 15 Apr 2002 04:25:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FBPkIA025838 for ; Mon, 15 Apr 2002 04:25:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10245 for ; Mon, 15 Apr 2002 04:25:48 -0700 (PDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA22356 for ; Mon, 15 Apr 2002 05:25:48 -0600 (MDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 04:25:47 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Apr 2002 04:25:47 -0700 Received: from red-msg-09.redmond.corp.microsoft.com ([157.54.12.7]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 04:25:46 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? Date: Mon, 15 Apr 2002 04:25:46 -0700 Message-ID: Thread-Topic: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? thread-index: AcHj0BfjgbqnOqxyTwC1yy7L9joTDQAmG/hg From: "Tuomas Aura" To: Cc: X-OriginalArrivalTime: 15 Apr 2002 11:25:46.0915 (UTC) FILETIME=[49D37730:01C1E470] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3FBPkIA025839 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jari Arkko wrote: > How about this: we don't provide any authentication of > the CN in the sense that all the messages be tied to each > other in some manner. But we provide a simple send cookie > - return cookie for each of the request - response pairs > in the protocol. We also delete the MAC field from the BA > and BR, and only keep the response cookie. Yes, I was almost going to suggest this. The advantage of simple cookies instead of a MAC for the BA/BR "authentication" is that the protocol and its limitations are much easier to understand. The disadvantage is that the simple cookie mechanism is clearly a little bit less secure. I'm not yet sure which solution is the best one but the simple cookie mechanisms looks much cleaner. I challenge everyone to compare the following alternative protocols and explain to themselves the exact differences between them. (1) Jari's protocol: 1a. MN(HoA) -> CN: HoTI(HoA, C0) 1b. MN(CoA) -> CN: CoTI(CoA, C1) 2a. CN -> MN(HoA): HoT(C0, K0, j) 2b. CN -> MN(CoA): CoT(C1, K1, i) 3. MN(CoA) -> CN: BU(HoA, CoA, C2, MAC_Kbu, j, i) 4. CN -> MN(CoA): BA(C2, MAC_Kbu) 5. CN -> MN(HoA): BR(C2, MAC_Kbu) Kbu= H(K0 | K1) (2) Protocol (1) without the cookies C0 and C1. 1a. MN(HoA) -> CN: HoTI(HoA) 1b. MN(CoA) -> CN: CoTI(CoA) 2a. CN -> MN(HoA): HoT(K0, j) 2b. CN -> MN(CoA): CoT(K1, i) (3) Protocol (1) without MACs on BA/BR. 4. CN -> MN(CoA): BA(C2) 5. CN -> MN(HoA): BR(C2) Here is my analysis of the above protocols: Clearly, (1) is the most secure one. BA/BR are authenticated with the same or almost the same strength as the BU. The curious thing with protocol (1) is that removing the cookies C0 and C1 from messages 1a/b and 2a/b makes the MAC_Kbu in BA/BR completely worthless. Without the cookies C0 and C1, the attacker can spoof messages 2a and 2b and thereby decide the value of Kbu. Therefore, the simple cookie mechanism of protocol (3) without the MACs in BA/BR is at least as secure as protocol (2). Obviously, the choice is between protocols (1) and (3). Currently I prefer (3) because I think most people will never understand why protocol (1) is slightly better. (I barely do myself.) I believe that the added security of protocol (1) is not worth much if the majority of protocol engineers never understand it. If someone is in favour of protocol (1) instead of (3), I challenge them to prove that protocol (1) is equivalent to protocol (4) below. A formal proof might influence my preferences. (4) Protocol (1) but BA/BR authenticated with Kba. 4. CN -> MN(CoA): BA(C2, MAC_Kba) 5. CN -> MN(HoA): BR(C2, MAC_Kba) Kba= H(C0 | C1) I think protocol (4) gives the same level of routing-based authentication for BA/BR as we already have for BU. I think this is fairly obvious. Note, however, that protocol (4) is not a realistic option because the correspondent would have to be stateful and remember either C0 and C1 or Kba. Tuomas From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 08:34:10 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14954 for ; Mon, 15 Apr 2002 08:34:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13518; Mon, 15 Apr 2002 06:33:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18642; Mon, 15 Apr 2002 05:33:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FCWqIA026037 for ; Mon, 15 Apr 2002 05:32:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FCWq4M026036 for mobile-ip-dist; Mon, 15 Apr 2002 05:32:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FCWnIA026029 for ; Mon, 15 Apr 2002 05:32:49 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14668 for ; Mon, 15 Apr 2002 05:32:53 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25053 for ; Mon, 15 Apr 2002 05:32:52 -0700 (PDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA28093 for ; Mon, 15 Apr 2002 21:32:51 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA20273; Mon, 15 Apr 2002 21:32:51 +0900 (JST) Date: Mon, 15 Apr 2002 21:32:31 +0900 (JST) Message-Id: <20020415.213231.64449083.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #16: unrecognized MH From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <200204120021.g3C0LC35258500@jurassic.eng.sun.com> References: <200204120021.g3C0LC35258500@jurassic.eng.sun.com> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: Samita Chakrabarti Content-Transfer-Encoding: 7bit > > > b) If a CN MUST support route optimization, then the spec should > > clarify that. How about adding a subsection in section 7 to > > clarify "Requirements for IPv6 Correspondent nodes" ? > > > > > > The draft should also clarify that OLD IPv6 nodes (without Mobility support) > should send 'mobility header unknown' message as an indication that they don't > support CN functionality for MIPv6. What is 'mobility header unknown'? I think the old IPv6 node need not to be modified. They will send 'ICMPv6 parameter problem' with 'unknown next header value' type. We can easily detect the node can't understand MIP6. # modifing all old ipv6 nodes is unrealistic to me. Instead, I propose to specify that the MN must use the bi-directional tunneling when it receives the above error (ICMPv6 paramprob, NH) against any of the mobility header. --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 08:53:18 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15669 for ; Mon, 15 Apr 2002 08:53:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02231; Mon, 15 Apr 2002 05:52:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18331; Mon, 15 Apr 2002 05:51:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FCp9IA026170 for ; Mon, 15 Apr 2002 05:51:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FCp9S5026169 for mobile-ip-dist; Mon, 15 Apr 2002 05:51:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FCp6IA026162 for ; Mon, 15 Apr 2002 05:51:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18159 for ; Mon, 15 Apr 2002 05:51:10 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24163 for ; Mon, 15 Apr 2002 06:51:09 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0FDE66A901; Mon, 15 Apr 2002 15:51:03 +0300 (EEST) Message-ID: <3CBACCDB.30007@piuha.net> Date: Mon, 15 Apr 2002 15:51:39 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #16: unrecognized MH References: <200204120021.g3C0LC35258500@jurassic.eng.sun.com> <20020415.213231.64449083.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: > What is 'mobility header unknown'? One, the MH protocol could be unknown to the recipient. This is clearly a job for ICMP. Two, the message type field (MH Type) inside the MH could be unknown to the recipient, perhaps due to an extension that the recipient doesn't support. We've been discussing whether that can be reported by ICMP, BA, or a special MH Error message. It seems that most people think ICMP Parameter Problem can be used. The only thing in this solution is that the receiver of the error message must take care in looking at what octet is being pointed to as the error. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 09:04:07 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16043 for ; Mon, 15 Apr 2002 09:04:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07637; Mon, 15 Apr 2002 06:03:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21636; Mon, 15 Apr 2002 06:03:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FD2XIA026279 for ; Mon, 15 Apr 2002 06:02:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FD2XrQ026278 for mobile-ip-dist; Mon, 15 Apr 2002 06:02:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FD2UIA026271 for ; Mon, 15 Apr 2002 06:02:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21385 for ; Mon, 15 Apr 2002 06:02:34 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08089 for ; Mon, 15 Apr 2002 06:02:33 -0700 (PDT) Received: from mbb4.ericsson.se (mbb4.ericsson.se [136.225.152.56]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3FD2W3G022148 for ; Mon, 15 Apr 2002 15:02:33 +0200 (MEST) Received: from era.ericsson.se (rcur34ip94.ericsson.se [147.214.34.94]) by mbb4.ericsson.se (PMDF V5.2-33 #39350) with ESMTP id <0GUM00ALE1K8KB@mbb4.ericsson.se> for mobile-ip@sunroof.eng.sun.com; Mon, 15 Apr 2002 15:02:32 +0200 (MET DST) Date: Mon, 15 Apr 2002 15:02:30 +0200 From: Martti Kuparinen Subject: [mobile-ip] padding problems in v16 To: mobile-ip@sunroof.eng.sun.com Message-id: <3CBACF66.3050806@era.ericsson.se> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-15 Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi! I think I found two errors in the MIPv6 draft: 5.1.3 Home Test Init - no padding is really needed 5.1.8 Binding Acknowledge - padding is really needed Or am I missing something here? Martti --- draft-ietf-mobileip-ipv6-16.txt.orig Mon Apr 15 14:52:07 2002 +++ draft-ietf-mobileip-ipv6-16.txt Mon Apr 15 14:55:58 2002 @@ -2339,9 +2339,8 @@ - Unique Identifier Parameter - If no actual parameters are present in this message, 4 bytes of Pad1 - or PadN parameters are needed to make the length of the message a - multiple of 8. + If no actual parameters are present in this message, no padding is + necessary. The HoTI message SHOULD be protected by an IPsec policy that employs ESP between the home agent and the mobile node. @@ -3111,8 +3110,9 @@ specification does not define any parameters valid for the Binding Acknowledgement message. - If no actual parameters are present in this message, no padding is - needed. + If no actual parameters are present in this message, 4 bytes of Pad1 + or PadN parameters are needed to make the length of the message a + multiple of 8. The Binding Acknowledgement is sent to the source address of the Binding Update message, regardless of whether the Binding Update From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 11:06:51 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19951 for ; Mon, 15 Apr 2002 11:06:50 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13708; Mon, 15 Apr 2002 08:06:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20488; Mon, 15 Apr 2002 08:06:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FF5LIA026564 for ; Mon, 15 Apr 2002 08:05:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FF5Lrb026563 for mobile-ip-dist; Mon, 15 Apr 2002 08:05:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FF5IIA026556 for ; Mon, 15 Apr 2002 08:05:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19989 for ; Mon, 15 Apr 2002 08:05:21 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00955 for ; Mon, 15 Apr 2002 09:05:20 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0C5FA6A901; Mon, 15 Apr 2002 18:05:20 +0300 (EEST) Message-ID: <3CBAEC55.5060105@piuha.net> Date: Mon, 15 Apr 2002 18:05:57 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Martti Kuparinen Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] padding problems in v16 References: <3CBACF66.3050806@era.ericsson.se> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Martti Kuparinen wrote: > Hi! > > I think I found two errors in the MIPv6 draft: > > 5.1.3 Home Test Init > - no padding is really needed > > 5.1.8 Binding Acknowledge > - padding is really needed > > Or am I missing something here? No, you're quite right. I think someone brought a similar issue earlier but the next version will fix these. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 16:27:03 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05898 for ; Mon, 15 Apr 2002 16:27:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14539; Mon, 15 Apr 2002 13:26:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08344; Mon, 15 Apr 2002 13:26:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FKPNIA027166 for ; Mon, 15 Apr 2002 13:25:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FKPNdx027165 for mobile-ip-dist; Mon, 15 Apr 2002 13:25:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FKPLIA027158 for ; Mon, 15 Apr 2002 13:25:21 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26301 for ; Mon, 15 Apr 2002 16:25:25 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA02183 for mobile-ip@sunroof.eng.sun.com; Mon, 15 Apr 2002 16:26:23 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3DI83IA023404 for ; Sat, 13 Apr 2002 11:08:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01606 for ; Sat, 13 Apr 2002 11:08:05 -0700 (PDT) Received: from web13402.mail.yahoo.com (web13402.mail.yahoo.com [216.136.175.60]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA03649 for ; Sat, 13 Apr 2002 12:08:05 -0600 (MDT) Message-ID: <20020413180804.28715.qmail@web13402.mail.yahoo.com> Received: from [24.124.60.64] by web13402.mail.yahoo.com via HTTP; Sat, 13 Apr 2002 11:08:04 PDT Date: Sat, 13 Apr 2002 11:08:04 -0700 (PDT) From: Guru P Subject: [mobile-ip] NAT traversal for mobile IP using UDP tunneling implementation To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: To All, I have a implementation of UDP tunneling for Mobile IP that does NAT traversal at: http://people.eecs.ku.edu/~pai/801/index.html Anybody interested at all? If somebody does have a look at it I would like to get some useful comments and suggestions. Thanks Guru __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 17:36:42 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07274 for ; Mon, 15 Apr 2002 17:36:41 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24386; Mon, 15 Apr 2002 14:35:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01865; Mon, 15 Apr 2002 14:35:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FLYpIA027492 for ; Mon, 15 Apr 2002 14:34:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FLYpbK027491 for mobile-ip-dist; Mon, 15 Apr 2002 14:34:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FLYmIA027484 for ; Mon, 15 Apr 2002 14:34:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13420 for ; Mon, 15 Apr 2002 14:34:51 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21487 for ; Mon, 15 Apr 2002 15:34:51 -0600 (MDT) 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 OAA04043; Mon, 15 Apr 2002 14:34:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3FLYls03612; Mon, 15 Apr 2002 14:34:47 -0700 X-mProtect: <200204152134> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd251z7h; Mon, 15 Apr 2002 14:34:46 PDT Message-ID: <3CBB4776.44793A6B@iprg.nokia.com> Date: Mon, 15 Apr 2002 14:34:46 -0700 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: Tuomas Aura CC: mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Before going ahead, we need to separate BA and BR. BA is sent immediately after the RR/BU messages. BR is sent much later (in fact just before RR Binding is about to expire). According Jari, section 11 is going to recommend a cookie lifetime (for C2) which is much less than the RR Binding Lifetime. Your C2 would have expired long before the binding expires. C2 can be used for BA, but not for BR, IMO. regards Vijay Tuomas Aura wrote: > > Jari Arkko wrote: > > > How about this: we don't provide any authentication of > > the CN in the sense that all the messages be tied to each > > other in some manner. But we provide a simple send cookie > > - return cookie for each of the request - response pairs > > in the protocol. We also delete the MAC field from the BA > > and BR, and only keep the response cookie. > > Yes, I was almost going to suggest this. > > The advantage of simple cookies instead of a MAC for the > BA/BR "authentication" is that the protocol and its > limitations are much easier to understand. The disadvantage > is that the simple cookie mechanism is clearly a little bit > less secure. I'm not yet sure which solution is the best one > but the simple cookie mechanisms looks much cleaner. > > I challenge everyone to compare the following alternative > protocols and explain to themselves the exact differences > between them. > > (1) Jari's protocol: > 1a. MN(HoA) -> CN: HoTI(HoA, C0) > 1b. MN(CoA) -> CN: CoTI(CoA, C1) > 2a. CN -> MN(HoA): HoT(C0, K0, j) > 2b. CN -> MN(CoA): CoT(C1, K1, i) > 3. MN(CoA) -> CN: BU(HoA, CoA, C2, MAC_Kbu, j, i) > 4. CN -> MN(CoA): BA(C2, MAC_Kbu) > 5. CN -> MN(HoA): BR(C2, MAC_Kbu) > Kbu= H(K0 | K1) > > (2) Protocol (1) without the cookies C0 and C1. > 1a. MN(HoA) -> CN: HoTI(HoA) > 1b. MN(CoA) -> CN: CoTI(CoA) > 2a. CN -> MN(HoA): HoT(K0, j) > 2b. CN -> MN(CoA): CoT(K1, i) > > (3) Protocol (1) without MACs on BA/BR. > 4. CN -> MN(CoA): BA(C2) > 5. CN -> MN(HoA): BR(C2) > > Here is my analysis of the above protocols: > Clearly, (1) is the most secure one. BA/BR are > authenticated with the same or almost the same > strength as the BU. The curious thing with protocol > (1) is that removing the cookies C0 and C1 from > messages 1a/b and 2a/b makes the MAC_Kbu in BA/BR > completely worthless. Without the cookies C0 and C1, > the attacker can spoof messages 2a and 2b and thereby > decide the value of Kbu. Therefore, the simple cookie > mechanism of protocol (3) without the MACs in BA/BR > is at least as secure as protocol (2). > > Obviously, the choice is between protocols (1) and (3). > Currently I prefer (3) because I think most people > will never understand why protocol (1) is slightly > better. (I barely do myself.) I believe that the added > security of protocol (1) is not worth much if the > majority of protocol engineers never understand it. > > If someone is in favour of protocol (1) instead of (3), > I challenge them to prove that protocol (1) is > equivalent to protocol (4) below. A formal proof > might influence my preferences. > > (4) Protocol (1) but BA/BR authenticated with Kba. > 4. CN -> MN(CoA): BA(C2, MAC_Kba) > 5. CN -> MN(HoA): BR(C2, MAC_Kba) > Kba= H(C0 | C1) > > I think protocol (4) gives the same level of > routing-based authentication for BA/BR as we already > have for BU. I think this is fairly obvious. Note, > however, that protocol (4) is not a realistic option > because the correspondent would have to be stateful > and remember either C0 and C1 or Kba. > > Tuomas From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 18:05:07 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07708 for ; Mon, 15 Apr 2002 18:05:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04338; Mon, 15 Apr 2002 15:04:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11709; Mon, 15 Apr 2002 15:04:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FM3XIA027671 for ; Mon, 15 Apr 2002 15:03:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FM3XJK027670 for mobile-ip-dist; Mon, 15 Apr 2002 15:03:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FM3TIA027663 for ; Mon, 15 Apr 2002 15:03:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11399 for ; Mon, 15 Apr 2002 15:03:33 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03781 for ; Mon, 15 Apr 2002 15:03:33 -0700 (PDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3FM3FI08249; Mon, 15 Apr 2002 15:03:15 -0700 (PDT) Message-ID: <020001c1e4c9$1e055570$7e6015ac@T23KEMPF> From: "James Kempf" To: "Vijay Devarapalli" , "Tuomas Aura" Cc: , References: <3CBB4776.44793A6B@iprg.nokia.com> Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? Date: Mon, 15 Apr 2002 15:01:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > According Jari, section 11 is going to recommend a cookie > lifetime (for C2) which is much less than the RR Binding > Lifetime. Your C2 would have expired long before the > binding expires. > Is this necessary? It would be good if the lifetime of the RR would suffice to do multiple handovers. Don't the cookie lifetime and RR lifetime have to be the same for this to be so? It would also be useful if the MN could do RR somewhat prior to the BU, then be able to issue BUs as needed. This avoids having the prerformance of the posthandover routing update change depend on the security step. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 18:24:40 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08160 for ; Mon, 15 Apr 2002 18:24:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17754; Mon, 15 Apr 2002 15:24:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18559; Mon, 15 Apr 2002 15:23:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FMN8IA027786 for ; Mon, 15 Apr 2002 15:23:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FMN8Jp027783 for mobile-ip-dist; Mon, 15 Apr 2002 15:23:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FMN4IA027775 for ; Mon, 15 Apr 2002 15:23:05 -0700 (PDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3FMN7g09209; Mon, 15 Apr 2002 18:23:07 -0400 (EDT) Date: Mon, 15 Apr 2002 18:24:06 -0400 (EDT) From: "Steven M. Glass" Reply-To: "Steven M. Glass" Subject: RE: [mobile-ip] Question about the I Bit in the Revocation Acknow ledgement Messag e To: Ahmad Muhanna Cc: "'mobile-ip'" In-Reply-To: "Your message with ID" <6B49EDFE974BD51197D70002A56079D801AFCBC5@zrc2c013.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Hello Steve; > Thanks again. > > But I am interested in keeping the discussion. > I hope you do not mind. Hey - this is why we're all here! > I am sure that legacy MN is listenning when expecting RRP, ONLY. > But MN could listen to for example some kind of Revocation request. Already deployed MNs never will. Note also that revocations are never requests! They're provided only if the policy on the other side allows/requires the update on the binding (e.g. for billing reasons). > It seems that the current approach requires the Co-located MN to do > almost the same work as FA while it receives a secure information. This is a byproduct of the colocation, not because of anything this document outlines for revocation support. MNs are their own FAs in terms of obtaining a CoA, decapsulation, and encapsulation in the case of a reverse tunnel. > However, MN registered with FA COA is not supposed to implement > any thing but the messaging is not secure. The signal from the FA is not secure. Any follow up response (if provided) from the HA will be, as will be any from an FA with which the MN has a SA (FA-MN authenticator). Would you feel better with the draft if it said "upon receiving an agent advertisement sent to the MNs unicast address from a foreign agent with which it has a current binding in which the sequence number is set to 0, the MN SHOULD attempt to reregister, either with "? This is the presumed behavior of all MNs anyway whenever they receive an agent advertisement with sequence number implying a loss of state from the FA through which they have a binding. > I agree, if FA needs to forward a revocation request all the way to the > MN, it would complicate the FA functionality a little bit more than what > the current proposal has. > > However, there are two points that can be mentioned here: > > 1. This process is (relatively speaking) rarely used. In other words, > It is not as expensinve as the MIP Registration. I don't see the relevance here. Added complexity is arguably worse when the feature is used more rarely and a simpler mechanism is availabl. I would argue that this is more expensive than the MIP deregistration (because it potentially requires the FA to unicast an advertisement after receiving the equivalent of "deregistration" notice), but I don't see the relevance there, either. > 2. The current approach requires the FA for example to remember > those MN which are permanently revoked and this is very expensive > for the FA to keep track with too. I presume you only mean the 'unconditional' revocations, those where I say the binding is consider revoked unconditionally, and thereby no reregistration will be allowed. In actuallity, remembering this is actually up to the implementation. It's true to say more generally that whomever made the decision to revoke needs to remember, but that doesn't mean it's the FA. Perhaps this comes down to just a wording change in the document, making the idea of "state" clearly implementation specific. There are two possiblities: Revok came from the home subnet. In this case the FA could remember because if the MN reregisters, it can either know to just deny the registration, or it can keep state for the pending registration. Either way, there is no risk of the MN getting a binding, because the decision to revok was not made here. Defering to the 'authority' which revoked the binding is perhaps the right thing to do anyway. Revok came from the foreign subnet. In this case the FA got an indication to "suddenly" revoke this registration either from another authority in its domain, or it's done this itself (e.g. user-intervention, the MN repeatedly failed authentication, etc). In the former case, the FA could remember because if the MN reregisters it can either deny, or keep state for the pending registration. In the later case, note it implies there's already state in the FA. Since it's up to the implementation, would you prefer if I either specified where these decisions are implementation-specific, or would you prefer if I lost the notion of 'unconditional' revocation altogether? Note that all revocation messages MUST be secured using an HA-FA authenticator, or equivalent mechanism, so there's "no" (added) risk that someone could get the FA to continue to deny registrations by pretending to be the HA revoking unconditionally. > I am sure it is a good idea to offer an end-to-end solution MN to HA which > can be used for this revocation just as the co-located and may be those > legacy MN can expect to recieve AA message with sequence number rolling back > to 0 or they have the option to discard the message. They should never be discarding these. They can if they want, but if the FA has actually lost its state, it *will* be ignoring any encapsulated packets for the MN. The MN needs to reclaim its binding if it wants to see any of them! Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 18:33:22 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08383 for ; Mon, 15 Apr 2002 18:33:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18212; Mon, 15 Apr 2002 15:32:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21631; Mon, 15 Apr 2002 15:32:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FMW3IA027877 for ; Mon, 15 Apr 2002 15:32:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FMW3OT027876 for mobile-ip-dist; Mon, 15 Apr 2002 15:32:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FMW0IA027869 for ; Mon, 15 Apr 2002 15:32:00 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10318 for ; Mon, 15 Apr 2002 15:32:03 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15997 for ; Mon, 15 Apr 2002 16:32:02 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 45CB26A901; Tue, 16 Apr 2002 01:31:55 +0300 (EEST) Message-ID: <3CBB54FF.6050005@piuha.net> Date: Tue, 16 Apr 2002 01:32:31 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: Tuomas Aura , mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <3CBB4776.44793A6B@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Before going ahead, we need to separate BA and BR. BA is > sent immediately after the RR/BU messages. BR is sent much > later (in fact just before RR Binding is about to expire). > According Jari, section 11 is going to recommend a cookie > lifetime (for C2) which is much less than the RR Binding > Lifetime. Your C2 would have expired long before the > binding expires. > > C2 can be used for BA, but not for BR, IMO. Cookie lifetimes that we have been talking about so far have been the CN cookies K0 and K1. The lifetime of these needs to be limited, to limit "future" in the future attack. The cookies from the MN, C0, C1, and C2 however are an independent matter. What is the right lifetime for them? Obviously it doesn't make sense to have a lifetime for C0 or C1 that is longer than the retranmission failure timeout. C2 could have a lifetime that simply matches the BCE lifetime. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 18:39:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08634 for ; Mon, 15 Apr 2002 18:39:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26171; Mon, 15 Apr 2002 16:38:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27324; Mon, 15 Apr 2002 15:36:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FMZEIA027960 for ; Mon, 15 Apr 2002 15:35:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FMZEDV027959 for mobile-ip-dist; Mon, 15 Apr 2002 15:35:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FMZBIA027952 for ; Mon, 15 Apr 2002 15:35:11 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23072 for ; Mon, 15 Apr 2002 15:35:15 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22744 for ; Mon, 15 Apr 2002 16:35:14 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 247FC6A901; Tue, 16 Apr 2002 01:34:58 +0300 (EEST) Message-ID: <3CBB55B6.7060908@piuha.net> Date: Tue, 16 Apr 2002 01:35:34 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: Vijay Devarapalli , Tuomas Aura , mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <3CBB4776.44793A6B@iprg.nokia.com> <020001c1e4c9$1e055570$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > Is this necessary? It would be good if the lifetime of the RR > would suffice to do multiple handovers. Don't the cookie > lifetime and RR lifetime have to be the same for this to be so? The CN cookies K0 and K1 will have a specific lifetime, the exact value of which has been under debate. This cookie lifetime is the time period during which you must at the latest send your BU. Another time period is the maximum allowable BCE lifetime, which extends from that time onwards. > It would also be useful if the MN could do RR somewhat prior > to the BU, then be able to issue BUs as needed. This avoids > having the prerformance of the posthandover routing update > change depend on the security step. Yes. And the intention is to allow some lifetime for the CN cookies so that this, fast movements, and reuse of cookies for multiple bindings can be done. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 18:50:31 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08935 for ; Mon, 15 Apr 2002 18:50:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00721; Mon, 15 Apr 2002 15:49:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00652; Mon, 15 Apr 2002 15:49:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FMmmIA028208 for ; Mon, 15 Apr 2002 15:48:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FMmmIg028207 for mobile-ip-dist; Mon, 15 Apr 2002 15:48:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FMmjIA028200 for ; Mon, 15 Apr 2002 15:48:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15166 for ; Mon, 15 Apr 2002 15:48:49 -0700 (PDT) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23464 for ; Mon, 15 Apr 2002 16:48:48 -0600 (MDT) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.12.3/8.12.3) with ESMTP id g3FMqBK0005063; Tue, 16 Apr 2002 00:52:14 +0200 From: "Henrik Levkowetz" To: "Guru P" , Subject: RE: [mobile-ip] NAT traversal for mobile IP using UDP tunneling implementation Date: Tue, 16 Apr 2002 00:48:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020413180804.28715.qmail@web13402.mail.yahoo.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Gurunandan, It was interesting to read about your implementation of the NAT traversal draft (based on the -00 version, I note). A few questions and comments: Why do you set the 'U' flag in the request? This is not clear from your description. The 'U' flag should generally NOT be set, as the UDP tunnelling overhead gives no benefit at all if you don't need to get through a NAT, and by setting the 'U' flag you will be using UDP tunnelling even if there is no NAT in the path. Also note that in the -01 and -02 drafts, the 'U' flag in the UDP Tunnel Request Extension has been renamed to 'F' (force). The link to 'Decapsulation' at the bottom of your page giving 'Changes to Registration Mechanism' is broken. (there's a /801/ missing) Your text on the protocol number in the IP header of the encapsulation sounds as if there's a choice, when there really is none. If the next header after the IP header is a UDP header, the only possible value for the protocol number is 17. You set the UDP checksum to zero when encapsulating; this is permissible but not advisable. You're needlessly stripping yourself of some protection against corrupted packets here. I suspect this may be the result of time pressure? When talking about the decapsulation, you mention that after stripping off the outer IP/UDP encapsulation, you call vif_rx() to handle the inner IP/UDP payload. Please note that the inner payload may be IP with any type of payload, not only UDP. I suspect that this is just a textual mistake, and the code handles any payload. I believe that the manner in which you do decapsulation (stateful, and dependent on your MIP_UDP_TUN_ACCEPT flag) is unsafe. Decapsulation should be done based on the presence of the new MIP message type header, not on anything else. Finally, I note that you have only implemented UDP tunnelling of the forward tunnel, not of the reverse tunnel. This is not according to the draft, but may work if the re-registrations are made often enough that the mapping of the NAT does not time out, and the MN and HA is implemented consistently. Although not acceptable in a full implementation, it may possibly be acceptable in your project due to time limitations. It will probably not be interoperable with other implementations. I have not read through your code, so have no comments on that. If you were to polish this a bit, to adhere more strictly to the draft, it would be interesting to do an interop test with your implementation, seeing that your code is for Linux and available for download. Regards, Henrik > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Guru P > Sent: Saturday, April 13, 2002 8:08 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] NAT traversal for mobile IP using UDP tunneling > implementation > > > To All, > I have a implementation of UDP tunneling for Mobile IP > that does NAT traversal at: > http://people.eecs.ku.edu/~pai/801/index.html > Anybody interested at all? If somebody does have a > look at it I would like to get some useful comments > and suggestions. Thanks > Guru > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 19:27:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09390 for ; Mon, 15 Apr 2002 19:27:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07904; Mon, 15 Apr 2002 17:27:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09382; Mon, 15 Apr 2002 16:27:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FNQgIA028415 for ; Mon, 15 Apr 2002 16:26:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3FNQgm8028414 for mobile-ip-dist; Mon, 15 Apr 2002 16:26:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3FNQcIA028407 for ; Mon, 15 Apr 2002 16:26:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09146 for ; Mon, 15 Apr 2002 16:26:43 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12857 for ; Mon, 15 Apr 2002 16:26:43 -0700 (PDT) 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 QAA10748; Mon, 15 Apr 2002 16:26:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3FNQfb14637; Mon, 15 Apr 2002 16:26:41 -0700 X-mProtect: <200204152326> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDbBubH; Mon, 15 Apr 2002 16:26:40 PDT Message-ID: <3CBB61B1.402B8EE8@iprg.nokia.com> Date: Mon, 15 Apr 2002 16:26:41 -0700 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: jari.arkko@piuha.net CC: mobile-ip@sunroof.eng.sun.com Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <3CBB4776.44793A6B@iprg.nokia.com> <3CBB54FF.6050005@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Vijay Devarapalli wrote: > > > Before going ahead, we need to separate BA and BR. BA is > > sent immediately after the RR/BU messages. BR is sent much > > later (in fact just before RR Binding is about to expire). > > According Jari, section 11 is going to recommend a cookie > > lifetime (for C2) which is much less than the RR Binding > > Lifetime. Your C2 would have expired long before the > > binding expires. > > > > C2 can be used for BA, but not for BR, IMO. > > Cookie lifetimes that we have been talking about so > far have been the CN cookies K0 and K1. The lifetime > of these needs to be limited, to limit "future" in > the future attack. > > The cookies from the MN, C0, C1, and C2 however are > an independent matter. What is the right lifetime for > them? Obviously it doesn't make sense to have a lifetime > for C0 or C1 that is longer than the retranmission failure > timeout. > > C2 could have a lifetime that simply matches the BCE lifetime. That makes sense. Thanks. The lifetimes for C0/C1/C2 should be the same BCE lifetime. And for K0, K1, I still think we can have the same lifetime as BCE lifetime, without additional harm. thanks Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 15 22:24:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12213 for ; Mon, 15 Apr 2002 22:24:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10969; Mon, 15 Apr 2002 20:24:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15036; Mon, 15 Apr 2002 19:24:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3G2NNIA028801 for ; Mon, 15 Apr 2002 19:23:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3G2NNSo028800 for mobile-ip-dist; Mon, 15 Apr 2002 19:23:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3G2NKIA028793 for ; Mon, 15 Apr 2002 19:23:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28894 for ; Mon, 15 Apr 2002 19:23:24 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10627 for ; Mon, 15 Apr 2002 20:23:24 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <20R3S2Y5>; Mon, 15 Apr 2002 22:23:22 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3A3CC@ftmail> From: "Alan O'Neill" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Last Call: Regional Tunneling input Date: Mon, 15 Apr 2002 22:23:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Below is the abstract for the draft that makes last call suggestions on Regional tunneling. see http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mods-00.txt Abstract Regional Registration modifies the normal MIP Registration signalling back to the HA so that the signalling can traverse an intermediate Gateway Foreign Agent (GFA). The registered binding is between the Home Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the GFA. Two extensions are defined to support this new Registration processing these being the Hierarchical Foreign Agent extension (HFAext) and the GFA IP address extension (GFAIPext). The former is used to carry the FA CoA to the GFA and the latter is used by the FA to allocate a GFA to the MN, and by the FA, GFA, HA to securely return the GFA IP address to the MN. The present processing rules for the HA registration enable the FA to advertise the GFA to the MN in a Foreign Agent Advertisement (FAA) and for the MN to include that GFA address into the CoA field of the MIP home Registration. This however assumes a number of things about the GFA address in the FAA and the addressing realms between the FA-GFA and GFA- HA.. Specifically, the GFA CoA and the GFA IP address must potentially be from two different addressing plans and hence cannot be in the same FAA. This draft describes the issues and suggests a solution that requires slight modifications to the required extensions, that generalises the Home Registration signalling for arbitrary intermediate MIP nodes, and only slightly modifies the processing rules for the MIP Home Registration. This draft also describes a way to support dynamic HA allocation along-side Regional Registrations. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 07:51:22 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29874 for ; Tue, 16 Apr 2002 07:51:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00905; Tue, 16 Apr 2002 04:50:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12420; Tue, 16 Apr 2002 04:50:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GBnZIA029566 for ; Tue, 16 Apr 2002 04:49:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GBnZ7c029565 for mobile-ip-dist; Tue, 16 Apr 2002 04:49:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GBnWIA029558 for ; Tue, 16 Apr 2002 04:49:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13513 for ; Tue, 16 Apr 2002 04:49:35 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12681 for ; Tue, 16 Apr 2002 05:49:34 -0600 (MDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA25555 for ; Tue, 16 Apr 2002 20:49:33 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA28910; Tue, 16 Apr 2002 20:49:33 +0900 (JST) Date: Tue, 16 Apr 2002 20:49:11 +0900 (JST) Message-Id: <20020416.204911.64114141.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #16: Error message from an unknown MH Type From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3CB5E828.40500@piuha.net> References: <3CB5D41E.9070707@piuha.net> <3CB5EF9D.425A83DD@iprg.nokia.com> <3CB5E828.40500@piuha.net> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: Jari Arkko Content-Transfer-Encoding: 7bit > > 0 - erroneous header field encountere > 1 - unrecognized Next Header type encountered > 2 - unrecognized IPv6 option encountered > > 1 and 2 seem to be inappropriate. What about 0? A quick > look at the usage of code 0 on e.g. wrong routing header > type seems to match the usage here. So go for ICMP Parameter > Problem and Code 0 instead? I understand that returning an ICMPv6 parameter problem with type 0 is the most generic way. But if we do that, the MN side must chase an IP packet included in the ICMPv6 packet to check if the parameter problem error is caused by an unknown MH type or by some other header errors. If we define a new MH type which indicates an error, it's very easy to handle the error. We need not chase the contents of the IP packet which has caused the error. So, I perfer all MIP6 nodes must return a MH with type X (X indicates an error) and error code if they receive an unknown MH type. --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 09:22:25 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02308 for ; Tue, 16 Apr 2002 09:22:24 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11205; Tue, 16 Apr 2002 06:21:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07131; Tue, 16 Apr 2002 06:21:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GDJGIA029763 for ; Tue, 16 Apr 2002 06:19:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GDJG5b029762 for mobile-ip-dist; Tue, 16 Apr 2002 06:19:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GDJCIA029755 for ; Tue, 16 Apr 2002 06:19:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23184 for ; Tue, 16 Apr 2002 06:19:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10043 for ; Tue, 16 Apr 2002 06:19:16 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01762; Tue, 16 Apr 2002 09:19:12 -0400 (EDT) Message-Id: <200204161319.JAA01762@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-piggyback-00.txt Date: Tue, 16 Apr 2002 09:19:12 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Nonfinal Mobility Header for Mobile IPv6 Author(s) : C. Perkins, F. Dupont Filename : draft-ietf-mobileip-piggyback-00.txt Pages : 10 Date : 15-Apr-02 This document specifies operations to allow inclusion of data along with a mobility header (from Mobile IPv6) containing a Binding Update or Binding Acknowledgement message. In this way, smoother handovers and reduced jitter and bandwidth utilization can be achieved. Interactions with IPsec-based verification of mobility messages are described; basically, establishment of such IPsec-based methods preclude the use of the mobility header specified in this document, unless simple modifications to IPsec (outside the scope of this document) can be utilized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-piggyback-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-piggyback-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-piggyback-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020415112501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-piggyback-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-piggyback-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020415112501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 16:35:27 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15680 for ; Tue, 16 Apr 2002 16:35:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26638; Tue, 16 Apr 2002 13:34:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12043; Tue, 16 Apr 2002 13:34:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GKX8IA000537 for ; Tue, 16 Apr 2002 13:33:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GKX81Y000536 for mobile-ip-dist; Tue, 16 Apr 2002 13:33:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GKX5IA000529 for ; Tue, 16 Apr 2002 13:33:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24901 for ; Tue, 16 Apr 2002 13:33:09 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27540 for ; Tue, 16 Apr 2002 14:33:08 -0600 (MDT) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 61680400617 for ; Tue, 16 Apr 2002 13:33:08 -0700 (PDT) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id NAA25083 for ; Tue, 16 Apr 2002 13:34:12 -0700 (PDT) Date: Tue, 16 Apr 2002 13:34:11 -0700 (PDT) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Mobile IP Working Group Subject: [mobile-ip] Reg with FA COA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, RFC3220 says that a MN registering with a FA COA MUST send the registration request to the IP source of the advertisement. If the FA is multihomed and advertises multiple COAs, there is a possibility that the MN sends the request to an interface that is different from the COA. From what I have read in the RFC, it appears that it is okay for the FA to use the same interface to forward the request, instead of the COA requested. Am I correct? If so, is the FA-HA auth ext created/authenticated using the SA between the COA and the HA, or the forwarding address and the HA? Hope my questions make sense :-) thanks, Siva From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 16:40:25 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16176 for ; Tue, 16 Apr 2002 16:40:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00405; Tue, 16 Apr 2002 13:39:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14941; Tue, 16 Apr 2002 13:39:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GKcOIA000617 for ; Tue, 16 Apr 2002 13:38:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GKcOvn000616 for mobile-ip-dist; Tue, 16 Apr 2002 13:38:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GKcKIA000606 for ; Tue, 16 Apr 2002 13:38:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27496 for ; Tue, 16 Apr 2002 13:38:25 -0700 (PDT) Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03576 for ; Tue, 16 Apr 2002 13:38:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E586.9B46AA44" Subject: [mobile-ip] Clarrification in RFC 3012 for computing MN-AAA authenticator Date: Tue, 16 Apr 2002 16:38:03 -0400 Message-ID: Thread-Topic: Clarrification in RFC 3012 for computing MN-AAA authenticator Thread-Index: AcHlkCRYM228MEJiEdapNACw0CjhiA== From: "Gowri Makineni" To: Cc: , Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C1E586.9B46AA44 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was wondering if anyone could clarrify my doubt as to how to compute = the=20 MN-AAA authenticator as stated in Section 8. of RFC 3012. It states: To compute the authenticator, apply MD5 computed on the following data,=20 in the order shown:=20 High-order byte from Challenge || Key ||=20 MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) = ||=20 Least-order 237 bytes from Challenge I have the following questioins: #1. When we say Preceding Mobile IP data, do we also include the MN-FA = challenge in it? #2. Regarding the least-order 237 bytes from Challenge, if the challenge = has only 10 bytes, do we include all ten bytes (repeating the first one) ? #3. Why do we include the Challenge value of MN-FA challenge twice (if = the answer to question #1 is true, the first time we compute the MD5 on the = preceding Mobile IP Data and the second time we use that info to compute the overall = MN-AAA authenticator) ? #4. I am a little bit confused because in Section 3.2, Foreign Agent = Processing for=20 Registration Requests it says: "In the event that the Challenge extension is authenticated through the = Mobile-Foreign=20 Authentication Extension, the Foreign Agent MAY remove the Challenge = Extension=20 from the Registration Request without disturbing the authentication = value computed by=20 the Mobile Node for use by the AAA or the Home Agent. If the Challenge = extension=20 is not removed, it MUST precede the Foreign-Home Authentication = extension." My question is that if the FA removes the extension, will the = authenticator not be=20 affected whether the authenticator be computed based on section 6. or = section 8 if and only if the answer to question #1 is True ? Thanks for enlighting me in advance, -Gowri=20 ------_=_NextPart_001_01C1E586.9B46AA44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Clarrification in RFC 3012 for computing MN-AAA = authenticator

Hi,

I was wondering if anyone could clarrify my = doubt as to how to compute the
MN-AAA authenticator as stated in Section 8. of = RFC 3012.

It states:
To compute the authenticator, apply MD5 = computed on the following data,
in the order shown:
High-order byte from Challenge || Key || =
MD5(Preceding Mobile IP data || Type, Subtype = (if present), Length, SPI) ||
Least-order 237 bytes from Challenge

I have the following questioins:

#1. When we say Preceding Mobile IP data, do we = also include the MN-FA challenge in it?

#2. Regarding the least-order 237 bytes from = Challenge, if the challenge has only
   10 bytes, do we include all ten = bytes (repeating the first one) ?

#3. Why do we include the Challenge value of = MN-FA challenge twice (if the answer to
    question #1 is true, the = first time we compute the MD5 on the preceding Mobile IP
    Data and the second time we = use that info to compute the overall MN-AAA authenticator) ?

#4. I am a little bit confused because in = Section 3.2, Foreign Agent Processing for
    Registration Requests it = says:

"In = the event that the Challenge extension is authenticated through the = Mobile-Foreign
Authentication Extension, the Foreign = Agent MAY = remove the Challenge Extension
from the Registration Request without = disturbing the authentication value computed by
the Mobile Node for use by the AAA or the Home = Agent. If the Challenge extension
is not removed, it MUST precede the = Foreign-Home Authentication extension."

   My question is that if the FA = removes the extension, will the authenticator not be
   affected whether the authenticator = be computed based on section 6. or section 8
   if and only if the answer to = question #1 is True ?


Thanks for enlighting me in advance,

-Gowri

------_=_NextPart_001_01C1E586.9B46AA44-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 18:59:02 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01342 for ; Tue, 16 Apr 2002 18:59:01 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13813; Tue, 16 Apr 2002 15:58:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14908; Tue, 16 Apr 2002 15:58:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GMvSIA000936 for ; Tue, 16 Apr 2002 15:57:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GMvSIn000935 for mobile-ip-dist; Tue, 16 Apr 2002 15:57:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GMvQIA000928 for ; Tue, 16 Apr 2002 15:57:26 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22256 for ; Tue, 16 Apr 2002 18:57:24 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA02919 for mobile-ip@sunroof.eng.sun.com; Tue, 16 Apr 2002 18:58:23 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GMDwIA000853 for ; Tue, 16 Apr 2002 15:13:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26916 for ; Tue, 16 Apr 2002 15:14:02 -0700 (PDT) Received: from inesc.inesc.pt (inesc.inesc.pt [146.193.0.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26619 for ; Tue, 16 Apr 2002 16:13:57 -0600 (MDT) Received: from cray.inesc.pt (IDENT:root@cray.inesc.pt [146.193.3.253]) by inesc.inesc.pt (8.9.3/8.9.3) with ESMTP id XAA33625; Tue, 16 Apr 2002 23:13:40 +0100 (WEST) (envelope-from pedro.estrela@inesc.pt) Received: from moicane1 (moicane1.inesc.pt [146.193.0.37]) by cray.inesc.pt (8.11.6/8.11.6) with SMTP id g3GMDHc28634; Tue, 16 Apr 2002 23:13:18 +0100 Message-ID: <001501c1e5d6$dacffb70$2500c192@inesc.pt> From: "Pedro Estrela" To: , Subject: [mobile-ip] ANNOUNCE: new individual submission - draft-estrela-timip-00.txt Date: Tue, 16 Apr 2002 23:12:29 -0700 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is an Individual Submission regarding a new micro-mobility approach for legacy terminals. Title : Terminal Independent Mobile IP (TIMIP) Author(s) : P. Estrela, A. Grilo, T. Vazão, M. Nunes Filename : draft-estrela-timip-00.txt Pages : 10 Date : March 2002 Abstract: IP mobility protocols usually assume that the mobile nodes have a mobility-aware IP stack, which is still a scenario that can seldom be found nowadays. Most terminals, including laptops and PDAs, still use legacy IP stacks, limiting their use to layer-2 mobility between Access Points (APs) connected to the same Access Router (AR) within a single IP subnet. This document presents Terminal Independent Mobile IP (TIMIP), which supports IP mobility of mobility-unaware mobile nodes with legacy IP stacks, while fully interoperating with Mobile IP to provide macromobility across IP subnets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-estrela-timip-00.txt All comments, reviews and suggestions are welcome; please send them directly to pedro.estrela@inesc.pt , and not to these mailing lists. From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 19:51:48 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06793 for ; Tue, 16 Apr 2002 19:51:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16513; Tue, 16 Apr 2002 17:51:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14648; Tue, 16 Apr 2002 16:51:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GNoEIA001153 for ; Tue, 16 Apr 2002 16:50:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3GNoDeI001152 for mobile-ip-dist; Tue, 16 Apr 2002 16:50:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3GNoAIA001145 for ; Tue, 16 Apr 2002 16:50:10 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g3GNoE35356438; Tue, 16 Apr 2002 16:50:14 -0700 (PDT) Message-Id: <200204162350.g3GNoE35356438@jurassic.eng.sun.com> Date: Tue, 16 Apr 2002 16:52:33 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Unresolved issue #16: unrecognized MH To: keiichi@iij.ad.jp Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xG+TAoQlF4aX7svxOfUylQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > The draft should also clarify that OLD IPv6 nodes (without Mobility support) > > should send 'mobility header unknown' message as an indication that they don't > > support CN functionality for MIPv6. > > What is 'mobility header unknown'? > Sorry, it was a misnomer, actually I meant ICMP param problem with 'unknown next header value' which is already being implemented in ipv6 nodes. The suggestion was to clarify that in the draft for mobile node implementation. > I think the old IPv6 node need not to be modified. They will send > 'ICMPv6 parameter problem' with 'unknown next header value' type. We > can easily detect the node can't understand MIP6. > > # modifing all old ipv6 nodes is unrealistic to me. Agreed. -Samita From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 20:11:36 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08856 for ; Tue, 16 Apr 2002 20:11:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22061; Tue, 16 Apr 2002 17:11:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21844; Tue, 16 Apr 2002 17:10:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H09xIA001211 for ; Tue, 16 Apr 2002 17:09:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H09xHK001210 for mobile-ip-dist; Tue, 16 Apr 2002 17:09:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H09uIA001203 for ; Tue, 16 Apr 2002 17:09:56 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g3H0A035359690; Tue, 16 Apr 2002 17:10:01 -0700 (PDT) Message-Id: <200204170010.g3H0A035359690@jurassic.eng.sun.com> Date: Tue, 16 Apr 2002 17:12:19 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Unresolved issue #16: unrecognized MH To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Shrewdness_of_Apes_839_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --Shrewdness_of_Apes_839_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: O3v1RuWscLeuQ6iDutQbbw== Hi Jari, > > Samita Chakrabarti wrote: > > > > What is 'mobility header unknown'? > Actually the above question was asked by Keiichi SHIMA, not me :-) I have used the term 'mobility header unknown' in my previous email incorrectly, I meant to say ICMP param problem with 'unknown next header value'. > One, the MH protocol could be unknown to the recipient. This > is clearly a job for ICMP. > Agreed. > Two, the message type field (MH Type) inside the MH could > be unknown to the recipient, perhaps due to an extension that > the recipient doesn't support. We've been discussing whether > that can be reported by ICMP, BA, or a special MH Error message. > It seems that most people think ICMP Parameter Problem can be > used. The only thing in this solution is that the receiver of the > error message must take care in looking at what octet is being > pointed to as the error. True. Please see my original email(attached). I had a request on clarification of "Requirements for IPv6 correspondent nodes" in the MIPv6 draft. Thanks, -Samita --Shrewdness_of_Apes_839_000 Content-Type: MESSAGE/rfc822; name=Mailbox Content-Description: Mailbox Date: Tue, 16 Apr 2002 17:10:56 -0700 (PDT) From: Postmaster Subject: Message from mail server Content-Length: 95 Mime-Version: 1.0 Status: RO X-IMAP: 1019002256 1 Delete. This is a system message. --END+PSEUDO-- From Samita.Chakrabarti@eng.sun.com Thu Apr 11 16:31:30 2002 Return-Path: Received: from engmail1.Eng.Sun.COM (engmail1.Eng.Sun.COM [129.146.1.13]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g3BNVU34249193 for ; Thu, 11 Apr 2002 16:31:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23189; Thu, 11 Apr 2002 16:31:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BNU6IA018190 for ; Thu, 11 Apr 2002 16:30:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3BNU66k018189 for mobile-ip-dist; Thu, 11 Apr 2002 16:30:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3BNU2IA018182 for ; Thu, 11 Apr 2002 16:30:02 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g3BNU535248958; Thu, 11 Apr 2002 16:30:05 -0700 (PDT) Message-Id: <200204112330.g3BNU535248958@jurassic.eng.sun.com> Date: Thu, 11 Apr 2002 16:32:22 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Unresolved issue #16: Error message from an unknown MH Type To: jari.arkko@piuha.net, vijayd@IPRG.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8pVjR+pVUmTSqfx7Bnnc6w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Length: 2260 Status: RO X-Status: $$$$ X-UID: 0000000001 > > > > I would prefer going with the ICMP parameter prob (this > > has been the normal practice whenever you dont recognize > > something in the packet). Maybe define a new error code. > > Or live with it, since the ICMP parameter prob also points > > to the corresponding offending octet in the original packet. > > > I'd be fine with this also. RFC 2463 lists the Parameter Problem > codes: > > 0 - erroneous header field encountere > 1 - unrecognized Next Header type encountered > 2 - unrecognized IPv6 option encountered > > 1 and 2 seem to be inappropriate. What about 0? A quick > look at the usage of code 0 on e.g. wrong routing header > type seems to match the usage here. So go for ICMP Parameter > Problem and Code 0 instead? Although I agree that we are overloading BA if we are to use BA to send the error message: unknown MH type, but using ICMP Param problem with code = 0 , does not quite carry the proper semantics of "Unknown MH Type". So, the question is how important it is to know by the recepient that it is indeed an unknown MH type or does ICMP PARAM with code=0, (with a pointer to the nextheader field) is enough for this purpose ? In this context, we have a new issue to clarify here. Question: Should a CN implementation MUST support route optimization ? (now that by default, route optimization is not mandatory for mobile nodes ) a) If by any chance, we decide that a CN may optionally support route optimization for MobileIP, then a CN which does not support route optimization, MUST handle HoTI/CoTI messages and BU by sending an appropriate error message to MN. So, if we consider sending ICMP param in this case, the code should be 1 (unrecognized next header) to indicate that it does not support RO. b) If a CN MUST support route optimization, then the spec should clarify that. How about adding a subsection in section 7 to clarify "Requirements for IPv6 Correspondent nodes" ? I think, it's hard for a CN to distinguish when to send 'unrecognized next header' or 'erroneous header field' in the above cases. Thanks, -Samita --Shrewdness_of_Apes_839_000-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 21:32:30 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16916 for ; Tue, 16 Apr 2002 21:32:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24063; Tue, 16 Apr 2002 19:32:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13112; Tue, 16 Apr 2002 18:31:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H1V9IA001440 for ; Tue, 16 Apr 2002 18:31:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H1V9YB001439 for mobile-ip-dist; Tue, 16 Apr 2002 18:31:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H1V5IA001432 for ; Tue, 16 Apr 2002 18:31:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18772 for ; Tue, 16 Apr 2002 18:31:09 -0700 (PDT) Received: from web11005.mail.yahoo.com (web11005.mail.yahoo.com [216.136.131.55]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA21991 for ; Tue, 16 Apr 2002 18:31:09 -0700 (PDT) Message-ID: <20020417013109.2063.qmail@web11005.mail.yahoo.com> Received: from [202.20.192.45] by web11005.mail.yahoo.com via HTTP; Wed, 17 Apr 2002 10:31:09 JST Date: Wed, 17 Apr 2002 10:31:09 +0900 (JST) From: =?euc-kr?q?lee=20inkyu?= Subject: [mobile-ip] Do we need Single Address Only bit? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit 'draft-ietf-mobileip-ipv6-16.txt' defines Single Address Only bit in 5.1.7. I wonder if it is really needed and want to ask you the case when the bit has to be set. Your answers would be appreciated. Regards, Inkyu _____________________________________________________________________ ¶Ç ´Ù¸¥ ³ª! ±ôÂïÇÑ ¾Æ¹ÙŸ ¸¸µé±â - ¾ßÈÄ! ¾Æ¹ÙŸ http://avatar.yahoo.co.kr/ ÇÏ·çÁ¾ÀÏ À̾߱âÇصµ ½Ã°£°¡´Â ÁÙ ¸ð¸£´Â - ¾ßÈÄ! äÆà http://chat.yahoo.co.kr/ From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 21:58:16 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19903 for ; Tue, 16 Apr 2002 21:58:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00880; Tue, 16 Apr 2002 18:57:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19260; Tue, 16 Apr 2002 18:57:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H1tpIA001587 for ; Tue, 16 Apr 2002 18:55:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H1tpb2001586 for mobile-ip-dist; Tue, 16 Apr 2002 18:55:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H1tmIA001579 for ; Tue, 16 Apr 2002 18:55:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18382 for ; Tue, 16 Apr 2002 18:55:52 -0700 (PDT) Received: from flower.ce.chungnam.ac.kr (flower.comeng.chungnam.ac.kr [168.188.44.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12138 for ; Tue, 16 Apr 2002 19:55:49 -0600 (MDT) Received: from schumann (beethoven.comeng.chungnam.ac.kr [168.188.46.68]) by flower.ce.chungnam.ac.kr (8.9.3/8.9.3) with SMTP id KAA23023 for ; Wed, 17 Apr 2002 10:56:27 +0900 (KST) Message-ID: <006a01c1e5b2$f9f4e480$442ebca8@ce.cnu.ac.kr> From: =?ks_c_5601-1987?B?TXlvdW5nLUh3YW4gT2hcKL/AuO3Ir1wp?= To: "IETF_MIP_WG_mailingList" Subject: [mobile-ip] Tunneling problem with sun's MIP implemenation. Date: Wed, 17 Apr 2002 10:55:40 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C1E5FE.69C5A920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C1E5FE.69C5A920 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCkkgaGF2ZSBzb21lIHByb2JsZW0gd2l0aCB0ZXN0aW5nIHRoZSBTVU4ncyBNSVAg aW1wbGVtZW50YXRpb24sIA0KdGhhdCBpcyB3aGVuIEkgcnVuIHRoZSBhYm92ZSBvbmUsIElQSVAg dHVubmVsaW5nIGRvZXNuJ3Qgd29yayBwcm9wZXJseS4NCkFjdHVhbGx5LCBpdCBzZWVtcyBpdCBk b2Vzbid0IHdvcmsgYXQgYWxsIG9uIGxpbnV4IDIuMi5YIG9yIGhpZ2hlciB2ZXJpb24uIA0KTXkg YXBvbG9naWVzIGluIGFkdmFuY2UgaWYgaSBhc2tlZCBkdXBsaWNhdGVkIHF1ZXN0aW9uLg0KaSBr bm93IHRoZXJlIGFyZSBBcmNoaXZlcyBmb3IgZGlzY3Vzc2VkIHRoaW5ncyBiZWZvcmUsIGJ1dCBp dCdzIHNvIGNvbXBsZXggdG8NCnNlYXJjaCB3aGF0IGkgd2FudC4NCg0KSW4gc2hvcnQsIHRoZSBw cm9ibGVtIGlzDQotIFdoZW4gY29ycmVzcG9uZGVudCBub2RlIChvciBBZ2VudCkgc2VuZHMgcGFj a2V0IHRvIE1OKHdoaWNoIGhhZCBtb3ZlZCB0byBGQSBhbHJlYWR5KQ0KICB0aGUgVHVubmVsIGZy b20gSEEgdG8gRkEgaXMgbm90IHNldHRlZCB1cC4NCg0KSSBoZWFyZCB0aGF0IHRoZXJlJ3Mgc29t ZSBkaWZmZXJlbmNlIHRvIFR1bm5lbGluZyBiZXR3ZWVuIGxpbnV4IDIuMC54IGFuZCBvdmVyIDIu Mi5Ycy4NCg0KU28gaG93IGNvdWxkIEkgbWFrZSBpdCB3b3JrIHByb3Blcmx5PyBhbnlvbmUgaGFk IHN1ZmZlcmVkIGZyb20gdGhpcyBwcm9ibGVtPw0KcGxlYXNlIGxldCBtZSBoYXZlIGRldGFpbCBh Ym91dCB0aGlzLg0KDQpUaGFua3MNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpNeW91bmctSHdhbiBPaC4NCkdy YWR1YXRlIFN0dWRlbnQgRGlzdHJpYnV0ZWQgU3lzdGVtIExhYi4gDQpEZXBhcnRtZW50IG9mIENv bXB1dGVyIEVuZ2luZWVyaW5nLCBDaHVuZ25hbSBOYXRpb25hbCBVbml2ZXJzaXR5IA0KMjIwIEt1 bmcgRG9uZywgVGFlam9uIDMwNTc2NCwgS29yZWEgDQpURUw6KzgyLTQyLTgyMy02MDQ5IEZBWDor ODItNDItODIyLTQ5OTcgDQpFLW1haWw6IG1ob2hAY2UuY251LmFjLmtyIA0KDQoNCg0K ------=_NextPart_000_0067_01C1E5FE.69C5A920 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTUuNDAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SGkgYWxsPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+SSBoYXZlIHNvbWUgcHJvYmxlbSB3aXRoIHRlc3RpbmcgdGhlIFNVTidzIE1J UCBpbXBsZW1lbnRhdGlvbiwgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50aGF0 IGlzIHdoZW4gSSBydW4gdGhlIGFib3ZlIG9uZSwgSVBJUCB0dW5uZWxpbmcgZG9lc24ndCB3b3Jr IA0KcHJvcGVybHkuPEJSPkFjdHVhbGx5LCBpdCBzZWVtcyBpdCBkb2Vzbid0IHdvcmsgYXQgYWxs IG9uIGxpbnV4IDIuMi5YIG9yIGhpZ2hlciANCnZlcmlvbi4gPEJSPk15IGFwb2xvZ2llcyBpbiBh ZHZhbmNlIGlmIGkgYXNrZWQgZHVwbGljYXRlZCBxdWVzdGlvbi48QlI+aSBrbm93IA0KdGhlcmUg YXJlIEFyY2hpdmVzIGZvciBkaXNjdXNzZWQgdGhpbmdzIGJlZm9yZSwgYnV0IGl0J3Mgc28gY29t cGxleCB0bzxCUj5zZWFyY2ggDQp3aGF0IGkgd2FudC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JbiBzaG9ydCwg dGhlIHByb2JsZW0gaXM8QlI+LSBXaGVuIGNvcnJlc3BvbmRlbnQgbm9kZSAob3IgDQpBZ2VudCkg c2VuZHMgcGFja2V0IHRvIE1OKHdoaWNoIGhhZCBtb3ZlZCB0byBGQSBhbHJlYWR5KTxCUj4mbmJz cDsgdGhlIFR1bm5lbCANCmZyb20gSEEgdG8gRkEgaXMgbm90IHNldHRlZCB1cC48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5JIGhlYXJkIHRoYXQgdGhlcmUncyBzb21lIGRpZmZlcmVuY2UgdG8gVHVubmVsaW5nIGJl dHdlZW4gDQpsaW51eCAyLjAueCBhbmQgb3ZlciAyLjIuWHMuPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+U28gaG93 IGNvdWxkIEkgbWFrZSBpdCB3b3JrIHByb3Blcmx5PyBhbnlvbmUgaGFkIHN1ZmZlcmVkIGZyb20g DQp0aGlzIHByb2JsZW0/PEJSPnBsZWFzZSBsZXQgbWUgaGF2ZSZuYnNwO2RldGFpbCBhYm91dCB0 aGlzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPlRoYW5rczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCjxCUj5NeW91bmctSHdhbiBPaC48QlI+R3Jh ZHVhdGUgU3R1ZGVudCBEaXN0cmlidXRlZCBTeXN0ZW0gTGFiLiA8QlI+RGVwYXJ0bWVudCANCm9m IENvbXB1dGVyIEVuZ2luZWVyaW5nLCBDaHVuZ25hbSBOYXRpb25hbCBVbml2ZXJzaXR5IDxCUj4y MjAgS3VuZyBEb25nLCBUYWVqb24gDQozMDU3NjQsIEtvcmVhIDxCUj5URUw6KzgyLTQyLTgyMy02 MDQ5IEZBWDorODItNDItODIyLTQ5OTcgPEJSPkUtbWFpbDogPEEgDQpocmVmPSJtYWlsdG86bWhv aEBjZS5jbnUuYWMua3IiPm1ob2hAY2UuY251LmFjLmtyPC9BPiA8L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEJSPjwvRk9OVD4mbmJzcDs8L0RJVj48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0067_01C1E5FE.69C5A920-- From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 22:49:47 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25689 for ; Tue, 16 Apr 2002 22:49:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14874; Tue, 16 Apr 2002 19:49:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02518; Tue, 16 Apr 2002 19:49:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2mLIA001790 for ; Tue, 16 Apr 2002 19:48:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2mK2d001789 for mobile-ip-dist; Tue, 16 Apr 2002 19:48:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2mGIA001782 for ; Tue, 16 Apr 2002 19:48:17 -0700 (PDT) Received: from lillen (ebayhobo179.EBay.Sun.COM [129.150.99.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3H2mGx10041; Wed, 17 Apr 2002 04:48:16 +0200 (MEST) Date: Wed, 17 Apr 2002 04:47:47 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Unresolved issue #5: Alternate CoA To: jari.arkko@piuha.net Cc: "'mobile-ip@sunroof.eng.sun.com'" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Text: State the following under 5.1.7: > The care-of address for the binding given in the Binding Update > message is normally that which was received as the value in the Source > Address field in the IPv6 header of the packet carrying the Binding > Update message. However, a care-of address different from the Source > Address MAY be specified by including an Alternate Care-of Address > option in the Binding Update message. When such message is sent to > the correspondent node, the Care-of Test Init and Care-of Test > messages MUST have been performed for the address in the Alternate > Care-of Address option (not the Source Address). The contents of > the Nonce Indices and the Authenticator options MUST be based on > information gained in this test. It would be useful to also put some text in section 8.2 to point out that when alt-coa is used the Care-of cookie needs to match it and not the IP source address of the BU. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 22:51:54 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25880 for ; Tue, 16 Apr 2002 22:51:53 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18867; Tue, 16 Apr 2002 19:51:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03278; Tue, 16 Apr 2002 19:51:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2oXIA001831 for ; Tue, 16 Apr 2002 19:50:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2oXe7001830 for mobile-ip-dist; Tue, 16 Apr 2002 19:50:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2oTIA001823 for ; Tue, 16 Apr 2002 19:50:29 -0700 (PDT) Received: from lillen (ebayhobo179.EBay.Sun.COM [129.150.99.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3H2oDx10169; Wed, 17 Apr 2002 04:50:13 +0200 (MEST) Date: Wed, 17 Apr 2002 04:49:44 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Unresolved issue #6: Reuse of nonces To: Vijay Devarapalli Cc: jari.arkko@piuha.net, "'mobile-ip@sunroof.eng.sun.com'" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Agree with most of the text, except for section 11. > > The actual window of vulnerability is only > MAX_RR_BINDING_LIFE (300 seconds). The MAX_COOKIE_LIFE > does not add anything to the window of vulnerability. So > why not make the MAX_COOKIE_LIFE also 300 seconds. > > lets assume an MN has initiated an RR test. An on-path > attacker (CN-HA path) could get hold of K0. For him to > launch to attack, he must generate a new K1 with his > CoA and send a BU as soon as the CN has sent a BAck to > the actual MN. If he does not do it immediately, the > packets from the CN will keep going to the right MN. > No harm done, till the attacker tries to use K0. And > when the attacker does this, he is able to hijack > connection for MAX_RR_BINDING_LIFE. Whatever the case, > the MN would be vulnerable only for MAX_RR_BINDING_LIFE. That is one type of attack but there are others. As I understand it an on-path attacker can do a future attack for the sum of MAX_RR_BINDING_LIFE and MAX_COOKIE_LIFE after having been on the path. So Mallory sits between the HA and CN at time T0. It does a HoTI/HoT exchange and gets a Home cookie at that time. Then it is no longer on the path due to Mallory moving (e.g. moving away from the CN's link). If Mallory sends a BU just before time T0+MAX_COOKIE_LIFE it can redirect packets for the MN until time T0+MAX_COOKIE_LIFE+MAX_RR_BINDING_LIFE. Thus if the MN arrives during that time it will not be able to communicate with the CN unless the MN performs a BU procedure before sending a single packet to the CN (and expecting to receive something back). So the time period for this particular threat is the sum of the two times. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 22:52:14 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25921 for ; Tue, 16 Apr 2002 22:52:14 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15845; Tue, 16 Apr 2002 19:51:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03479; Tue, 16 Apr 2002 19:51:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2omIA001844 for ; Tue, 16 Apr 2002 19:50:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2om42001843 for mobile-ip-dist; Tue, 16 Apr 2002 19:50:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2ogIA001836 for ; Tue, 16 Apr 2002 19:50:42 -0700 (PDT) Received: from lillen (ebayhobo179.EBay.Sun.COM [129.150.99.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3H2ogx10187; Wed, 17 Apr 2002 04:50:42 +0200 (MEST) Date: Wed, 17 Apr 2002 04:50:13 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > This isn't security related, but I think it is something that *must* be > fixed before the MIPv6 goes to RFC. I think it is sufficient "before MIPv6+IPv6+... can be deployed" - while the issue is important I don't see why it needs to hold up the MIPv6 specification. I'd prefer this being done as a short separate draft since this makes it easier to fold it into RFC 2461 at a later time. > Ideally, we could insert some text into the MIPv6 spec saying that this > behavior needs to be modified for routers that are handling wireless > links, but this would be somewhat counter to the trend in MIPv6 of > integrating MIP more tightly with standard IPv6 mechanisms. > Alternatively, we could do a separate draft that modified the text in > RFC 2461 to make the random delay behavior a SHOULD, or add rate > limiting behavior instead (i.e. make the random delay behavior be a > function of the incoming SolRA rate). Pre-RFC versions of neighbor discovery had a the ability (if my memory serves me) for routers to immediately unicast a RA in response to a RS, but randomly delay and rate limit any multicast RAs send it response to RSs. Having a mechanisms to select between an immediate unicast response and a delayed multicast response seemed not worth the effort at the time, but that is an avenue that can be explored now. For instance, if the last RS was received less than 3 seconds ago the router could do the randomly delayed multicast RA; otherwise an immediate unicast RA. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 22:52:42 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25951 for ; Tue, 16 Apr 2002 22:52:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16076; Tue, 16 Apr 2002 19:52:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03736; Tue, 16 Apr 2002 19:52:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2p3IA001861 for ; Tue, 16 Apr 2002 19:51:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2p3V8001860 for mobile-ip-dist; Tue, 16 Apr 2002 19:51:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2ovIA001853 for ; Tue, 16 Apr 2002 19:50:58 -0700 (PDT) Received: from lillen (ebayhobo179.EBay.Sun.COM [129.150.99.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3H2oux10215; Wed, 17 Apr 2002 04:50:56 +0200 (MEST) Date: Wed, 17 Apr 2002 04:50:27 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [mobile-ip] Unresolved issue #14: RR ESP protection keyword To: "Karen E Nielsen (TED)" Cc: "'Michael Thomas'" , jari.arkko@piuha.net, "'mobile-ip@sunroof.eng.sun.com'" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > This of course mean that the IPSEC selectors should be able to scan > the Mobility Header Type field (RR HOT is MH type 3, BU is MH type 5 etc.) > Does anyone see a problem with this ? I've been assuming that the policy would be broader by covering all packets with protocol=MH that are being forwarded by the HA. The BU/BA/BR packets are sent directly between CN and MN so in practise this will not mean that more packets get encrypted by the HA. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 22:53:02 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25971 for ; Tue, 16 Apr 2002 22:53:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19693; Tue, 16 Apr 2002 19:52:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03921; Tue, 16 Apr 2002 19:52:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2pJIA001878 for ; Tue, 16 Apr 2002 19:51:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2pJ0v001877 for mobile-ip-dist; Tue, 16 Apr 2002 19:51:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2pCIA001863 for ; Tue, 16 Apr 2002 19:51:13 -0700 (PDT) Received: from lillen (ebayhobo179.EBay.Sun.COM [129.150.99.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3H2pCx10230; Wed, 17 Apr 2002 04:51:12 +0200 (MEST) Date: Wed, 17 Apr 2002 04:50:43 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Unresolved issue #16: Error message from an unknown MH Type To: jari.arkko@piuha.net Cc: "'mobile-ip@sunroof.eng.sun.com'" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Proposal: We should just define a new error code under the Binding Ack > message, and include the reception of this message in the state > machines even when it is not a response to a Binding Update. > > Text: > - 146 Unknown MH Type While this works I think it might be a source of confusion when BA messages are sent in response to "random" MH packets. What would the authenticator be in such a BA? Don't implementations need to handle packets with this error code differently than other Perhaps we should rename Binding Missing to be "Mobility Header Error" and have a code for the "binding missing" as well as "unknown MH type" cases? I think they both have similar issue in the sense that, unlike a BA, there isn't an authenticator etc. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 22:53:27 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25995 for ; Tue, 16 Apr 2002 22:53:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19942; Tue, 16 Apr 2002 19:52:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04174; Tue, 16 Apr 2002 19:52:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2pdIA001895 for ; Tue, 16 Apr 2002 19:51:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2pdrx001894 for mobile-ip-dist; Tue, 16 Apr 2002 19:51:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2pVIA001880 for ; Tue, 16 Apr 2002 19:51:32 -0700 (PDT) Received: from lillen (ebayhobo179.EBay.Sun.COM [129.150.99.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3H2pUx10234; Wed, 17 Apr 2002 04:51:31 +0200 (MEST) Date: Wed, 17 Apr 2002 04:51:01 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [mobile-ip] Unresolved issue #3: BA, BR authentication? To: Tuomas Aura Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I do not like the BA/BR authentication. First, do they need > to be authenticated? Second, the protocol is difficult to > understand and analyze. I think it makes sense to prevent off-path attackers from being able to confuse the MN by sending CoT/HoT/BA/BR packets. That should just require a cookie (akin to the sequence number in TCP SYN packets preventing spoofed SYN|ACK packets). Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 22:53:43 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26037 for ; Tue, 16 Apr 2002 22:53:42 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20220; Tue, 16 Apr 2002 19:53:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04323; Tue, 16 Apr 2002 19:53:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2pvIA001928 for ; Tue, 16 Apr 2002 19:51:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2pvlu001927 for mobile-ip-dist; Tue, 16 Apr 2002 19:51:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2plIA001909 for ; Tue, 16 Apr 2002 19:51:47 -0700 (PDT) Received: from lillen (ebayhobo179.EBay.Sun.COM [129.150.99.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3H2pix10243; Wed, 17 Apr 2002 04:51:44 +0200 (MEST) Date: Wed, 17 Apr 2002 04:51:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Unresolved issue #16: unrecognized MH To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= , Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I think the old IPv6 node need not to be modified. They will send > 'ICMPv6 parameter problem' with 'unknown next header value' type. We > can easily detect the node can't understand MIP6. Yes, and the mipv6 spec should point this out. > # modifing all old ipv6 nodes is unrealistic to me. > > Instead, I propose to specify that the MN must use the bi-directional > tunneling when it receives the above error (ICMPv6 paramprob, NH) > against any of the mobility header. Using 'ICMPv6 parameter problem' with 'unknown next header value' from a MIPv6 CN just because it doesn't understand a new MH type seems wrong. And we want to allow future MIPv6 security schemes to define new MH type values should they need to do so. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 22:54:00 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26063 for ; Tue, 16 Apr 2002 22:53:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16726; Tue, 16 Apr 2002 19:53:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04514; Tue, 16 Apr 2002 19:53:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2q9IA001952 for ; Tue, 16 Apr 2002 19:52:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H2q9QK001951 for mobile-ip-dist; Tue, 16 Apr 2002 19:52:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H2q0IA001932 for ; Tue, 16 Apr 2002 19:52:00 -0700 (PDT) Received: from lillen (ebayhobo179.EBay.Sun.COM [129.150.99.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3H2pxx10248; Wed, 17 Apr 2002 04:51:59 +0200 (MEST) Date: Wed, 17 Apr 2002 04:51:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Unresolved issue #13: SPI field To: "Charles E. Perkins" Cc: jari.arkko@piuha.net, "'mobile-ip@sunroof.eng.sun.com'" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The SPI field has to be available, to allow for selection of > the appropriate Binding Security Association to be used for > calculations involving the authentication data. Charlie, [Just in case this didn't already get resolved] Do you see the SPI field being used by anything that is in the current mipv6 draft? If not, why can't any security scheme which needs an SPI field define an SPI option to carry this information? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Apr 16 23:20:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28363 for ; Tue, 16 Apr 2002 23:20:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22953; Tue, 16 Apr 2002 21:20:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18220; Tue, 16 Apr 2002 20:19:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H3JAIA002241 for ; Tue, 16 Apr 2002 20:19:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3H3JAur002240 for mobile-ip-dist; Tue, 16 Apr 2002 20:19:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3H3J7IA002233 for ; Tue, 16 Apr 2002 20:19:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18060; Tue, 16 Apr 2002 20:19:11 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28327; Tue, 16 Apr 2002 20:19:11 -0700 (PDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA06511; Wed, 17 Apr 2002 12:19:10 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA21058; Wed, 17 Apr 2002 12:19:09 +0900 (JST) Date: Wed, 17 Apr 2002 12:18:49 +0900 (JST) Message-Id: <20020417.121849.77577466.keiichi@iij.ad.jp> To: Erik.Nordmark@sun.com Cc: Samita.Chakrabarti@eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #16: unrecognized MH From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: References: X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: Erik Nordmark Content-Transfer-Encoding: 7bit > > Instead, I propose to specify that the MN must use the bi-directional > > tunneling when it receives the above error (ICMPv6 paramprob, NH) > > against any of the mobility header. > > Using 'ICMPv6 parameter problem' with 'unknown next header value' > from a MIPv6 CN just because it doesn't understand a new MH type > seems wrong. Sorry, my wording were not clear enough... I suggest that all MN must use bi-directional tunneling when they receive an ICMPv6 Parameter Problem for a mobility header from *legacy IPv6 nodes which don't understand MIP6*. (I guess many implementors do this, though the spec doesn't say anything about this behavior.) > And we want to allow future MIPv6 security schemes to define new MH type > values should they need to do so. As I have said in another mail, I prefer a new MH type which indicates an error. When a *new* MIP6 MN/CN receives such a MH indicates an error from *old* MIP6 MN/CN, they can easily fall back to the old spec. I think the ICMPv6 parameter problem with type 0 seems too generic for this purpose. --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 17 14:21:51 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00266 for ; Wed, 17 Apr 2002 14:21:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17566; Wed, 17 Apr 2002 12:20:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07204; Wed, 17 Apr 2002 11:19:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HIIHIA003894 for ; Wed, 17 Apr 2002 11:18:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HIIHXE003893 for mobile-ip-dist; Wed, 17 Apr 2002 11:18:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HIIEIA003886 for ; Wed, 17 Apr 2002 11:18:14 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06869 for ; Wed, 17 Apr 2002 11:18:14 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28869 for ; Wed, 17 Apr 2002 11:18:14 -0700 (PDT) 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 LAA01409; Wed, 17 Apr 2002 11:18:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3HIICu12881; Wed, 17 Apr 2002 11:18:12 -0700 X-mProtect: <200204171818> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtK2zR3; Wed, 17 Apr 2002 11:18:10 PDT Message-ID: <3CBDBC62.21C19B77@iprg.nokia.com> Date: Wed, 17 Apr 2002 11:18:10 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Manolis Sifalakis , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, some comments below.. James Kempf wrote: > > 1. In Anticipated Handover Overview (3.1.1) it is understood that the > > oAR after sending the PrRtAdv message it waits for an F-BU request > > before starting to tunnel the traffic, destined for the oCoA, to the > > nCoA or the nAR. > > > > Q1. What happens if the MN delays to cross to the new link after > sending > > the F-BU (since for a mobile host anything can easily happen to delay > > the link traversal)? Are the packets still delivered to the local link > > untill a L2 trigger appears or are they sent through the tunnel to the > > nCoA/nRA? > > > > If there is a L2 Link Down trigger on the old access router, this can be > used to determine when to start tunneling. > If no such trigger exists, the access router can either start tunneling ^^^^ The AR must start tunneling immediately after processing the FBU. In fact, the control (to turn on tunneling) must reside at the MN. > > immediately, in which case the mobile node will miss those packets sent > before it moves, or it can bicast packets down the old link and the > tunnel. > clarification: bicasting is not proposed in the spec (after a long discussion culminating in a vote at London IETF). > > > > > 3. Q. Up untill section 3.5.2 in the document (that I read), there is > > nowhere mentioned that the aAR may be the HA. Instead it is constantly > > implied that the HA is different from the oAR or the aAR. Is that > > correct? If yes why? > > > > Would it make any change in the protocol description? > I agree with Alper's comment; old AR "acts like" an HA in tunneling packets to a new IP address. > > > > > 4. Some typos, I suppose, in 3.1.1, 3.1.3, 3.1.8, are that F-BU is > often > > used to mean F-BAck. If I have misanderstood and an AR can indeed send > > F-BUs to the MN, then the typo is in the description of the F-BU. > > > > It should probably be F-BAck. > Thank you for finding the typos, and for your comments. Regards, -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 17 15:06:20 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02162 for ; Wed, 17 Apr 2002 15:06:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06393; Wed, 17 Apr 2002 12:04:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27555; Wed, 17 Apr 2002 12:03:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HJ2MIA004279 for ; Wed, 17 Apr 2002 12:02:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HJ2Max004278 for mobile-ip-dist; Wed, 17 Apr 2002 12:02:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HJ2IIA004271 for ; Wed, 17 Apr 2002 12:02:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29119 for ; Wed, 17 Apr 2002 12:02:22 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05290 for ; Wed, 17 Apr 2002 12:02:21 -0700 (PDT) Received: from T23KEMPF (dhcp169.docomolabs-usa.com [172.21.96.169]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3HJ2JI27660; Wed, 17 Apr 2002 12:02:19 -0700 (PDT) Message-ID: <00cf01c1e642$2c476130$a96015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: References: Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Wed, 17 Apr 2002 09:58:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, We're preparing a separate draft for this, which I think we will submit to IPNG this week. It is very short (4 pages I think). The draft adds a bit to the RS saying that the host would like an immediate response. Of course, hosts can cheat and send it even if they aren't doing MIP handover, but if everybody plays the rules the congestion control should work, like TCP. The other issue is whether there should be some kind of reference in the Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are recommended to use it. jak ----- Original Message ----- From: "Erik Nordmark" To: "James Kempf" Cc: Sent: Tuesday, April 16, 2002 7:50 PM Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > > This isn't security related, but I think it is something that *must* be > > fixed before the MIPv6 goes to RFC. > > I think it is sufficient "before MIPv6+IPv6+... can be deployed" - > while the issue is important I don't see why it needs to hold up > the MIPv6 specification. > > I'd prefer this being done as a short separate draft since this makes it > easier to fold it into RFC 2461 at a later time. > > > Ideally, we could insert some text into the MIPv6 spec saying that this > > behavior needs to be modified for routers that are handling wireless > > links, but this would be somewhat counter to the trend in MIPv6 of > > integrating MIP more tightly with standard IPv6 mechanisms. > > Alternatively, we could do a separate draft that modified the text in > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > limiting behavior instead (i.e. make the random delay behavior be a > > function of the incoming SolRA rate). > > Pre-RFC versions of neighbor discovery had a the ability (if my memory serves > me) for routers to immediately unicast a RA in response to a RS, but > randomly delay and rate limit any multicast RAs send it response to RSs. > > Having a mechanisms to select between an immediate unicast response and > a delayed multicast response seemed not worth the effort at the time, but > that is an avenue that can be explored now. > For instance, if the last RS was received less than 3 seconds ago > the router could do the randomly delayed multicast RA; otherwise > an immediate unicast RA. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 17 19:04:02 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10474 for ; Wed, 17 Apr 2002 19:04:01 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00179; Wed, 17 Apr 2002 17:04:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18388; Wed, 17 Apr 2002 16:03:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HN2hIA004606 for ; Wed, 17 Apr 2002 16:02:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HN2hSh004605 for mobile-ip-dist; Wed, 17 Apr 2002 16:02:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HN2dIA004596 for ; Wed, 17 Apr 2002 16:02:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18005 for ; Wed, 17 Apr 2002 16:02:43 -0700 (PDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03148 for ; Wed, 17 Apr 2002 17:02:42 -0600 (MDT) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3HN2eO15597; Wed, 17 Apr 2002 16:02:40 -0700 (PDT) Message-ID: <3CBDFF10.281B919B@cs.ucsb.edu> Date: Wed, 17 Apr 2002 16:02:40 -0700 From: Robert Chalmers Organization: UCSB Computer Science X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "Charles E. Perkins" Subject: [mobile-ip] Editorial comments on Draft 16 - Section 6-13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is the second half of the editorial comments, covering Sections 6 through 13. C6.4P9: /Home Agents MAY include/ What happens when a router splits its advertisement due to it being too large? If this option is included in only the first 'portion', then later 'portions' will force the lifetime to be reset to the Router Lifetime. Does this option have to be included in all 'portions'? C7: What happened to the sub-section describing the requirements for all hosts and routers? Are there no longer any requirements on CNs? What about handling route optimization messages? C7.1P5: Reword the paragraph to something like: 'Filtering routers SHOULD support different rules for Type 0 and Type 2 Routing headers so that filtering of source routed packets (Type 0) will not necessarily limit MIPv6 traffic via Type 2 Routing headers.' C7.3P3: s/options/messages/ C7.3P6: s/option/message/ C7.3P7: The paragraph is not completely clear that the packets with the HAO are sent with the CoA as the source address. It also seems to preclude the use of reverse tunneling. Actually, shouldn't reverse tunneling be a requirement? Decapsulation is, but encapsulation is not. C8: The discussion of CN RR processing is missing. C8.1P1: There's no note about requiring a valid BCE to accept the HAO. C8.2P1S1: s/option/message/ C8.2P1S3: /packet MUST contain/ This actually contradicts Section 5.1.7. C8.2P1S4: s/Option Length/Header Len/ None of the MIPv6 messages state the required minimum value of Header Len. C8.2P1S5: 16-bit sequence numbers. C8.2P3S1: s/any other reason (than/any reason other than/ s/Number) MUST/Number MUST/ C8.3P2S1: s/node (or/node, or/ s/exists)./exists./ C8.3P2S2: s/new Binding/Binding/ C8.3P2S-1: s/this lifetime in the Binding Cache entry/its lifetime/ C8.5P1S1: s/option/message/ C8.5P1S2: s/and the 'A' bit was set in the Binding Update,// C8.5P1S-2: s/was not sent/was not set/ C8.5P6: /In response to/ Isn't this actually an error that would require a reply by the rules in the first paragraph. This paragraph should just be removed. C8.6: May need to state that the BR meet certain security requirements if that is so decided. C8.6P2S1,-1: s/option/message/ C8.6P2S2: This sentence should be removed, it refers to piggy-backing. C8.7P2S3: s/in addition// C8.7P3S1: /SHOULD return/ This is a MUST in Section 8.5. C8.7P3S-1: s/a "home registration"/"home registrations"/ C8.7P4S-1: s/to add an entry again/to again add an entry/ C8.8P4S2: This is just a nit, but here we state a MUST in terms of a weakly defined concept of 'persistent' ICMP messages. Should there be something more concrete? C8.9: This sub-section should actually follow Section 8.7. C8.9P1S3: s/Type 0/Type 2/ C8.9P2S1: s/Type 0/Type 2/ C8.9P4: /It is possible that/ This paragraph no longer applies. C9.1P2: Missing a couple of tests: 1) require the presence of an HAO 2) require that HoA in HAO and BU match. Plus, the final test about DAD is rather rough. C9.1P2S2-4: /SHOULD return a Binding Ack/ This is a MUST in Section 8.5. C9.1P3S2: s/node (or update its/node, or update an/ s/for this mobile node,// C9.1P6S1: s/possible/possibly/ C9.1P6S5: Are the lifetime of all BCEs actually limited to the minimum of all prefix lifetimes? I don't think that this is mandated in later text. C9.1P7S3: /The only currently defined/ This is repetitive and not very informative. C9.1P8: What about the other things that the HA must do for the MN, such as reverse tunneling and prefix propagation? C9.2P2S2: s/entry in/entry marked as a "home registration" in/ s/that is marked as a "home registration"// C9.2P4S3: /The only currently defined/ Again a repeat and not very informative. C9.2P5S1: s/link addressed/link that are addressed/ C9.3P1S1: s/link addressed/link that are addressed/ s/using using/using/ C9.3P2: /The Router (R) bit/ This no longer applies. C9.3P4S-1: /This check MUST include/ What if the 'S' bit was set, do we still check all possible combinations. Prefix Length is no longer applicable. C9.4P2S1: /Prefix Length field was nonzero/ Prefix Length is no longer applicable. C9.5P1S1: /sent to it from a mobile node's home address/ What does this mean exactly? I think it should be made more clear. It should also be mentioned that this is the default behavior until route optimization has been setup. C9.6P2S1: s/need protection/require protection/ Are BUs and BAs ever tunneled? C9.7: The section reads a bit odd. C9.7P3: /receive Mobile Prefix/ This seems to be talking about normal IPv6 renumbering. If that's the case then nodes receive just normal Prefix Adverts. If this is actually about sending Mobile Prefix Adverts then the paragraph is not at all clear. C9.8P1S-1: s/each other home agent/other home agents/ This is an extremely long sentence. C9.8P2S2: /If the Home Agent (H) bit...skip all/ This will skip the next step which fits the same criteria. C9.9.1P4S1: /possibly including ... destination options/ This clause is obsolete. It refers to piggy-backing. C9.9.2P1S2: s/home address changes/home address./ C9.9.2P1S3: s/Router Solicitation/Mobile Prefix Solicitation/ C9.9.2P1S4,5: Add periods to end of bullets. C9.9.2P2S4: /ensure that a transmission is scheduled/ It may help to add a '(as described below) here to make it clear that scheduling is a separate issue. C9.9.2P2S5: /are any unacknowledged/ It's not mentioned until much later how to acknowledge an advert. In fact, the mechanism doesn't quite work since it depended on the fact that a BR would be piggy-backed on the advert. C9.9.2P2S6: /SHOULD have the Binding Request/ This won't work without piggy-backing. C9.9.2P3S1: s/Router Advertisement/Prefix Advertisement/ This is an extremely long sentence. C9.9.2P5: /The mobile will get the revised information/ Not quite true anymore. C9.9.2P6: /RAND_ADV_DELAY is/ This paragraph should maybe come a little earlier. C9.9.3P1S5: /the advertisement MUST include/ This won't work without piggy-backing. C9.9.3P2: This won't work without piggy-backing. C9.9.3P2S1: s/Sequence Number/Unique Identifier/ C9.9.3P2-4: These are really scheduling issues and should appear in the previous sub-section. C9.9.4P1-2: These are not HA operations. They belong in the MN operations section. C10.1P1S1: s/address as well as/address, as well as/ C10.1P1S6: s/address in this way./address./ C10.1P1S7: /When sending such packets/ This is only true for route optimization. C10.1P3: This paragraph ignores reverse tunneling, nor does it mention that the CN must have a valid BCE prior to using the HAO. C10.1P3S3: s/e.g., to TCP/e.g., TCP/ C10.2P1S4: s/e.g., by TCP/e.g., TCP/ C10.2P1S9: s/through through/through/ May also note that further IPSec processing may occur on outer header according to normal IPSec rules. C10.2P1S-1: s/remain the same/remains the same/ C10.2P2S1: s/any new SA/a new SA/ C10.4P8S1: s/link-level address to it/addressed to it at the link-level/ C10.7P1S2: s/option/message/ C10.7P1S6: s/sub-option/parameter/ s/option/message/ C10.7P3: /The Prefix Length/ The first sentence no longer applies. The rest of the paragraph should be in reference to the value of the 'S' bit. C10.7P5S2: /These additional/ This assumes the existence of piggy-backing. C10.7P5S3: /Each care-of address/ I don't understand this sentence! C10.7P7S4: s/showing Status 138/containing a Status of 138/ C10.7P7S-1: s/appendix B/Appendix B/ C10.8P2S1: s/discovery/discover/ C10.8P2S-1: s/Request message/request message/ C10.9P1S2: s/See for example/See, for example,/ C10.9P1S-1: s/Sub-Option/Parameter/ C10.9P3S1: s/Cache to record/Cache in order to record/ C10.9P3S-1: /SHOULD be less than or equal to/ Previously, I think that the lifetime was supposed to be less than the remaining lifetime of the home registration binding which may be less than the lifetime of either the HoA or CoA. C10.9P4S-1: /A mobile node MAY set/ This sentence has no relation to the rest of the paragraph. It should actually go at the end of the first paragraph. C10.9P8: /The mobile node, however, need not send/ This is about piggy-backing and should be removed. C10.10P1S3: /The Source Address/ This sentence seems a bit redundant with respect to the next sentence. C10.10P1S5: s/agenet/agent/ C10.10P3S2: s/5.1.5/5.1.6/ C10.10P3S3: /The Source Address/ Again this seems a bit redundant. C10.11P2S5: s/sub-option/parameter/ s/option/message/ C10.11P5S-1: s/4.5/4.5.4/ C10.13P1S1: s/about the same/for the same/ C10.14P1S3: s/Option Length/Header Len/ s/option/message/ C10.14P2: /Any Binding Acknowledgement/ This paragraph assumes the presence of piggy-backing. C10.15P1S2: /except that this lifetime MUST NOT exceed/ The maximum lifetime differs from time in Section 10.9. C10.15P3: s/Sub-Option/Parameter/ C10.16: This is a repeat of Section 10.17. C10.17P1: This is incorrect for new MIPv6 messages. Instead the Code 0 solution as discussed recently on the mailing list should be presented. C10.17P2S1: /although ALL IPv6 nodes/ This is actually no longer stipulated in the requirements. C10.17P2S-1: /this error message indicates/ It should also be noted that the mobile node should not attempt route optimization with this CN. C10.18P3S1: s/address (but/address, but/ s/authenticated)./authenticated./ C10.19P2S5,6: /The packet MUST be protected by IPSec/ This precludes the MN from soliciting an advert prior to configuring its HoA which is said to be acceptable in Section 9.9.3 C10.19P5: /If the advertisement contains/ Specific to piggy-backed solution for acknowledging adverts. C10.21P2: /In order to receive/ This paragraph is confusing. It starts out by talking about receiving multicast, but finishes with adding HAO to sent packets. It should be split up and clarified. Also, in the last paragraph of the section, an alternative to adding the HAO is provided through reverse tunneling. Question, will HAOs work now with multicast since CNs won't have a matching BCE? C12: This section should be an appendix. C12.2P1S1: s/opening up/opening/ s/cache i.e. there/ s/cache; i.e., there/ C12.3P1S1: s/level of security/levels of security/ C12.3P1S-1: /This isn't/ There seems to be a dangling sentence here. C13P1S4: s/5.1.2 to 5.1.9/5.1.2 through 5.1.9/ C13P3S2: s/5.2.2 to 5.2.5/5.2.2 through 5.2.5/ C13P3: Need to add entries for Nonce Indices and Authentication Data parameters. C13P5: The destination sub-options will probably disappear. C13P6S1: s/IPv6 Routing Header type, 2/IPv6 Type 2 Routing header/ C13P6S2: /The value 2 is/ The tense of 'is' seems odd, but I don't know if it's correct for this type of section. C14.1P1S1: /The use of IPSec/ This is a sentence fragment. s/protects/protect/ C14.2P1S-1: /Replay protection is provided/ I don't think that this sentence applies any longer. C14.3P2S2: s/in order to perform e.g./e.g., in order to perform/ C14.3P2S-1: /maximum of five minutes/ I'm not sure that a maximum was defined anywhere in the document. C14.3P3: This paragraph is very colloquial and rather loose. C14.3P3S1: s/node is when/node occur when/ C14.3P3S2: s/path as well but/path, as well, but/ C14.3P3S3: s/security as well in/security, as well as in/ C14.4P1S3: s/the answers/replies/ C14.4P1S-2: /the home address has agreed/ I'm not sure what it means for the home address to agree to anything. C14.4P3: /A node receiving/ This paragraph is not about security and should be removed. C14.5P2S-1: s/inside as well as/inside, as well as/ C14.5P3S1: s/that device which implement/that a device which implements/ s/distinguish routing header type 2 from other routing/ s/distinguish between a Type 2 Routing header and other Routing/ C14.5P3S-1: s/use of routing/uses of Routing/ Acknowledgements: s/University of California at Santa Barbara/ University of California, Santa Barbara/ enjoy, Bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 17 19:04:32 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10486 for ; Wed, 17 Apr 2002 19:04:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06513; Wed, 17 Apr 2002 16:04:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18438; Wed, 17 Apr 2002 16:03:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HN2dIA004598 for ; Wed, 17 Apr 2002 16:02:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HN2dQv004595 for mobile-ip-dist; Wed, 17 Apr 2002 16:02:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HN2aIA004588 for ; Wed, 17 Apr 2002 16:02:36 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17992 for ; Wed, 17 Apr 2002 16:02:40 -0700 (PDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03106 for ; Wed, 17 Apr 2002 17:02:39 -0600 (MDT) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3HN2cO15591; Wed, 17 Apr 2002 16:02:38 -0700 (PDT) Message-ID: <3CBDFF0E.2679A217@cs.ucsb.edu> Date: Wed, 17 Apr 2002 16:02:38 -0700 From: Robert Chalmers Organization: UCSB Computer Science X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "Charles E. Perkins" Subject: [mobile-ip] Editorial comments on Draft 16 - Sections 1-5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Comments on draft 16. I realize that this is an interim draft, but I wanted to ensure that these issues were addressed in draft 17. Note: These are mainly editorial nits, but I wasn't sure if Charlie was the only one still editing the document. I've broken up the comments into two parts to ensure that they will fit within the e-mail size limit. First off, I think that the current version of the draft is hard to read and very repetitious. We need to limit explaining things in more than one place. This usually leads to inconsistencies when changes are made (as will soon be seen). In particular, Section 4 should really only be an overview. It should contain just the high-level view of the protocol necessary for the reader to understand how it works. Details (SHOULDs and MUSTs) should occur in later sections describing the requirements and operations (7-10). Another general problem throughout the document is the inconsistent use of capitalization. At times home agent, binding update, etc. are capitalized, and other times not. If something is a major term defined in the document then I think it should be capitalized everywhere. Now on to the specifics (most of you will probably want to hit Del at this point). I'll use the notation C1P1S1 to mean chapter (section) 1, paragraph 1, sentence 1. Negative numbers count from the end; e.g., C1P1S-1 would be the last sentence of the first paragraph. If not clear, I'll indicate the context of the comment with /pertinent text/, and I'll indicate possible word (phrase) substitution with s/hapy/happy/. C2P3S-1: s/nor stationary/or stationary/ C2P9S-1: /due to the ability to not be concerned with/ This could be made more concise in terms of 'decoupling'. C2P11S1: s/used IPv4/uses IPv4/ s/and returned a/and returns a/ C2P11S-1: Odd sentence and actually somewhat questionable. Do you really think that a "huge" number of home agents would respond causing implosion and severe packet loss? I think you're more likely to simply lose a packet in the network. C2P12S1: s/option on/option for/ C3.1P11: /Security Association/ This term, SPD, Binding Key and BSA are capitalized while the other terms are not. Also the first word, a, is not capitalized for three of the four. Finally, the last sentence mentions a key defined above where no key had been previously defined. C3.2P1: /home address/ The definition is somewhat circular with respect to 'home link'. C3.2P10: /care-of address/ This should be moved before the definition of 'home agent' since that definition refers to the CoA. C3.2P10S2: s/at a time/any given time/ C4: This section is the most inconsistent in its level of detail. Moreover, the ordering is odd. The basic operation should probably be first, and should probably subsume Section 4.8. All new protocols, destination options, ICMP messages, etc. should be presented in order. Currently they are separated by too much description - it gets confusing. C4.1P1S1: I'd lose the pre-reference to Section 4.2. It doesn't help. C4.1P2S1: Return Routability needs to be defined as a term in Section 3.2. C4.1P2S2: s/subsequence/subsequent/ C4.1P6S-2: s/Section 4.5/Section 4.5.5/ C4.1P7S-2: s/Section 4.5/Section 4.5.5/ C4.1P8S1: s/request a mobile node to send/request that a mobile node send/ C4.1P10,11: This is not really overview material. It should be pushed to Section 5.1.1. C4.2P4S2: s/This binding registration is done by the mobile node/ The mobile node performs this binding registration by/ C4.2P4S3: s/address in this binding registered with its home agent/ address associated with this binding registration/ C4.2P5S1: s/node's care-of/node's new care-of/ C4.2P5S2: /it is specified to be used/ Odd sentence structure. C4.2P6S-1: /care-of addresses/ Why multiple addresses? The section talks about only one home address - multiple home addresses are introduced much later. C4.2P8S1: s/destination option/message/ C4.2P9: Refers to piggybacking, and should be removed. C4.2P10: No mention is made of HAO being legal only when route optimization is being used, i.e., a binding cache entry exists at CN. Too much detail is not necessary, but it should be stated in the overview that reverse tunneling is now the 'basic' mode. C4.2P10S4: /yet ingress filtering/ Odd sentence. Why is 'yet' used here? The second clause does not contradict the first. What does the second clause actually add to the sentence? C4.3P1S1: /As mentioned in/ The reference doesn't really help here. C4.3P2S3: /transparent to the correspondent node/ We should be careful here. It is only transparent to upper layers. C4.3P2S-2: s/sections 10.2 and 5.3/Sections 5.3 and 10.2/ C4.4: This is not really overview material. It should be pushed to Section 5.3. C4.5: This should really be the last sub-section of the overview section, and it should only contain overview material pertinent to security such as the threats, features and rationale. The actual operations should be moved to the operational sections (8-10). C4.5.1: This section needs to be rewritten to sound less colloquial. Words like 'lie' and 'trick' should be replaced with more formal terms. Plus, capitalization is inconsistent with previous sections: s/binding update/Binding Update/ C4.5.1P2S2: s/a attacker/An attacker/ C4.5.1P2S-1: s/didn't/did not/ C4.5.1P4S3: s/node accepted this/node accepts this/ C4.5.1P4S3,4: s/mobile/mobile node/ s/correspondent/correspondent node/ C4.5.1P7S1: s/is used to/is leveraged to/ s/other parties/a third party:/ C4.5.1P7S2: s/traffic against a/traffic toward a/ s/without giving a possibility for/without allowing/ C4.5.1P8: Rather thin description. C4.5.1P9S1: s/where IPv6/where the IPv6/ s/from other nodes./from other nodes:/ C4.5.1P9S2: s/allows the kind/allows this kind/ s/MIPV6 needs/MIPv6 requires/ C4.5.1P11: Should be included with the intro paragraph for this sub-section. C4.5.2P2S2: s/can thus have/thus have/ C4.5.2P2S-1: s/4.5.5/4.5.4/ C4.5.2P3S2: s/belonging under/belonging to/ This sentence is the a conclusion and should be stated at the end of the paragraph, or stated first and then defended. C4.5.2P4S1: /A different approach/ Different from what, an infrastructure-less approach? The difference between infrastructured versus infrastructure-less was made in the previous paragraph. C4.5.2P4S2: /with the addresses/ You don't really perform an exchange with addresses. s/sent cookies/exchanged cookies/ C4.5.2P5S1: s/as follows./as follows:/ C4.5.3: The title doesn't really fit the content. The text pertains only to reverse tunneling. C4.5.4P2S2: s/used to for/used for/ C4.5.5P1S3: /receive traffic on them/ Do you really receive traffic on an address? C4.5.5P1S5: s/exchanges were responses/exchanges where responses/ C4.5.5P1S6: s/receive the a binding/receive a binding/ C4.5.5P3S-1: s/will can be/will be/ C4.5.5P5: Here 'l' is used as one of the nonce subscripts when later 'i' is used. In fact, if 'i' and 'j' are used they should be used in order. In later text, 'j' is used before 'i' and it seems odd. C4.5.5: /HoTI (Home Test Init) Message/ s/This message tells/This message imparts/ or /This message conveys/ C4.5.5: /CoT (Care-of Test) Message/ s/sent directly the mobile node./sent directly to the mobile node at its CoA/ s/used for distinguishing home/used to distinguish between home/ s/from each other// C4.5.6P3S1: s/situations it is/situations in which it is/ C4.5.6P3S2: s/treat/consider/ C4.5.6P4S4: s/by stopping/by not/ C4.5.7: Should probably be the first security sub-section. C4.6P6: Need a period at end of last sentence. Plus, should add 'This message is specified in Section 5.9' for consistency. C4.7P9: Sequence number is back to 16-bits. There's actually an old reference to "int" data type which should have been changed to "char", but is now correct. C4.7P10S-1: s/lifetime on/lifetime of/ C4.7P13: /SHOULD NOT be deleted/ /MUST NOT be changed/ Seems a bit heavy for an overview of the conceptual data structures., and it's probably all repeated later anyway. C4.7P16: /The home address for which/ s/home addresses/home address/ The second bullet is a bit confusing. C4.7P20: Sequence number is back to 16-bits. C4.8P3S-1: s/4.5/4.5.5./ C4.8P5: This is a repeat from what was already said in the Basic Operation sub-section. C5.1P1S3: s/5.1.2 to 5.1.9/5.1.2 through 5.1.9/ C5.1P1S4: This seems like an odd place for this requirement. I'd leave it for specific sections pertaining to MN operations. C5.1.1P6S2: /MH Type/ s/5.1.2 to 5.1.8/5.1.2 through 5.1.9/ C5.1.1P7S3: /Checksum/ s/section 8.1/Section 8.1/ C5.1.2P1S-1: s/NOT respond Binding/NOT respond to Binding/ C5.1.2P4S1: /Parameters/ Lose the comma after 'Variable-length field'. This is repeated for all message descriptions. C5.1.2P4: The sentence from paragraph 6, 'The encoding and format ... in Section 5.2', should be moved up to this paragraph to provide a pre-reference for the Authentication Data parameter. This also occurs in Sections 5.1.7 and 5.1.8. C5.1.2P5S-1: /The actual authenticator calculation/ s/over sequence/over a sequence/ The reference to the description in Section 4.5 doesn't seem to exist. This also occurs in Sections 5.1.7 and 5.1.8. C5.1.3P1S1: Should specifically mention that the procedure is to test the validity of the home address. C5.1.3P3: /Flags/ This should simply be a reserved field. There shouldn't be any specific purpose designated for the bits. C5.1.3P5: /If no actual parameters/ No padding required. C5.1.4P1S1: Should specifically mention that the procedure is to test the validity of the care-of address. C5.1.4P3: /Reserved/ This should simply be a reserved field. There shouldn't be any specific purpose designated for the bits. C5.1.5P1S1: s/is an answer/is a response/ C5.1.5: The home cookie is a 128-bit field aligned on a 32-bit boundary. I do believe it should be on a 64-bit boundary. C5.1.5P3: /Reserved/ This should be a contiguous 32-bit field. Otherwise, it has to be separated into two separate 16-bit reserved fields. Again, it should not be specifically reserved for use by future flags. C5.1.5P9S-1: s/prevent attackets e.g. on the same link as the MN to/ prevent attackers, possibly on the same link as the MN, to/ C5.1.6P1S1: s/is an answer/is a response/ C5.1.6: The care-of cookie is a 128-bit field aligned on a 32-bit boundary. I do believe it should be on a 64-bit boundary. C5.1.6P3: /Reserved/ This should be a contiguous 32-bit field. Otherwise, it has to be separated into two separate 16-bit reserved fields. Again, it should not be specifically reserved for use by future flags. C5.1.7P4S-1: /Home Registration/ The last part in parentheses, 'given by the ...', is confusing at this point in the document. Since the HoA is provided in the BU, nothing should be said here. Later, it is stated that the HAO is necessary and that both addresses must match. C5.1.7P6S1: s/request the receiving/request that the receiving/ s/to perform Duplicate/perform Duplicate/ C5.1.7P8S-1: /Sequence Number/ The last sentence no longer applies. Error code 141 should probably mention here for consistency. C5.1.7P10S1: /Home Address/ Replace the existing sentence with something like: 'The home address of the mobile node associated with this Binding Update.' C5.1.7P16S1: s/message to the correspondent/message to a correspondent/ s/include the Home/include a Home/ s/avoid reflection/avoid the reflection/ C5.1.7P16S2: s/A Binding Update/However, a Binding Update/ C5.1.7P17S2: s/check for the equal/check for equal/ C5.1.7P18: This paragraph is unnecessary and confusing with respect to previous paragraphs. C5.1.7P20S1: s/, if present,// C5.1.7P22S1: s/Binding parameter/Binding Update/ C5.1.7P20,22: Seems like a bit too much detail for this section. C5.1.8P1S2: s/Binding Parameter carried in the// C5.1.8P1S3: s/an answer/in response/ The sentence should actually be reworded to avoid ending that clause in 'to'. C5.1.8P4: /144/ and /145/ s/Too old/Expired/ C5.1.8P6S1: /Lifetime/ s/node will SHOULD/node SHOULD/ C5.1.8P7S1: s/keep on using/continue to use/ s/of outgoing/on outgoing/ C5.1.8P8S-1: /Refresh/ The last sentence no longer applies. C5.1.8P14S-1: s/inserted to the message/added to the message/ C5.1.8P15S-1: s/Binding Ack Parameter/Binding Acknowledgement/ C5.1.9P1S2: s/Option i.e./Option, i.e.,/ C5.1.9P2-5: These belong in the MN operations section. C5.1.9P3S2: s/loss of resources spent on the/a waste of resources on/ C5.1.9P7: /Reserved/ This should simply be a reserved field. There shouldn't be any specific purpose designated for the bits. C5.1.9P8S-1: /Home Address/ s/if there mobile/in cases where the mobile/ C5.2.1P5S-1: /Parameter Type/ s/sub-options in the option/ s/parameters in the message/ C5.2.1P6S2: /Parameter Length/ s/the Parameter Data field// C5.2.1P6S3: /Parameter Length/ Why is this different from the way destination sub-options were used - length excludes first two fields? Is there a precedent we are following? C5.2.1P7: /Parameter Data/ Replace existing text with something like: 'A variable length field that contains data specific to the parameter.' C5.2.1P8: An odd question - if all parameters must start on 8-byte boundaries, why don't we make all message end on 8-byte boundaries. Is is to simply make those message without a parameter take up minimum space. When considering those that require a parameter, though, does it make any since to 'require' padding. Wouldn't that space be better spent as reserved space. C5.2.2-5.2.7: A new format has been introduced here. The name of the parameter is repeated, and the alignment requirement are in parentheses. It should be kept consistent with the other packet formats. C5.2.2P3S-1: s/used, rather/used rather/ C5.2.3P2S1: s/into the Parameters area of some/in the Parameter of a/ C5.2.4P1S1: s/Identifier parameter/Identifier Parameter/ C5.2.4P2: The HoTI and CoTI messages mention this parameter as legal, but here it says only BU and BR can have it. C5.2.5P1S1: s/Address parameter/Address Parameter/ C5.2.6P1S1: s/8n+6/8n+2/ C5.2.7P1S1: s/8n+6/8n+2/ C5.3P1S-2: Again, we should be careful about the use of the word transparent. C5.3: This sub-section should be rearranged a little. The last paragraph (P14) should immediately follow P7, 'The alignment requirement...'. P13 should follow P14. P8, 'The inclusion of...', should be moved to the end of the sub-section. C5.4P1S1: s/node which the/node. The/ C5.4P2: Reword the paragraph to something like: 'This uses a different routing header type than defined for "regular" IPv6 source routing, enabling firewalls to apply different rules to source routed packets than to MIPv6. This routing header type (Type 2) is restricted to carry only one IPv6 address. All IPv6 nodes which process this routing header MUST verify that the address contained within is the node's own home address in order to prevent packets from being forwarded outside the node.' C5.4.1P4: /Routing Type/ A full sentence would be more clear. C5.4.1P5: /Segments Left/ s/remaining, i.e., number/remaining; i.e., the number/ The last sentence is not quite true. Segments left can be decremented within the node and resubmitted to the IP stack. On the second pass, the field will be zero, and this is still a valid header. C5.4.1P6: /Reserved/ s/transmission; ignored/transmission, and ignore/ C5.4.2: This should be moved to the CN operations section. C5.4.2P1S2: s/cache and if/cache. If/ s/then the IP/, then the IP/ s/of type 2/with type 2/ s/rules below and moves the Home Address to/ rules below. The Home Address is copied into/ s/RH and places the Care of Address in/ RH, and the Care-of Address is placed in/ C5.4.2P2S1: s/conceptually/conceptual/ C5.4.3P1S2: s/routing header of type 2/Type 2 Routing header/ C5.4.3P1: All bullets need final periods. C5.4.3P2: If you follow these steps, the packet would then fail the tests in the previous paragraph. C5.4.3P2S1: This is a sentence fragment. C5.4.3P2S2: s/RFC 2460 i.e. swap/RFC 2460; i.e., swap/ C5.4.3P3: The paragraph is not very clear. It depends on a previous explanation of how t he original AH was calculated. It may be helpful to repeat that part here. C5.4.3P3S1: s/Header any/Header, any/ C5.4.3P3S-1: Replace the sentence with something like: 'Thus, the AH calculations at the sender and receiver will have an identical view of the packet.' C5.4.4P1: The paragraph is oddly presented. It could be made clearer with something like: 'The ordering rules for extension headers in an IPv6 packet are described in Section 4.1 of RFC 2460. The new Routing header (Type 2) defined for Mobile IPv6 follows the same ordering as other routing headers. If more than one routing header (e.g., both a Type 0 and a Type 2 Routing header are present), the Type 2 Routing header should follow all other Routing headers.' C5.4.5P1S-1: s/done to type 2 routing headers/done for Type 2 Routing headers/ C5.5: I believe this section will be removed. If not, however, it should be made a sub-section of Section 5.3. C5.6P1S-1: s/agents there responds/agents responds/ s/message giving/message, providing/ C5.6P7S2: s/then MUST return/MUST then return/ C5.6P7S-1: s/node not registered/node is not registered/ C5.1P1S-1: s/agents there responds/agents responds/ s/message giving/message, providing/ C5.9P1S-1: This section refers to itself. Should this be Section 9.7? C5.9P2: /Source Address/ s/i.e. same prefix/i.e., same network prefix/ C5.9P4: /Authentication Header/ Replace description with something like: 'An AH header MUST be included unless the mobile node has yet to configure a home address.' C5.9P8S1: /Prefix Information/ s/options,/options./ s/which contain/Each option carries/ s/the mobile node should/that the mobile node should use to/ s/address(es) with./address(es)./ C5.9P11S2: /Home Agents MUST ignore/ Should this be 'Mobile nodes MUST ignore'? enjoy, Bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 17 19:28:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10857 for ; Wed, 17 Apr 2002 19:28:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13406; Wed, 17 Apr 2002 17:28:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29570; Wed, 17 Apr 2002 16:28:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HNS2IA004766 for ; Wed, 17 Apr 2002 16:28:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3HNS2IW004765 for mobile-ip-dist; Wed, 17 Apr 2002 16:28:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3HNRxIA004758 for ; Wed, 17 Apr 2002 16:27:59 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18028 for ; Wed, 17 Apr 2002 16:28:02 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07404 for ; Wed, 17 Apr 2002 17:28:02 -0600 (MDT) 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 QAA20184; Wed, 17 Apr 2002 16:28:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3HNS0W15361; Wed, 17 Apr 2002 16:28:00 -0700 X-mProtect: <200204172328> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrskMgI; Wed, 17 Apr 2002 16:27:58 PDT Message-ID: <3CBE04FF.DD0C2869@iprg.nokia.com> Date: Wed, 17 Apr 2002 16:27:59 -0700 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: jari.arkko@piuha.net CC: Tuomas Aura , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, Jari Arkko wrote: > So, we need to figure out if there is a serious enough vulnerability > without BA/BR authentication. > > The attack we had in mind was a DoS attack where the attacker > bombs the MN with bogus HoTs or CoTs. In the plain RR protocol > these can be sent from anywhere in the Internet, and the MN has > no way of distinguishing them from each real ones. Granted, the > attacker has to be sending these messages all the time unless he > knows when RR is initiated. As a result of the attack, BU fails. > This failure is though noticeable in the form of an error code in > the BA. As a result, the MN may not get RO but at least it can > still keep on doing bidirectional tunneling. > > In a more serious variant of the attack the attacker spoofs also > successful BAs. If the MN happens to believe them, it starts RO > while the real CN doesn't have a BCE, leading to at least some > packets being blackholed. It may be possible to survive this given > that there most likely isn't any forward progress on application > layer and the BM messages keep coming to the MN. However, the MN > may need some intelligence in getting out of the attack situation > and staying with bidirectional tunneling while the attacker continues > the attack. > > Is this serious enough? I'm not sure! A question about the serious variant of the attack. When this attacker spoofs the successful BA, has the MN sent out another BU? If no, then there is no problem. The spoofed BA is dropped because there is no corresponding pending BU. If yes, then the sequence numbers dont match. The BA is dropped. If the attacker was able to guess the right sequence number he still cant use it. This is because the MAC_Kbu in the BA wont be correct and the spoofed BA is dropped. So the scenario where the MN believes the CN has a BCE while the CN does not, cannot happen. Please let me know if I am missing something. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Apr 17 21:23:18 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12489 for ; Wed, 17 Apr 2002 21:23:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24687; Wed, 17 Apr 2002 19:23:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01191; Wed, 17 Apr 2002 18:21:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3I0wgIA004917 for ; Wed, 17 Apr 2002 17:58:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3I0wgAt004916 for mobile-ip-dist; Wed, 17 Apr 2002 17:58:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3I0wdIA004909 for ; Wed, 17 Apr 2002 17:58:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24564 for ; Wed, 17 Apr 2002 17:58:39 -0700 (PDT) Received: from mail.imnetpia.com ([211.237.39.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09809 for ; Wed, 17 Apr 2002 18:58:38 -0600 (MDT) Received: from vonbill ([211.237.39.126]) by mail.imnetpia.com (8.11.0/8.11.0) with SMTP id g3I0vMV30084 for ; Thu, 18 Apr 2002 09:57:22 +0900 Message-ID: <007801c1e674$2ca043e0$7e27edd3@vonbill> From: "HoGeun Lee" To: Subject: [mobile-ip] Does Windows support for Mobile IPv6? Date: Thu, 18 Apr 2002 09:58:38 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01C1E6BF.9C726810" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0075_01C1E6BF.9C726810 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8uIA0KDQpBcyBmYXIgYXMgSSBrbm93LCBXaGVuIHdlIHVzZSBJUHY2IGluIHdpbmRvd3MN Cg0KV0luZG93cyAyMDAwIG5lZWRzIElQdjYgcGF0Y2guDQpXSW5kb3dzIFhQIGhhcyBidWlpdCBp biBJUHY2IHN0YWNrIGJ1dCBuZWVkcyB0byBiZSBlbmFibGVkLg0KDQpUaGUgV2luZG93cyB0aGF0 IEkgbWVudGlvbmVkIGlzIElQdjYgZW5hYmxlZCB3aW5kb3dzIDIwMDAgYW5kIElQdjYgZW5hYmxl ZCB3aW5kb3dzIFhQLg0KSW4gdGhpcyBjYXNlLCBJIHdhbnQgdG8ga25vdyBpZiBUSEVTRSBXSU5E T1dTIFNVUFBPUlQgTU4gRlVOQ1RJT05BTElUWS4NCmFuZCBpZiBzbywgd2hpY2ggSW50ZXJuZXQt ZHJhZnQgdmVyc2lvbiBpcyB0aGUgYmFzZWQgZm9yIHN1cHBvcnRpbmcgZm9yIG1vYmlsZSBJUHY2 ID8NCg0KSSBhbSB0cnlpbmcgdG8gc2V0dXAgYSB0ZXN0YmVkIGZvciBNb2JpbGUgSVB2Ni4gSEEg bWF5IGJlIHRoZSBsaW51eCBiYXNlZCwgDQpJcyB0aGVyZSB0aGUgaW50ZXJvcGVyYWJpbGl0eSBp biBjYXNlIHRoYXQgSEEgKEhvbWUgQWdlbnQpIGlzIExpbnV4IGJhc2VkIE1hY2hpbmUgYW5kIE1O IGlzIHdpbmRvd3MgYmFzZWQgbWFjaGluZT8NCg0KdGhhbmtzIGluIGFkdmFuY2UuDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpIb0dldW4gTGVlDQoN CklNbmV0cGlhIENvLiwgTHRkLiAoaHR0cDovL3d3dy5pbW5ldHBpYS5jb20pDQpSJkQgRGl2LiAv IEFzc2lzYW50IHJlc2VhcmNoIGVuZ2luZWVyDQogDQo5RiwgODIzLTIzLCBIb1NhbiBCL0QsIFll b2tzYW0tRG9uZywNCkthbmduYW0tR3UsIFNlb3VsLCBLb3JlYSAgMTM1LTA4MA0KUGhvbmUgIDog KDgyLTIpICA1NjctMDk1Nw0KRmF4LiAgICAgIDogKDgyLTIpICA1NjctMDM2OA0KTW9ibGllICA6 ICg4Mi0xNikgMjUzLTI1OTINCkUtbWFpbCAgOiBob2dldW5AaW1uZXRwaWEuY29tLCANCk1TTiA6 IHZvbmJpbGxAaG90bWFpbC5jb20NCg0K ------=_NextPart_000_0075_01C1E6BF.9C726810 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTUuNDAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPjxG T05UIGZhY2U9sby4ssO8IHNpemU9Mj5IZWxsby4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPbG8uLLDvCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPbG8 uLLDvCBzaXplPTI+QXMgZmFyIGFzIEkga25vdywgV2hlbiB3ZSB1c2UgSVB2NiBpbiANCndpbmRv d3M8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj5XSW5kb3dzIDIwMDAgbmVl ZHMgSVB2NiBwYXRjaC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9sby4ssO8IHNpemU9 Mj5XSW5kb3dzIFhQIGhhcyBidWlpdCBpbiBJUHY2IHN0YWNrIGJ1dCBuZWVkcyB0byBiZSANCmVu YWJsZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+VGhlIFdpbmRvd3Mg dGhhdCZuYnNwO0kgbWVudGlvbmVkIGlzIElQdjYgZW5hYmxlZCANCndpbmRvd3MgMjAwMCBhbmQg SVB2NiBlbmFibGVkIHdpbmRvd3MgWFAuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPbG8 uLLDvCBzaXplPTI+SW4gdGhpcyBjYXNlLCBJIHdhbnQgdG8ga25vdyBpZiBUSEVTRSBXSU5ET1dT IFNVUFBPUlQgDQpNTiBGVU5DVElPTkFMSVRZLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT2xvLiyw7wgc2l6ZT0yPmFuZCBpZiBzbywgd2hpY2ggSW50ZXJuZXQtZHJhZnQgdmVyc2lvbiBp cyB0aGUgYmFzZWQgDQpmb3Igc3VwcG9ydGluZyBmb3IgbW9iaWxlIElQdjYgPzwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPkkmbmJzcDthbSB0cnlpbmcgdG8gc2V0dXAgYSZu YnNwO3Rlc3RiZWQgZm9yIE1vYmlsZSANCklQdjYuIDwvRk9OVD48Rk9OVCBmYWNlPbG8uLLDvCBz aXplPTI+SEEmbmJzcDttYXkgYmUgdGhlIGxpbnV4IGJhc2VkLCA8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9sby4ssO8PjxGT05UIHNpemU9Mj5JcyB0aGVyZSB0aGUgaW50ZXJvcGVyYWJp bGl0eSBpbiBjYXNlIHRoYXQgSEEgDQooSG9tZSBBZ2VudCkgaXMgTGludXggYmFzZWQgTWFjaGlu ZSBhbmQgTU4gaXMgd2luZG93cyBiYXNlZCANCm1hY2hpbmU/PC9GT05UPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPnRoYW5rcyBpbiBhZHZhbmNlLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+SG9HZXVuIA0KTGVl PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPklNbmV0 cGlhIENvLiwgTHRkLiAoPEEgDQpocmVmPSJodHRwOi8vd3d3LmltbmV0cGlhLmNvbSI+aHR0cDov L3d3dy5pbW5ldHBpYS5jb208L0E+KTxCUj5SJmFtcDtEIERpdi4gLyANCkFzc2lzYW50IHJlc2Vh cmNoIGVuZ2luZWVyPEJSPiZuYnNwOzxCUj45RiwgODIzLTIzLCBIb1NhbiBCL0QsIA0KWWVva3Nh bS1Eb25nLDxCUj5LYW5nbmFtLUd1LCBTZW91bCwgS29yZWEmbmJzcDsgMTM1LTA4MDxCUj5QaG9u ZSZuYnNwOyA6IA0KKDgyLTIpJm5ic3A7IDU2Ny0wOTU3PEJSPkZheC4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgOiAoODItMikmbmJzcDsgDQo1NjctMDM2ODxCUj5Nb2JsaWUmbmJzcDsg OiAoODItMTYpIDI1My0yNTkyPEJSPkUtbWFpbCZuYnNwOyA6IDxBIA0KaHJlZj0ibWFpbHRvOmhv Z2V1bkBpbW5ldHBpYS5jb20iPmhvZ2V1bkBpbW5ldHBpYS5jb208L0E+LCA8QlI+TVNOIDogPEEg DQpocmVmPSJtYWlsdG86dm9uYmlsbEBob3RtYWlsLmNvbSI+dm9uYmlsbEBob3RtYWlsLmNvbTwv QT48QlI+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0075_01C1E6BF.9C726810-- From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 05:11:46 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29530 for ; Thu, 18 Apr 2002 05:11:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03175; Thu, 18 Apr 2002 02:10:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19613; Thu, 18 Apr 2002 02:06:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3I8dEIA005531 for ; Thu, 18 Apr 2002 01:39:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3I8dEJJ005530 for mobile-ip-dist; Thu, 18 Apr 2002 01:39:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3I8dAIA005523 for ; Thu, 18 Apr 2002 01:39:10 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14418 for ; Thu, 18 Apr 2002 01:38:44 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21427 for ; Thu, 18 Apr 2002 02:38:43 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 95EEB6A901; Thu, 18 Apr 2002 11:38:36 +0300 (EEST) Message-ID: <3CBE6ECF.3040502@piuha.net> Date: Thu, 18 Apr 2002 09:59:27 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: lee inkyu Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Do we need Single Address Only bit? References: <20020417013109.2063.qmail@web11005.mail.yahoo.com> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit lee inkyu wrote: > 'draft-ietf-mobileip-ipv6-16.txt' defines > Single Address Only bit in 5.1.7. > > I wonder if it is really needed and want > to ask you the case when the bit has to be > set. This functionality is useful when the home link has multiple prefixes, and you want to register all your home addresses at the same time. See 10.7 and 9.1 for rules on when to set the bit. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 07:25:51 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01370 for ; Thu, 18 Apr 2002 07:25:50 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18696; Thu, 18 Apr 2002 05:24:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09356; Thu, 18 Apr 2002 04:20:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IAqbIA005763 for ; Thu, 18 Apr 2002 03:52:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IAqaOJ005762 for mobile-ip-dist; Thu, 18 Apr 2002 03:52:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IAqXIA005755 for ; Thu, 18 Apr 2002 03:52:33 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18521 for ; Thu, 18 Apr 2002 03:52:28 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28667 for ; Thu, 18 Apr 2002 03:52:26 -0700 (PDT) Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g3IAn9I8025159 for ; Thu, 18 Apr 2002 19:49:10 +0900 (KST) Message-ID: <00ee01c1e6c7$1b5e9bb0$792d024b@yhhan> From: "Youn-Hee Han" To: Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Thu, 18 Apr 2002 19:52:17 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01C1E712.8B11C630" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00EB_01C1E712.8B11C630 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIHBvaW50IG91dCBhbm90aGVyIHN0dW1ibGluZyBibG9jayBpbiBSRkMg MjQ2MSwgaW4gb3JkZXIgdG8gDQphY2hpdmUgZ29vZCBNSVB2NiBoYW5kb2ZmIHBlcmZvcm1hbmNl Lg0KDQpQYWdlIDU1IG9mIFJGQyAyNDYxIHN0YXRlcyB0aGUgZm9sbG93aW5ncy4NCg0KICAgQmVm b3JlIGEgaG9zdCBzZW5kcyBhbiBpbml0aWFsIHNvbGljaXRhdGlvbiwgaXQgU0hPVUxEIGRlbGF5 IHRoZQ0KICAgdHJhbnNtaXNzaW9uIGZvciBhIHJhbmRvbSBhbW91bnQgb2YgdGltZSBiZXR3ZWVu IDAgYW5kDQogICBNQVhfUlRSX1NPTElDSVRBVElPTl9ERUxBWS4gIFRoaXMgc2VydmVzIHRvIGFs bGV2aWF0ZSBjb25nZXN0aW9uIHdoZW4NCiAgIG1hbnkgaG9zdHMgc3RhcnQgdXAgb24gYSBsaW5r IGF0IHRoZSBzYW1lIHRpbWUsIHN1Y2ggYXMgbWlnaHQgaGFwcGVuDQogICBhZnRlciByZWNvdmVy eSBmcm9tIGEgcG93ZXIgZmFpbHVyZS4gIElmIGEgaG9zdCBoYXMgYWxyZWFkeSBwZXJmb3JtZWQN CiAgIGEgcmFuZG9tIGRlbGF5IHNpbmNlIHRoZSBpbnRlcmZhY2UgYmVjYW1lIChyZSllbmFibGVk IChlLmcuLCBhcyBwYXJ0DQogICBvZiBEdXBsaWNhdGUgQWRkcmVzcyBEZXRlY3Rpb24gW0FERFJD T05GXSkgdGhlcmUgaXMgbm8gbmVlZCB0byBkZWxheQ0KICAgYWdhaW4gYmVmb3JlIHNlbmRpbmcg dGhlIGZpcnN0IFJvdXRlciBTb2xpY2l0YXRpb24gbWVzc2FnZS4NCg0KVGhlIGFib3ZlIGJsb2Nr IHN0YXRlcyB0aGUgY2FzZSBmb3IgYW4gTU4gc2VuZGluZyBhbiBSUyBiZWZvcmUgcmVjZWl2aW5n IGFuIFJBLg0KV2hlbiBhbiBNTiBtb3ZlcyBhbmQgcmUtYXR0YWNoZXMgdG8gYSBuZXcgbGluaywg IHRyYW5zbWl0dGlvbiBhbiBSUyBwcmlvciB0byANCnJlY2V2aW5nIGFuIFJBIGlzIGdvb2QgYmVo YXZpb3IgZm9yIHJlZHVjaW5nIEwzIGhhbmRvZmYgdGltZXMuDQpIb3dldmVyLCB0aGUgZGVsYXlp bmcgYnkgc29tZSByYW5kb20gYW1vdW50IGV2aWRlbnRseSBiZWNvbWVzIGFuIG9ic3RhY2xlIA0K Zm9yIEwzIGhhbmRvZmYgcGVyZm9ybWFuY2UuIEFsdGhvdWdoIHRoZSByYW5kb20gZGVsYXkgYmVo YXZpb3IgaXMgYSBTSE9VTEQsIA0KdGhlcmUgc2hvdWxkIGJlIHNvbWUga2luZCBvZiByZWZlcmVu Y2UgaW4gdGhlIE1vYmlsZSBJUHY2IHNwZWMgdG8gaXQNCg0KUGFnZSA1NSBvZiBSRkMgMjQ2MSBh bHNvIHN0YXRlcyB0aGUgZm9sbG93aW5ncy4NCg0KICAgTW9yZW92ZXIsIGEgaG9zdCBTSE9VTEQg c2VuZCBhdCBsZWFzdCBvbmUgc29saWNpdGF0aW9uIGluIHRoZSBjYXNlIHdoZXJlIGFuDQogICBh ZHZlcnRpc2VtZW50IGlzIHJlY2VpdmVkIHByaW9yIHRvIGhhdmluZyBzZW50IGEgc29saWNpdGF0 aW9uLg0KICAgVW5zb2xpY2l0ZWQgUm91dGVyIEFkdmVydGlzZW1lbnRzIG1heSBiZSBpbmNvbXBs ZXRlIChzZWUgU2VjdGlvbg0KICAgNi4yLjMpOyBzb2xpY2l0ZWQgYWR2ZXJ0aXNlbWVudHMgYXJl IGV4cGVjdGVkIHRvIGNvbnRhaW4gY29tcGxldGUNCiAgIGluZm9ybWF0aW9uLg0KDQpJbiBvcmRl ciB0byByZXF1aXJlIGNvbXBsZXRlIG5ldyBsaW5rIGluZm9ybWF0aW9uLCB0aGUgYWJvdmUgYmxv Y2sgc3RhdGVzIA0KYW4gTU4gU0hPVUxEIHNlbmQgYW4gUlMsIGFsdGhvdWdoIGl0IHJlY2VpdmVz IGFuIHVuc29saWNpdGVkIFJBIHByaW9yIHRvIHNlbmRpbmcgYW4gUlMuDQpJIGFtIHdvcnJpZWQg dGhhdCB0aGUgQlVzIGZvciBuZXcgQ09BIG11c3QgYmUgc2VudCB0byBIQSBhbmQgQ04gb25seSBh ZnRlciANCnJlY2VpdmluZyBhIHNvbGljaXRlZCBSQS4gU3VjaCBiZWhhdmlvciBpcyBhbHNvIGFu IG9ic3RhY2xlIGZvciBMMyBoYW5kb2ZmIHBlcmZvcm1hbmNlLg0KQWx0aG91Z2ggc3VjaCBiZWhh dmlvciBpcyBhIFNIT1VMRCwgdGhlcmUgc2hvdWxkIGJlIHNvbWUga2luZCBvZiByZWZlcmVuY2Ug DQppbiB0aGUgTW9iaWxlIElQdjYgc3BlYyB0byBpdCwgdG9vLg0KDQoNCllvdW4tSGVlIEhhbiwN ClNhbXN1bmcgQWR2YW5jZWQgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kgKFNBSVQpDQoNCg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1lcyBLZW1wZiIgPGtlbXBmQGRv Y29tb2xhYnMtdXNhLmNvbT4NClRvOiAiRXJpayBOb3JkbWFyayIgPEVyaWsuTm9yZG1hcmtAU3Vu LkNPTT4NCkNjOiA8bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb20+DQpTZW50OiBUaHVyc2Rh eSwgQXByaWwgMTgsIDIwMDIgMTo1OCBBTQ0KU3ViamVjdDogUmU6IFttb2JpbGUtaXBdIFJBIFNv bGljaXRhdGlvbiBSZXNwb25zZSBEZWxheSBQZXJmb3JtYW5jZSBGYXRhbGl0eQ0KDQoNCj4gRXJp aywNCj4gDQo+IFdlJ3JlIHByZXBhcmluZyBhIHNlcGFyYXRlIGRyYWZ0IGZvciB0aGlzLCB3aGlj aCBJIHRoaW5rIHdlIHdpbGwgc3VibWl0DQo+IHRvIElQTkcgdGhpcyB3ZWVrLiBJdCBpcyB2ZXJ5 IHNob3J0ICg0IHBhZ2VzIEkgdGhpbmspLiBUaGUgZHJhZnQgYWRkcyBhDQo+IGJpdCB0byB0aGUg UlMgc2F5aW5nIHRoYXQgdGhlIGhvc3Qgd291bGQgbGlrZSBhbiBpbW1lZGlhdGUgcmVzcG9uc2Uu IE9mDQo+IGNvdXJzZSwgaG9zdHMgY2FuIGNoZWF0IGFuZCBzZW5kIGl0IGV2ZW4gaWYgdGhleSBh cmVuJ3QgZG9pbmcgTUlQDQo+IGhhbmRvdmVyLCBidXQgaWYgZXZlcnlib2R5IHBsYXlzIHRoZSBy dWxlcyB0aGUgY29uZ2VzdGlvbiBjb250cm9sIHNob3VsZA0KPiB3b3JrLCBsaWtlIFRDUC4NCj4g DQo+IFRoZSBvdGhlciBpc3N1ZSBpcyB3aGV0aGVyIHRoZXJlIHNob3VsZCBiZSBzb21lIGtpbmQg b2YgcmVmZXJlbmNlIGluIHRoZQ0KPiBNb2JpbGUgSVB2NiBzcGVjIHRvIGl0LCBzbyB0aGF0IGlt cGxlbWVudG9ycyBvZiBNb2JpbGUgSVB2NiBhcmUNCj4gcmVjb21tZW5kZWQgdG8gdXNlIGl0Lg0K PiANCj4gICAgICAgICAgICAgamFrDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t DQo+IEZyb206ICJFcmlrIE5vcmRtYXJrIiA8RXJpay5Ob3JkbWFya0BzdW4uY29tPg0KPiBUbzog IkphbWVzIEtlbXBmIiA8a2VtcGZAZG9jb21vbGFicy11c2EuY29tPg0KPiBDYzogPG1vYmlsZS1p cEBzdW5yb29mLmVuZy5zdW4uY29tPg0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAxNiwgMjAwMiA3 OjUwIFBNDQo+IFN1YmplY3Q6IFJlOiBbbW9iaWxlLWlwXSBSQSBTb2xpY2l0YXRpb24gUmVzcG9u c2UgRGVsYXkgUGVyZm9ybWFuY2UNCj4gRmF0YWxpdHkNCj4gDQo+IA0KPiA+ID4gVGhpcyBpc24n dCBzZWN1cml0eSByZWxhdGVkLCBidXQgSSB0aGluayBpdCBpcyBzb21ldGhpbmcgdGhhdCAqbXVz dCoNCj4gYmUNCj4gPiA+IGZpeGVkIGJlZm9yZSB0aGUgTUlQdjYgZ29lcyB0byBSRkMuDQo+ID4N Cj4gPiBJIHRoaW5rIGl0IGlzIHN1ZmZpY2llbnQgImJlZm9yZSBNSVB2NitJUHY2Ky4uLiBjYW4g YmUgZGVwbG95ZWQiIC0NCj4gPiB3aGlsZSB0aGUgaXNzdWUgaXMgaW1wb3J0YW50IEkgZG9uJ3Qg c2VlIHdoeSBpdCBuZWVkcyB0byBob2xkIHVwDQo+ID4gdGhlIE1JUHY2IHNwZWNpZmljYXRpb24u DQo+ID4NCj4gPiBJJ2QgcHJlZmVyIHRoaXMgYmVpbmcgZG9uZSBhcyBhIHNob3J0IHNlcGFyYXRl IGRyYWZ0IHNpbmNlIHRoaXMgbWFrZXMNCj4gaXQNCj4gPiBlYXNpZXIgdG8gZm9sZCBpdCBpbnRv IFJGQyAyNDYxIGF0IGEgbGF0ZXIgdGltZS4NCj4gPg0KPiA+ID4gSWRlYWxseSwgd2UgY291bGQg aW5zZXJ0IHNvbWUgdGV4dCBpbnRvIHRoZSBNSVB2NiBzcGVjIHNheWluZyB0aGF0DQo+IHRoaXMN Cj4gPiA+IGJlaGF2aW9yIG5lZWRzIHRvIGJlIG1vZGlmaWVkIGZvciByb3V0ZXJzIHRoYXQgYXJl IGhhbmRsaW5nIHdpcmVsZXNzDQo+ID4gPiBsaW5rcywgYnV0IHRoaXMgd291bGQgYmUgc29tZXdo YXQgY291bnRlciB0byB0aGUgdHJlbmQgaW4gTUlQdjYgb2YNCj4gPiA+IGludGVncmF0aW5nIE1J UCBtb3JlIHRpZ2h0bHkgd2l0aCBzdGFuZGFyZCBJUHY2IG1lY2hhbmlzbXMuDQo+ID4gPiBBbHRl cm5hdGl2ZWx5LCB3ZSBjb3VsZCBkbyBhIHNlcGFyYXRlIGRyYWZ0IHRoYXQgbW9kaWZpZWQgdGhl IHRleHQNCj4gaW4NCj4gPiA+IFJGQyAyNDYxIHRvIG1ha2UgdGhlIHJhbmRvbSBkZWxheSBiZWhh dmlvciBhIFNIT1VMRCwgb3IgYWRkIHJhdGUNCj4gPiA+IGxpbWl0aW5nIGJlaGF2aW9yIGluc3Rl YWQgKGkuZS4gbWFrZSB0aGUgcmFuZG9tIGRlbGF5IGJlaGF2aW9yIGJlIGENCj4gPiA+IGZ1bmN0 aW9uIG9mIHRoZSBpbmNvbWluZyBTb2xSQSByYXRlKS4NCj4gPg0KPiA+IFByZS1SRkMgdmVyc2lv bnMgb2YgbmVpZ2hib3IgZGlzY292ZXJ5IGhhZCBhIHRoZSBhYmlsaXR5IChpZiBteSBtZW1vcnkN Cj4gc2VydmVzDQo+ID4gbWUpIGZvciByb3V0ZXJzIHRvIGltbWVkaWF0ZWx5IHVuaWNhc3QgYSBS QSBpbiByZXNwb25zZSB0byBhIFJTLCBidXQNCj4gPiByYW5kb21seSBkZWxheSBhbmQgcmF0ZSBs aW1pdCBhbnkgbXVsdGljYXN0IFJBcyBzZW5kIGl0IHJlc3BvbnNlIHRvDQo+IFJTcy4NCj4gPg0K PiA+IEhhdmluZyBhIG1lY2hhbmlzbXMgdG8gc2VsZWN0IGJldHdlZW4gYW4gaW1tZWRpYXRlIHVu aWNhc3QgcmVzcG9uc2UNCj4gYW5kDQo+ID4gYSBkZWxheWVkIG11bHRpY2FzdCByZXNwb25zZSBz ZWVtZWQgbm90IHdvcnRoIHRoZSBlZmZvcnQgYXQgdGhlIHRpbWUsDQo+IGJ1dA0KPiA+IHRoYXQg aXMgYW4gYXZlbnVlIHRoYXQgY2FuIGJlIGV4cGxvcmVkIG5vdy4NCj4gPiBGb3IgaW5zdGFuY2Us IGlmIHRoZSBsYXN0IFJTIHdhcyByZWNlaXZlZCBsZXNzIHRoYW4gMyBzZWNvbmRzIGFnbw0KPiA+ IHRoZSByb3V0ZXIgY291bGQgZG8gdGhlIHJhbmRvbWx5IGRlbGF5ZWQgbXVsdGljYXN0IFJBOyBv dGhlcndpc2UNCj4gPiBhbiBpbW1lZGlhdGUgdW5pY2FzdCBSQS4NCj4gPg0KPiA+ICAgRXJpaw0K PiA+DQo+ID4NCj4gDQo+ ------=_NextPart_000_00EB_01C1E712.8B11C630 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ5MTUuNTAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPkkg d291bGQgbGlrZSB0byBwb2ludCBvdXQgYW5vdGhlciBzdHVtYmxpbmcgYmxvY2sgaW4gUkZDIDI0 NjEsIGluIG9yZGVyIHRvIA0KPEJSPmFjaGl2ZSBnb29kIE1JUHY2IGhhbmRvZmYgcGVyZm9ybWFu Y2UuPEJSPjxCUj5QYWdlIDU1IG9mIFJGQyAyNDYxIHN0YXRlcyB0aGUgDQpmb2xsb3dpbmdzLjxC Uj48QlI+Jm5ic3A7Jm5ic3A7IEJlZm9yZSBhIGhvc3Qgc2VuZHMgYW4gaW5pdGlhbCBzb2xpY2l0 YXRpb24sIGl0IA0KU0hPVUxEIGRlbGF5IHRoZTxCUj4mbmJzcDsmbmJzcDsgdHJhbnNtaXNzaW9u IGZvciBhIHJhbmRvbSBhbW91bnQgb2YgdGltZSANCmJldHdlZW4gMCBhbmQ8QlI+Jm5ic3A7Jm5i c3A7IE1BWF9SVFJfU09MSUNJVEFUSU9OX0RFTEFZLiZuYnNwOyBUaGlzIHNlcnZlcyB0byANCmFs bGV2aWF0ZSBjb25nZXN0aW9uIHdoZW48QlI+Jm5ic3A7Jm5ic3A7IG1hbnkgaG9zdHMgc3RhcnQg dXAgb24gYSBsaW5rIGF0IHRoZSANCnNhbWUgdGltZSwgc3VjaCBhcyBtaWdodCBoYXBwZW48QlI+ Jm5ic3A7Jm5ic3A7IGFmdGVyIHJlY292ZXJ5IGZyb20gYSBwb3dlciANCmZhaWx1cmUuJm5ic3A7 IElmIGEgaG9zdCBoYXMgYWxyZWFkeSBwZXJmb3JtZWQ8QlI+Jm5ic3A7Jm5ic3A7IGEgcmFuZG9t IGRlbGF5IA0Kc2luY2UgdGhlIGludGVyZmFjZSBiZWNhbWUgKHJlKWVuYWJsZWQgKGUuZy4sIGFz IHBhcnQ8QlI+Jm5ic3A7Jm5ic3A7IG9mIA0KRHVwbGljYXRlIEFkZHJlc3MgRGV0ZWN0aW9uIFtB RERSQ09ORl0pIHRoZXJlIGlzIG5vIG5lZWQgdG8gDQpkZWxheTxCUj4mbmJzcDsmbmJzcDsgYWdh aW4gYmVmb3JlIHNlbmRpbmcgdGhlIGZpcnN0IFJvdXRlciBTb2xpY2l0YXRpb24gDQptZXNzYWdl LjxCUj48QlI+VGhlIGFib3ZlIGJsb2NrIHN0YXRlcyB0aGUgY2FzZSBmb3IgYW4gTU4gc2VuZGlu ZyBhbiBSUyBiZWZvcmUgDQpyZWNlaXZpbmcgYW4gUkEuPEJSPldoZW4gYW4gTU4gbW92ZXMgYW5k IHJlLWF0dGFjaGVzIHRvIGEgbmV3IGxpbmssJm5ic3A7IA0KdHJhbnNtaXR0aW9uIGFuIFJTIHBy aW9yIHRvIDxCUj5yZWNldmluZyBhbiBSQSBpcyBnb29kIGJlaGF2aW9yIGZvciByZWR1Y2luZyBM MyANCmhhbmRvZmYgdGltZXMuPEJSPkhvd2V2ZXIsIHRoZSBkZWxheWluZyBieSBzb21lIHJhbmRv bSBhbW91bnQgZXZpZGVudGx5IGJlY29tZXMgDQphbiBvYnN0YWNsZSA8QlI+Zm9yIEwzIGhhbmRv ZmYgcGVyZm9ybWFuY2UuIEFsdGhvdWdoIHRoZSByYW5kb20gZGVsYXkgYmVoYXZpb3IgDQppcyBh IFNIT1VMRCwgPEJSPnRoZXJlIHNob3VsZCBiZSBzb21lIGtpbmQgb2YgcmVmZXJlbmNlIGluIHRo ZSBNb2JpbGUgSVB2NiBzcGVjIA0KdG8gaXQ8QlI+PEJSPlBhZ2UgNTUgb2YgUkZDIDI0NjEgYWxz byBzdGF0ZXMgdGhlIGZvbGxvd2luZ3MuPEJSPjxCUj4mbmJzcDsmbmJzcDsgDQpNb3Jlb3Zlciwg YSBob3N0IFNIT1VMRCBzZW5kIGF0IGxlYXN0IG9uZSBzb2xpY2l0YXRpb24gaW4gdGhlIGNhc2Ug d2hlcmUgDQphbjxCUj4mbmJzcDsmbmJzcDsgYWR2ZXJ0aXNlbWVudCBpcyByZWNlaXZlZCBwcmlv ciB0byBoYXZpbmcgc2VudCBhIA0Kc29saWNpdGF0aW9uLjxCUj4mbmJzcDsmbmJzcDsgVW5zb2xp Y2l0ZWQgUm91dGVyIEFkdmVydGlzZW1lbnRzIG1heSBiZSANCmluY29tcGxldGUgKHNlZSBTZWN0 aW9uPEJSPiZuYnNwOyZuYnNwOyA2LjIuMyk7IHNvbGljaXRlZCBhZHZlcnRpc2VtZW50cyBhcmUg DQpleHBlY3RlZCB0byBjb250YWluIGNvbXBsZXRlPEJSPiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlv bi48QlI+PEJSPkluIG9yZGVyIHRvIA0KcmVxdWlyZSBjb21wbGV0ZSBuZXcgbGluayBpbmZvcm1h dGlvbiwgdGhlIGFib3ZlIGJsb2NrIHN0YXRlcyA8QlI+YW4gTU4gU0hPVUxEIA0Kc2VuZCBhbiBS UywgYWx0aG91Z2ggaXQgcmVjZWl2ZXMgYW4gdW5zb2xpY2l0ZWQgUkEgcHJpb3IgdG8gc2VuZGlu ZyBhbiBSUy48QlI+SSANCmFtIHdvcnJpZWQgdGhhdCB0aGUgQlVzIGZvciBuZXcgQ09BIG11c3Qg YmUgc2VudCB0byBIQSBhbmQgQ04gb25seSBhZnRlciANCjxCUj5yZWNlaXZpbmcgYSBzb2xpY2l0 ZWQgUkEuIFN1Y2ggYmVoYXZpb3IgaXMgYWxzbyBhbiBvYnN0YWNsZSBmb3IgTDMgaGFuZG9mZiAN CnBlcmZvcm1hbmNlLjxCUj5BbHRob3VnaCBzdWNoIGJlaGF2aW9yIGlzIGEgU0hPVUxELCB0aGVy ZSBzaG91bGQgYmUgc29tZSBraW5kIG9mIA0KcmVmZXJlbmNlIDxCUj5pbiB0aGUgTW9iaWxlIElQ djYgc3BlYyB0byBpdCwgdG9vLjxCUj48QlI+PEJSPllvdW4tSGVlIA0KSGFuLDxCUj5TYW1zdW5n IEFkdmFuY2VkIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5IChTQUlUKTxCUj48QlI+PEJSPi0tLS0t IA0KT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8QlI+RnJvbTogIkphbWVzIEtlbXBmIiAmbHQ7PEEg DQpocmVmPSJtYWlsdG86a2VtcGZAZG9jb21vbGFicy11c2EuY29tIj5rZW1wZkBkb2NvbW9sYWJz LXVzYS5jb208L0E+Jmd0OzxCUj5UbzogDQoiRXJpayBOb3JkbWFyayIgJmx0OzxBIA0KaHJlZj0i bWFpbHRvOkVyaWsuTm9yZG1hcmtAU3VuLkNPTSI+RXJpay5Ob3JkbWFya0BTdW4uQ09NPC9BPiZn dDs8QlI+Q2M6ICZsdDs8QSANCmhyZWY9Im1haWx0bzptb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3Vu LmNvbSI+bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb208L0E+Jmd0OzxCUj5TZW50OiANClRo dXJzZGF5LCBBcHJpbCAxOCwgMjAwMiAxOjU4IEFNPEJSPlN1YmplY3Q6IFJlOiBbbW9iaWxlLWlw XSBSQSBTb2xpY2l0YXRpb24gDQpSZXNwb25zZSBEZWxheSBQZXJmb3JtYW5jZSBGYXRhbGl0eTxC Uj48QlI+PEJSPiZndDsgRXJpayw8QlI+Jmd0OyA8QlI+Jmd0OyBXZSdyZSANCnByZXBhcmluZyBh IHNlcGFyYXRlIGRyYWZ0IGZvciB0aGlzLCB3aGljaCBJIHRoaW5rIHdlIHdpbGwgc3VibWl0PEJS PiZndDsgdG8gDQpJUE5HIHRoaXMgd2Vlay4gSXQgaXMgdmVyeSBzaG9ydCAoNCBwYWdlcyBJIHRo aW5rKS4gVGhlIGRyYWZ0IGFkZHMgYTxCUj4mZ3Q7IGJpdCANCnRvIHRoZSBSUyBzYXlpbmcgdGhh dCB0aGUgaG9zdCB3b3VsZCBsaWtlIGFuIGltbWVkaWF0ZSByZXNwb25zZS4gT2Y8QlI+Jmd0OyAN CmNvdXJzZSwgaG9zdHMgY2FuIGNoZWF0IGFuZCBzZW5kIGl0IGV2ZW4gaWYgdGhleSBhcmVuJ3Qg ZG9pbmcgTUlQPEJSPiZndDsgDQpoYW5kb3ZlciwgYnV0IGlmIGV2ZXJ5Ym9keSBwbGF5cyB0aGUg cnVsZXMgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBzaG91bGQ8QlI+Jmd0OyANCndvcmssIGxpa2Ug VENQLjxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBvdGhlciBpc3N1ZSBpcyB3aGV0aGVyIHRoZXJlIHNo b3VsZCBiZSBzb21lIA0Ka2luZCBvZiByZWZlcmVuY2UgaW4gdGhlPEJSPiZndDsgTW9iaWxlIElQ djYgc3BlYyB0byBpdCwgc28gdGhhdCBpbXBsZW1lbnRvcnMgb2YgDQpNb2JpbGUgSVB2NiBhcmU8 QlI+Jmd0OyByZWNvbW1lbmRlZCB0byB1c2UgaXQuPEJSPiZndDsgDQo8QlI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCmphazxCUj4mZ3Q7IDxCUj4mZ3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS08QlI+Jmd0OyBGcm9tOiAiRXJpayBOb3JkbWFyayIgDQombHQ7PEEgaHJlZj0ibWFpbHRvOkVy aWsuTm9yZG1hcmtAc3VuLmNvbSI+RXJpay5Ob3JkbWFya0BzdW4uY29tPC9BPiZndDs8QlI+Jmd0 OyANClRvOiAiSmFtZXMgS2VtcGYiICZsdDs8QSANCmhyZWY9Im1haWx0bzprZW1wZkBkb2NvbW9s YWJzLXVzYS5jb20iPmtlbXBmQGRvY29tb2xhYnMtdXNhLmNvbTwvQT4mZ3Q7PEJSPiZndDsgDQpD YzogJmx0OzxBIA0KaHJlZj0ibWFpbHRvOm1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tIj5t b2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbTwvQT4mZ3Q7PEJSPiZndDsgDQpTZW50OiBUdWVz ZGF5LCBBcHJpbCAxNiwgMjAwMiA3OjUwIFBNPEJSPiZndDsgU3ViamVjdDogUmU6IFttb2JpbGUt aXBdIFJBIA0KU29saWNpdGF0aW9uIFJlc3BvbnNlIERlbGF5IFBlcmZvcm1hbmNlPEJSPiZndDsg RmF0YWxpdHk8QlI+Jmd0OyA8QlI+Jmd0OyANCjxCUj4mZ3Q7ICZndDsgJmd0OyBUaGlzIGlzbid0 IHNlY3VyaXR5IHJlbGF0ZWQsIGJ1dCBJIHRoaW5rIGl0IGlzIHNvbWV0aGluZyB0aGF0IA0KKm11 c3QqPEJSPiZndDsgYmU8QlI+Jmd0OyAmZ3Q7ICZndDsgZml4ZWQgYmVmb3JlIHRoZSBNSVB2NiBn b2VzIHRvIFJGQy48QlI+Jmd0OyANCiZndDs8QlI+Jmd0OyAmZ3Q7IEkgdGhpbmsgaXQgaXMgc3Vm ZmljaWVudCAiYmVmb3JlIE1JUHY2K0lQdjYrLi4uIGNhbiBiZSANCmRlcGxveWVkIiAtPEJSPiZn dDsgJmd0OyB3aGlsZSB0aGUgaXNzdWUgaXMgaW1wb3J0YW50IEkgZG9uJ3Qgc2VlIHdoeSBpdCBu ZWVkcyANCnRvIGhvbGQgdXA8QlI+Jmd0OyAmZ3Q7IHRoZSBNSVB2NiBzcGVjaWZpY2F0aW9uLjxC Uj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IEknZCANCnByZWZlciB0aGlzIGJlaW5nIGRvbmUgYXMg YSBzaG9ydCBzZXBhcmF0ZSBkcmFmdCBzaW5jZSB0aGlzIG1ha2VzPEJSPiZndDsgDQppdDxCUj4m Z3Q7ICZndDsgZWFzaWVyIHRvIGZvbGQgaXQgaW50byBSRkMgMjQ2MSBhdCBhIGxhdGVyIHRpbWUu PEJSPiZndDsgDQomZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IElkZWFsbHksIHdlIGNvdWxkIGluc2Vy dCBzb21lIHRleHQgaW50byB0aGUgTUlQdjYgc3BlYyANCnNheWluZyB0aGF0PEJSPiZndDsgdGhp czxCUj4mZ3Q7ICZndDsgJmd0OyBiZWhhdmlvciBuZWVkcyB0byBiZSBtb2RpZmllZCBmb3IgDQpy b3V0ZXJzIHRoYXQgYXJlIGhhbmRsaW5nIHdpcmVsZXNzPEJSPiZndDsgJmd0OyAmZ3Q7IGxpbmtz LCBidXQgdGhpcyB3b3VsZCBiZSANCnNvbWV3aGF0IGNvdW50ZXIgdG8gdGhlIHRyZW5kIGluIE1J UHY2IG9mPEJSPiZndDsgJmd0OyAmZ3Q7IGludGVncmF0aW5nIE1JUCBtb3JlIA0KdGlnaHRseSB3 aXRoIHN0YW5kYXJkIElQdjYgbWVjaGFuaXNtcy48QlI+Jmd0OyAmZ3Q7ICZndDsgQWx0ZXJuYXRp dmVseSwgd2UgY291bGQgDQpkbyBhIHNlcGFyYXRlIGRyYWZ0IHRoYXQgbW9kaWZpZWQgdGhlIHRl eHQ8QlI+Jmd0OyBpbjxCUj4mZ3Q7ICZndDsgJmd0OyBSRkMgMjQ2MSANCnRvIG1ha2UgdGhlIHJh bmRvbSBkZWxheSBiZWhhdmlvciBhIFNIT1VMRCwgb3IgYWRkIHJhdGU8QlI+Jmd0OyAmZ3Q7ICZn dDsgDQpsaW1pdGluZyBiZWhhdmlvciBpbnN0ZWFkIChpLmUuIG1ha2UgdGhlIHJhbmRvbSBkZWxh eSBiZWhhdmlvciBiZSBhPEJSPiZndDsgJmd0OyANCiZndDsgZnVuY3Rpb24gb2YgdGhlIGluY29t aW5nIFNvbFJBIHJhdGUpLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFByZS1SRkMgDQp2ZXJz aW9ucyBvZiBuZWlnaGJvciBkaXNjb3ZlcnkgaGFkIGEgdGhlIGFiaWxpdHkgKGlmIG15IG1lbW9y eTxCUj4mZ3Q7IA0Kc2VydmVzPEJSPiZndDsgJmd0OyBtZSkgZm9yIHJvdXRlcnMgdG8gaW1tZWRp YXRlbHkgdW5pY2FzdCBhIFJBIGluIHJlc3BvbnNlIHRvIGEgDQpSUywgYnV0PEJSPiZndDsgJmd0 OyByYW5kb21seSBkZWxheSBhbmQgcmF0ZSBsaW1pdCBhbnkgbXVsdGljYXN0IFJBcyBzZW5kIGl0 IA0KcmVzcG9uc2UgdG88QlI+Jmd0OyBSU3MuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSGF2 aW5nIGEgbWVjaGFuaXNtcyB0byBzZWxlY3QgDQpiZXR3ZWVuIGFuIGltbWVkaWF0ZSB1bmljYXN0 IHJlc3BvbnNlPEJSPiZndDsgYW5kPEJSPiZndDsgJmd0OyBhIGRlbGF5ZWQgDQptdWx0aWNhc3Qg cmVzcG9uc2Ugc2VlbWVkIG5vdCB3b3J0aCB0aGUgZWZmb3J0IGF0IHRoZSB0aW1lLDxCUj4mZ3Q7 IGJ1dDxCUj4mZ3Q7IA0KJmd0OyB0aGF0IGlzIGFuIGF2ZW51ZSB0aGF0IGNhbiBiZSBleHBsb3Jl ZCBub3cuPEJSPiZndDsgJmd0OyBGb3IgaW5zdGFuY2UsIGlmIA0KdGhlIGxhc3QgUlMgd2FzIHJl Y2VpdmVkIGxlc3MgdGhhbiAzIHNlY29uZHMgYWdvPEJSPiZndDsgJmd0OyB0aGUgcm91dGVyIGNv dWxkIA0KZG8gdGhlIHJhbmRvbWx5IGRlbGF5ZWQgbXVsdGljYXN0IFJBOyBvdGhlcndpc2U8QlI+ Jmd0OyAmZ3Q7IGFuIGltbWVkaWF0ZSANCnVuaWNhc3QgUkEuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7 ICZndDsmbmJzcDsmbmJzcDsgRXJpazxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyANCiZndDs8QlI+Jmd0 OyA8QlI+Jmd0OzwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_00EB_01C1E712.8B11C630-- From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 10:27:39 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08010 for ; Thu, 18 Apr 2002 10:27:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00323; Thu, 18 Apr 2002 07:26:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25127; Thu, 18 Apr 2002 07:24:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IDxYIA006105 for ; Thu, 18 Apr 2002 06:59:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IDxYJ8006104 for mobile-ip-dist; Thu, 18 Apr 2002 06:59:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IDxSIA006097 for ; Thu, 18 Apr 2002 06:59:28 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07005 for ; Thu, 18 Apr 2002 06:59:27 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04122 for ; Thu, 18 Apr 2002 06:59:27 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4DD516A905; Thu, 18 Apr 2002 16:59:20 +0300 (EEST) Message-ID: <3CBED045.8050901@piuha.net> Date: Thu, 18 Apr 2002 16:55:17 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: Tuomas Aura , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Jari, > > Jari Arkko wrote: > > >>So, we need to figure out if there is a serious enough vulnerability >>without BA/BR authentication. >> >>The attack we had in mind was a DoS attack where the attacker >>bombs the MN with bogus HoTs or CoTs. In the plain RR protocol >>these can be sent from anywhere in the Internet, and the MN has >>no way of distinguishing them from each real ones. Granted, the >>attacker has to be sending these messages all the time unless he >>knows when RR is initiated. As a result of the attack, BU fails. >>This failure is though noticeable in the form of an error code in >>the BA. As a result, the MN may not get RO but at least it can >>still keep on doing bidirectional tunneling. >> >>In a more serious variant of the attack the attacker spoofs also >>successful BAs. If the MN happens to believe them, it starts RO >>while the real CN doesn't have a BCE, leading to at least some >>packets being blackholed. It may be possible to survive this given >>that there most likely isn't any forward progress on application >>layer and the BM messages keep coming to the MN. However, the MN >>may need some intelligence in getting out of the attack situation >>and staying with bidirectional tunneling while the attacker continues >>the attack. >> >>Is this serious enough? I'm not sure! >> > > A question about the serious variant of the attack. When this > attacker spoofs the successful BA, has the MN sent out another BU? > If no, then there is no problem. The spoofed BA is dropped because > there is no corresponding pending BU. If yes, then the sequence > numbers dont match. The BA is dropped. This is an excellent observation! The sequence number works in this case as a sort of a weak cookie, which as you point out, the attacker doesn't know. Perhaps this could be enough. Question: in BR, we don't have a sequence number. If the BR is more like a binding refresh request, should we add the sequence number also there? > If the attacker was able to guess the right sequence number he > still cant use it. This is because the MAC_Kbu in the BA wont be > correct and the spoofed BA is dropped. We were discussing removing MAC_Kbu from the BA, and replacing it with a simple returned cookie. It may now turn out that the sequence number may be a sufficient cookie. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 12:14:30 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12955 for ; Thu, 18 Apr 2002 12:14:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12906; Thu, 18 Apr 2002 10:14:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15229; Thu, 18 Apr 2002 09:13:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IFqrIA006293 for ; Thu, 18 Apr 2002 08:52:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IFqqce006292 for mobile-ip-dist; Thu, 18 Apr 2002 08:52:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IFqkIA006285 for ; Thu, 18 Apr 2002 08:52:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28861 for ; Thu, 18 Apr 2002 08:52:48 -0700 (PDT) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10623 for ; Thu, 18 Apr 2002 09:52:47 -0600 (MDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3IFrrK0010189; Thu, 18 Apr 2002 17:53:54 +0200 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" , "Mobile IP Working Group" Cc: "Charlie Perkins" Subject: RE: [mobile-ip] Reg with FA COA Date: Thu, 18 Apr 2002 17:50:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Siva, You have a point here, and the same applies to the problem you brought up with a FA setting the 'R'-bit in its advertisements, the mobile will register with the FA and the FA will send the request to the HA, but between what addresses will the FA-HA auth ext be used, the co-located CoA that recides on the MN or the source address of the FA? I believe that this should be clarified in 3220 /Fredrik >-----Original Message----- >From: owner-mobile-ip@sunroof.eng.sun.com >[mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Sivasundar >Ramamurthy >Sent: den 16 april 2002 22:34 >To: Mobile IP Working Group >Subject: [mobile-ip] Reg with FA COA > > >Hello, > >RFC3220 says that a MN registering with a FA COA MUST send the >registration request to the IP source of the advertisement. If the FA >is multihomed and advertises multiple COAs, there is a possibility >that the MN sends the request to an interface that is different >from the COA. > >>From what I have read in the RFC, it appears that it is okay for the >FA to use the same interface to forward the request, instead of the >COA requested. Am I correct? If so, is the FA-HA auth ext >created/authenticated using the SA between the COA and the HA, or the >forwarding address and the HA? > >Hope my questions make sense :-) > > >thanks, > >Siva From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 12:57:50 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14530 for ; Thu, 18 Apr 2002 12:57:50 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03007; Thu, 18 Apr 2002 09:57:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29788; Thu, 18 Apr 2002 09:57:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IGVhIA006381 for ; Thu, 18 Apr 2002 09:31:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IGVgFY006380 for mobile-ip-dist; Thu, 18 Apr 2002 09:31:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IGV8IA006373 for ; Thu, 18 Apr 2002 09:31:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21178 for ; Thu, 18 Apr 2002 09:30:32 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06562 for ; Thu, 18 Apr 2002 09:30:32 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id BA106802; Thu, 18 Apr 2002 09:34:42 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id AA1C71307; Thu, 18 Apr 2002 11:30:30 -0500 (CDT) Received: from compaq.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id MAA0002015628; Thu, 18 Apr 2002 12:30:30 -0400 (EDT) Message-ID: <3CBEF4A5.A8180452@compaq.com> Date: Thu, 18 Apr 2002 12:30:30 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> <3CBED045.8050901@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Question: in BR, we don't have a sequence number. If the BR > is more like a binding refresh request, should we add the sequence > number also there? We can use the Unique Identifier for this, right? Section 5.2.4: "The Unique Identifier parameter is valid only in Binding Request and Binding Update messages. The Unique Identifier field contains a 16-bit value that serves to uniquely identify a Binding Request among those sent by this Source Address, and to allow the Binding Update to identify the specific Binding Request to which it responds." It goes on to say it's useful for renumbering, but you've found another use for it. -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 12:58:27 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14579 for ; Thu, 18 Apr 2002 12:58:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24145; Thu, 18 Apr 2002 09:57:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00386; Thu, 18 Apr 2002 09:57:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IGkQIA006396 for ; Thu, 18 Apr 2002 09:46:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IGkPgd006395 for mobile-ip-dist; Thu, 18 Apr 2002 09:46:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IGjYIA006388 for ; Thu, 18 Apr 2002 09:45:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27170 for ; Thu, 18 Apr 2002 09:44:58 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01598 for ; Thu, 18 Apr 2002 10:44:53 -0600 (MDT) 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 JAA24949; Thu, 18 Apr 2002 09:44:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3IGiAg14685; Thu, 18 Apr 2002 09:44:10 -0700 X-mProtect: <200204181644> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwEtVgm; Thu, 18 Apr 2002 09:44:09 PDT Message-ID: <3CBEF7D9.B7F4DC35@iprg.nokia.com> Date: Thu, 18 Apr 2002 09:44:09 -0700 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: jari.arkko@piuha.net CC: Tuomas Aura , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> <3CBED045.8050901@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > This is an excellent observation! The sequence number works in > this case as a sort of a weak cookie, which as you point out, > the attacker doesn't know. Perhaps this could be enough. Great! I think it is enough. > Question: in BR, we don't have a sequence number. If the BR > is more like a binding refresh request, should we add the sequence > number also there? Maybe we should look at what a spoofed BR can cause. At the worst it makes the MN go through RR/BU procedure with a CN. Perhaps, we could just do some rate limitation at the MN (Charlie's idea). It does not process more than a certain number of BRs for a period of X duration. IMO, BR does not need any protection. > > > If the attacker was able to guess the right sequence number he > > still cant use it. This is because the MAC_Kbu in the BA wont be > > correct and the spoofed BA is dropped. > > We were discussing removing MAC_Kbu from the BA, and replacing it with > a simple returned cookie. It may now turn out that the sequence number > may be a sufficient cookie. So, Tuomas Aura's option (3) is not needed now (see Tuomas's mail on this subject). In fact (1) is much better than option (3) that he was proposing (because cookie C2 is not needed) regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 17:05:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22904 for ; Thu, 18 Apr 2002 17:05:41 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28125; Thu, 18 Apr 2002 15:05:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07279; Thu, 18 Apr 2002 14:05:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IL4cIA007110 for ; Thu, 18 Apr 2002 14:04:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IL4bYC007109 for mobile-ip-dist; Thu, 18 Apr 2002 14:04:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IL4aIA007102 for ; Thu, 18 Apr 2002 14:04:36 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12226 for ; Thu, 18 Apr 2002 17:04:38 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA05304 for mobile-ip@sunroof.eng.sun.com; Thu, 18 Apr 2002 17:05:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3I6LiIA005305 for ; Wed, 17 Apr 2002 23:21:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA22663 for ; Wed, 17 Apr 2002 23:21:44 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20292 for ; Thu, 18 Apr 2002 00:21:43 -0600 (MDT) Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g3I6I1I9025514; Thu, 18 Apr 2002 15:18:06 +0900 (KST) Message-ID: <006401c1e6a1$3d1a4720$792d024b@yhhan> From: "Youn-Hee Han" To: "James Kempf" Cc: References: <00cf01c1e642$2c476130$a96015ac@T23KEMPF> Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Thu, 18 Apr 2002 15:21:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g3I6LkIA005306 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I would like to point out another stumbling block in RFC 2461, in order to achive good MIPv6 handoff performance. Page 55 of RFC 2461 states the followings. Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure. If a host has already performed a random delay since the interface became (re)enabled (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no need to delay again before sending the first Router Solicitation message. The above block states the case for an MN sending an RS before receiving an RA. When an MN moves and re-attaches to a new link, transmittion an RS prior to receving an RA is good behavior for reducing L3 handoff times. However, the delaying by some random amount evidently becomes an obstacle for L3 handoff performance. Although the random delay behavior is a SHOULD, there should be some kind of reference in the Mobile IPv6 spec to it Page 55 of RFC 2461 also states the followings. Moreover, a host SHOULD send at least one solicitation in the case where an advertisement is received prior to having sent a solicitation. Unsolicited Router Advertisements may be incomplete (see Section 6.2.3); solicited advertisements are expected to contain complete information. In order to require complete new link information, the above block states an MN SHOULD send an RS, although it receives an unsolicited RA prior to sending an RS. I am worried that the BUs for new COA must be sent to HA and CN only after receiving a solicited RA. Such behavior is also an obstacle for L3 handoff performance. Although such behavior is a SHOULD, there should be some kind of reference in the Mobile IPv6 spec to it, too. Youn-Hee Han, Samsung Advanced Institute of Technology (SAIT) ----- Original Message ----- From: "James Kempf" To: "Erik Nordmark" Cc: Sent: Thursday, April 18, 2002 1:58 AM Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > Erik, > > We're preparing a separate draft for this, which I think we will submit > to IPNG this week. It is very short (4 pages I think). The draft adds a > bit to the RS saying that the host would like an immediate response. Of > course, hosts can cheat and send it even if they aren't doing MIP > handover, but if everybody plays the rules the congestion control should > work, like TCP. > > The other issue is whether there should be some kind of reference in the > Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are > recommended to use it. > > jak > > ----- Original Message ----- > From: "Erik Nordmark" > To: "James Kempf" > Cc: > Sent: Tuesday, April 16, 2002 7:50 PM > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance > Fatality > > > > > This isn't security related, but I think it is something that *must* > be > > > fixed before the MIPv6 goes to RFC. > > > > I think it is sufficient "before MIPv6+IPv6+... can be deployed" - > > while the issue is important I don't see why it needs to hold up > > the MIPv6 specification. > > > > I'd prefer this being done as a short separate draft since this makes > it > > easier to fold it into RFC 2461 at a later time. > > > > > Ideally, we could insert some text into the MIPv6 spec saying that > this > > > behavior needs to be modified for routers that are handling wireless > > > links, but this would be somewhat counter to the trend in MIPv6 of > > > integrating MIP more tightly with standard IPv6 mechanisms. > > > Alternatively, we could do a separate draft that modified the text > in > > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > > limiting behavior instead (i.e. make the random delay behavior be a > > > function of the incoming SolRA rate). > > > > Pre-RFC versions of neighbor discovery had a the ability (if my memory > serves > > me) for routers to immediately unicast a RA in response to a RS, but > > randomly delay and rate limit any multicast RAs send it response to > RSs. > > > > Having a mechanisms to select between an immediate unicast response > and > > a delayed multicast response seemed not worth the effort at the time, > but > > that is an avenue that can be explored now. > > For instance, if the last RS was received less than 3 seconds ago > > the router could do the randomly delayed multicast RA; otherwise > > an immediate unicast RA. > > > > Erik > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 17:07:15 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22965 for ; Thu, 18 Apr 2002 17:07:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22615; Thu, 18 Apr 2002 14:06:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07789; Thu, 18 Apr 2002 14:06:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IL5kIA007127 for ; Thu, 18 Apr 2002 14:05:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IL5jpN007126 for mobile-ip-dist; Thu, 18 Apr 2002 14:05:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IL5iIA007119 for ; Thu, 18 Apr 2002 14:05:44 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20451 for ; Thu, 18 Apr 2002 17:05:46 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA05313 for mobile-ip@sunroof.eng.sun.com; Thu, 18 Apr 2002 17:06:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IBovIA005932 for ; Thu, 18 Apr 2002 04:50:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15316 for ; Thu, 18 Apr 2002 04:50:58 -0700 (PDT) Received: from gslacks.cs.umass.edu (gslacks.cs.umass.edu [128.119.245.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11371 for ; Thu, 18 Apr 2002 05:50:57 -0600 (MDT) Received: from localhost (brian@localhost) by gslacks.cs.umass.edu (8.11.6/8.8.8) with ESMTP id g3IBHQV07489; Thu, 18 Apr 2002 07:17:26 -0400 X-Authentication-Warning: gslacks.cs.umass.edu: brian owned process doing -bs Date: Thu, 18 Apr 2002 07:17:26 -0400 (EDT) From: Brian Levine Subject: [mobile-ip] Networked Group Communication 2002 (Call for Papers) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: undisclosed-recipients:; Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: My apologies if you receive multiple copies of this CFP. ------------------------------------------------------------- Fourth International Workshop on Networked Group Communication October 23-25, 2002 Boston, Massachusetts, USA Organized in cooperation with ACM SIGCOMM and COST 264 http://signl.cs.umass.edu/ngc2002 The aim of NGC is to allow researchers and practitioners to present the design and implementation techniques for networked group communication. The focus of the workshop is on peer-to-peer, multicast, and networked group communication, ranging from the link layer, through routing, and reliability and traffic control, right up to session and application level control mechanisms. This workshop is the fourth of this international event. The first workshop was in Pisa, Italy, in November 1999; the second was in Stanford, USA, in November 2000; the third was in London, UK, in November 2001. We wish to distinguish NGC as a forum for novel and creative research projects and discussions on the future of networked group communication in academia and industry. To this end, NGC invites you to submit five-page extended abstracts. Authors of accepted papers will be invited to present at the workshop and publish full-length versions of their papers in the workshop proceedings. The extended abstract abstract should represent the paper in "short form." Authors should include full references, figures and significant results when available. The submissions will be judged on significance, originality, clarity, relevance, and correctness. The conference will be held at Holiday Inn, Brookline in Boston, MA. It will start with two half-day tutorials on October 23, 2002. The technical program will include a keynote and invited talks on October 24-25, 2002. Depending on interest level, and suitable proposed topics, there may also be a panel discussion as well as a poster session. Authors are invited to submit papers on any issue related to networked group communication, including: * peer-to-peer applications * applications and services enabled through multicast * wireless and mobile communication * multiplayer games * measurement studies * content distribution * network security * application layer multicast * economic models * novel group communication architectures * routing, naming, address allocation * group and session management techniques * QoS and network engineering * scalability: overheads, stability, analysis, experiments * adaption and congestion control for group communication * heterogeneous group communication * reliable and semi-reliable protocols Important Dates: Paper Registration and Submission: May 17, 2002 Notification: July 24, 2002 Camera Ready copy: August 15, 2002 Conference Dates: October 23-25, 2002 Committee: Technical Co-Chairs: Mostafa Ammar (Georgia Tech) Brian Neil Levine (University of Massachusetts Amherst) General Chair: John Byers (Boston University) Technical Committee: Kevin Almeroth UC Santa Barbara Samrat Bhattacharjee Univ. Maryland Supratik Bhattacharyya Sprint Advanced Technology Labs Ernst Biersak Institut Eurecom John Byers Boston University Jon Crowcroft University of Cambridge Christophe Diot Sprint Advanced Technology Labs Constantinos Dovrolis University of Delaware Jordi Domingo-Pascual Universitat Politecnica de Catalunya Derek Eager University of Saskatchewan Wolfgang Effelsberg University of Mannheim Serge Fdida Laboratoire LIP6-CNRS Lixin Gao University of Massachusetts J.J. Garcia-Luna-Aceves University of California, Santa Cruz Mark Handley ICSI Center for Internet Research Markus Hoffman Lucent Technologies David Hutchison Lancaster University Sugih Jamin University of Michigan Jim Kurose University of Massachus Guy Leduc universite de Liege Jorg Liebeherr University of Virginia Peter Parnes Lulea University of Technology Sanjoy Paul Lucent Technologies Christos Papadopoulos Univerity of Southern California Colin Perkins Information Sciences Institute Luigi Rizzo ICSI Center for Internet Research Elizabeth Royer University of California, Santa Barbara Dan Rubenstein Columbia University Thierry Turletti INRIA-Sophia Antipolis Clay Shields Georgetown University Burkhard Stiller ETH Zuerich Ellen Zegura Georgia Tech From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 17:57:43 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24063 for ; Thu, 18 Apr 2002 17:57:42 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18093; Thu, 18 Apr 2002 14:57:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25467; Thu, 18 Apr 2002 14:57:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ILuNIA007456 for ; Thu, 18 Apr 2002 14:56:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ILuNqm007455 for mobile-ip-dist; Thu, 18 Apr 2002 14:56:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ILuKIA007448 for ; Thu, 18 Apr 2002 14:56:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21804 for ; Thu, 18 Apr 2002 14:56:23 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13460 for ; Thu, 18 Apr 2002 15:56:22 -0600 (MDT) 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 OAA13309; Thu, 18 Apr 2002 14:56:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3ILuKf09908; Thu, 18 Apr 2002 14:56:20 -0700 X-mProtect: <200204182156> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnQ75Fb; Thu, 18 Apr 2002 14:56:19 PDT Message-ID: <3CBF4103.E5FD81E@iprg.nokia.com> Date: Thu, 18 Apr 2002 14:56:19 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality References: <00cf01c1e642$2c476130$a96015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, I see your need, but I am a little concerned about the increase in RAs and the associated overhead.. There is also the potential for abuse as you mention. Shouldn't a MN interested in faster address acquisition use something like FMIPv6 ? Regards, -Rajeev James Kempf wrote: > Erik, > > We're preparing a separate draft for this, which I think we will submit > to IPNG this week. It is very short (4 pages I think). The draft adds a > bit to the RS saying that the host would like an immediate response. Of > course, hosts can cheat and send it even if they aren't doing MIP > handover, but if everybody plays the rules the congestion control should > work, like TCP. > > The other issue is whether there should be some kind of reference in the > Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are > recommended to use it. > > jak > > ----- Original Message ----- > From: "Erik Nordmark" > To: "James Kempf" > Cc: > Sent: Tuesday, April 16, 2002 7:50 PM > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance > Fatality > > > > This isn't security related, but I think it is something that *must* > be > > > fixed before the MIPv6 goes to RFC. > > > > I think it is sufficient "before MIPv6+IPv6+... can be deployed" - > > while the issue is important I don't see why it needs to hold up > > the MIPv6 specification. > > > > I'd prefer this being done as a short separate draft since this makes > it > > easier to fold it into RFC 2461 at a later time. > > > > > Ideally, we could insert some text into the MIPv6 spec saying that > this > > > behavior needs to be modified for routers that are handling wireless > > > links, but this would be somewhat counter to the trend in MIPv6 of > > > integrating MIP more tightly with standard IPv6 mechanisms. > > > Alternatively, we could do a separate draft that modified the text > in > > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > > limiting behavior instead (i.e. make the random delay behavior be a > > > function of the incoming SolRA rate). > > > > Pre-RFC versions of neighbor discovery had a the ability (if my memory > serves > > me) for routers to immediately unicast a RA in response to a RS, but > > randomly delay and rate limit any multicast RAs send it response to > RSs. > > > > Having a mechanisms to select between an immediate unicast response > and > > a delayed multicast response seemed not worth the effort at the time, > but > > that is an avenue that can be explored now. > > For instance, if the last RS was received less than 3 seconds ago > > the router could do the randomly delayed multicast RA; otherwise > > an immediate unicast RA. > > > > Erik > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 18:13:34 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24418 for ; Thu, 18 Apr 2002 18:13:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27994; Thu, 18 Apr 2002 15:13:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03133; Thu, 18 Apr 2002 15:12:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IMCAIA007550 for ; Thu, 18 Apr 2002 15:12:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3IMCAZO007549 for mobile-ip-dist; Thu, 18 Apr 2002 15:12:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IMC8IA007542 for ; Thu, 18 Apr 2002 15:12:08 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04417 for ; Thu, 18 Apr 2002 18:12:11 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA05523 for mobile-ip@sunroof.eng.sun.com; Thu, 18 Apr 2002 18:13:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3IHjlIA006711 for ; Thu, 18 Apr 2002 10:45:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23897 for ; Thu, 18 Apr 2002 10:45:50 -0700 (PDT) Received: from mail.seas.smu.edu (mail.seas.smu.edu [129.119.3.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24621 for ; Thu, 18 Apr 2002 10:45:50 -0700 (PDT) Received: by engr.smu.edu (Smail-3.2.0.111 2000-Feb-17 #17) id ; Thu, 18 Apr 2002 12:45:50 -0500 (CDT) Date: Thu, 18 Apr 2002 12:45:49 -0500 (CDT) From: Abdul Aziz X-Sender: aaziz@buz.seas.smu.edu To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Simulation Environment for IPv6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi All, Is there any tool available for simulating IPv6 except OPNET ? Thanks in Advance, Abdul Aziz From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 21:51:36 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28539 for ; Thu, 18 Apr 2002 21:51:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15351; Thu, 18 Apr 2002 19:51:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02841; Thu, 18 Apr 2002 18:51:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J1o8IA007947 for ; Thu, 18 Apr 2002 18:50:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J1o8gW007946 for mobile-ip-dist; Thu, 18 Apr 2002 18:50:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J1o4IA007939 for ; Thu, 18 Apr 2002 18:50:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02617 for ; Thu, 18 Apr 2002 18:50:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11850 for ; Thu, 18 Apr 2002 19:50:07 -0600 (MDT) 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 SAA24440; Thu, 18 Apr 2002 18:50:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3J1o3u15273; Thu, 18 Apr 2002 18:50:03 -0700 X-mProtect: <200204190150> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd355Utw; Thu, 18 Apr 2002 18:50:02 PDT Message-ID: <3CBF77CA.7F2A1BF@iprg.nokia.com> Date: Thu, 18 Apr 2002 18:50:02 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tuomas Aura CC: mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Tuomas, Tuomas Aura wrote: > Jari Arkko wrote: > > > How about this: we don't provide any authentication of > > the CN in the sense that all the messages be tied to each > > other in some manner. But we provide a simple send cookie > > - return cookie for each of the request - response pairs > > in the protocol. We also delete the MAC field from the BA > > and BR, and only keep the response cookie. > > Yes, I was almost going to suggest this. > > The advantage of simple cookies instead of a MAC for the > BA/BR "authentication" is that the protocol and its > limitations are much easier to understand. The disadvantage > is that the simple cookie mechanism is clearly a little bit > less secure. I'm not yet sure which solution is the best one > but the simple cookie mechanisms looks much cleaner. > > I challenge everyone to compare the following alternative > protocols and explain to themselves the exact differences > between them. > > (1) Jari's protocol: > 1a. MN(HoA) -> CN: HoTI(HoA, C0) > 1b. MN(CoA) -> CN: CoTI(CoA, C1) > 2a. CN -> MN(HoA): HoT(C0, K0, j) > 2b. CN -> MN(CoA): CoT(C1, K1, i) > 3. MN(CoA) -> CN: BU(HoA, CoA, C2, MAC_Kbu, j, i) > 4. CN -> MN(CoA): BA(C2, MAC_Kbu) > 5. CN -> MN(HoA): BR(C2, MAC_Kbu) > Kbu= H(K0 | K1) > > (2) Protocol (1) without the cookies C0 and C1. > 1a. MN(HoA) -> CN: HoTI(HoA) > 1b. MN(CoA) -> CN: CoTI(CoA) > 2a. CN -> MN(HoA): HoT(K0, j) > 2b. CN -> MN(CoA): CoT(K1, i) > > (3) Protocol (1) without MACs on BA/BR. > 4. CN -> MN(CoA): BA(C2) > 5. CN -> MN(HoA): BR(C2) > > Here is my analysis of the above protocols: > Clearly, (1) is the most secure one. BA/BR are > authenticated with the same or almost the same > strength as the BU. The curious thing with protocol > (1) is that removing the cookies C0 and C1 from > messages 1a/b and 2a/b makes the MAC_Kbu in BA/BR > completely worthless. Without the cookies C0 and C1, > the attacker can spoof messages 2a and 2b and thereby > decide the value of Kbu. Therefore, the simple cookie > mechanism of protocol (3) without the MACs in BA/BR > is at least as secure as protocol (2). > > Obviously, the choice is between protocols (1) and (3). > Currently I prefer (3) because I think most people > will never understand why protocol (1) is slightly > better. (I barely do myself.) I believe that the added > security of protocol (1) is not worth much if the > majority of protocol engineers never understand it. > I think that the advantage of having MAC_Kbu (even without C0 and C1) versus having C2 alone is the attacker has to grab K0 and K1 sent towards different IP addresses. With C2 alone in BA, it is sufficient if he gets hold of C2 sent to an IP address. I agree with you that having C0 and C1 in MAC_Kbu for BA should be considered. So.. > > If someone is in favour of protocol (1) instead of (3), > I challenge them to prove that protocol (1) is > equivalent to protocol (4) below. A formal proof > might influence my preferences. > > (4) Protocol (1) but BA/BR authenticated with Kba. > 4. CN -> MN(CoA): BA(C2, MAC_Kba) > 5. CN -> MN(HoA): BR(C2, MAC_Kba) > Kba= H(C0 | C1) > > I think protocol (4) gives the same level of > routing-based authentication for BA/BR as we already > have for BU. I think this is fairly obvious. Note, > however, that protocol (4) is not a realistic option > because the correspondent would have to be stateful > and remember either C0 and C1 or Kba. > Well, what if K0 = MAC_Kcn (HoA | Nj | C0 | 0) K1 = MAC_Kcn (CoA | Ni | C1 | 1) Kbu = H (K0 | K1) (as before), and BA includes MAC_Kbu, and the MN supplies C0 and C1 in BU ? The downside is it adds 8 extra bytes whether or not BA is desired by the MN. Since the sequence number in BU can be used in place of C2, the overhead is 4 bytes. Regards, -Rajeev > > Tuomas From owner-mobile-ip@sunroof.eng.sun.com Thu Apr 18 21:57:51 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28630 for ; Thu, 18 Apr 2002 21:57:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23423; Thu, 18 Apr 2002 18:57:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04692; Thu, 18 Apr 2002 18:57:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J1uKIA008044 for ; Thu, 18 Apr 2002 18:56:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J1uK9Z008043 for mobile-ip-dist; Thu, 18 Apr 2002 18:56:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J1uFIA008036 for ; Thu, 18 Apr 2002 18:56:17 -0700 (PDT) Received: from lillen (d-mpk17-86-112.Eng.Sun.COM [129.146.86.112]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3J1uDx20638; Fri, 19 Apr 2002 03:56:13 +0200 (MEST) Date: Fri, 19 Apr 2002 03:55:44 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality To: James Kempf Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <00cf01c1e642$2c476130$a96015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > We're preparing a separate draft for this, which I think we will submit > to IPNG this week. It is very short (4 pages I think). Good. > The draft adds a > bit to the RS saying that the host would like an immediate response. Of > course, hosts can cheat and send it even if they aren't doing MIP > handover, but if everybody plays the rules the congestion control should > work, like TCP. And what should the router do when it receives 100 RSs within one second all with the bit set? With this approach there is a danger that all implementation, whether mobile or not, set the "I want a fast response" bit you propose. Thus I think the routers need to rate limit in any case. But we can argue this on the IPv6 list :-) > The other issue is whether there should be some kind of reference in the > Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are > recommended to use it. Seems like a useful discussion for IPv6 node requirements at some point in time. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 01:44:09 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02826 for ; Fri, 19 Apr 2002 01:44:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24557; Thu, 18 Apr 2002 22:43:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10398; Thu, 18 Apr 2002 22:43:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J5gNIA008471 for ; Thu, 18 Apr 2002 22:42:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J5gNvd008470 for mobile-ip-dist; Thu, 18 Apr 2002 22:42:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J5gIIA008450 for ; Thu, 18 Apr 2002 22:42:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10145 for ; Thu, 18 Apr 2002 22:42:22 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17623 for ; Thu, 18 Apr 2002 23:42:21 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ABE936A905; Fri, 19 Apr 2002 08:42:13 +0300 (EEST) Message-ID: <3CBFAE5B.5030901@piuha.net> Date: Fri, 19 Apr 2002 08:42:51 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli , Tuomas Aura Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> <3CBED045.8050901@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > The sequence number works in > this case as a sort of a weak cookie, which as you point out, > the attacker doesn't know. Perhaps this could be enough. An update: It was pointed out to me by Tuomas that we don't want to repeat the problems we have with TCP sequence numbers as cookies. Sequence numbers are too predictable. Instead, a cookie should be added. And it does look like the approach #3 is preferred by many folks, on the basis of giving some protection but still being easily understood and analyzed. The one attack that this doesn't protect against is someone on the visited network who can see the cleartext C2 going to the CN, and could spoof an answer BA. However, an attacker on this link could also do lots of other bad things, such as sending TCP RSTs on the traffic between the MN and the CN. > Question: in BR, we don't have a sequence number. If the BR > is more like a binding refresh request, should we add the sequence > number also there? One idea is that since we have a very BR-like functionality already in BM, and since there is no way we can authenticate a BM, we should just merge this functionality and not have any authentication. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 01:53:31 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03045 for ; Fri, 19 Apr 2002 01:53:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28602; Thu, 18 Apr 2002 22:53:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11719; Thu, 18 Apr 2002 22:52:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J5q8IA008541 for ; Thu, 18 Apr 2002 22:52:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J5q7fs008540 for mobile-ip-dist; Thu, 18 Apr 2002 22:52:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J5q4IA008533 for ; Thu, 18 Apr 2002 22:52:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA16048 for ; Thu, 18 Apr 2002 22:52:08 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA22797 for ; Thu, 18 Apr 2002 23:52:07 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 213916A905 for ; Fri, 19 Apr 2002 08:51:57 +0300 (EEST) Message-ID: <3CBFB0A3.3020600@piuha.net> Date: Fri, 19 Apr 2002 08:52:35 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Updated unresolved issue #16: Unrecognized MH Type Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Background: Draft 16 states that an error should be given if an unknown MH Type is received. This error may be necessary in terms of diagnosing implementation problems, but it's main use is the ability to determine that the peer does not support some new extension that requires a new MH Type. However, draft 16 does not describe what kind of error can be given. It isn't clear that a Binding Acknowledgement can be used for this purpose as the error may not be given as a response to Binding Update and there isn't an appropriate error code yet. Question: Is this an important error to give? Should we define a new MH Type and message called Error that would contain an error code? Or should we use the Binding Ack message with a new error code? Or should we define the BM message as a general error message for mobility, and define an error code for wrong MH Type? Or should we use ICMP Parameter Problem Code 0 (erroneous header field encountered) and pointer to MH Type to indicate problems. Proposal: Use of the Binding Ack message does not seem appropriate as it would be then be used in a quite different role than originally intended. The ICMP Parameter Problem Code 0 approach is possible, but involves a complicated decision based on looking at the reported pointer and original packet. Such actions are typically not done based on these messages. A new error message might be appropriate, but then we would have two error-reporting messages, Binding Error and Binding Missing. The proposal is therefore that the Binding Missing message be renamed to Mobility Error, and added an error code to indicate (1) unsupported MH Type, (2) missing binding, and (3) any new error perhaps needed in future extensions. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 02:15:52 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11678 for ; Fri, 19 Apr 2002 02:15:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05922; Thu, 18 Apr 2002 23:15:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00562; Thu, 18 Apr 2002 23:15:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J6EQIA008631 for ; Thu, 18 Apr 2002 23:14:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J6EQQG008630 for mobile-ip-dist; Thu, 18 Apr 2002 23:14:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J6EMIA008623 for ; Thu, 18 Apr 2002 23:14:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00360 for ; Thu, 18 Apr 2002 23:14:27 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA29965 for ; Fri, 19 Apr 2002 00:14:26 -0600 (MDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA28711 for ; Fri, 19 Apr 2002 15:14:23 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA08110 for ; Fri, 19 Apr 2002 15:14:22 +0900 (JST) Date: Fri, 19 Apr 2002 15:13:59 +0900 (JST) Message-Id: <20020419.151359.87062421.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Updated unresolved issue #16: Unrecognized MH Type From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3CBFB0A3.3020600@piuha.net> References: <3CBFB0A3.3020600@piuha.net> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. From: Jari Arkko > > Proposal: Use of the Binding Ack message does not seem appropriate as > it would be then be used in a quite different role than originally > intended. The ICMP Parameter Problem Code 0 approach is possible, but > involves a complicated decision based on looking at the reported > pointer and original packet. Such actions are typically not done > based on these messages. A new error message might be appropriate, > but then we would have two error-reporting messages, Binding Error > and Binding Missing. The proposal is therefore that the Binding > Missing message be renamed to Mobility Error, and added an error > code to indicate (1) unsupported MH Type, (2) missing binding, and > (3) any new error perhaps needed in future extensions. --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 05:48:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14565 for ; Fri, 19 Apr 2002 05:48:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18994; Fri, 19 Apr 2002 03:48:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18962; Fri, 19 Apr 2002 02:47:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J9kwIA009099 for ; Fri, 19 Apr 2002 02:46:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3J9kwF2009098 for mobile-ip-dist; Fri, 19 Apr 2002 02:46:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3J9ksIA009091 for ; Fri, 19 Apr 2002 02:46:54 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18638 for ; Fri, 19 Apr 2002 02:46:58 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16761 for ; Fri, 19 Apr 2002 03:46:57 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3J9ku3G014777 for ; Fri, 19 Apr 2002 11:46:56 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 19 11:46:47 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTQJCR>; Fri, 19 Apr 2002 11:46:47 +0200 Message-ID: <79D18F182376D311856D0008C791A93908229247@esealnt407> From: =?iso-8859-1?Q?Tomas_Goldbeck-L=F6we_=28ERA=29?= To: "'Fredrik Johansson'" , Sivasundar Ramamurthy , Mobile IP Working Group Cc: Charlie Perkins Subject: RE: [mobile-ip] Reg with FA COA Date: Fri, 19 Apr 2002 11:45:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Fredrik and Siva, Agree that it should be clarified if it is not clear already. And in my opinion, the FA-HA SA should be between the src_FA address and the dst_HA address. That's because the HA wants to authenticate the packet before processing it, i.e. just looking at the IP header and be able to authenticate. my first 2 cents Thanks. --> Tomas > -----Original Message----- > From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] > Sent: den 18 april 2002 17:51 > To: Sivasundar Ramamurthy; Mobile IP Working Group > Cc: Charlie Perkins > Subject: RE: [mobile-ip] Reg with FA COA > > > Hi Siva, > > You have a point here, and the same applies to the problem > you brought up > with a FA setting the 'R'-bit in its advertisements, the mobile will > register with the FA and the FA will send the request to the > HA, but between > what addresses will the FA-HA auth ext be used, the > co-located CoA that > recides on the MN or the source address of the FA? > > I believe that this should be clarified in 3220 > /Fredrik > > >-----Original Message----- > >From: owner-mobile-ip@sunroof.eng.sun.com > >[mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Sivasundar > >Ramamurthy > >Sent: den 16 april 2002 22:34 > >To: Mobile IP Working Group > >Subject: [mobile-ip] Reg with FA COA > > > > > >Hello, > > > >RFC3220 says that a MN registering with a FA COA MUST send the > >registration request to the IP source of the advertisement. If the FA > >is multihomed and advertises multiple COAs, there is a possibility > >that the MN sends the request to an interface that is different > >from the COA. > > > >>From what I have read in the RFC, it appears that it is okay for the > >FA to use the same interface to forward the request, instead of the > >COA requested. Am I correct? If so, is the FA-HA auth ext > >created/authenticated using the SA between the COA and the HA, or the > >forwarding address and the HA? > > > >Hope my questions make sense :-) > > > > > >thanks, > > > >Siva > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 07:24:57 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16149 for ; Fri, 19 Apr 2002 07:24:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24402; Fri, 19 Apr 2002 04:24:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10010; Fri, 19 Apr 2002 04:24:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JBNbIA009398 for ; Fri, 19 Apr 2002 04:23:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JBNbsq009397 for mobile-ip-dist; Fri, 19 Apr 2002 04:23:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JBNXIA009390 for ; Fri, 19 Apr 2002 04:23:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01408 for ; Fri, 19 Apr 2002 04:23:36 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA15587 for ; Fri, 19 Apr 2002 05:23:34 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16110; Fri, 19 Apr 2002 07:23:31 -0400 (EDT) Message-Id: <200204191123.HAA16110@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com, aaa-wg@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-nai-00.txt Date: Fri, 19 Apr 2002 07:23:30 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : AAA NAI for Mobile IPv4 Extension Author(s) : F. Johansson, T. Johansson Filename : draft-ietf-mobileip-aaa-nai-00.txt Pages : 8 Date : 18-Apr-02 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple AAA servers the reauthentication request may not be received by the same AAAH as previous authentication requests. In order for the new AAAH to be able to forward the request to the correct HA it has to know the identity of the HA. This document defines an extension that enables the HA to pass its identity to the mobile node which can in turn pass it to the AAA server when changing point of attachment. This document specifies a NAI extension that can carry these NAIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-nai-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-aaa-nai-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-aaa-nai-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418141649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-nai-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-nai-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418141649.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 09:02:25 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18479 for ; Fri, 19 Apr 2002 09:02:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07874; Fri, 19 Apr 2002 06:01:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26113; Fri, 19 Apr 2002 06:01:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JD0uIA009569 for ; Fri, 19 Apr 2002 06:00:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JD0u3I009568 for mobile-ip-dist; Fri, 19 Apr 2002 06:00:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JD0rIA009561 for ; Fri, 19 Apr 2002 06:00:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25733 for ; Fri, 19 Apr 2002 06:00:57 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29075 for ; Fri, 19 Apr 2002 07:00:56 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3JD0jd24592; Fri, 19 Apr 2002 15:00:45 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA02030; Fri, 19 Apr 2002 15:00:45 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3JD0iT36286; Fri, 19 Apr 2002 15:00:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204191300.g3JD0iT36286@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brett Pentland cc: James Kempf , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality In-reply-to: Your message of Fri, 12 Apr 2002 11:37:15 +1100. <3CB62C3B.230F5800@eng.monash.edu.au> Date: Fri, 19 Apr 2002 15:00:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: If a flag in the RS is the correct approach => I believe there is a better approach even for fast RS/RA (which is not a good idea in the general case IMHO). In another email, Francis mentioned a technique of triggering an RA when an interface comes up. => your message suggested the MN sends a RS because the layer 2 detects the arrival on a new link. My observation is that another entity can get the same information and use it to trigger a RA. Francis, perhaps you could elaborate on how a mobile node's interface coming up on a network could be made to trigger an RA from the router on that network without sending an RS (or a very similar packet). => If another entity on the link detects the arrival of the new MN, it can give the info to a router which can send a RA. The conditions are: - detection by another entity (works well for PPP, IEEE 802.11 in infrastructure mode, any layer 2 with some kind of association for network access control, etc) - some communication betwee the entity and a router (obvious if the entity is a router) - an arrival frequency low enough (delay between two arrivals far greater than MAX_RA_DELAY_TIME) Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 09:11:30 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18815 for ; Fri, 19 Apr 2002 09:11:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11677; Fri, 19 Apr 2002 06:11:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28637; Fri, 19 Apr 2002 06:10:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JDAMIA009680 for ; Fri, 19 Apr 2002 06:10:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JDAMhc009679 for mobile-ip-dist; Fri, 19 Apr 2002 06:10:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JDAJIA009672 for ; Fri, 19 Apr 2002 06:10:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28486 for ; Fri, 19 Apr 2002 06:10:23 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29749; Fri, 19 Apr 2002 07:10:22 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3JDAKd25952; Fri, 19 Apr 2002 15:10:20 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA02145; Fri, 19 Apr 2002 15:10:20 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3JDAKT36329; Fri, 19 Apr 2002 15:10:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200204191310.g3JDAKT36329@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: James Kempf , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality In-reply-to: Your message of Wed, 17 Apr 2002 04:50:13 +0200. Date: Fri, 19 Apr 2002 15:10:20 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > Ideally, we could insert some text into the MIPv6 spec saying that this > behavior needs to be modified for routers that are handling wireless > links, but this would be somewhat counter to the trend in MIPv6 of > integrating MIP more tightly with standard IPv6 mechanisms. > Alternatively, we could do a separate draft that modified the text in > RFC 2461 to make the random delay behavior a SHOULD, or add rate > limiting behavior instead (i.e. make the random delay behavior be a > function of the incoming SolRA rate). Pre-RFC versions of neighbor discovery had a the ability (if my memory serves me) for routers to immediately unicast a RA in response to a RS, but randomly delay and rate limit any multicast RAs send it response to RSs. Having a mechanisms to select between an immediate unicast response and a delayed multicast response seemed not worth the effort at the time, but that is an avenue that can be explored now. For instance, if the last RS was received less than 3 seconds ago the router could do the randomly delayed multicast RA; otherwise an immediate unicast RA. => I disagree with the reasonning because it uses the assumption there is only one router: if RAs are immediately sent (unicasted or multicasted, this doesn't matter) at the reception of a multicasted RS, then they will collide. So I agree the bit approach is not good, but the right approach (to unicast the RS) has some difficulties... (PS: I can't see a better alternative to trigger though the link layer a RA) Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 10:16:01 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20857 for ; Fri, 19 Apr 2002 10:16:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29032; Fri, 19 Apr 2002 08:14:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16111; Fri, 19 Apr 2002 07:14:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JEDxIA009865 for ; Fri, 19 Apr 2002 07:14:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JEDx2Y009864 for mobile-ip-dist; Fri, 19 Apr 2002 07:13:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JEDuIA009857 for ; Fri, 19 Apr 2002 07:13:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15809 for ; Fri, 19 Apr 2002 07:13:59 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10081 for ; Fri, 19 Apr 2002 07:13:59 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3JEDljR009851; Fri, 19 Apr 2002 07:13:47 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABM33602; Fri, 19 Apr 2002 07:11:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA19483; Fri, 19 Apr 2002 07:13:47 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15552.9754.947421.690767@thomasm-u1.cisco.com> Date: Fri, 19 Apr 2002 07:13:46 -0700 (PDT) To: Rajeev Koodli Cc: James Kempf , Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality In-Reply-To: <3CBF4103.E5FD81E@iprg.nokia.com> References: <00cf01c1e642$2c476130$a96015ac@T23KEMPF> <3CBF4103.E5FD81E@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev Koodli writes: > Hello Jim, > > I see your need, but I am a little concerned about the increase in > RAs and the associated overhead.. There is also the potential for abuse > as you mention. Shouldn't a MN interested in faster > address acquisition use something like FMIPv6 ? Rajeev, This assumes that the AR supports and offers FMIPv6. I don't see that as the case always, especially with open kiosk kinds of situations. IMO, it should be possible for a mobile node reasonably close to its home agent to dispense with all of the heavy machinery (and dependencies) and achieve reasonable results. The couple of seconds of delay here (as well as DAD) doesn't strike me as striking a very good balance. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 11:15:53 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23247 for ; Fri, 19 Apr 2002 11:15:53 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03299; Fri, 19 Apr 2002 09:15:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15528; Fri, 19 Apr 2002 08:15:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFEdIA010020 for ; Fri, 19 Apr 2002 08:14:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JFEdaQ010019 for mobile-ip-dist; Fri, 19 Apr 2002 08:14:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFEaIA010012 for ; Fri, 19 Apr 2002 08:14:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15355 for ; Fri, 19 Apr 2002 08:14:35 -0700 (PDT) From: rene.purnadi@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22975 for ; Fri, 19 Apr 2002 09:14:34 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3JFEms05119 for ; Fri, 19 Apr 2002 10:14:49 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Apr 2002 10:14:27 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 19 Apr 2002 10:14:24 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Fri, 19 Apr 2002 10:14:24 -0500 Message-ID: <748E8123D183394982E32A511DB3E73610B128@daebe005.NOE.Nokia.com> Thread-Topic: [mobile-ip] RA Solicitation Response Delay Performance Fatality Thread-Index: AcHnIYjJlXhQn0w4S9Ca4iPi0Aj2qAAkdvzw To: , Cc: X-OriginalArrivalTime: 19 Apr 2002 15:14:24.0979 (UTC) FILETIME=[E414EA30:01C1E7B4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3JFEaIA010013 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sorry for my ignorance, but back to the root of the discussion: Why we need the immediate RA upon RS? I know that without immediate RA, the L3 handoff is delayed. But both FMIPv6 and BETH allow the MN to use the old CoA for a while (thanks to the tunnel) before executing 'non time critical' L3 handoff. The L2 handoff is considered as time 'critical' Thanks for any explanation Rene Purnadi Nokia Research Center Phone: +1 972.894.4897 Mobile: +1 972.342.3503 e-mail: rene.purnadi@nokia.com -----Original Message----- From: ext Youn-Hee Han [mailto:yhhan@sait.samsung.co.kr] Sent: Thursday, April 18, 2002 1:21 AM To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality I would like to point out another stumbling block in RFC 2461, in order to achive good MIPv6 handoff performance. Page 55 of RFC 2461 states the followings. Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure. If a host has already performed a random delay since the interface became (re)enabled (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no need to delay again before sending the first Router Solicitation message. The above block states the case for an MN sending an RS before receiving an RA. When an MN moves and re-attaches to a new link, transmittion an RS prior to receving an RA is good behavior for reducing L3 handoff times. However, the delaying by some random amount evidently becomes an obstacle for L3 handoff performance. Although the random delay behavior is a SHOULD, there should be some kind of reference in the Mobile IPv6 spec to it Page 55 of RFC 2461 also states the followings. Moreover, a host SHOULD send at least one solicitation in the case where an advertisement is received prior to having sent a solicitation. Unsolicited Router Advertisements may be incomplete (see Section 6.2.3); solicited advertisements are expected to contain complete information. In order to require complete new link information, the above block states an MN SHOULD send an RS, although it receives an unsolicited RA prior to sending an RS. I am worried that the BUs for new COA must be sent to HA and CN only after receiving a solicited RA. Such behavior is also an obstacle for L3 handoff performance. Although such behavior is a SHOULD, there should be some kind of reference in the Mobile IPv6 spec to it, too. Youn-Hee Han, Samsung Advanced Institute of Technology (SAIT) ----- Original Message ----- From: "James Kempf" To: "Erik Nordmark" Cc: Sent: Thursday, April 18, 2002 1:58 AM Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > Erik, > > We're preparing a separate draft for this, which I think we will submit > to IPNG this week. It is very short (4 pages I think). The draft adds a > bit to the RS saying that the host would like an immediate response. Of > course, hosts can cheat and send it even if they aren't doing MIP > handover, but if everybody plays the rules the congestion control should > work, like TCP. > > The other issue is whether there should be some kind of reference in the > Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are > recommended to use it. > > jak > > ----- Original Message ----- > From: "Erik Nordmark" > To: "James Kempf" > Cc: > Sent: Tuesday, April 16, 2002 7:50 PM > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance > Fatality > > > > > This isn't security related, but I think it is something that *must* > be > > > fixed before the MIPv6 goes to RFC. > > > > I think it is sufficient "before MIPv6+IPv6+... can be deployed" - > > while the issue is important I don't see why it needs to hold up > > the MIPv6 specification. > > > > I'd prefer this being done as a short separate draft since this makes > it > > easier to fold it into RFC 2461 at a later time. > > > > > Ideally, we could insert some text into the MIPv6 spec saying that > this > > > behavior needs to be modified for routers that are handling wireless > > > links, but this would be somewhat counter to the trend in MIPv6 of > > > integrating MIP more tightly with standard IPv6 mechanisms. > > > Alternatively, we could do a separate draft that modified the text > in > > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > > limiting behavior instead (i.e. make the random delay behavior be a > > > function of the incoming SolRA rate). > > > > Pre-RFC versions of neighbor discovery had a the ability (if my memory > serves > > me) for routers to immediately unicast a RA in response to a RS, but > > randomly delay and rate limit any multicast RAs send it response to > RSs. > > > > Having a mechanisms to select between an immediate unicast response > and > > a delayed multicast response seemed not worth the effort at the time, > but > > that is an avenue that can be explored now. > > For instance, if the last RS was received less than 3 seconds ago > > the router could do the randomly delayed multicast RA; otherwise > > an immediate unicast RA. > > > > Erik > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 11:29:30 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23780 for ; Fri, 19 Apr 2002 11:29:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14413; Fri, 19 Apr 2002 09:29:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20692; Fri, 19 Apr 2002 08:29:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFSKIA010298 for ; Fri, 19 Apr 2002 08:28:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JFSKh9010297 for mobile-ip-dist; Fri, 19 Apr 2002 08:28:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFSHIA010290 for ; Fri, 19 Apr 2002 08:28:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19331 for ; Fri, 19 Apr 2002 08:28:20 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00468 for ; Fri, 19 Apr 2002 09:28:17 -0600 (MDT) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3JFS1I03348; Fri, 19 Apr 2002 08:28:01 -0700 (PDT) Message-ID: <000001c1e7b6$9288fd80$746015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Manolis Sifalakis" , References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 Date: Fri, 19 Apr 2002 06:37:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, > ^^^^ > The AR must start tunneling immediately after processing the FBU. In fact, > the control (to turn on tunneling) must reside at the MN. > > > > > immediately, in which case the mobile node will miss those packets sent > > before it moves, or it can bicast packets down the old link and the > > tunnel. > > > > clarification: bicasting is not proposed in the spec (after a long > discussion > culminating in a vote at London IETF). > If it does this, the mobile loses packets between when the FBU is received by the AR and when it finally arrives on the other link (remember: neither bicasting nor buffering are in this draft). If the router gets a Link Down, this can be used to reduce the packet loss to just the L2 handover blackout period. Of course, if this trigger is not available, then the FBU must be used. Or was there some other reason why you feel the FBU must be the tunnel setup trigger? jak From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 11:44:40 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24294 for ; Fri, 19 Apr 2002 11:44:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14946; Fri, 19 Apr 2002 09:44:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26588; Fri, 19 Apr 2002 08:44:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFhiIA010414 for ; Fri, 19 Apr 2002 08:43:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JFhiOI010413 for mobile-ip-dist; Fri, 19 Apr 2002 08:43:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFheIA010406 for ; Fri, 19 Apr 2002 08:43:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14550 for ; Fri, 19 Apr 2002 08:43:44 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01552 for ; Fri, 19 Apr 2002 08:43:44 -0700 (PDT) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3JFhXI03942; Fri, 19 Apr 2002 08:43:34 -0700 (PDT) Message-ID: <007101c1e7b8$be054660$746015ac@T23KEMPF> From: "James Kempf" To: "Youn-Hee Han" , References: <00ee01c1e6c7$1b5e9bb0$792d024b@yhhan> Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Fri, 19 Apr 2002 08:37:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Youn-Hee, Good points. I think there needs to be something in the spec which says that an MN shouldn't wait to solicit, and that an AR should send complete information if possible (RAs are limited to PMTU size). jak ----- Original Message ----- From: "Youn-Hee Han" To: Sent: Thursday, April 18, 2002 3:52 AM Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > I would like to point out another stumbling block in RFC 2461, in order to > achive good MIPv6 handoff performance. > > Page 55 of RFC 2461 states the followings. > > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when > many hosts start up on a link at the same time, such as might happen > after recovery from a power failure. If a host has already performed > a random delay since the interface became (re)enabled (e.g., as part > of Duplicate Address Detection [ADDRCONF]) there is no need to delay > again before sending the first Router Solicitation message. > > The above block states the case for an MN sending an RS before receiving an RA. > When an MN moves and re-attaches to a new link, transmittion an RS prior to > receving an RA is good behavior for reducing L3 handoff times. > However, the delaying by some random amount evidently becomes an obstacle > for L3 handoff performance. Although the random delay behavior is a SHOULD, > there should be some kind of reference in the Mobile IPv6 spec to it > > Page 55 of RFC 2461 also states the followings. > > Moreover, a host SHOULD send at least one solicitation in the case where an > advertisement is received prior to having sent a solicitation. > Unsolicited Router Advertisements may be incomplete (see Section > 6.2.3); solicited advertisements are expected to contain complete > information. > > In order to require complete new link information, the above block states > an MN SHOULD send an RS, although it receives an unsolicited RA prior to sending an RS. > I am worried that the BUs for new COA must be sent to HA and CN only after > receiving a solicited RA. Such behavior is also an obstacle for L3 handoff performance. > Although such behavior is a SHOULD, there should be some kind of reference > in the Mobile IPv6 spec to it, too. > > > Youn-Hee Han, > Samsung Advanced Institute of Technology (SAIT) > > > ----- Original Message ----- > From: "James Kempf" > To: "Erik Nordmark" > Cc: > Sent: Thursday, April 18, 2002 1:58 AM > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > > > > Erik, > > > > We're preparing a separate draft for this, which I think we will submit > > to IPNG this week. It is very short (4 pages I think). The draft adds a > > bit to the RS saying that the host would like an immediate response. Of > > course, hosts can cheat and send it even if they aren't doing MIP > > handover, but if everybody plays the rules the congestion control should > > work, like TCP. > > > > The other issue is whether there should be some kind of reference in the > > Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are > > recommended to use it. > > > > jak > > > > ----- Original Message ----- > > From: "Erik Nordmark" > > To: "James Kempf" > > Cc: > > Sent: Tuesday, April 16, 2002 7:50 PM > > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance > > Fatality > > > > > > > > This isn't security related, but I think it is something that *must* > > be > > > > fixed before the MIPv6 goes to RFC. > > > > > > I think it is sufficient "before MIPv6+IPv6+... can be deployed" - > > > while the issue is important I don't see why it needs to hold up > > > the MIPv6 specification. > > > > > > I'd prefer this being done as a short separate draft since this makes > > it > > > easier to fold it into RFC 2461 at a later time. > > > > > > > Ideally, we could insert some text into the MIPv6 spec saying that > > this > > > > behavior needs to be modified for routers that are handling wireless > > > > links, but this would be somewhat counter to the trend in MIPv6 of > > > > integrating MIP more tightly with standard IPv6 mechanisms. > > > > Alternatively, we could do a separate draft that modified the text > > in > > > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > > > limiting behavior instead (i.e. make the random delay behavior be a > > > > function of the incoming SolRA rate). > > > > > > Pre-RFC versions of neighbor discovery had a the ability (if my memory > > serves > > > me) for routers to immediately unicast a RA in response to a RS, but > > > randomly delay and rate limit any multicast RAs send it response to > > RSs. > > > > > > Having a mechanisms to select between an immediate unicast response > > and > > > a delayed multicast response seemed not worth the effort at the time, > > but > > > that is an avenue that can be explored now. > > > For instance, if the last RS was received less than 3 seconds ago > > > the router could do the randomly delayed multicast RA; otherwise > > > an immediate unicast RA. > > > > > > Erik > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 11:56:37 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24853 for ; Fri, 19 Apr 2002 11:56:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25900; Fri, 19 Apr 2002 09:56:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27387; Fri, 19 Apr 2002 08:56:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFtYIA010527 for ; Fri, 19 Apr 2002 08:55:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JFtYMn010526 for mobile-ip-dist; Fri, 19 Apr 2002 08:55:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFtUIA010519 for ; Fri, 19 Apr 2002 08:55:31 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01666 for ; Fri, 19 Apr 2002 08:55:34 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08813 for ; Fri, 19 Apr 2002 08:55:34 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3JFtYi13397; Fri, 19 Apr 2002 10:55:34 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TXPYK>; Fri, 19 Apr 2002 10:55:32 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCBFF@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: mobile-ip@sunroof.eng.sun.com Cc: "'fredrik@ipunplugged.com'" , "'tony.johansson@ericsson.com'" Subject: [mobile-ip] A Question about:draft-ietf-mobileip-aaa-nai-00.txt Date: Fri, 19 Apr 2002 10:55:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E7BA.A1E1FD00" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E7BA.A1E1FD00 Content-Type: text/plain; charset="iso-8859-1" Hello All; I would like to address the following two points: I. Mobile Node and the new HA NAI extension: In section 4. It reads: " A mobile node MUST provide this in every registration request sent when re-authenticating, or when requesting a specific IP address at initial authentication." 1. Does this mean that whenever the mobile Node include a specific Static Home IP address, Mobile Node MUST provide the AAA NAI extension with Subtype 1? 2. Does this mean when the MN change point of attachment due to Inter-FA handoff It MUST include this extension. If 1 & 2 are true? Where is the backward compatibility with legacy Mobile Node? II. Home Agent handling of AAAH Identity Subtype extension: In section 5. It reads: "The home agent MUST provide this in every registration reply if using the AAA server ." I would prefer more explicit sentence similar to one used earlier: "The home agent MUST provide this in every registration reply sent to the mobile node destined through the AAA infrastructure." Thanks for consideration. Regards; Ahmad Muhanna ------_=_NextPart_001_01C1E7BA.A1E1FD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A Question about:draft-ietf-mobileip-aaa-nai-00.txt

Hello All;
I would like to address the following two = points:

I. Mobile Node and the new HA NAI extension:

In section 4. It reads:
" A mobile node MUST provide this in every = registration request sent
   when re-authenticating, or when = requesting a specific IP address at
   initial authentication."

        1. Does = this mean that whenever the mobile Node include a specific = Static
        Home IP = address, Mobile Node MUST provide the AAA NAI extension with Subtype = 1?

        2. Does = this mean when the MN change point of attachment due to Inter-FA = handoff
        It MUST = include this extension.

If 1 & 2 are true?
Where is the backward compatibility with legacy = Mobile Node?

II. Home Agent handling of AAAH Identity Subtype = extension:

In section 5. It reads:

"The home agent MUST provide this in every = registration reply if using
   the AAA server ."

I would prefer more explicit sentence similar to one = used earlier:

"The home agent MUST provide this in every = registration reply sent to
  the mobile node destined through the AAA = infrastructure."

Thanks for consideration.

Regards;
Ahmad Muhanna

------_=_NextPart_001_01C1E7BA.A1E1FD00-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 12:02:52 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25358 for ; Fri, 19 Apr 2002 12:02:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12146; Fri, 19 Apr 2002 09:00:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29263; Fri, 19 Apr 2002 09:00:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFxwIA010607 for ; Fri, 19 Apr 2002 08:59:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JFxwvp010606 for mobile-ip-dist; Fri, 19 Apr 2002 08:59:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JFxtIA010599 for ; Fri, 19 Apr 2002 08:59:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28953 for ; Fri, 19 Apr 2002 08:59:58 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01781; Fri, 19 Apr 2002 09:59:58 -0600 (MDT) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3JFxeI04617; Fri, 19 Apr 2002 08:59:40 -0700 (PDT) Message-ID: <00bc01c1e7ba$fe54fb00$746015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Erik Nordmark" , References: <00cf01c1e642$2c476130$a96015ac@T23KEMPF> <3CBF4103.E5FD81E@iprg.nokia.com> Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Fri, 19 Apr 2002 08:58:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sure. But FMIPv6 isn't part of the base spec, and I think the base spec should implementable in a way that gives good performance. jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Erik Nordmark" ; Sent: Thursday, April 18, 2002 2:56 PM Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > > Hello Jim, > > I see your need, but I am a little concerned about the increase in > RAs and the associated overhead.. There is also the potential for abuse > as you mention. Shouldn't a MN interested in faster > address acquisition use something like FMIPv6 ? > > Regards, > > -Rajeev > > > James Kempf wrote: > > > Erik, > > > > We're preparing a separate draft for this, which I think we will submit > > to IPNG this week. It is very short (4 pages I think). The draft adds a > > bit to the RS saying that the host would like an immediate response. Of > > course, hosts can cheat and send it even if they aren't doing MIP > > handover, but if everybody plays the rules the congestion control should > > work, like TCP. > > > > The other issue is whether there should be some kind of reference in the > > Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are > > recommended to use it. > > > > jak > > > > ----- Original Message ----- > > From: "Erik Nordmark" > > To: "James Kempf" > > Cc: > > Sent: Tuesday, April 16, 2002 7:50 PM > > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance > > Fatality > > > > > > This isn't security related, but I think it is something that *must* > > be > > > > fixed before the MIPv6 goes to RFC. > > > > > > I think it is sufficient "before MIPv6+IPv6+... can be deployed" - > > > while the issue is important I don't see why it needs to hold up > > > the MIPv6 specification. > > > > > > I'd prefer this being done as a short separate draft since this makes > > it > > > easier to fold it into RFC 2461 at a later time. > > > > > > > Ideally, we could insert some text into the MIPv6 spec saying that > > this > > > > behavior needs to be modified for routers that are handling wireless > > > > links, but this would be somewhat counter to the trend in MIPv6 of > > > > integrating MIP more tightly with standard IPv6 mechanisms. > > > > Alternatively, we could do a separate draft that modified the text > > in > > > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > > > limiting behavior instead (i.e. make the random delay behavior be a > > > > function of the incoming SolRA rate). > > > > > > Pre-RFC versions of neighbor discovery had a the ability (if my memory > > serves > > > me) for routers to immediately unicast a RA in response to a RS, but > > > randomly delay and rate limit any multicast RAs send it response to > > RSs. > > > > > > Having a mechanisms to select between an immediate unicast response > > and > > > a delayed multicast response seemed not worth the effort at the time, > > but > > > that is an avenue that can be explored now. > > > For instance, if the last RS was received less than 3 seconds ago > > > the router could do the randomly delayed multicast RA; otherwise > > > an immediate unicast RA. > > > > > > Erik > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 12:07:50 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25752 for ; Fri, 19 Apr 2002 12:07:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27556; Fri, 19 Apr 2002 10:07:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01711; Fri, 19 Apr 2002 09:07:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JG6jIA010698 for ; Fri, 19 Apr 2002 09:06:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JG6jvC010697 for mobile-ip-dist; Fri, 19 Apr 2002 09:06:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JG6gIA010690 for ; Fri, 19 Apr 2002 09:06:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01332 for ; Fri, 19 Apr 2002 09:06:46 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27061; Fri, 19 Apr 2002 10:06:45 -0600 (MDT) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3JG6gI05034; Fri, 19 Apr 2002 09:06:43 -0700 (PDT) Message-ID: <00eb01c1e7bb$f9f506d0$746015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: "Erik Nordmark" , References: Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Fri, 19 Apr 2002 09:05:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > With this approach there is a danger that all implementation, whether mobile > or not, set the "I want a fast response" bit you propose. > Thus I think the routers need to rate limit in any case. > But we can argue this on the IPv6 list :-) > Sure. But that's true of any mechanism that requires node co-operation to relieve congestion, like TCP backoff. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 12:15:21 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26982 for ; Fri, 19 Apr 2002 12:15:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01505; Fri, 19 Apr 2002 10:15:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04361; Fri, 19 Apr 2002 09:15:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JGEPIA010796 for ; Fri, 19 Apr 2002 09:14:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JGEPS2010795 for mobile-ip-dist; Fri, 19 Apr 2002 09:14:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JGEMIA010788 for ; Fri, 19 Apr 2002 09:14:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26559 for ; Fri, 19 Apr 2002 09:14:26 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09417 for ; Fri, 19 Apr 2002 10:14:25 -0600 (MDT) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3JGECI05433; Fri, 19 Apr 2002 09:14:13 -0700 (PDT) Message-ID: <016d01c1e7bd$06333920$746015ac@T23KEMPF> From: "James Kempf" To: "Francis Dupont" , "Brett Pentland" Cc: References: <200204191300.g3JD0iT36286@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Fri, 19 Apr 2002 09:12:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit This will work as well. But not if the only trigger is on the mobile. jak ----- Original Message ----- From: "Francis Dupont" To: "Brett Pentland" Cc: "James Kempf" ; Sent: Friday, April 19, 2002 6:00 AM Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > In your previous mail you wrote: > > If a flag in the RS is the correct approach > > => I believe there is a better approach even for fast RS/RA (which is > not a good idea in the general case IMHO). > > In another email, Francis mentioned a technique of triggering an RA > when an interface comes up. > > => your message suggested the MN sends a RS because the layer 2 detects > the arrival on a new link. My observation is that another entity can get > the same information and use it to trigger a RA. > > Francis, perhaps you could > elaborate on how a mobile node's interface coming up on a network could be > made to trigger an RA from the router on that network without sending an RS > (or a very similar packet). > > => If another entity on the link detects the arrival of the new MN, it can > give the info to a router which can send a RA. The conditions are: > - detection by another entity (works well for PPP, IEEE 802.11 in > infrastructure mode, any layer 2 with some kind of association for > network access control, etc) > - some communication betwee the entity and a router (obvious if the entity > is a router) > - an arrival frequency low enough (delay between two arrivals far greater > than MAX_RA_DELAY_TIME) > > Thanks > > Francis.Dupont@enst-bretagne.fr > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 12:16:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27229 for ; Fri, 19 Apr 2002 12:16:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02449; Fri, 19 Apr 2002 10:16:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04933; Fri, 19 Apr 2002 09:16:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JGFxIA010824 for ; Fri, 19 Apr 2002 09:15:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JGFxjA010823 for mobile-ip-dist; Fri, 19 Apr 2002 09:15:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JGFuIA010816 for ; Fri, 19 Apr 2002 09:15:56 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04639 for ; Fri, 19 Apr 2002 09:16:00 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11210 for ; Fri, 19 Apr 2002 09:16:00 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3JGFxi26129; Fri, 19 Apr 2002 11:16:00 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TXQKD>; Fri, 19 Apr 2002 11:15:58 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC01@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: mobile-ip@sunroof.eng.sun.com Cc: "'fredrik@ipunplugged.com'" , "'tony.johansson@ericsson.com'" Subject: RE: [mobile-ip] A Question about:draft-ietf-mobileip-aaa-nai-00.t xt Date: Fri, 19 Apr 2002 11:15:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E7BD.7D1073F0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E7BD.7D1073F0 Content-Type: text/plain; charset="iso-8859-1" Hello Again; One more thing please: In section 5. It reads: " If the AAAH identity is present, the foreign agent MUST direct an authentication request to this home AAA server when authenticating the mobile node through the AAA infrastructure by means described in [2] " I am not sure if the foreign agent has any control over this!! What about the following text? " If the AAAH identity is present, the foreign agent MUST include this identity when requesting the Mobile Node authentication through the AAA infrastructure as described in [2]. " Regards; Ahmad Muhanna -----Original Message----- From: Muhanna, Ahmad [RICH1:2Q20:EXCH] Sent: Friday, April 19, 2002 10:56 AM To: mobile-ip@sunroof.eng.sun.com Cc: 'fredrik@ipunplugged.com'; 'tony.johansson@ericsson.com' Subject: [mobile-ip] A Question about:draft-ietf-mobileip-aaa-nai-00.txt Hello All; I would like to address the following two points: I. Mobile Node and the new HA NAI extension: In section 4. It reads: " A mobile node MUST provide this in every registration request sent when re-authenticating, or when requesting a specific IP address at initial authentication." 1. Does this mean that whenever the mobile Node include a specific Static Home IP address, Mobile Node MUST provide the AAA NAI extension with Subtype 1? 2. Does this mean when the MN change point of attachment due to Inter-FA handoff It MUST include this extension. If 1 & 2 are true? Where is the backward compatibility with legacy Mobile Node? II. Home Agent handling of AAAH Identity Subtype extension: In section 5. It reads: "The home agent MUST provide this in every registration reply if using the AAA server ." I would prefer more explicit sentence similar to one used earlier: "The home agent MUST provide this in every registration reply sent to the mobile node destined through the AAA infrastructure." Thanks for consideration. Regards; Ahmad Muhanna ------_=_NextPart_001_01C1E7BD.7D1073F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] A Question = about:draft-ietf-mobileip-aaa-nai-00.txt

Hello Again;

One more thing please:

In section 5. It reads:
"
   If the AAAH identity is present, the = foreign agent MUST direct an
   authentication request to this home AAA = server when authenticating
   the mobile node through the AAA = infrastructure by means described in
   [2]
"
I am not sure if the foreign agent has any control = over this!!

What about the following text?
"
   If the AAAH identity is present, the = foreign agent MUST include
   this identity when requesting the = Mobile Node authentication
   through the AAA infrastructure as = described in [2].
"

Regards;
Ahmad Muhanna


-----Original Message-----
From: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Sent: Friday, April 19, 2002 10:56 AM
To: mobile-ip@sunroof.eng.sun.com
Cc: 'fredrik@ipunplugged.com'; = 'tony.johansson@ericsson.com'
Subject: [mobile-ip] A Question = about:draft-ietf-mobileip-aaa-nai-00.txt


Hello All;
I would like to address the following two points: =
I. Mobile Node and the new HA NAI extension:
In section 4. It reads:
" A mobile node MUST provide this in every = registration request sent
   when re-authenticating, or when = requesting a specific IP address at
   initial authentication."
        1. Does = this mean that whenever the mobile Node include a specific Static =
        Home IP = address, Mobile Node MUST provide the AAA NAI extension with Subtype 1? =
        2. Does = this mean when the MN change point of attachment due to Inter-FA = handoff
        It MUST = include this extension.
If 1 & 2 are true?
Where is the backward compatibility with legacy = Mobile Node?
II. Home Agent handling of AAAH Identity Subtype = extension:
In section 5. It reads:
"The home agent MUST provide this in every = registration reply if using
   the AAA server ."
I would prefer more explicit sentence similar to one = used earlier:
"The home agent MUST provide this in every = registration reply sent to
  the mobile node destined through the AAA = infrastructure."
Thanks for consideration.
Regards;
Ahmad Muhanna

------_=_NextPart_001_01C1E7BD.7D1073F0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 12:24:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28341 for ; Fri, 19 Apr 2002 12:24:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11447; Fri, 19 Apr 2002 10:24:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07167; Fri, 19 Apr 2002 09:24:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JGNLIA010970 for ; Fri, 19 Apr 2002 09:23:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JGNLXZ010969 for mobile-ip-dist; Fri, 19 Apr 2002 09:23:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JGNIIA010962 for ; Fri, 19 Apr 2002 09:23:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00012 for ; Fri, 19 Apr 2002 09:23:22 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00450 for ; Fri, 19 Apr 2002 10:23:07 -0600 (MDT) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3JGMvI05907; Fri, 19 Apr 2002 09:22:57 -0700 (PDT) Message-ID: <01a501c1e7be$3eda4920$746015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <748E8123D183394982E32A511DB3E73610B128@daebe005.NOE.Nokia.com> Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Fri, 19 Apr 2002 09:21:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit FMIPv6/BETH is not part of the base spec, so it is not MUST implement. I think the base spec should be defined such that people can get good performance. For better performance they may want to implement FMIPv6/BETH. Think about it like buying a car. You don't want to tell people they need to buy a Porsche in order to be able to accelerate into freeway traffic. jak ----- Original Message ----- From: To: ; Cc: Sent: Friday, April 19, 2002 8:14 AM Subject: RE: [mobile-ip] RA Solicitation Response Delay Performance Fatality > Sorry for my ignorance, but back to the root of the discussion: > > Why we need the immediate RA upon RS? I know that without immediate RA, the L3 handoff is delayed. But both FMIPv6 and BETH allow the MN to use the old CoA for a while (thanks to the tunnel) before executing 'non time critical' L3 handoff. The L2 handoff is considered as time 'critical' > > Thanks for any explanation > > Rene Purnadi > Nokia Research Center > Phone: +1 972.894.4897 > Mobile: +1 972.342.3503 > e-mail: rene.purnadi@nokia.com > > > -----Original Message----- > From: ext Youn-Hee Han [mailto:yhhan@sait.samsung.co.kr] > Sent: Thursday, April 18, 2002 1:21 AM > To: James Kempf > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance > Fatality > > > I would like to point out another stumbling block in RFC 2461, in order to > achive good MIPv6 handoff performance. > > Page 55 of RFC 2461 states the followings. > > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when > many hosts start up on a link at the same time, such as might happen > after recovery from a power failure. If a host has already performed > a random delay since the interface became (re)enabled (e.g., as part > of Duplicate Address Detection [ADDRCONF]) there is no need to delay > again before sending the first Router Solicitation message. > > The above block states the case for an MN sending an RS before receiving an RA. > When an MN moves and re-attaches to a new link, transmittion an RS prior to > receving an RA is good behavior for reducing L3 handoff times. > However, the delaying by some random amount evidently becomes an obstacle > for L3 handoff performance. Although the random delay behavior is a SHOULD, > there should be some kind of reference in the Mobile IPv6 spec to it > > Page 55 of RFC 2461 also states the followings. > > Moreover, a host SHOULD send at least one solicitation in the case where an > advertisement is received prior to having sent a solicitation. > Unsolicited Router Advertisements may be incomplete (see Section > 6.2.3); solicited advertisements are expected to contain complete > information. > > In order to require complete new link information, the above block states > an MN SHOULD send an RS, although it receives an unsolicited RA prior to sending an RS. > I am worried that the BUs for new COA must be sent to HA and CN only after > receiving a solicited RA. Such behavior is also an obstacle for L3 handoff performance. > Although such behavior is a SHOULD, there should be some kind of reference > in the Mobile IPv6 spec to it, too. > > > Youn-Hee Han, > Samsung Advanced Institute of Technology (SAIT) > > > ----- Original Message ----- > From: "James Kempf" > To: "Erik Nordmark" > Cc: > Sent: Thursday, April 18, 2002 1:58 AM > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > > > > Erik, > > > > We're preparing a separate draft for this, which I think we will submit > > to IPNG this week. It is very short (4 pages I think). The draft adds a > > bit to the RS saying that the host would like an immediate response. Of > > course, hosts can cheat and send it even if they aren't doing MIP > > handover, but if everybody plays the rules the congestion control should > > work, like TCP. > > > > The other issue is whether there should be some kind of reference in the > > Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are > > recommended to use it. > > > > jak > > > > ----- Original Message ----- > > From: "Erik Nordmark" > > To: "James Kempf" > > Cc: > > Sent: Tuesday, April 16, 2002 7:50 PM > > Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance > > Fatality > > > > > > > > This isn't security related, but I think it is something that *must* > > be > > > > fixed before the MIPv6 goes to RFC. > > > > > > I think it is sufficient "before MIPv6+IPv6+... can be deployed" - > > > while the issue is important I don't see why it needs to hold up > > > the MIPv6 specification. > > > > > > I'd prefer this being done as a short separate draft since this makes > > it > > > easier to fold it into RFC 2461 at a later time. > > > > > > > Ideally, we could insert some text into the MIPv6 spec saying that > > this > > > > behavior needs to be modified for routers that are handling wireless > > > > links, but this would be somewhat counter to the trend in MIPv6 of > > > > integrating MIP more tightly with standard IPv6 mechanisms. > > > > Alternatively, we could do a separate draft that modified the text > > in > > > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > > > limiting behavior instead (i.e. make the random delay behavior be a > > > > function of the incoming SolRA rate). > > > > > > Pre-RFC versions of neighbor discovery had a the ability (if my memory > > serves > > > me) for routers to immediately unicast a RA in response to a RS, but > > > randomly delay and rate limit any multicast RAs send it response to > > RSs. > > > > > > Having a mechanisms to select between an immediate unicast response > > and > > > a delayed multicast response seemed not worth the effort at the time, > > but > > > that is an avenue that can be explored now. > > > For instance, if the last RS was received less than 3 seconds ago > > > the router could do the randomly delayed multicast RA; otherwise > > > an immediate unicast RA. > > > > > > Erik > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 13:07:32 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04705 for ; Fri, 19 Apr 2002 13:07:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22814; Fri, 19 Apr 2002 10:07:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22292; Fri, 19 Apr 2002 10:06:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JH5sIA011120 for ; Fri, 19 Apr 2002 10:05:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JH5rHk011119 for mobile-ip-dist; Fri, 19 Apr 2002 10:05:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JH5oIA011112 for ; Fri, 19 Apr 2002 10:05:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21908 for ; Fri, 19 Apr 2002 10:05:55 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03363 for ; Fri, 19 Apr 2002 11:05:54 -0600 (MDT) 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 KAA28801; Fri, 19 Apr 2002 10:05:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3JH5rk08582; Fri, 19 Apr 2002 10:05:53 -0700 X-mProtect: <200204191705> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrBT2Zt; Fri, 19 Apr 2002 10:05:51 PDT Message-ID: <3CC04E6F.23E002F5@iprg.nokia.com> Date: Fri, 19 Apr 2002 10:05:51 -0700 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: jari.arkko@piuha.net CC: Tuomas Aura , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> <3CBED045.8050901@piuha.net> <3CBFAE5B.5030901@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Jari Arkko wrote: > > > The sequence number works in > > this case as a sort of a weak cookie, which as you point out, > > the attacker doesn't know. Perhaps this could be enough. > > An update: It was pointed out to me by Tuomas that we don't want to repeat > the problems we have with TCP sequence numbers as cookies. Sequence > numbers are too predictable. Instead, a cookie should be added. The assumption in my earlier mail was that the sequence number in the binding ack was covered by a MAC. This MAC was generated using Kbu. This is from your proposal at http://www.piuha.net/~jarkko/publications/mipv6/issues/issue3.txt. I was just simplifying that by eliminating C2. So even if the attacker guesses the sequence number, he still cant generate the MAC. > And it does look like the approach #3 is preferred by many folks, private emails?? I havent seen anything on the mailing list. > on the basis of giving some protection but still being easily understood > and analyzed. But approach #1 is better than #3. I hope you agree with that. > One idea is that since we have a very BR-like functionality already in > BM, and since there is no way we can authenticate a BM, we should just merge > this functionality and not have any authentication. Agree with that. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 13:16:47 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05670 for ; Fri, 19 Apr 2002 13:16:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04761; Fri, 19 Apr 2002 11:16:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27970; Fri, 19 Apr 2002 10:16:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JHFgIA011231 for ; Fri, 19 Apr 2002 10:15:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JHFg3O011230 for mobile-ip-dist; Fri, 19 Apr 2002 10:15:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JHFcIA011223 for ; Fri, 19 Apr 2002 10:15:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21249 for ; Fri, 19 Apr 2002 10:15:30 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08681 for ; Fri, 19 Apr 2002 11:15:29 -0600 (MDT) 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 KAA29817; Fri, 19 Apr 2002 10:15:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3JHFSb23207; Fri, 19 Apr 2002 10:15:28 -0700 X-mProtect: <200204191715> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdP9IzWH; Fri, 19 Apr 2002 10:15:27 PDT Message-ID: <3CC050AF.B9F1C13@iprg.nokia.com> Date: Fri, 19 Apr 2002 10:15:27 -0700 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: jari.arkko@piuha.net, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> <3CBED045.8050901@piuha.net> <3CBFAE5B.5030901@piuha.net> <3CC04E6F.23E002F5@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry for following up on my own mail.... > > One idea is that since we have a very BR-like functionality already in > > BM, and since there is no way we can authenticate a BM, we should just merge > > this functionality and not have any authentication. > > Agree with that. I missed this. I do not understand what you mean by "merging this functionality?" Are you thinking of eliminating BR and adding another code to the BM message? I hope you didnt mean that. The agree was only for BR not needing any authentication Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 15:22:27 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21830 for ; Fri, 19 Apr 2002 15:22:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01607; Fri, 19 Apr 2002 12:21:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15051; Fri, 19 Apr 2002 12:21:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JJKmIA011448 for ; Fri, 19 Apr 2002 12:20:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JJKmde011447 for mobile-ip-dist; Fri, 19 Apr 2002 12:20:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JJKjIA011440 for ; Fri, 19 Apr 2002 12:20:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21257 for ; Fri, 19 Apr 2002 12:20:49 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25411 for ; Fri, 19 Apr 2002 13:20:47 -0600 (MDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3JJKVkL025825; Fri, 19 Apr 2002 12:20:32 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA29516; Fri, 19 Apr 2002 15:20:31 -0400 (EDT) Date: Fri, 19 Apr 2002 15:20:31 -0400 From: "Madhavi W. Chandra" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Message-ID: <20020419152031.A29507@cisco.com> References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Mon, Apr 08, 2002 at 03:30:37PM -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: HI All, Is there a problem statement associated with this draft? We are not clear on what problem this draft is trying to solve. If the idea is to enable a fast handoff by reducing signaling all the way to the HA, this falls in the domain of the handoff draft for v4. It seems like a heavy weight idea for implementation, without clear need. Please comment. Thanks, Madhavi On Mon, Apr 08, 2002 at 03:30:37PM -0500, Basavaraj.Patil@nokia.com wrote: > Folks, > > This is a WG last call for: Mobile IP Regional Registration - > draft-ietf-mobileip-reg-tunnel-06.txt > This draft is a standards track WG document. > > Please send in your comments by April 22nd, 2002 to the authors or > to the WG discussion list. > > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 15:41:28 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24325 for ; Fri, 19 Apr 2002 15:41:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10206; Fri, 19 Apr 2002 12:40:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21796; Fri, 19 Apr 2002 12:40:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JJddIA011528 for ; Fri, 19 Apr 2002 12:39:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JJdd1L011527 for mobile-ip-dist; Fri, 19 Apr 2002 12:39:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JJdaIA011520 for ; Fri, 19 Apr 2002 12:39:36 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21429 for ; Fri, 19 Apr 2002 12:39:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17464 for ; Fri, 19 Apr 2002 13:39:39 -0600 (MDT) 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 MAA08380; Fri, 19 Apr 2002 12:39:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3JJdc425893; Fri, 19 Apr 2002 12:39:38 -0700 X-mProtect: <200204191939> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWVrCNm; Fri, 19 Apr 2002 12:39:37 PDT Message-ID: <3CC07279.CFA48B8@iprg.nokia.com> Date: Fri, 19 Apr 2002 12:39:37 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Madhavi W. Chandra" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Madhavi, I think the problem statement is clear. A method is needed by which registrations can be localized. Fast handoff does not solve this problem. Every new attachment to an access router still would need to deliver a binding update to a home agent. Regards, Charlie P. "Madhavi W. Chandra" wrote: > > HI All, > > Is there a problem statement associated with this draft? We are not > clear on what problem this draft is trying to solve. If the idea is to > enable a fast handoff by reducing signaling all the way to the HA, > this falls in the domain of the handoff draft for v4. > > It seems like a heavy weight idea for implementation, without clear > need. Please comment. > > Thanks, > Madhavi > > On Mon, Apr 08, 2002 at 03:30:37PM -0500, Basavaraj.Patil@nokia.com wrote: > > Folks, > > > > This is a WG last call for: Mobile IP Regional Registration - > > draft-ietf-mobileip-reg-tunnel-06.txt > > This draft is a standards track WG document. > > > > Please send in your comments by April 22nd, 2002 to the authors or > > to the WG discussion list. > > > > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 16:12:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27729 for ; Fri, 19 Apr 2002 16:12:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24398; Fri, 19 Apr 2002 14:12:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01851; Fri, 19 Apr 2002 13:12:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JKBKIA011679 for ; Fri, 19 Apr 2002 13:11:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JKBKsq011678 for mobile-ip-dist; Fri, 19 Apr 2002 13:11:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JKBHIA011671 for ; Fri, 19 Apr 2002 13:11:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01310 for ; Fri, 19 Apr 2002 13:11:21 -0700 (PDT) From: Scott_Grant@NAI.com Received: from RelayDAL.nai.com (relaydal.nai.com [161.69.213.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08041 for ; Fri, 19 Apr 2002 14:11:21 -0600 (MDT) Received: from txwsout1.nai.com (txwsout1.nai.com [161.69.96.120]) by RelayDAL.nai.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g3JKAbg08622 for ; Fri, 19 Apr 2002 15:10:38 -0500 (CDT) Received: FROM tx-ex-bridge1.nai.com BY txwsout1.nai.com ; Fri Apr 19 15:13:14 2002 -0500 Received: by DAL-96-124.nai.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 15:13:16 -0500 Message-ID: <55E02B6F8FA8D311985300902740BB200426C7C7@SNC-5-88.nai.com> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Vendor Specific Attributes supporting IP Mobile? Date: Fri, 19 Apr 2002 15:12:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I'd like to add support to the product that I'm working on(Sniffer) for Mobile IP. Toward that end, if any of you are using any Vendor Specific Attributes(for RADIUS, L2TP etc) that are directly related to Mobile IP, CDMA 2000, or even GSM networks, PLEASE let me know details and I'll try to add that support to our product. I'd appreciate any responses, and I feel that this would help all of our customers. Scott From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 17:30:36 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05992 for ; Fri, 19 Apr 2002 17:30:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06126; Fri, 19 Apr 2002 15:30:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26146; Fri, 19 Apr 2002 14:30:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JLTJIA011842 for ; Fri, 19 Apr 2002 14:29:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JLTI0t011841 for mobile-ip-dist; Fri, 19 Apr 2002 14:29:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JLTFIA011834 for ; Fri, 19 Apr 2002 14:29:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05612 for ; Fri, 19 Apr 2002 14:29:18 -0700 (PDT) Received: from cisco.com (shako.cisco.com [64.102.17.78]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11654 for ; Fri, 19 Apr 2002 15:29:18 -0600 (MDT) Received: (from mchandra@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA17511; Fri, 19 Apr 2002 17:29:04 -0400 (EDT) Date: Fri, 19 Apr 2002 17:29:04 -0400 From: "Madhavi W. Chandra" To: "Charles E. Perkins" Cc: "Madhavi W. Chandra" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Message-ID: <20020419172904.B16284@cisco.com> References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC07279.CFA48B8@iprg.nokia.com>; from charliep@iprg.nokia.com on Fri, Apr 19, 2002 at 12:39:37PM -0700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, Thanks for the quick response. On Fri, Apr 19, 2002 at 12:39:37PM -0700, Charles E. Perkins wrote: > > Hello Madhavi, > > I think the problem statement is clear. A method is needed by which > registrations can be localized. I agree that minimizing the long haul is needed. However, I'm not clear on why introducing a hierarchy and heavy weight changes to MIP entities is beneficial. It imposes much on a practical implementation. Dynamic 'local' home agent allocation could minimize the long haul without the new messages and much change to MN. I respectfully disagree that the problem statement is clear. Regards, Madhavi > > Fast handoff does not solve this problem. Every new attachment to > an access router still would need to deliver a binding update to > a home agent. > > Regards, > Charlie P. > > > "Madhavi W. Chandra" wrote: > > > > HI All, > > > > Is there a problem statement associated with this draft? We are not > > clear on what problem this draft is trying to solve. If the idea is to > > enable a fast handoff by reducing signaling all the way to the HA, > > this falls in the domain of the handoff draft for v4. > > > > It seems like a heavy weight idea for implementation, without clear > > need. Please comment. > > > > Thanks, > > Madhavi > > > > On Mon, Apr 08, 2002 at 03:30:37PM -0500, Basavaraj.Patil@nokia.com wrote: > > > Folks, > > > > > > This is a WG last call for: Mobile IP Regional Registration - > > > draft-ietf-mobileip-reg-tunnel-06.txt > > > This draft is a standards track WG document. > > > > > > Please send in your comments by April 22nd, 2002 to the authors or > > > to the WG discussion list. > > > > > > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 18:04:52 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09766 for ; Fri, 19 Apr 2002 18:04:52 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20487; Fri, 19 Apr 2002 16:04:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26543; Fri, 19 Apr 2002 15:04:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JM3xIA011970 for ; Fri, 19 Apr 2002 15:03:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JM3x0T011969 for mobile-ip-dist; Fri, 19 Apr 2002 15:03:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JM3uIA011962 for ; Fri, 19 Apr 2002 15:03:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08264 for ; Fri, 19 Apr 2002 15:04:00 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15599 for ; Fri, 19 Apr 2002 15:03:59 -0700 (PDT) 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 PAA15707; Fri, 19 Apr 2002 15:03:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3JM3w812806; Fri, 19 Apr 2002 15:03:58 -0700 X-mProtect: <200204192203> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxY6UIc; Fri, 19 Apr 2002 15:03:55 PDT Message-ID: <3CC0944C.C9347BA9@iprg.nokia.com> Date: Fri, 19 Apr 2002 15:03:56 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Madhavi W. Chandra" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Madhavi W. Chandra" wrote: >> I think the problem statement is clear. A method is needed by which >> registrations can be localized. > > I agree that minimizing the long haul is needed. However, > I'm not clear on why introducing a hierarchy and heavy weight > changes to MIP entities is beneficial. It imposes much > on a practical implementation. This is debatable. It is possible to make good implementations that don't take much code. > Dynamic 'local' home agent allocation could minimize the long haul > without the new messages and much change to MN. This is another technique. It has advantages and disadvantages. That doesn't mean the problem statement is unclear. It more means that there is another solution which may be more appropriate for your constraints, but for a slightly different problem. For instance, your solution would not work for a host with a statically allocated home address. And yet I have no problems with the solution to the other problem that you mention. In fact, I helped to work on it. > I respectfully disagree that the problem statement is clear. I hope this helps, and anyway I really think you are trying to solve a somewhat different problem. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 18:16:54 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11028 for ; Fri, 19 Apr 2002 18:16:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21061; Fri, 19 Apr 2002 15:16:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01644; Fri, 19 Apr 2002 15:16:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JMEsIA012065 for ; Fri, 19 Apr 2002 15:14:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JMEsRu012064 for mobile-ip-dist; Fri, 19 Apr 2002 15:14:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JMEpIA012057 for ; Fri, 19 Apr 2002 15:14:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11980 for ; Fri, 19 Apr 2002 15:14:55 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00197 for ; Fri, 19 Apr 2002 16:14:54 -0600 (MDT) Received: from mkulkarn-u10.cisco.com (mkulkarn-u10.cisco.com [128.107.162.246]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3JMEgpG002152; Fri, 19 Apr 2002 15:14:42 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by mkulkarn-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA26477; Fri, 19 Apr 2002 15:14:42 -0700 (PDT) Message-ID: <3CC096D2.BE322956@cisco.com> Date: Fri, 19 Apr 2002 15:14:42 -0700 From: Milind Kulkarni X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Madhavi W. Chandra" CC: "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with Madhavi's opinion that the problem statement is not very clear. There are only two perceived problem this draft is trying to solve as per section 9: 9. Regional Registration Message Formats These messages are used by the mobile node instead of the existing Registration Request and Registration Reply, in order (1) to make registration work faster, and also (2) to reduce network load for Mobile IP registration. Argument #2 is very weak. While it may be good to localize the registrations, it is probably just a small optimization. However, all the extra messaging and work that the MN, RFA, GFA need to do, doesn't address the root cause. After doing all this Regional registration messaging, the problem of hand-off remains, although the frequency of that may be slightly reduced. What do others think? Thanks, Milind "Madhavi W. Chandra" wrote: > > Hi Charlie, > > Thanks for the quick response. > > On Fri, Apr 19, 2002 at 12:39:37PM -0700, Charles E. Perkins wrote: > > > > Hello Madhavi, > > > > I think the problem statement is clear. A method is needed by which > > registrations can be localized. > > I agree that minimizing the long haul is needed. However, > I'm not clear on why introducing a hierarchy and heavy weight > changes to MIP entities is beneficial. It imposes much > on a practical implementation. > > Dynamic 'local' home agent allocation could minimize the long haul > without the new messages and much change to MN. > > I respectfully disagree that the problem statement is clear. > > Regards, > Madhavi > > > > > Fast handoff does not solve this problem. Every new attachment to > > an access router still would need to deliver a binding update to > > a home agent. > > > > Regards, > > Charlie P. > > > > > > "Madhavi W. Chandra" wrote: > > > > > > HI All, > > > > > > Is there a problem statement associated with this draft? We are not > > > clear on what problem this draft is trying to solve. If the idea is to > > > enable a fast handoff by reducing signaling all the way to the HA, > > > this falls in the domain of the handoff draft for v4. > > > > > > It seems like a heavy weight idea for implementation, without clear > > > need. Please comment. > > > > > > Thanks, > > > Madhavi > > > > > > On Mon, Apr 08, 2002 at 03:30:37PM -0500, Basavaraj.Patil@nokia.com wrote: > > > > Folks, > > > > > > > > This is a WG last call for: Mobile IP Regional Registration - > > > > draft-ietf-mobileip-reg-tunnel-06.txt > > > > This draft is a standards track WG document. > > > > > > > > Please send in your comments by April 22nd, 2002 to the authors or > > > > to the WG discussion list. > > > > > > > > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 18:24:23 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11798 for ; Fri, 19 Apr 2002 18:24:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10200; Fri, 19 Apr 2002 15:23:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04991; Fri, 19 Apr 2002 15:23:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JMN9IA012153 for ; Fri, 19 Apr 2002 15:23:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JMN90S012152 for mobile-ip-dist; Fri, 19 Apr 2002 15:23:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JMN5IA012145 for ; Fri, 19 Apr 2002 15:23:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04700 for ; Fri, 19 Apr 2002 15:23:09 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09921 for ; Fri, 19 Apr 2002 15:23:09 -0700 (PDT) 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 PAA17555; Fri, 19 Apr 2002 15:23:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3JMN8w06541; Fri, 19 Apr 2002 15:23:08 -0700 X-mProtect: <200204192223> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ4mXau; Fri, 19 Apr 2002 15:23:06 PDT Message-ID: <3CC098CA.CA6E1E9C@iprg.nokia.com> Date: Fri, 19 Apr 2002 15:23:06 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Milind Kulkarni CC: "Madhavi W. Chandra" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Milind Kulkarni wrote: > 9. Regional Registration Message Formats > > These messages are used by the mobile node instead of the > existing Registration Request and Registration Reply, in > order (1) to make registration work faster, and also > (2) to reduce network load for Mobile IP registration. > > Argument #2 is very weak. While it may be good to localize > the registrations, it is probably just a small optimization. > However, all the extra messaging and work that the MN, RFA, > GFA need to do, doesn't address the root cause. After doing > all this Regional registration messaging, the problem of > hand-off remains, although the frequency of that may be > slightly reduced. > > What do others think? I guess I'm not "others", but anyway I have an opinion about it. First, regional registration is not mandatory. If your product is not intended to be sold into a market that needs it, you do not have to implement. Second, there are many distinct techniques that each produce some performance improvement. You do not have to implement all of them or any of them, but I don't believe that means that the opportunity should be removed for those people who may need the additional performance improvement. Third, it's done. It's not like we have to make a huge investment to produce the technology. We already have it. There's no reason to prohibit people who want it from using it. Fourth, regional registration does not reduce the frequency of handover. It only localizes the resulting signaling. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 18:30:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12361 for ; Fri, 19 Apr 2002 18:30:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01134; Fri, 19 Apr 2002 16:30:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08451; Fri, 19 Apr 2002 15:30:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JMTOIA012257 for ; Fri, 19 Apr 2002 15:29:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JMTOWg012256 for mobile-ip-dist; Fri, 19 Apr 2002 15:29:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.130] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JMTLIA012249 for ; Fri, 19 Apr 2002 15:29:21 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g3JMTO1j000391; Fri, 19 Apr 2002 15:29:24 -0700 (PDT) Message-Id: <200204192229.g3JMTO1j000391@jurassic.eng.sun.com> Date: Fri, 19 Apr 2002 15:31:43 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Updated unresolved issue #16: Unrecognized MH Type To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +GUZlEPWdW8MkM32ymL+Tw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Question: Is this an important error to give? Should we define a new > MH Type and message called Error that would contain an error code? Or > should we use the Binding Ack message with a new error code? Or should > we define the BM message as a general error message for mobility, and > define an error code for wrong MH Type? Or should we use ICMP > Parameter Problem Code 0 (erroneous header field encountered) and > pointer to MH Type to indicate problems. > > Proposal: Use of the Binding Ack message does not seem appropriate as > it would be then be used in a quite different role than originally > intended. The ICMP Parameter Problem Code 0 approach is possible, but > involves a complicated decision based on looking at the reported > pointer and original packet. Such actions are typically not done > based on these messages. A new error message might be appropriate, > but then we would have two error-reporting messages, Binding Error > and Binding Missing. The proposal is therefore that the Binding > Missing message be renamed to Mobility Error, and added an error > code to indicate (1) unsupported MH Type, (2) missing binding, and > (3) any new error perhaps needed in future extensions. The new error message seems to be a clean approach. Renaming BM to "Mobility binding error" should cover binding msg related errors and missing binding (this is in a way an error too) message. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 18:43:39 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13842 for ; Fri, 19 Apr 2002 18:43:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11634; Fri, 19 Apr 2002 16:43:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06893; Fri, 19 Apr 2002 15:43:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JMggIA012358 for ; Fri, 19 Apr 2002 15:42:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JMgfq4012357 for mobile-ip-dist; Fri, 19 Apr 2002 15:42:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JMgcIA012350 for ; Fri, 19 Apr 2002 15:42:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21420 for ; Fri, 19 Apr 2002 15:42:42 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17831 for ; Fri, 19 Apr 2002 15:42:42 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3JMgf412918 for ; Fri, 19 Apr 2002 17:42:41 -0500 (CDT) Message-ID: <3CC09D75.5000609@alcatel.com> Date: Fri, 19 Apr 2002 17:43:01 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Milind and Madhavi, Isn't it very late to raise the problem statement issue for reg-tunnel draft? This draft has been around since so long and it in fact is rooted on Charlie and others' research as early as 1998. Sorry to say, but what have you been doing then? reg-tunnel draft for v4 and a similar one for v6 (at the expense of flaring up some early debates) are part of extensions to the base mipv4/v6 protocols for domain-based mobility. Let's go for them. Regards, Milind Kulkarni wrote: >I agree with Madhavi's opinion that the problem statement >is not very clear. There are only two perceived problem >this draft is trying to solve as per section 9: > >9. Regional Registration Message Formats > > These messages are used by the mobile node instead of the > existing Registration Request and Registration Reply, in > order (1) to make registration work faster, and also > (2) to reduce network load for Mobile IP registration. > >Argument #2 is very weak. While it may be good to localize >the registrations, it is probably just a small optimization. >However, all the extra messaging and work that the MN, RFA, >GFA need to do, doesn't address the root cause. After doing >all this Regional registration messaging, the problem of >hand-off remains, although the frequency of that may be >slightly reduced. > >What do others think? > >Thanks, >Milind > > > >"Madhavi W. Chandra" wrote: > >>Hi Charlie, >> >>Thanks for the quick response. >> >>On Fri, Apr 19, 2002 at 12:39:37PM -0700, Charles E. Perkins wrote: >> >>>Hello Madhavi, >>> >>>I think the problem statement is clear. A method is needed by which >>>registrations can be localized. >>> >>I agree that minimizing the long haul is needed. However, >>I'm not clear on why introducing a hierarchy and heavy weight >>changes to MIP entities is beneficial. It imposes much >>on a practical implementation. >> >>Dynamic 'local' home agent allocation could minimize the long haul >>without the new messages and much change to MN. >> >>I respectfully disagree that the problem statement is clear. >> >>Regards, >>Madhavi >> >>>Fast handoff does not solve this problem. Every new attachment to >>>an access router still would need to deliver a binding update to >>>a home agent. >>> >>>Regards, >>>Charlie P. >>> >>> >>>"Madhavi W. Chandra" wrote: >>> >>>>HI All, >>>> >>>>Is there a problem statement associated with this draft? We are not >>>>clear on what problem this draft is trying to solve. If the idea is to >>>>enable a fast handoff by reducing signaling all the way to the HA, >>>>this falls in the domain of the handoff draft for v4. >>>> >>>>It seems like a heavy weight idea for implementation, without clear >>>>need. Please comment. >>>> >>>>Thanks, >>>>Madhavi >>>> >>>>On Mon, Apr 08, 2002 at 03:30:37PM -0500, Basavaraj.Patil@nokia.com wrote: >>>> >>>>>Folks, >>>>> >>>>>This is a WG last call for: Mobile IP Regional Registration - >>>>>draft-ietf-mobileip-reg-tunnel-06.txt >>>>>This draft is a standards track WG document. >>>>> >>>>>Please send in your comments by April 22nd, 2002 to the authors or >>>>>to the WG discussion list. >>>>> >>>>>-Basavaraj >>>>> --behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 19:11:25 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16479 for ; Fri, 19 Apr 2002 19:11:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04034; Fri, 19 Apr 2002 17:11:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19229; Fri, 19 Apr 2002 16:11:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JNAOIA012457 for ; Fri, 19 Apr 2002 16:10:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JNAOTn012456 for mobile-ip-dist; Fri, 19 Apr 2002 16:10:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JNALIA012449 for ; Fri, 19 Apr 2002 16:10:21 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27949 for ; Fri, 19 Apr 2002 16:10:25 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03748 for ; Fri, 19 Apr 2002 17:10:25 -0600 (MDT) Received: from mkulkarn-u10.cisco.com (mkulkarn-u10.cisco.com [128.107.162.246]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3JNAOpG028533; Fri, 19 Apr 2002 16:10:24 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by mkulkarn-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA26494; Fri, 19 Apr 2002 16:10:24 -0700 (PDT) Message-ID: <3CC0A3E0.DE3AA0F@cisco.com> Date: Fri, 19 Apr 2002 16:10:24 -0700 From: Milind Kulkarni X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> <3CC09D75.5000609@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Behcet, Regarding being late on this draft, isn't that how things usually get done, during last minute? Just kidding :) But that's not the point. IMHO the point is, better late than never. And the last-call email solicits comment by April 22 (which is still good 3 days away). I am entitled to an opinion just like anyone else. And I am not sorry about expressing it. Regards, Milind Whatever Behcet Sarikaya wrote: > > Milind and Madhavi, > Isn't it very late to raise the problem statement issue for reg-tunnel > draft? This draft has been around since so long and it in fact is rooted > on Charlie and others' research as early as 1998. Sorry to say, but what > have you been doing then? > reg-tunnel draft for v4 and a similar one for v6 (at the expense of > flaring up some early debates) are part of extensions to the base > mipv4/v6 protocols for domain-based mobility. > Let's go for them. > Regards, From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 19:26:11 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18173 for ; Fri, 19 Apr 2002 19:26:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21365; Fri, 19 Apr 2002 17:26:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25059; Fri, 19 Apr 2002 16:26:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JNPEIA012549 for ; Fri, 19 Apr 2002 16:25:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3JNPDRG012548 for mobile-ip-dist; Fri, 19 Apr 2002 16:25:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3JNPAIA012541 for ; Fri, 19 Apr 2002 16:25:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03039 for ; Fri, 19 Apr 2002 16:25:15 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21000 for ; Fri, 19 Apr 2002 17:25:14 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3JNP2i01610; Fri, 19 Apr 2002 18:25:02 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TXYJX>; Fri, 19 Apr 2002 18:25:02 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC09@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Charles E. Perkins'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt Date: Fri, 19 Apr 2002 18:25:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E7F9.6CD16620" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E7F9.6CD16620 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie; I am sorry you may have come across this point before but I hope you have a quick answer. In section 1. Introduction of this draft it says: " Foreign agents that support regional registrations are also required to support registrations according to Mobile IPv4 [9]. If there is a foreign agent address announced in the Agent Advertisement, the mobile node may register that foreign agent care-of address with its home agent [9]. " Now: as per RFC3220, FA are required to set the 'F' bit in Agent advertisement as per section 2.1.1. " An Agent Advertisement message MUST NOT have the 'B' bit set if the 'F' bit is not also set. Furthermore, at least one of the 'F' bit and the 'H' bit MUST be set in any Agent Advertisement message sent " Also, in RFC3220 section 2.1.1. It is required to have at least one care-of address when the 'F' bit is set. " Care-of Address(es) The advertised foreign agent care-of address(es) provided by this foreign agent. An Agent Advertisement MUST include at least one care-of address if the 'F' bit is set. The number of care-of addresses present is determined by the Length field in the Extension. " On the other hand, (in section 3.3.) this draft says that the 'I' bit MUST be set to support the regional tunneling management. It also continues to say that IF the 'I' bit is set, there MUST be at least one care-of address in Agent Advertisement. However, it say that this care-of address could be set to ZERO. Now: Here is the conflict: A Foreign Agent which supports regional tunneling management MUST support registrations according to Mobile IPv4 [9]. In other words, this FA MUST set both the 'F' and 'I' bits. I hope you agree. The problem is that you override the requirement of RFC3220 " Which is a MUST" by allowing the FA to set the only included care-of address to ZERO. A legacy Mobile Node which does not support regional tunneling management will not be able to register with this FA. Please let me know of what you think? Thanks for consideration. Ahmad Muhanna ------_=_NextPart_001_01C1E7F9.6CD16620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] WG Last Call: = draft-ietf-mobileip-reg-tunnel-06.txt

Hello Charlie;
I am sorry you may have come across this point = before but I hope you have a quick answer.

In section 1. Introduction of this draft it = says:
"
   Foreign agents that support regional = registrations are also required
   to support registrations according to = Mobile IPv4 [9].  If there is
   a foreign agent address announced in = the Agent Advertisement, the
   mobile node may register that foreign = agent care-of address with its
   home agent [9].
"

Now: as per RFC3220, FA are required to set the 'F' = bit in Agent advertisement as per section
2.1.1.
"
   An Agent Advertisement message MUST NOT = have the 'B' bit set if the
   'F' bit is not also set.  = Furthermore, at least one of the 'F' bit
   and the 'H' bit MUST be set in any = Agent Advertisement message sent
"

Also, in RFC3220 section 2.1.1. It is required to = have at least one care-of address
when the 'F' bit is set.

"
      Care-of = Address(es)

          &nb= sp;    The advertised foreign agent care-of address(es) = provided
          &nb= sp;    by this foreign agent.  An Agent = Advertisement MUST
          &nb= sp;    include at least one care-of address if the 'F' = bit is
          &nb= sp;    set.  The number of care-of addresses = present is
          &nb= sp;    determined by the Length field in the = Extension.
"

On the other hand, (in section 3.3.) this draft says = that the 'I' bit MUST be set to support
the regional tunneling management. It also continues = to say that IF the
'I' bit is set, there MUST be at least one care-of = address in Agent Advertisement.
However, it say that this care-of address could be = set to ZERO.

Now:
Here is the conflict:

A Foreign Agent which supports regional tunneling = management MUST support
registrations according to Mobile IPv4 [9]. In other = words, this FA MUST set both the 'F' and 'I' bits.
I hope you agree.

The problem is that you override the requirement of = RFC3220 " Which is a MUST"
by allowing the FA to set the only included care-of = address to ZERO.

A legacy Mobile Node which does not support regional = tunneling management will
not be able to register with this FA.

Please let me know of what you think?
Thanks for consideration.

Ahmad Muhanna

------_=_NextPart_001_01C1E7F9.6CD16620-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 20:21:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23572 for ; Fri, 19 Apr 2002 20:21:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06481; Fri, 19 Apr 2002 17:21:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15714; Fri, 19 Apr 2002 17:21:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K0KVIA012662 for ; Fri, 19 Apr 2002 17:20:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3K0KVvD012661 for mobile-ip-dist; Fri, 19 Apr 2002 17:20:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K0KRIA012654 for ; Fri, 19 Apr 2002 17:20:27 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21172 for ; Fri, 19 Apr 2002 17:20:32 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21199 for ; Fri, 19 Apr 2002 17:20:32 -0700 (PDT) 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 RAA23061; Fri, 19 Apr 2002 17:20:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3K0KUh10371; Fri, 19 Apr 2002 17:20:30 -0700 X-mProtect: <200204200020> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfWDtTv; Fri, 19 Apr 2002 17:20:28 PDT Message-ID: <3CC0B44C.DB862958@iprg.nokia.com> Date: Fri, 19 Apr 2002 17:20:28 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Manolis Sifalakis , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > Rajeev, > > > ^^^^ > > The AR must start tunneling immediately after processing the FBU. In > fact, > > the control (to turn on tunneling) must reside at the MN. > > > > > > > > immediately, in which case the mobile node will miss those packets > sent > > > before it moves, or it can bicast packets down the old link and the > > > tunnel. > > > > > > > clarification: bicasting is not proposed in the spec (after a long > > discussion > > culminating in a vote at London IETF). > > > > If it does this, the mobile loses packets between when the FBU is > received > by the AR and when it finally arrives on the other link (remember: > neither > bicasting nor buffering are in this draft). Right, how to handle potential packet loss is another issue. > > > If the router gets a Link Down, this can be used to reduce the packet > loss > to just the L2 handover blackout period. Of course, if this trigger is > not available, then the FBU must be used. > > Or was there some other reason why you feel the FBU must be the > tunnel setup trigger? > My concern is redirecting traffic without explicit consent from the MN. Is "Link Down" enough authorization to start forwarding traffic on the tunnel ? I am not sure.. The base protocol itself has to operate with FBU, which authorizes the AR to refirect traffic. Regards, -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 20:39:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25643 for ; Fri, 19 Apr 2002 20:39:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17908; Fri, 19 Apr 2002 18:39:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21243; Fri, 19 Apr 2002 17:38:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K0cBIA012773 for ; Fri, 19 Apr 2002 17:38:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3K0cB1Z012772 for mobile-ip-dist; Fri, 19 Apr 2002 17:38:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K0c8IA012765 for ; Fri, 19 Apr 2002 17:38:08 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21001 for ; Fri, 19 Apr 2002 17:38:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13201 for ; Fri, 19 Apr 2002 18:38:10 -0600 (MDT) 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 RAA23530; Fri, 19 Apr 2002 17:38:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3K0c9W21244; Fri, 19 Apr 2002 17:38:09 -0700 X-mProtect: <200204200038> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLq7vBF; Fri, 19 Apr 2002 17:38:07 PDT Message-ID: <3CC0B870.B007C2AF@iprg.nokia.com> Date: Fri, 19 Apr 2002 17:38:08 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: James Kempf , Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality References: <00cf01c1e642$2c476130$a96015ac@T23KEMPF> <3CBF4103.E5FD81E@iprg.nokia.com> <15552.9754.947421.690767@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Mike, Michael Thomas wrote: > Rajeev Koodli writes: > > Hello Jim, > > > > I see your need, but I am a little concerned about the increase in > > RAs and the associated overhead.. There is also the potential for abuse > > as you mention. Shouldn't a MN interested in faster > > address acquisition use something like FMIPv6 ? > > Rajeev, > > This assumes that the AR supports and offers > FMIPv6. I don't see that as the case always, > especially with open kiosk kinds of situations. > IMO, it should be possible for a mobile node > reasonably close to its home agent to dispense > with all of the heavy machinery (and dependencies) > and achieve reasonable results. The couple of > seconds of delay here (as well as DAD) doesn't > strike me as striking a very good balance. > > If the address acquisition is due to roaming, then the delay is tolerable. If it is due to handover, I agree that FMIPv6 may not be available everywhere. But, I am still concerned about the increase in RA overhead. A tweak that might dampen the load is to consider multicasting solicited RA to all-nodes so that the solicitations are reduced. Each node should wait for a short time (say few tens of milliseconds) before sending an RS. This may have been discussed in IPv6 with a No :-) -Rajeev > Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 20:51:57 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26832 for ; Fri, 19 Apr 2002 20:51:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16724; Fri, 19 Apr 2002 18:51:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25541; Fri, 19 Apr 2002 17:51:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K0p5IA012880 for ; Fri, 19 Apr 2002 17:51:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3K0p5hu012879 for mobile-ip-dist; Fri, 19 Apr 2002 17:51:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K0p2IA012872 for ; Fri, 19 Apr 2002 17:51:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00448 for ; Fri, 19 Apr 2002 17:51:05 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16494 for ; Fri, 19 Apr 2002 18:51:04 -0600 (MDT) Received: from AlperVAIO (dhcp115.docomolabs-usa.com [172.21.96.115]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3K0opI27934; Fri, 19 Apr 2002 17:50:51 -0700 (PDT) Message-ID: <046701c1e804$7016f330$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Rajeev Koodli" , "James Kempf" Cc: "Manolis Sifalakis" , References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 Date: Fri, 19 Apr 2002 17:43:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, > > If the router gets a Link Down, this can be used to reduce the packet > > loss > > to just the L2 handover blackout period. Of course, if this trigger is > > not available, then the FBU must be used. > > > > Or was there some other reason why you feel the FBU must be the > > tunnel setup trigger? > > > > My concern is redirecting traffic without explicit consent from the > MN. Is "Link Down" enough authorization to start forwarding > traffic on the tunnel ? I am not sure.. The base protocol itself has to > operate with FBU, which authorizes the AR to refirect traffic. F-BU is always a must. The feature is: if the network supports link-down trigger, oldAR can further wait (after receiving F-BU) for this trigger to change the routing. So, this is an additional optimization to change the routing at the exact point in time (L2 event), and relies on link-layer triggers. We must already have this stated (probably not clear enough) in the draft. alper From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 21:38:12 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01619 for ; Fri, 19 Apr 2002 21:38:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11026; Fri, 19 Apr 2002 18:37:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15145; Fri, 19 Apr 2002 18:37:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K1aTIA012985 for ; Fri, 19 Apr 2002 18:36:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3K1aSLR012984 for mobile-ip-dist; Fri, 19 Apr 2002 18:36:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K1aKIA012977 for ; Fri, 19 Apr 2002 18:36:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12100 for ; Fri, 19 Apr 2002 18:36:24 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10693 for ; Fri, 19 Apr 2002 18:36:23 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3K1WSi05852; Fri, 19 Apr 2002 20:32:28 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TXYTY>; Fri, 19 Apr 2002 20:32:27 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC0A@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Charles E. Perkins'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt Date: Fri, 19 Apr 2002 20:32:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E80B.39E8D8D0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E80B.39E8D8D0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie; one more thing. DO we need section 6? I thought that there is a new draft which also address GNAI for the AAA use. draft-ietf-mobileip-aaa-nai-00.txt Can not we add FA-NAI subtype to the this draft and get rid of section 6? Regards; Ahmad Muhanna Nortel Networks ------_=_NextPart_001_01C1E80B.39E8D8D0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt

Hello Charlie;
one more thing.

DO we need section 6?

I thought that there is a new draft which also address GNAI for the AAA use.
draft-ietf-mobileip-aaa-nai-00.txt

Can not we add FA-NAI subtype to the this draft and get rid of
section 6?


Regards;
Ahmad Muhanna
Nortel Networks

------_=_NextPart_001_01C1E80B.39E8D8D0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Apr 19 23:55:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17657 for ; Fri, 19 Apr 2002 23:55:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23556; Fri, 19 Apr 2002 20:55:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00893; Fri, 19 Apr 2002 20:54:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K3s7IA013208 for ; Fri, 19 Apr 2002 20:54:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3K3s7dp013207 for mobile-ip-dist; Fri, 19 Apr 2002 20:54:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3K3s4IA013200 for ; Fri, 19 Apr 2002 20:54:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13086 for ; Fri, 19 Apr 2002 20:54:09 -0700 (PDT) Received: from cisco.com (shako.cisco.com [64.102.17.78]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24775 for ; Fri, 19 Apr 2002 21:54:08 -0600 (MDT) Received: (from mchandra@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA28534; Fri, 19 Apr 2002 23:54:06 -0400 (EDT) Date: Fri, 19 Apr 2002 23:54:06 -0400 From: "Madhavi W. Chandra" To: Behcet Sarikaya Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Message-ID: <20020419235406.A19700@cisco.com> References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> <3CC09D75.5000609@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC09D75.5000609@alcatel.com>; from behcet.sarikaya@alcatel.com on Fri, Apr 19, 2002 at 05:43:01PM -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Behcet It is certainly not our intention to undermine anyone's research. However, when a draft is to become an RFC, there are implications for implementation. At that point, it is not that simple to say that one need not implement the RFC. Thus, we are simply trying to understand the problem space that the regional tunneling draft is trying to solve. It seems to impose many changes to the existing MIP architecture, not to mention, the mobile node. Since an RFC will move this work from research to deployment, we are trying to understand the technical merits. We do apologize for the late nature of these comments. However, I'm not sure that because our comments are late is reason to dismiss them or the fact that this work has been going on since 1998 is reason to standardize it. Hopefully, we can have a technical discussion to address our comments. I hope that you and Charlie can understand our position. Regards, Madhavi P.S. As I was not following the WG in 1998, I'm not sure that what I was doing then is relevant. However, if you are still interested, do send me an email and I will be glad to elaborate. On Fri, Apr 19, 2002 at 05:43:01PM -0500, Behcet Sarikaya wrote: > Milind and Madhavi, > Isn't it very late to raise the problem statement issue for reg-tunnel > draft? This draft has been around since so long and it in fact is rooted > on Charlie and others' research as early as 1998. Sorry to say, but what > have you been doing then? > reg-tunnel draft for v4 and a similar one for v6 (at the expense of > flaring up some early debates) are part of extensions to the base > mipv4/v6 protocols for domain-based mobility. > Let's go for them. > Regards, > > Milind Kulkarni wrote: > > >I agree with Madhavi's opinion that the problem statement > >is not very clear. There are only two perceived problem > >this draft is trying to solve as per section 9: > > > >9. Regional Registration Message Formats > > > > These messages are used by the mobile node instead of the > > existing Registration Request and Registration Reply, in > > order (1) to make registration work faster, and also > > (2) to reduce network load for Mobile IP registration. > > > >Argument #2 is very weak. While it may be good to localize > >the registrations, it is probably just a small optimization. > >However, all the extra messaging and work that the MN, RFA, > >GFA need to do, doesn't address the root cause. After doing > >all this Regional registration messaging, the problem of > >hand-off remains, although the frequency of that may be > >slightly reduced. > > > >What do others think? > > > >Thanks, > >Milind > > > > > > > >"Madhavi W. Chandra" wrote: > > > >>Hi Charlie, > >> > >>Thanks for the quick response. > >> > >>On Fri, Apr 19, 2002 at 12:39:37PM -0700, Charles E. Perkins wrote: > >> > >>>Hello Madhavi, > >>> > >>>I think the problem statement is clear. A method is needed by which > >>>registrations can be localized. > >>> > >>I agree that minimizing the long haul is needed. However, > >>I'm not clear on why introducing a hierarchy and heavy weight > >>changes to MIP entities is beneficial. It imposes much > >>on a practical implementation. > >> > >>Dynamic 'local' home agent allocation could minimize the long haul > >>without the new messages and much change to MN. > >> > >>I respectfully disagree that the problem statement is clear. > >> > >>Regards, > >>Madhavi > >> > >>>Fast handoff does not solve this problem. Every new attachment to > >>>an access router still would need to deliver a binding update to > >>>a home agent. > >>> > >>>Regards, > >>>Charlie P. > >>> > >>> > >>>"Madhavi W. Chandra" wrote: > >>> > >>>>HI All, > >>>> > >>>>Is there a problem statement associated with this draft? We are not > >>>>clear on what problem this draft is trying to solve. If the idea is to > >>>>enable a fast handoff by reducing signaling all the way to the HA, > >>>>this falls in the domain of the handoff draft for v4. > >>>> > >>>>It seems like a heavy weight idea for implementation, without clear > >>>>need. Please comment. > >>>> > >>>>Thanks, > >>>>Madhavi > >>>> > >>>>On Mon, Apr 08, 2002 at 03:30:37PM -0500, Basavaraj.Patil@nokia.com > wrote: > >>>> > >>>>>Folks, > >>>>> > >>>>>This is a WG last call for: Mobile IP Regional Registration - > >>>>>draft-ietf-mobileip-reg-tunnel-06.txt > >>>>>This draft is a standards track WG document. > >>>>> > >>>>>Please send in your comments by April 22nd, 2002 to the authors or > >>>>>to the WG discussion list. > >>>>> > >>>>>-Basavaraj > >>>>> > --behcet > From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 20 08:01:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01178 for ; Sat, 20 Apr 2002 08:01:21 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11204; Sat, 20 Apr 2002 06:01:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05910; Sat, 20 Apr 2002 05:01:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KBxwIA013885 for ; Sat, 20 Apr 2002 04:59:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3KBxwGr013884 for mobile-ip-dist; Sat, 20 Apr 2002 04:59:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KBxtIA013877 for ; Sat, 20 Apr 2002 04:59:55 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05485 for ; Sat, 20 Apr 2002 04:59:58 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16299 for ; Sat, 20 Apr 2002 05:59:57 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3KBxupG017257; Sat, 20 Apr 2002 04:59:57 -0700 (PDT) Received: from DBLAIRW2K (rtp-vpn2-261.cisco.com [10.82.241.5]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACS07117; Sat, 20 Apr 2002 04:59:55 -0700 (PDT) From: "Dana L. Blair" To: "Behcet Sarikaya" , Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Sat, 20 Apr 2002 07:59:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3CC09D75.5000609@alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Behcet Sarikaya > Sent: Friday, April 19, 2002 6:43 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] WG Last Call: > draft-ietf-mobileip-reg-tunnel-06.txt > > > Milind and Madhavi, > Isn't it very late to raise the problem statement issue for reg-tunnel > draft? This draft has been around since so long and it in fact is rooted Not really. That's what last call is for. > on Charlie and others' research as early as 1998. Sorry to say, but what > have you been doing then? Personal comments like this question don't promote the exchange of ideas. I appreciate the research efforts of any individual because certainly the internet has benefited from research. However, internet drafts are about application. Not all research is implemented. > reg-tunnel draft for v4 and a similar one for v6 (at the expense of > flaring up some early debates) are part of extensions to the base > mipv4/v6 protocols for domain-based mobility. Unnecessary extensions. If you'll define "domain-based mobility" in a new email thread, we might be able to see how the base mobile IP RFCs and the handover draft (with some possible updates) can solve the problem. thanks, Dana > Let's go for them. > Regards, > > Milind Kulkarni wrote: > > >I agree with Madhavi's opinion that the problem statement > >is not very clear. There are only two perceived problem > >this draft is trying to solve as per section 9: > > > >9. Regional Registration Message Formats > > > > These messages are used by the mobile node instead of the > > existing Registration Request and Registration Reply, in > > order (1) to make registration work faster, and also > > (2) to reduce network load for Mobile IP registration. > > > >Argument #2 is very weak. While it may be good to localize > >the registrations, it is probably just a small optimization. > >However, all the extra messaging and work that the MN, RFA, > >GFA need to do, doesn't address the root cause. After doing > >all this Regional registration messaging, the problem of > >hand-off remains, although the frequency of that may be > >slightly reduced. > > > >What do others think? > > > >Thanks, > >Milind > > > > > > > >"Madhavi W. Chandra" wrote: > > > >>Hi Charlie, > >> > >>Thanks for the quick response. > >> > >>On Fri, Apr 19, 2002 at 12:39:37PM -0700, Charles E. Perkins wrote: > >> > >>>Hello Madhavi, > >>> > >>>I think the problem statement is clear. A method is needed by which > >>>registrations can be localized. > >>> > >>I agree that minimizing the long haul is needed. However, > >>I'm not clear on why introducing a hierarchy and heavy weight > >>changes to MIP entities is beneficial. It imposes much > >>on a practical implementation. > >> > >>Dynamic 'local' home agent allocation could minimize the long haul > >>without the new messages and much change to MN. > >> > >>I respectfully disagree that the problem statement is clear. > >> > >>Regards, > >>Madhavi > >> > >>>Fast handoff does not solve this problem. Every new attachment to > >>>an access router still would need to deliver a binding update to > >>>a home agent. > >>> > >>>Regards, > >>>Charlie P. > >>> > >>> > >>>"Madhavi W. Chandra" wrote: > >>> > >>>>HI All, > >>>> > >>>>Is there a problem statement associated with this draft? We are not > >>>>clear on what problem this draft is trying to solve. If the > idea is to > >>>>enable a fast handoff by reducing signaling all the way to the HA, > >>>>this falls in the domain of the handoff draft for v4. > >>>> > >>>>It seems like a heavy weight idea for implementation, without clear > >>>>need. Please comment. > >>>> > >>>>Thanks, > >>>>Madhavi > >>>> > >>>>On Mon, Apr 08, 2002 at 03:30:37PM -0500, Basavaraj.Patil@nokia.com > wrote: > >>>> > >>>>>Folks, > >>>>> > >>>>>This is a WG last call for: Mobile IP Regional Registration - > >>>>>draft-ietf-mobileip-reg-tunnel-06.txt > >>>>>This draft is a standards track WG document. > >>>>> > >>>>>Please send in your comments by April 22nd, 2002 to the authors or > >>>>>to the WG discussion list. > >>>>> > >>>>>-Basavaraj > >>>>> > --behcet > > From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 20 08:01:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01183 for ; Sat, 20 Apr 2002 08:01:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11231; Sat, 20 Apr 2002 06:01:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05954; Sat, 20 Apr 2002 05:01:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KBxsIA013875 for ; Sat, 20 Apr 2002 04:59:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3KBxsvD013874 for mobile-ip-dist; Sat, 20 Apr 2002 04:59:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KBxpIA013867 for ; Sat, 20 Apr 2002 04:59:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05473 for ; Sat, 20 Apr 2002 04:59:54 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16602 for ; Sat, 20 Apr 2002 04:59:54 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3KBxrpG017241 for ; Sat, 20 Apr 2002 04:59:54 -0700 (PDT) Received: from DBLAIRW2K (rtp-vpn2-261.cisco.com [10.82.241.5]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACS07114; Sat, 20 Apr 2002 04:59:52 -0700 (PDT) From: "Dana L. Blair" To: Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Sat, 20 Apr 2002 07:59:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I am trying to understand the problem this draft is addressing. The Abstract: Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a new kind of "regional" registration, i.e., registration local to the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. From the abstract, seems like it is trying to limit the impact of home agent round trip when the care-of address changes. From the introduction: By registering locally, the signaling delay is reduced, and this may improve the performance of handover. The only circumstances mentioned where the care-of address will change and "MAY" produce the undesired "long" home agent round trip is handover. I don't think we need an RFC that "MAY" fix a problem this is already being addressed by another working group draft, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt. Looks to me like the purpose of this draft is to point out a problem that occurs during handover. So, if the handover draft is not addressing the problem, then the handover draft needs a little more work. This draft shouldn't move to the next phase because it's not solving a un-addressed problem. The handover draft should be updated (if it not already) to solve the problem. thanks, Dana BTW, this draft is not listed in the Last Call section of the status page, http://www.ietf.org/IESG/status.html. If we are going to have a status page it should be up to date. > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of > Basavaraj.Patil@nokia.com > Sent: Monday, April 08, 2002 4:31 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt > > > Folks, > > This is a WG last call for: Mobile IP Regional Registration - > draft-ietf-mobileip-reg-tunnel-06.txt > This draft is a standards track WG document. > > Please send in your comments by April 22nd, 2002 to the authors or > to the WG discussion list. > > -Basavaraj > From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 20 08:01:31 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01223 for ; Sat, 20 Apr 2002 08:01:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16600; Sat, 20 Apr 2002 06:01:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06053; Sat, 20 Apr 2002 05:01:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KC0AIA013902 for ; Sat, 20 Apr 2002 05:00:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3KC0AGj013901 for mobile-ip-dist; Sat, 20 Apr 2002 05:00:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KC04IA013887 for ; Sat, 20 Apr 2002 05:00:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18780 for ; Sat, 20 Apr 2002 05:00:07 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14406 for ; Sat, 20 Apr 2002 06:00:06 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3KBxspG017244; Sat, 20 Apr 2002 04:59:54 -0700 (PDT) Received: from DBLAIRW2K (rtp-vpn2-261.cisco.com [10.82.241.5]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACS07115; Sat, 20 Apr 2002 04:59:53 -0700 (PDT) From: "Dana L. Blair" To: "Charles E. Perkins" , "Madhavi W. Chandra" Cc: Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Sat, 20 Apr 2002 07:59:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3CC07279.CFA48B8@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Charles E. > Perkins > Sent: Friday, April 19, 2002 3:40 PM > To: Madhavi W. Chandra > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] WG Last Call: > draft-ietf-mobileip-reg-tunnel-06.txt > > > Hello Madhavi, > > I think the problem statement is clear. A method is needed by which > registrations can be localized. Under what circumstances is this method needed ? The only circumstance mentioned in the draft is handoff "MAY" need this in the introduction. > > Fast handoff does not solve this problem. Every new attachment to > an access router still would need to deliver a binding update to > a home agent. Then the fast handoff draft needs more work. The reg-tunnel draft should not move to the next phase. thanks, Dana > > Regards, > Charlie P. > > > "Madhavi W. Chandra" wrote: > > > > HI All, > > > > Is there a problem statement associated with this draft? We are not > > clear on what problem this draft is trying to solve. If the idea is to > > enable a fast handoff by reducing signaling all the way to the HA, > > this falls in the domain of the handoff draft for v4. > > > > It seems like a heavy weight idea for implementation, without clear > > need. Please comment. > > > > Thanks, > > Madhavi > > > > On Mon, Apr 08, 2002 at 03:30:37PM -0500, > Basavaraj.Patil@nokia.com wrote: > > > Folks, > > > > > > This is a WG last call for: Mobile IP Regional Registration - > > > draft-ietf-mobileip-reg-tunnel-06.txt > > > This draft is a standards track WG document. > > > > > > Please send in your comments by April 22nd, 2002 to the authors or > > > to the WG discussion list. > > > > > > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 20 08:01:57 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01234 for ; Sat, 20 Apr 2002 08:01:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17045; Sat, 20 Apr 2002 05:01:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06090; Sat, 20 Apr 2002 05:01:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KC0CIA013905 for ; Sat, 20 Apr 2002 05:00:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3KC0BIK013904 for mobile-ip-dist; Sat, 20 Apr 2002 05:00:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KC05IA013894 for ; Sat, 20 Apr 2002 05:00:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05614 for ; Sat, 20 Apr 2002 05:00:08 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16355 for ; Sat, 20 Apr 2002 06:00:08 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3KBxb2q021208; Sat, 20 Apr 2002 04:59:38 -0700 (PDT) Received: from DBLAIRW2K (rtp-vpn2-261.cisco.com [10.82.241.5]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACS07116; Sat, 20 Apr 2002 04:59:54 -0700 (PDT) From: "Dana L. Blair" To: "Charles E. Perkins" , "Milind Kulkarni" Cc: "Madhavi W. Chandra" , Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Sat, 20 Apr 2002 07:59:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3CC098CA.CA6E1E9C@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Charles E. > Perkins > Sent: Friday, April 19, 2002 6:23 PM > To: Milind Kulkarni > Cc: Madhavi W. Chandra; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] WG Last Call: > draft-ietf-mobileip-reg-tunnel-06.txt > > > Milind Kulkarni wrote: > > > 9. Regional Registration Message Formats > > > > These messages are used by the mobile node instead of the > > existing Registration Request and Registration Reply, in > > order (1) to make registration work faster, and also > > (2) to reduce network load for Mobile IP registration. Charles, Under what circmstances does registration not work fast enough ? Under what circumstances does the network load for Mobile IP registration need to be reduced ? This draft implies that Mobile IP is not scalable without additional infrastructure elements. I completely disagree with this implication. > > > > Argument #2 is very weak. While it may be good to localize > > the registrations, it is probably just a small optimization. > > However, all the extra messaging and work that the MN, RFA, > > GFA need to do, doesn't address the root cause. After doing > > all this Regional registration messaging, the problem of > > hand-off remains, although the frequency of that may be > > slightly reduced. > > > > What do others think? > > I guess I'm not "others", but anyway I have an opinion about it. > > First, regional registration is not mandatory. If your > product is not intended to be sold into a market that needs > it, you do not have to implement. If the draft is solving a unique problem, then it may be useful. However, if implementing the draft is optional, and there is no circumstance where the option is needed, then we don't need an RFC for the option. > > Second, there are many distinct techniques that each produce > some performance improvement. You do not have to implement > all of them or any of them, but I don't believe that means > that the opportunity should be removed for those people who > may need the additional performance improvement. The case for performance improvement in a specific circumstance has not been made in this draft. > > Third, it's done. It's not like we have to make a huge > investment to produce the technology. We already have it. > There's no reason to prohibit people who want it from using it. By creating a draft that doesn't address any real world circumstance, it looks like there is a problem with mobile IP when there is none. This creates alot of confusion when it comes down to what protocols and functions should be implemented. > > Fourth, regional registration does not reduce the frequency > of handover. It only localizes the resulting signaling. Looks like you are saying handover won't work without regional registration. I disagree with this. If there is an issue not addressed by the handover draft(s), it should be fixed there. No need for another RFC. thanks, Dana > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 20 14:08:12 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05451 for ; Sat, 20 Apr 2002 14:08:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10489; Sat, 20 Apr 2002 12:08:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05404; Sat, 20 Apr 2002 11:07:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KI7DGs000359 for ; Sat, 20 Apr 2002 11:07:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3KI7DxM000356 for mobile-ip-dist; Sat, 20 Apr 2002 11:07:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KI77Gu000341 for ; Sat, 20 Apr 2002 11:07:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11685 for ; Sat, 20 Apr 2002 08:17:36 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03356 for ; Sat, 20 Apr 2002 09:17:35 -0600 (MDT) Received: from T23KEMPF (dhcp169.docomolabs-usa.com [172.21.96.169]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3KFHCI18095; Sat, 20 Apr 2002 08:17:12 -0700 (PDT) Message-ID: <000401c1e87e$3a586740$a96015ac@T23KEMPF> From: "James Kempf" To: "Milind Kulkarni" , "Madhavi W. Chandra" Cc: "Charles E. Perkins" , References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Sat, 20 Apr 2002 05:42:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think there is still a problem with HA registration latency regardless of whether you optimize handoff. The handoff signaling optimizes out the movement detection algorithm, RegReg optimizes HA registration latency. So there are two different problems. That said, RegReg is one solution to optimizing HA registration, there are other solutions that leverage fast handoff somewhat better and therefore would require less mechanism. The RegReg solution was concieved and developed prior to the fast handoff algorithms, so it is not suprising that it did not consider this possibility. There has been some (limited) implementation experience with RegReg, much less with fast handoff, and none with leveraging fast handoff for localized HA signaling, so I don't see a problem with the RegReg draft as it stands, with perhaps the exception that Alan O'Neill's comments about fixing how the CoA and GFA addresses are distributed should probably be taken into consideration. Would be interesting to compare a RegReg implementation for localized registration to an implementation that leveraged fast handoff. jak ----- Original Message ----- From: "Milind Kulkarni" To: "Madhavi W. Chandra" Cc: "Charles E. Perkins" ; Sent: Friday, April 19, 2002 3:14 PM Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt > I agree with Madhavi's opinion that the problem statement > is not very clear. There are only two perceived problem > this draft is trying to solve as per section 9: > > 9. Regional Registration Message Formats > > These messages are used by the mobile node instead of the > existing Registration Request and Registration Reply, in > order (1) to make registration work faster, and also > (2) to reduce network load for Mobile IP registration. > > Argument #2 is very weak. While it may be good to localize > the registrations, it is probably just a small optimization. > However, all the extra messaging and work that the MN, RFA, > GFA need to do, doesn't address the root cause. After doing > all this Regional registration messaging, the problem of > hand-off remains, although the frequency of that may be > slightly reduced. > > What do others think? > > Thanks, > Milind > > > > "Madhavi W. Chandra" wrote: > > > > Hi Charlie, > > > > Thanks for the quick response. > > > > On Fri, Apr 19, 2002 at 12:39:37PM -0700, Charles E. Perkins wrote: > > > > > > Hello Madhavi, > > > > > > I think the problem statement is clear. A method is needed by which > > > registrations can be localized. > > > > I agree that minimizing the long haul is needed. However, > > I'm not clear on why introducing a hierarchy and heavy weight > > changes to MIP entities is beneficial. It imposes much > > on a practical implementation. > > > > Dynamic 'local' home agent allocation could minimize the long haul > > without the new messages and much change to MN. > > > > I respectfully disagree that the problem statement is clear. > > > > Regards, > > Madhavi > > > > > > > > Fast handoff does not solve this problem. Every new attachment to > > > an access router still would need to deliver a binding update to > > > a home agent. > > > > > > Regards, > > > Charlie P. > > > > > > > > > "Madhavi W. Chandra" wrote: > > > > > > > > HI All, > > > > > > > > Is there a problem statement associated with this draft? We are not > > > > clear on what problem this draft is trying to solve. If the idea is to > > > > enable a fast handoff by reducing signaling all the way to the HA, > > > > this falls in the domain of the handoff draft for v4. > > > > > > > > It seems like a heavy weight idea for implementation, without clear > > > > need. Please comment. > > > > > > > > Thanks, > > > > Madhavi > > > > > > > > On Mon, Apr 08, 2002 at 03:30:37PM -0500, Basavaraj.Patil@nokia.com wrote: > > > > > Folks, > > > > > > > > > > This is a WG last call for: Mobile IP Regional Registration - > > > > > draft-ietf-mobileip-reg-tunnel-06.txt > > > > > This draft is a standards track WG document. > > > > > > > > > > Please send in your comments by April 22nd, 2002 to the authors or > > > > > to the WG discussion list. > > > > > > > > > > -Basavaraj > From owner-mobile-ip@sunroof.eng.sun.com Sat Apr 20 14:13:35 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05531 for ; Sat, 20 Apr 2002 14:13:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08737; Sat, 20 Apr 2002 12:13:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06528; Sat, 20 Apr 2002 11:13:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KICkGs000437 for ; Sat, 20 Apr 2002 11:12:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3KICk0I000436 for mobile-ip-dist; Sat, 20 Apr 2002 11:12:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KIChGs000429 for ; Sat, 20 Apr 2002 11:12:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06418 for ; Sat, 20 Apr 2002 11:12:45 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18910 for ; Sat, 20 Apr 2002 11:12:45 -0700 (PDT) Received: from T23KEMPF (dhcp57.docomolabs-usa.com [172.21.96.57]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3KICRI21678; Sat, 20 Apr 2002 11:12:29 -0700 (PDT) Message-ID: <00a301c1e896$b6ab42a0$a96015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Manolis Sifalakis" , References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 Date: Sat, 20 Apr 2002 10:20:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, The FBU is always needed. The Link Down is just an optimization to avoid starting the tunnel before the MN has actually moved. Hope that clarifies. jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Manolis Sifalakis" ; Sent: Friday, April 19, 2002 5:20 PM Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 > James Kempf wrote: > > > Rajeev, > > > > > ^^^^ > > > The AR must start tunneling immediately after processing the FBU. In > > fact, > > > the control (to turn on tunneling) must reside at the MN. > > > > > > > > > > > immediately, in which case the mobile node will miss those packets > > sent > > > > before it moves, or it can bicast packets down the old link and the > > > > tunnel. > > > > > > > > > > clarification: bicasting is not proposed in the spec (after a long > > > discussion > > > culminating in a vote at London IETF). > > > > > > > If it does this, the mobile loses packets between when the FBU is > > received > > by the AR and when it finally arrives on the other link (remember: > > neither > > bicasting nor buffering are in this draft). > > Right, how to handle potential packet loss is another issue. > > > > > > > If the router gets a Link Down, this can be used to reduce the packet > > loss > > to just the L2 handover blackout period. Of course, if this trigger is > > not available, then the FBU must be used. > > > > Or was there some other reason why you feel the FBU must be the > > tunnel setup trigger? > > > > My concern is redirecting traffic without explicit consent from the > MN. Is "Link Down" enough authorization to start forwarding > traffic on the tunnel ? I am not sure.. The base protocol itself has to > operate with FBU, which authorizes the AR to refirect traffic. > > Regards, > > -Rajeev > > > > > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 21 05:28:14 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22834 for ; Sun, 21 Apr 2002 05:28:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26325; Sun, 21 Apr 2002 02:27:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09162; Sun, 21 Apr 2002 02:27:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3L9QgGs001339 for ; Sun, 21 Apr 2002 02:26:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3L9Qgw4001338 for mobile-ip-dist; Sun, 21 Apr 2002 02:26:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3L9QdGs001331 for ; Sun, 21 Apr 2002 02:26:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21107 for ; Sun, 21 Apr 2002 02:26:40 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23177; Sun, 21 Apr 2002 03:26:40 -0600 (MDT) Received: from T23KEMPF (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3L9QFI10419; Sun, 21 Apr 2002 02:26:16 -0700 (PDT) Message-ID: <000001c1e916$5dbbddf0$446015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Michael Thomas" Cc: "Erik Nordmark" , References: <00cf01c1e642$2c476130$a96015ac@T23KEMPF> <3CBF4103.E5FD81E@iprg.nokia.com> <15552.9754.947421.690767@thomasm-u1.cisco.com> <3CC0B870.B007C2AF@iprg.nokia.com> Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Sat, 20 Apr 2002 10:23:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, In general, I think we want to reduce or eliminate multicasting of unsolicited RAs on wireless links when possible. This even holds for wireless links with large aggregate bandwidth, like WLAN. I have recently seen some simulation results (currently unpublished) in NS2 which show that in heavily loaded WLAN cells, the RAs tend to get delayed or dropped due to link contention, resulting in long delays in handover time. jak ----- Original Message ----- From: "Rajeev Koodli" To: "Michael Thomas" Cc: "James Kempf" ; "Erik Nordmark" ; Sent: Friday, April 19, 2002 5:38 PM Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > > Hello Mike, > > Michael Thomas wrote: > > > Rajeev Koodli writes: > > > Hello Jim, > > > > > > I see your need, but I am a little concerned about the increase in > > > RAs and the associated overhead.. There is also the potential for abuse > > > as you mention. Shouldn't a MN interested in faster > > > address acquisition use something like FMIPv6 ? > > > > Rajeev, > > > > This assumes that the AR supports and offers > > FMIPv6. I don't see that as the case always, > > especially with open kiosk kinds of situations. > > IMO, it should be possible for a mobile node > > reasonably close to its home agent to dispense > > with all of the heavy machinery (and dependencies) > > and achieve reasonable results. The couple of > > seconds of delay here (as well as DAD) doesn't > > strike me as striking a very good balance. > > > > > > If the address acquisition is due to roaming, then > the delay is tolerable. If it is due to handover, I > agree that FMIPv6 may not be available > everywhere. But, I am still concerned about the > increase in RA overhead. > > A tweak that might dampen the load is to consider > multicasting solicited RA to all-nodes so that > the solicitations are reduced. Each node should > wait for a short time (say few tens of milliseconds) > before sending an RS. > This may have been discussed in IPv6 with a No :-) > > -Rajeev > > > > Mike > > From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 21 06:03:37 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23140 for ; Sun, 21 Apr 2002 06:03:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11199; Sun, 21 Apr 2002 04:01:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17040; Sun, 21 Apr 2002 03:01:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3LA0kGs001431 for ; Sun, 21 Apr 2002 03:00:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3LA0ket001430 for mobile-ip-dist; Sun, 21 Apr 2002 03:00:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3LA0hGs001423 for ; Sun, 21 Apr 2002 03:00:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16937 for ; Sun, 21 Apr 2002 03:00:42 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27979 for ; Sun, 21 Apr 2002 04:00:42 -0600 (MDT) Received: from T23KEMPF (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3LA0JI11197; Sun, 21 Apr 2002 03:00:19 -0700 (PDT) Message-ID: <007201c1e91b$200127e0$446015ac@T23KEMPF> From: "James Kempf" To: "James Kempf" , "Milind Kulkarni" , "Madhavi W. Chandra" Cc: "Charles E. Perkins" , References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> <000401c1e87e$3a586740$a96015ac@T23KEMPF> Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Sun, 21 Apr 2002 02:58:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit So it sounds like there is some amount of opposition to this draft going to draft standard, and there is also the possibility of an alternative and maybe simpler solution leveraging fast handoff, though the details of such a solution need to be fleshed out. Would there be any objection to moving this to experimental, such as was done with the MIPv4 fast handoff draft itself, until these issues are resolved? jak From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 21 18:53:46 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02544 for ; Sun, 21 Apr 2002 18:53:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10623; Sun, 21 Apr 2002 15:52:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28391; Sun, 21 Apr 2002 15:51:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3LMp2Gs002065 for ; Sun, 21 Apr 2002 15:51:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3LMp2J4002064 for mobile-ip-dist; Sun, 21 Apr 2002 15:51:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3LMoxGs002057 for ; Sun, 21 Apr 2002 15:50:59 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22737 for ; Sun, 21 Apr 2002 15:50:55 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19796 for ; Sun, 21 Apr 2002 16:50:54 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KGUWSPYC7G8WW2UW@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Mon, 22 Apr 2002 08:50:37 +1000 Received: from thwack (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 702FB12C006; Sun, 21 Apr 2002 22:50:36 +0000 (/etc/localtime) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189]) by thwack.its.monash.edu.au (Postfix) with ESMTP id E6BFA12C007; Mon, 22 Apr 2002 08:50:34 +1000 (EST) Date: Mon, 22 Apr 2002 08:50:34 +1000 From: Greg Daley Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality To: Francis Dupont Cc: Erik Nordmark , James Kempf , mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3CC3423A.AC4B2F20@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200204191310.g3JDAKT36329@givry.rennes.enst-bretagne.fr> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Francis, > => I disagree with the reasonning because it uses the assumption there is > only one router: if RAs are immediately sent (unicasted or multicasted, > this doesn't matter) at the reception of a multicasted RS, then they will > collide. So I agree the bit approach is not good, but the right approach > (to unicast the RS) has some difficulties... > (PS: I can't see a better alternative to trigger though the link layer a RA) It would be straightforward to ensure that only one router on any link is using the 'Fast Response' bit. This would guarantee that the fastest reply available is achieved, with appropriate backup capability (i.e. current rfc2461, in the case where failure occurs). Greg Daley From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 21 20:14:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03228 for ; Sun, 21 Apr 2002 20:14:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03894; Sun, 21 Apr 2002 18:13:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04854; Sun, 21 Apr 2002 17:13:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M0CbGs002244 for ; Sun, 21 Apr 2002 17:12:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3M0Ca73002243 for mobile-ip-dist; Sun, 21 Apr 2002 17:12:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M0CXGs002236 for ; Sun, 21 Apr 2002 17:12:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06801 for ; Sun, 21 Apr 2002 17:12:36 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15681 for ; Sun, 21 Apr 2002 17:12:35 -0700 (PDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 21 Apr 2002 17:11:32 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Apr 2002 17:12:35 -0700 Received: from red-msg-09.redmond.corp.microsoft.com ([157.54.12.7]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 21 Apr 2002 17:11:32 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] Unresolved issue #3: BA, BR authentication? Date: Sun, 21 Apr 2002 17:11:31 -0700 Message-ID: Thread-Topic: [mobile-ip] Unresolved issue #3: BA, BR authentication? thread-index: AcHlusTbuKU48S0kTFaFTLwGl/MVzQD14Fsg From: "Tuomas Aura" To: X-OriginalArrivalTime: 22 Apr 2002 00:11:32.0157 (UTC) FILETIME=[41CD86D0:01C1E992] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3M0CYGs002237 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I agree. Cookies seems sufficient for this purpose. Tuomas > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: 17 April 2002 03:51 > To: Tuomas Aura > Cc: mobile-ip@sunroof.eng.sun.com; jari.arkko@piuha.net > Subject: RE: [mobile-ip] Unresolved issue #3: BA, BR authentication? > > > I do not like the BA/BR authentication. First, do they need > > to be authenticated? Second, the protocol is difficult to > > understand and analyze. > > I think it makes sense to prevent off-path attackers from being able > to confuse the MN by sending CoT/HoT/BA/BR packets. > That should just require a cookie (akin to the sequence number in TCP > SYN packets preventing spoofed SYN|ACK packets). > > Erik From owner-mobile-ip@sunroof.eng.sun.com Sun Apr 21 23:41:11 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07398 for ; Sun, 21 Apr 2002 23:41:10 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04696; Sun, 21 Apr 2002 20:40:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26410; Sun, 21 Apr 2002 20:40:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M3dZGs002600 for ; Sun, 21 Apr 2002 20:39:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3M3dYPP002599 for mobile-ip-dist; Sun, 21 Apr 2002 20:39:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M3dVGs002592 for ; Sun, 21 Apr 2002 20:39:31 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26318 for ; Sun, 21 Apr 2002 20:39:33 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04451 for ; Sun, 21 Apr 2002 20:39:33 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3M3ZW425157; Sun, 21 Apr 2002 22:35:32 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TX6PK>; Sun, 21 Apr 2002 22:35:40 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC0C@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Charlie Perkins'" Cc: mobile-ip@sunroof.eng.sun.com, Behcet Sarikaya , "'Madhavi W. Chandra'" Subject: [mobile-ip] RE: [mobile-imp] WG Last Call: draft-ietf-mobileip-reg-tunnel-06. txt Date: Sun, 21 Apr 2002 22:35:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E9AE.C4A2F600" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E9AE.C4A2F600 Content-Type: text/plain; charset="iso-8859-1" Well, me too. I am not sure what I was doing in 1998. I believe the scope of this discussion is really absolutely too late. However, I would like to continue to raise technical issues about this draft which mostly related to backward compatibility. In section 4.4: Home Agent Considerations: Issue No. 1: " A Registration Request that does not contain a GFA IP Address extension or a Replay Protection Style extension is processed by the home agent as described in [9]. If the home agent receives a Registration Request with one of these extensions, and the home agent does not support the extension, the home agent must return a Registration Reply with the Code value set to UNSUPPORTED_EXTENSION [9]. " This section mandates that a legacy HA rejects any Registration Request which contains a GFA IP Address extension or a Replay Protection Style extension with an error code of UNSUPPORTED_EXTENSION. Where is the backward compatibility here. Also, it references RFC3220 while RFC3220 does not have an error code of UNSUPPORTED_EXTENSION.!!! Issue No. 2: " If a home agent receives a Registration Request message with the care-of address set to zero, and a GFA IP Address extension, it MUST register the IP address of the GFA as the care-of address of the mobile node in its mobility binding list. " This section also mandates that a legacy HA to accept a Registration Request with Care-of Address set to zero and a GFA IP Address extension and to include the GFA IP address as the care-of address in the binding table. Is this backward compatible solution!!!!! Issue No. 3: " If a home agent receives a Registration Request message with the care-of address set to zero, but no GFA IP Address extension, it MUST deny the request by sending a Registration Reply message with the Code field set to ZERO_CAREOF_ADDRESS (see section 8.4). " This section also mandates that a legacy HA rejects a Registration Request which contains a care-of address field of zero by sending a Registration Reply message with error code of ZERO_CAREOF_ADDRESS. Again, where is the backward compatibility here or we are asking all carriers to update their HAs in order to be standard compliant by not supporting this feature!!! I hope that there is someone out there who have an answer for these issues. Regards; Ahmad Muhanna ------_=_NextPart_001_01C1E9AE.C4A2F600 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-imp] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt

Well, me too. I am not sure what I was doing in 1998.

I believe the scope of this discussion is really absolutely too late.
However, I would like to continue to raise technical issues about
this draft which mostly related to backward compatibility.

In section 4.4: Home Agent Considerations:

Issue No. 1:
"
   A Registration Request that does not contain a GFA IP Address
   extension or a Replay Protection Style extension is processed
   by the home agent as described in [9].  If the home agent
   receives a Registration Request with one of these extensions,
   and the home agent does not support the extension, the home
   agent must return a Registration Reply with the Code value set to
   UNSUPPORTED_EXTENSION [9]. 
"

This section mandates that a legacy HA rejects any Registration Request which
contains a GFA IP Address extension or a Replay Protection Style extension with
an error code of UNSUPPORTED_EXTENSION. Where is the backward compatibility
here. Also, it references RFC3220 while RFC3220 does not have an error code of
UNSUPPORTED_EXTENSION.!!!

Issue No. 2:
"
   If a home agent receives a Registration
   Request message with the care-of address set to zero, and a GFA
   IP Address extension, it MUST register the IP address of the GFA
   as the care-of address of the mobile node in its mobility binding
   list.
"

This section also mandates that a legacy HA to accept a Registration Request
with Care-of Address set to zero and a GFA IP Address extension and to include
the GFA IP address as the care-of address in the binding table.
Is this backward compatible solution!!!!!


Issue No. 3:
"
If a home agent
   receives a Registration Request message with the care-of address set
   to zero, but no GFA IP Address extension, it MUST deny the request
   by sending a Registration Reply message with the Code field set to
   ZERO_CAREOF_ADDRESS (see section 8.4).
"

This section also mandates that a legacy HA rejects a Registration Request
which contains a care-of address field of zero by sending a Registration Reply
message with error code of ZERO_CAREOF_ADDRESS.
Again, where is the backward compatibility here or we are asking all carriers
to update their HAs in order to be standard compliant by not supporting this
feature!!!

I hope that there is someone out there who have an answer for these issues.

Regards;
Ahmad Muhanna


 

------_=_NextPart_001_01C1E9AE.C4A2F600-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 01:05:25 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08378 for ; Mon, 22 Apr 2002 01:05:24 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06259; Sun, 21 Apr 2002 23:04:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA09105; Sun, 21 Apr 2002 22:04:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M53PGs002754 for ; Sun, 21 Apr 2002 22:03:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3M53PhB002753 for mobile-ip-dist; Sun, 21 Apr 2002 22:03:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M53MGs002746 for ; Sun, 21 Apr 2002 22:03:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA08811 for ; Sun, 21 Apr 2002 22:03:22 -0700 (PDT) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA17851 for ; Sun, 21 Apr 2002 23:03:21 -0600 (MDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KGV9SN59WY8Y525R@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Mon, 22 Apr 2002 15:03:10 +1000 Received: from blammo (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 2CB6412C016; Mon, 22 Apr 2002 05:03:07 +0000 (/etc/localtime) Received: from eng.monash.edu.au (brettpc.eng.monash.edu.au [130.194.252.100]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 9F1AF12C008; Mon, 22 Apr 2002 15:01:59 +1000 (EST) Date: Mon, 22 Apr 2002 16:01:59 +1100 From: Brett Pentland Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality X-Sender: "Brett Pentland" To: Francis Dupont Cc: James Kempf , mobile-ip@sunroof.eng.sun.com Message-id: <3CC39947.D76F7F0@eng.monash.edu.au> Organization: CTIE - Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en]C-CCK-MCD monwin/024 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200204191300.g3JD0iT36286@givry.rennes.enst-bretagne.fr> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Thanks for your response; I hadn't really pursued that line of thought. In any case, the method you describe requires significant infrastructure to work. I think that in cases where that infrastructure is not in place, if a mobile node is aware that a layer two handover has occured then it is desirable that it be able to perform a handover at layer three quickly. Regards, Brett. Francis Dupont wrote: > > In your previous mail you wrote: > > If a flag in the RS is the correct approach > > => I believe there is a better approach even for fast RS/RA (which is > not a good idea in the general case IMHO). > > In another email, Francis mentioned a technique of triggering an RA > when an interface comes up. > > => your message suggested the MN sends a RS because the layer 2 detects > the arrival on a new link. My observation is that another entity can get > the same information and use it to trigger a RA. > > Francis, perhaps you could > elaborate on how a mobile node's interface coming up on a network could be > made to trigger an RA from the router on that network without sending an RS > (or a very similar packet). > > => If another entity on the link detects the arrival of the new MN, it can > give the info to a router which can send a RA. The conditions are: > - detection by another entity (works well for PPP, IEEE 802.11 in > infrastructure mode, any layer 2 with some kind of association for > network access control, etc) > - some communication betwee the entity and a router (obvious if the entity > is a router) > - an arrival frequency low enough (delay between two arrivals far greater > than MAX_RA_DELAY_TIME) > > Thanks > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 01:25:56 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08560 for ; Mon, 22 Apr 2002 01:25:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11416; Sun, 21 Apr 2002 23:24:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA13780; Sun, 21 Apr 2002 22:24:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M5NrGs002872 for ; Sun, 21 Apr 2002 22:23:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3M5NrN9002871 for mobile-ip-dist; Sun, 21 Apr 2002 22:23:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M5NoGs002864 for ; Sun, 21 Apr 2002 22:23:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA29087 for ; Sun, 21 Apr 2002 22:23:51 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11125 for ; Sun, 21 Apr 2002 23:23:50 -0600 (MDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3M5QWH03162 for ; Mon, 22 Apr 2002 00:26:32 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 00:23:49 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 00:23:12 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Mon, 22 Apr 2002 00:23:11 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12CD6@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Thread-Index: AcHpG4pZQhilm8jKTeq+tUP5i6pp9gAoW7Fg To: , , Cc: , X-OriginalArrivalTime: 22 Apr 2002 05:23:12.0538 (UTC) FILETIME=[CC1937A0:01C1E9BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3M5NoGs002865 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit James, Obviously the authors of the draft need to address the concerns that have been raised by WG members. Lets not jump the gun and simply go forward with making this I-D an experimental RFC. I do not believe that will be of any real value. Lets continue this discussion some more and give the authors a chance to clarify the problem statement as well as other details. And if we see that there is no WG consensus after that, we can drop the I-D (or make it experimental if the WG wants to do so). -Basavaraj > > So it sounds like there is some amount of opposition to this > draft going > to draft standard, and there is also the possibility of an alternative > and maybe simpler solution leveraging fast handoff, though the details > of such a solution need to be fleshed out. > > Would there be any objection to moving this to experimental, > such as was > done with the MIPv4 fast handoff draft itself, until these issues are > resolved? > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 02:19:20 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17689 for ; Mon, 22 Apr 2002 02:19:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25314; Mon, 22 Apr 2002 00:18:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10171; Sun, 21 Apr 2002 23:18:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M6HOGs003025 for ; Sun, 21 Apr 2002 23:17:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3M6HOgE003024 for mobile-ip-dist; Sun, 21 Apr 2002 23:17:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M6HKGs003017 for ; Sun, 21 Apr 2002 23:17:20 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10047 for ; Sun, 21 Apr 2002 23:17:22 -0700 (PDT) Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25092 for ; Mon, 22 Apr 2002 00:17:21 -0600 (MDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3M6KOgL015489; Mon, 22 Apr 2002 08:20:25 +0200 From: "Fredrik Johansson" To: "Ahmad Muhanna" , Cc: , Subject: RE: [mobile-ip] A Question about:draft-ietf-mobileip-aaa-nai-00.txt Date: Mon, 22 Apr 2002 08:17:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC01@zrc2c013.us.nortel.com> Importance: Normal X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Ahmad, sounds reasonable /Fredrik >-----Original Message----- >From: Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] >Sent: den 19 april 2002 18:16 >To: mobile-ip@sunroof.eng.sun.com >Cc: 'fredrik@ipunplugged.com'; 'tony.johansson@ericsson.com' >Subject: RE: [mobile-ip] A Question about:draft-ietf-mobileip-aaa-nai-00.txt > > >Hello Again; >One more thing please: >In section 5. It reads: >" > If the AAAH identity is present, the foreign agent MUST direct an > authentication request to this home AAA server when authenticating > the mobile node through the AAA infrastructure by means described in > [2] >" >I am not sure if the foreign agent has any control over this!! >What about the following text? >" > If the AAAH identity is present, the foreign agent MUST include > this identity when requesting the Mobile Node authentication > through the AAA infrastructure as described in [2]. >" >Regards; >Ahmad Muhanna From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 06:31:41 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20795 for ; Mon, 22 Apr 2002 06:31:40 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22295; Mon, 22 Apr 2002 03:31:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08401; Mon, 22 Apr 2002 03:31:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MALsH8003475 for ; Mon, 22 Apr 2002 03:30:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3M8NeLI003399 for mobile-ip-dist; Mon, 22 Apr 2002 01:23:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M8NaGs003392 for ; Mon, 22 Apr 2002 01:23:36 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17644 for ; Mon, 22 Apr 2002 01:06:01 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00915 for ; Mon, 22 Apr 2002 02:06:00 -0600 (MDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KGVG6RJQ6K921U5Z@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Mon, 22 Apr 2002 18:05:35 +1000 Received: from splat (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 128CB130003; Mon, 22 Apr 2002 08:05:34 +0000 (/etc/localtime) Received: from eng.monash.edu.au (brettpc.eng.monash.edu.au [130.194.252.100]) by splat.its.monash.edu.au (Postfix) with ESMTP id 299E7130003; Mon, 22 Apr 2002 18:05:33 +1000 (EST) Date: Mon, 22 Apr 2002 19:05:33 +1100 From: Brett Pentland Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality X-Sender: "Brett Pentland" To: Francis Dupont Cc: Erik Nordmark , James Kempf , mobile-ip@sunroof.eng.sun.com Message-id: <3CC3C44D.176E8512@eng.monash.edu.au> Organization: CTIE - Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en]C-CCK-MCD monwin/024 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200204191310.g3JDAKT36329@givry.rennes.enst-bretagne.fr> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Francis Dupont wrote: > > > Ideally, we could insert some text into the MIPv6 spec saying that this > > behavior needs to be modified for routers that are handling wireless > > links, but this would be somewhat counter to the trend in MIPv6 of > > integrating MIP more tightly with standard IPv6 mechanisms. > > Alternatively, we could do a separate draft that modified the text in > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > limiting behavior instead (i.e. make the random delay behavior be a > > function of the incoming SolRA rate). > > Pre-RFC versions of neighbor discovery had a the ability (if my memory serves > me) for routers to immediately unicast a RA in response to a RS, but > randomly delay and rate limit any multicast RAs send it response to RSs. > > Having a mechanisms to select between an immediate unicast response and > a delayed multicast response seemed not worth the effort at the time, but > that is an avenue that can be explored now. > For instance, if the last RS was received less than 3 seconds ago > the router could do the randomly delayed multicast RA; otherwise > an immediate unicast RA. > > => I disagree with the reasonning because it uses the assumption there is > only one router: if RAs are immediately sent (unicasted or multicasted, > this doesn't matter) at the reception of a multicasted RS, then they will > collide. So I agree the bit approach is not good, but the right approach > (to unicast the RS) has some difficulties... > (PS: I can't see a better alternative to trigger though the link layer a RA) A good point. Perhaps a small delay is still required to prevent collisions (unless implementation of small random delays is too tricky) or possibly better still, if sending fast responses was made configurable then it could be enabled only on access routers where faster handovers are desirable and then only on one router on any given link. Regards, Brett. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 13:42:51 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04499 for ; Mon, 22 Apr 2002 13:42:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06542; Mon, 22 Apr 2002 10:42:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03476; Mon, 22 Apr 2002 10:42:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHfEGs004283 for ; Mon, 22 Apr 2002 10:41:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHfEZv004280 for mobile-ip-dist; Mon, 22 Apr 2002 10:41:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHf5Gu004253 for ; Mon, 22 Apr 2002 10:41:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00867 for ; Mon, 22 Apr 2002 09:55:57 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19068 for ; Mon, 22 Apr 2002 10:55:57 -0600 (MDT) Message-ID: <00f401c1ea1e$5728e1a0$8e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> <000401c1e87e$3a586740$a96015ac@T23KEMPF> <3CC4263C.E5B1D41E@iprg.nokia.com> Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Mon, 22 Apr 2002 09:54:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, > > I think there is still a problem with HA registration latency regardless > > of whether you optimize handoff. The handoff signaling optimizes out the > > movement detection algorithm, RegReg optimizes HA registration latency. ^^^^ This line... > - Fast handover has to do with the local address (IP access address, > care-of address, ...) > - Regional Registration has to do with the home address. > This is a fundamental and very interesting difference. ^^^^^^^^ ...is exactly what you say here... > This inference is untrue unless you assign very particular meaning > to the phrase "the fast handoff algorithms". ^^^^^ ...which is why I don't quite understand why you say this. > Again, I believe that there is no easy comparison, and that the answers > will always depend on various parameters that are not naturally related > to each other. > Sounds like I need to write the draft. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 13:44:30 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04626 for ; Mon, 22 Apr 2002 13:44:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29751; Mon, 22 Apr 2002 10:40:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02396; Mon, 22 Apr 2002 10:39:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHd8Gs004186 for ; Mon, 22 Apr 2002 10:39:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHd8p6004185 for mobile-ip-dist; Mon, 22 Apr 2002 10:39:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHd4Gs004177 for ; Mon, 22 Apr 2002 10:39:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13974 for ; Mon, 22 Apr 2002 07:53:59 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24503 for ; Mon, 22 Apr 2002 08:53:58 -0600 (MDT) 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 HAA25157; Mon, 22 Apr 2002 07:53:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MErve20227; Mon, 22 Apr 2002 07:53:57 -0700 X-mProtect: <200204221453> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdm7YcNy; Mon, 22 Apr 2002 07:53:55 PDT Message-ID: <3CC423F9.BFE5704C@iprg.nokia.com> Date: Mon, 22 Apr 2002 07:53:45 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dana L. Blair" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Dana, "Dana L. Blair" wrote: > > > 9. Regional Registration Message Formats > > > > > > These messages are used by the mobile node instead of the > > > existing Registration Request and Registration Reply, in > > > order (1) to make registration work faster, and also > > > (2) to reduce network load for Mobile IP registration. > > Charles, > > Under what circmstances does registration not work fast enough ? > > Under what circumstances does the network load for Mobile IP > registration need to be reduced ? > > This draft implies that Mobile IP is not scalable without > additional infrastructure elements. I completely disagree with > this implication. I didn't see that implication in the draft. It wouldn't be something that I would write, as you may guess. The circumstances you request are those for which the additional registration traffic is undesirable. For instance, it could be that an access network has an Internet Gateway that is expensive for traffic in and out of the network. > > First, regional registration is not mandatory. If your > > product is not intended to be sold into a market that needs > > it, you do not have to implement. > > If the draft is solving a unique problem, then it may be useful. > > However, if implementing the draft is optional, > and there is no circumstance where the option is needed, > then we don't need an RFC for the option. Surely you didn't mean that. Surely you can allow for the existence of RFCs to specify features that you do not have to implement. The option is needed where systems can be made to have better performance by localizing registrations. Results have been published to show this, and it's intuitively obvious. > > Second, there are many distinct techniques that each produce > > some performance improvement. You do not have to implement > > all of them or any of them, but I don't believe that means > > that the opportunity should be removed for those people who > > may need the additional performance improvement. > > The case for performance improvement in a specific circumstance > has not been made in this draft. Are you arguing now for a "Performance Considerations"? Does this go before or after the "IANA Considerations"? Can you point to other Proposed Standards with such text? > > Third, it's done. It's not like we have to make a huge > > investment to produce the technology. We already have it. > > There's no reason to prohibit people who want it from using it. > > By creating a draft that doesn't address any real world circumstance, > it looks like there is a problem with mobile IP when there is none. > This creates alot of confusion when it comes down to what protocols > and functions should be implemented. I'm not confused, and we have implemented systems where the protocol improves performance. You don't have to, and from your comments I would guess you would not recommend doing so. > > > Fourth, regional registration does not reduce the frequency > > of handover. It only localizes the resulting signaling. > > Looks like you are saying handover won't work without regional > registration. I disagree with this. If there is an issue not > addressed by the handover draft(s), it should be fixed there. > No need for another RFC. I did not say this. I only say that handovers can work better and less expensively with regional registration. Furthermore, I very much disagree that every issue with handovers needs to be solved in one draft. There are many techniques for improvement, and they should (MUST, even!) be treated separately. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 13:45:54 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04752 for ; Mon, 22 Apr 2002 13:45:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14323; Mon, 22 Apr 2002 11:45:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05375; Mon, 22 Apr 2002 10:45:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHisGs004416 for ; Mon, 22 Apr 2002 10:44:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHisPB004415 for mobile-ip-dist; Mon, 22 Apr 2002 10:44:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHf5H0004253 for ; Mon, 22 Apr 2002 10:44:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24208 for ; Mon, 22 Apr 2002 09:41:27 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29072 for ; Mon, 22 Apr 2002 09:41:26 -0700 (PDT) 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 JAA00547; Mon, 22 Apr 2002 09:41:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MGfPG12192; Mon, 22 Apr 2002 09:41:25 -0700 X-mProtect: <200204221641> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJLkTtb; Mon, 22 Apr 2002 09:41:23 PDT Message-ID: <3CC43D2A.4CD1A1F4@iprg.nokia.com> Date: Mon, 22 Apr 2002 09:41:14 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf , Basavaraj.Patil@nokia.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44A12CD6@daebe007.NOE.Nokia.com> <006c01c1ea19$d67b95b0$8e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim and Basavaraj, James Kempf wrote: > Raj, > > Dana has already expressed his opposition to it going forward as > standard, based on his belief that the function it is trying to perform > can be performed with considerably less mechanism using the fast handoff > techniques As I tried to explain in my last note, these techniques are different, and solve different problems which are both related to handover performance. Handovers are affected by a number of factors, and it's not appropriate to expect that every factor will be solved by the same mechanism. > > I certainly believe we need to continue the discussion, and > support that, but I also believe there is enough question about the > draft's value as a standard that we should consider other avenues for > publication. Publication as Proposed Standard is appropriate, because the work has been done, implemented, and shown to work. > The only concern is that > it may serve > as a precedent for Mobile IPv6, where the issue is more important, due > to the lack of a large installed base. I'm categorically opposed to > introducing any hint of VLR-like functionality into Mobile IPv6 > networks unless there is no other way to provide the functionality and > it is critically needed. It is important to keep regional registration separate from Mobile IPv6, and from Mobile IPv4 for that matter. I don't think anyone is suggesting that such protocol become mandatory to implement. If the protocol is done, works, and is useful for some systems, then that is enough reason for publication. If your Mobile IPv6 system does not need it, then you should not put it in -- nor would anyone expect you to do so. Also, characterizing the solution as "VLR"-like is prejudicial and inaccurate in my opinion. VLRs are a lot different, and only become similar at a very very high level view. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 13:47:38 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04826 for ; Mon, 22 Apr 2002 13:47:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09790; Mon, 22 Apr 2002 10:47:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05846; Mon, 22 Apr 2002 10:47:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHkGGs004486 for ; Mon, 22 Apr 2002 10:46:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHkGIH004485 for mobile-ip-dist; Mon, 22 Apr 2002 10:46:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHgOGw004325 for ; Mon, 22 Apr 2002 10:46:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28192 for ; Mon, 22 Apr 2002 08:11:09 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15685 for ; Mon, 22 Apr 2002 09:11:09 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MFAq0E000859; Mon, 22 Apr 2002 17:10:52 +0200 (MEST) Received: from research-gs4iel.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA17553; Mon, 22 Apr 2002 17:10:51 +0200 Message-Id: <5.0.0.25.0.20020422165013.02307740@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 22 Apr 2002 17:10:47 +0200 To: "Ahmad Muhanna", "'Charlie Perkins'" From: Annika Jonsson Subject: Re: [mobile-ip] RE: [mobile-imp] WG Last Call: draft-ietf-mobileip-reg-tunnel-06. txt Cc: mobile-ip@sunroof.eng.sun.com, Behcet Sarikaya , "'Madhavi W. Chandra'" In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC0C@zrc2c013.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, you are right in all cases, but it only matters in one case in my opinion. It is the difficult balance between backwards compatibility and optimisations. That the GFA IP extension and zero CoA field is not backwards compatible is obvious, but this is an optimisation, since it is better for the visited network to be able to allocate GFA and CoA dynamically. I think we should allow this, but not as the only solution. That is why I would like to keep the possibility for the MN to include the CoA address in my answer to Alan's suggestions. The first issue that you bring up is more critical, namely what happens if a HA doesn't support these new extensions? The "UNSUPPORTED_EXTENSION" doesn't exist, as you say. So the HA will probably answer with e.g. 128 reason unspecified, or 129 administratively prohibited , or 134 poorly formed Request. We should correct this, and clarify that if the MN receives such a reply, it should try to send a new registration using the advertised CoA. /Annika At 22:35 2002-04-21 -0500, Ahmad Muhanna wrote: >Well, me too. I am not sure what I was doing in 1998. > >I believe the scope of this discussion is really absolutely too late. >However, I would like to continue to raise technical issues about >this draft which mostly related to backward compatibility. > >In section 4.4: Home Agent Considerations: > >Issue No. 1: >" > A Registration Request that does not contain a GFA IP Address > extension or a Replay Protection Style extension is processed > by the home agent as described in [9]. If the home agent > receives a Registration Request with one of these extensions, > and the home agent does not support the extension, the home > agent must return a Registration Reply with the Code value set to > UNSUPPORTED_EXTENSION [9]. >" > >This section mandates that a legacy HA rejects any Registration Request which >contains a GFA IP Address extension or a Replay Protection Style extension >with >an error code of UNSUPPORTED_EXTENSION. Where is the backward compatibility >here. Also, it references RFC3220 while RFC3220 does not have an error >code of >UNSUPPORTED_EXTENSION.!!! > >Issue No. 2: >" > If a home agent receives a Registration > Request message with the care-of address set to zero, and a GFA > IP Address extension, it MUST register the IP address of the GFA > as the care-of address of the mobile node in its mobility binding > list. >" > >This section also mandates that a legacy HA to accept a Registration Request >with Care-of Address set to zero and a GFA IP Address extension and to >include >the GFA IP address as the care-of address in the binding table. >Is this backward compatible solution!!!!! > >Issue No. 3: >" >If a home agent > receives a Registration Request message with the care-of address set > to zero, but no GFA IP Address extension, it MUST deny the request > by sending a Registration Reply message with the Code field set to > ZERO_CAREOF_ADDRESS (see section 8.4). >" > >This section also mandates that a legacy HA rejects a Registration Request >which contains a care-of address field of zero by sending a Registration >Reply >message with error code of ZERO_CAREOF_ADDRESS. >Again, where is the backward compatibility here or we are asking all carriers >to update their HAs in order to be standard compliant by not supporting this >feature!!! > >I hope that there is someone out there who have an answer for these issues. > >Regards; >Ahmad Muhanna > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:01:21 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05517 for ; Mon, 22 Apr 2002 14:01:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28051; Mon, 22 Apr 2002 12:01:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11142; Mon, 22 Apr 2002 11:00:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHxvGs004611 for ; Mon, 22 Apr 2002 10:59:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHxvEX004610 for mobile-ip-dist; Mon, 22 Apr 2002 10:59:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHxsGs004603 for ; Mon, 22 Apr 2002 10:59:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24906 for ; Mon, 22 Apr 2002 09:43:18 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00273 for ; Mon, 22 Apr 2002 09:43:18 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3MGgj2q022250; Mon, 22 Apr 2002 09:42:45 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-117.cisco.com [128.107.163.117]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACS29716; Mon, 22 Apr 2002 09:43:03 -0700 (PDT) Message-ID: <3CC43D97.432E5727@cisco.com> Date: Mon, 22 Apr 2002 09:43:03 -0700 From: "Alpesh S. Patel" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Milind Kulkarni , "Madhavi W. Chandra" , "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> <000401c1e87e$3a586740$a96015ac@T23KEMPF> <007201c1e91b$200127e0$446015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James, I strongly support your thought of moving this contribution to experimental stage for the time being. Let us evaluate some simpler alternatives to the fast handoff problem, which is more realistic. Thanks Alpesh James Kempf wrote: > So it sounds like there is some amount of opposition to this draft going > to draft standard, and there is also the possibility of an alternative > and maybe simpler solution leveraging fast handoff, though the details > of such a solution need to be fleshed out. > > Would there be any objection to moving this to experimental, such as was > done with the MIPv4 fast handoff draft itself, until these issues are > resolved? > > jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:04:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05703 for ; Mon, 22 Apr 2002 14:04:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00465; Mon, 22 Apr 2002 12:04:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13106; Mon, 22 Apr 2002 11:04:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI22Gs004718 for ; Mon, 22 Apr 2002 11:02:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI22QU004712 for mobile-ip-dist; Mon, 22 Apr 2002 11:02:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI1rGs004662 for ; Mon, 22 Apr 2002 11:01:54 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10869 for ; Mon, 22 Apr 2002 10:52:56 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18434 for ; Mon, 22 Apr 2002 11:52:55 -0600 (MDT) 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 KAA05554; Mon, 22 Apr 2002 10:52:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MHqsq24212; Mon, 22 Apr 2002 10:52:54 -0700 X-mProtect: <200204221752> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdezGDN5; Mon, 22 Apr 2002 10:52:52 PDT Message-ID: <3CC44DF5.8DAAB8F5@iprg.nokia.com> Date: Mon, 22 Apr 2002 10:52:53 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> <000401c1e87e$3a586740$a96015ac@T23KEMPF> <3CC4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, Thanks for your clarification. I see now that you did not say the thing I thought you said, and I agree with what you did say. In my defense, I will offer that I had not yet coffee! (that's a lousy excuse!) Regards, Charlie P. James Kempf wrote: > > Hi Charlie, > > > > I think there is still a problem with HA registration latency > regardless > > > of whether you optimize handoff. The handoff signaling optimizes out > the > > > movement detection algorithm, RegReg optimizes HA registration > latency. > ^^^^ > This line... > > > - Fast handover has to do with the local address (IP access address, > > care-of address, ...) > > - Regional Registration has to do with the home address. > > This is a fundamental and very interesting difference. > ^^^^^^^^ > ...is exactly what you say here... > > > This inference is untrue unless you assign very particular meaning > > to the phrase "the fast handoff algorithms". > ^^^^^ > > ...which is why I don't quite understand why you say this. > > > Again, I believe that there is no easy comparison, and that the > answers > > will always depend on various parameters that are not naturally > related > > to each other. > > > > Sounds like I need to write the draft. > > jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:05:17 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05751 for ; Mon, 22 Apr 2002 14:05:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17513; Mon, 22 Apr 2002 11:04:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13177; Mon, 22 Apr 2002 11:04:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI2BGs004770 for ; Mon, 22 Apr 2002 11:02:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI2ARL004761 for mobile-ip-dist; Mon, 22 Apr 2002 11:02:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI1wGs004687 for ; Mon, 22 Apr 2002 11:01:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11665 for ; Mon, 22 Apr 2002 11:01:57 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20841 for ; Mon, 22 Apr 2002 11:01:57 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MI1gp22583; Mon, 22 Apr 2002 13:01:42 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TYFAA>; Mon, 22 Apr 2002 13:01:39 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC15@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Charlie Perkins'" , James Kempf , Basavaraj.Patil@nokia.com Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt Date: Mon, 22 Apr 2002 13:01:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA27.BCD19340" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EA27.BCD19340 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie; please see my comments inline. > > > Hello Jim and Basavaraj, > > James Kempf wrote: > > > Raj, > > > > Dana has already expressed his opposition to it going forward as > > standard, based on his belief that the function it is > trying to perform > > can be performed with considerably less mechanism using the > fast handoff > > techniques > > As I tried to explain in my last note, these techniques are different, > and solve different problems which are both related to handover > performance. Handovers are affected by a number of factors, and > it's not appropriate to expect that every factor will be solved by > the same mechanism. > > > > > I certainly believe we need to continue the > discussion, and > > support that, but I also believe there is enough question about the > > draft's value as a standard that we should consider other > avenues for > > publication. > > Publication as Proposed Standard is appropriate, because the work > has been done, implemented, and shown to work. > > > The only > concern is that > > it may serve > > as a precedent for Mobile IPv6, where the issue is more > important, due > > to the lack of a large installed base. I'm categorically opposed to > > introducing any hint of VLR-like functionality into Mobile IPv6 > > networks unless there is no other way to provide the > functionality and > > it is critically needed. > > It is important to keep regional registration separate from > Mobile IPv6, > and from Mobile IPv4 for that matter. I don't think anyone I respectfully disagree. Your proposed solution in this draft affects existing Mobile IPv4 implementation in many aspects!!! Ahmad Muhanna > is suggesting > that such protocol become mandatory to implement. > > If the protocol is done, works, and is useful for some systems, then > that is enough reason for publication. If your Mobile IPv6 system > does not need it, then you should not put it in -- nor would anyone > expect you to do so. > > Also, characterizing the solution as "VLR"-like is prejudicial > and inaccurate in my opinion. VLRs are a lot different, and > only become similar at a very very high level view. > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C1EA27.BCD19340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] WG Last Call: = draft-ietf-mobileip-reg-tunnel-06.txt

Hello Charlie;
please see my comments inline.

>
>
> Hello Jim and Basavaraj,
>
> James Kempf wrote:
>
> > Raj,
> >
> > Dana has already expressed his opposition = to it going forward as
> > standard, based on his belief that the = function it is
> trying to perform
> > can be performed with considerably less = mechanism using the
> fast handoff
> > techniques
>
> As I tried to explain in my last note, these = techniques are different,
> and solve different problems which are both = related to handover
> performance.  Handovers are affected by a = number of factors, and
> it's not appropriate to expect that every = factor will be solved by
> the same mechanism.
>
> >
> = >            = I certainly believe we need to continue the
> discussion, and
> > support that, but I also believe there is = enough question about the
> > draft's value as a standard that we should = consider other
> avenues for
> > publication.
>
> Publication as Proposed Standard is = appropriate, because the work
> has been done, implemented, and shown to = work.
>
> = >           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;   The only
> concern is that
> > it may serve
> > as a precedent for Mobile IPv6, where the = issue is more
> important, due
> > to the lack of a large installed base. I'm = categorically opposed to
> > introducing any hint of VLR-like = functionality into  Mobile IPv6
> > networks unless there is no other way to = provide the
> functionality and
> > it is critically needed.
>
> It is important to keep regional registration = separate from
> Mobile IPv6,
> and from Mobile IPv4 for that matter.  I = don't think anyone

I respectfully disagree. Your proposed solution in = this draft affects existing
Mobile IPv4 implementation in many aspects!!!

Ahmad Muhanna

> is suggesting
> that such protocol become mandatory to = implement.
>
> If the protocol is done, works, and is useful = for some systems, then
> that is enough reason for publication.  If = your Mobile IPv6 system
> does not need it, then you should not put it in = -- nor would anyone
> expect you to do so.
>
> Also, characterizing the solution as = "VLR"-like is prejudicial
> and inaccurate in my opinion.  VLRs are a = lot different, and
> only become similar at a very very high level = view.
>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C1EA27.BCD19340-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:05:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05774 for ; Mon, 22 Apr 2002 14:05:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25751; Mon, 22 Apr 2002 12:05:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13413; Mon, 22 Apr 2002 11:05:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI31Gs004924 for ; Mon, 22 Apr 2002 11:03:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI2xpF004919 for mobile-ip-dist; Mon, 22 Apr 2002 11:02:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI24HK004727 for ; Mon, 22 Apr 2002 11:02:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06794 for ; Mon, 22 Apr 2002 08:55:00 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28619 for ; Mon, 22 Apr 2002 09:54:58 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MFsmp04257; Mon, 22 Apr 2002 10:54:48 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TYB5G>; Mon, 22 Apr 2002 10:54:44 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC12@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Fredrik Johansson'" , mobile-ip@sunroof.eng.sun.com Cc: fredrik@ipunplugged.com, tony.johansson@ericsson.com Subject: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt Date: Mon, 22 Apr 2002 10:54:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA16.03D0CC00" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EA16.03D0CC00 Content-Type: text/plain; charset="iso-8859-1" Hi Fredrik; Please see my comments inline. Regards; Ahmad Muhanna Ahmad, please see comments inline /fredrik Hello All; I would like to address the following two points: I. Mobile Node and the new HA NAI extension: In section 4. It reads: " A mobile node MUST provide this in every registration request sent when re-authenticating, or when requesting a specific IP address at initial authentication." 1. Does this mean that whenever the mobile Node include a specific Static Home IP address, Mobile Node MUST provide the AAA NAI extension with Subtype 1? [->] yes 2. Does this mean when the MN change point of attachment due to Inter-FA handoff It MUST include this extension. [->] yes If 1 & 2 are true? Where is the backward compatibility with legacy Mobile Node? [->] Isn't it the same as with any extension needed to authenticate through an AAA infrastructure, e.g. the MN-AAA Authentication extension must be present in order for the FA/HA to authenticate via AAA? ************ I do not think that It is the same!! RFC3012 introduced a new way of authenticating the MN to the FA without violating backward compatibility of RFC2002 or later RFC3220. Mobile Node does not know which way or the standard the foreign agent uses to authenticate it. It could be through RADIUS, AAA, Diameter who knows. The point here is that this draft mandates that every Mobile Node include AAA NAI extension with subtype of 1 whenever it requests static Mobile IP or during Inter-FA handoff. Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile Node which exist right now, does not do this. After this draft becomes a standard, according to this section, MN is not following the standard by not sending AAA NAI extension in initial Registration Request or during re-authentication.!!! This is not backward compatible!!!! Thanks; Ahmad ***************** II. Home Agent handling of AAAH Identity Subtype extension: In section 5. It reads: "The home agent MUST provide this in every registration reply if using the AAA server ." I would prefer more explicit sentence similar to one used earlier: "The home agent MUST provide this in every registration reply sent to the mobile node destined through the AAA infrastructure." [->]You mean so don't have to send it every time? I have no problem with that. /Fredrik Thanks for consideration. Regards; Ahmad Muhanna ------_=_NextPart_001_01C1EA16.03D0CC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt

Hi Fredrik;

Please see my comments inline.

Regards;
Ahmad Muhanna



Ahmad,
 
please see comments inline
/fredrik


Hello All;
I would like to address the following two points: =
I. Mobile Node and the new HA NAI extension:
In section 4. It reads:
" A mobile node MUST provide this in every = registration request sent
   when re-authenticating, or when = requesting a specific IP address at
   initial authentication."
        1. Does = this mean that whenever the mobile Node include a specific Static =
        Home IP = address, Mobile Node MUST provide the AAA NAI extension with Subtype 1? =
[->] yes
        2. Does = this mean when the MN change point of attachment due to Inter-FA = handoff
        It MUST = include this extension.
[->] yes
If 1 & 2 are true?
Where is the backward compatibility with legacy = Mobile Node?

[->] Isn't it the same as with any extension = needed to authenticate through an
AAA infrastructure, e.g. the MN-AAA Authentication = extension must be present
in order for the FA/HA to authenticate via = AAA?

************
I do not think that It is the same!!
RFC3012 introduced a new way of authenticating the = MN to the FA without violating
backward compatibility of RFC2002 or later = RFC3220.
Mobile Node does not know which way or the standard = the foreign agent uses to
authenticate it. It could be through RADIUS, AAA, = Diameter who knows.

The point here is that this draft mandates that every = Mobile Node include AAA NAI extension
with subtype of 1 whenever it requests static Mobile = IP or during Inter-FA handoff.
Now: (Standard Compliant RFC3220, RFC3012bis) Legacy = Mobile Node which exist right now,
does not do this.
After this draft becomes a standard, according to = this section, MN is not following the
standard by not sending AAA NAI extension in initial = Registration Request or during re-authentication.!!!

This is not backward compatible!!!!


Thanks;
Ahmad
*****************

II. Home Agent handling of AAAH Identity Subtype = extension:
In section 5. It reads:
"The home agent MUST provide this in every = registration reply if using
   the AAA server ."
I would prefer more explicit sentence similar to one = used earlier:
"The home agent MUST provide this in every = registration reply sent to
  the mobile node destined through the AAA = infrastructure."
 
[->]You mean so don't have to send it every time? = I have no problem with that.
/Fredrik
 Thanks for consideration.
Regards;
Ahmad Muhanna

------_=_NextPart_001_01C1EA16.03D0CC00-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:06:30 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05857 for ; Mon, 22 Apr 2002 14:06:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01793; Mon, 22 Apr 2002 12:06:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13937; Mon, 22 Apr 2002 11:06:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI40Gs005059 for ; Mon, 22 Apr 2002 11:04:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI40AN005055 for mobile-ip-dist; Mon, 22 Apr 2002 11:04:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI3KHG004941 for ; Mon, 22 Apr 2002 11:03:31 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02981 for ; Mon, 22 Apr 2002 07:39:40 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15054 for ; Mon, 22 Apr 2002 07:39:39 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MEdQs7025413; Mon, 22 Apr 2002 16:39:26 +0200 (MEST) Received: from research-gs4iel.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA16679; Mon, 22 Apr 2002 16:39:26 +0200 Message-Id: <5.0.0.25.0.20020422163410.02396980@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 22 Apr 2002 16:39:22 +0200 To: "Ahmad Muhanna", "'Charles E. Perkins'" From: Annika Jonsson Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC09@zrc2c013.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi see my comments below... >Now: >Here is the conflict: > >A Foreign Agent which supports regional tunneling management MUST support >registrations according to Mobile IPv4 [9]. In other words, this FA MUST >set both the 'F' and 'I' bits. >I hope you agree. Yes. >The problem is that you override the requirement of RFC3220 " Which is a >MUST" >by allowing the FA to set the only included care-of address to ZERO. > >A legacy Mobile Node which does not support regional tunneling management >will >not be able to register with this FA. Correct. >Please let me know of what you think? >Thanks for consideration. You are right. If a FA is configured not to address any CoA, it will not support "pure RFC 3220" MN:s. It is up to the administrator of the network to decide if this is OK or not. We want to support backwards compatibility, but we also want to support optimisations, and that's why the draft includes both options. /Annika >Ahmad Muhanna From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:06:52 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05891 for ; Mon, 22 Apr 2002 14:06:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18525; Mon, 22 Apr 2002 11:06:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13913; Mon, 22 Apr 2002 11:06:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI3rGs005041 for ; Mon, 22 Apr 2002 11:03:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI3qvb005040 for mobile-ip-dist; Mon, 22 Apr 2002 11:03:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI3KH0004941 for ; Mon, 22 Apr 2002 11:03:22 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05101 for ; Mon, 22 Apr 2002 09:29:49 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01715 for ; Mon, 22 Apr 2002 10:29:49 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MGPsp20694; Mon, 22 Apr 2002 11:25:54 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TYCZ3>; Mon, 22 Apr 2002 11:25:51 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC14@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Annika Jonsson'" , "'Charles E. Perkins'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt Date: Mon, 22 Apr 2002 11:25:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA1A.582518C0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EA1A.582518C0 Content-Type: text/plain; charset="iso-8859-1" Hi Annika; I believe that any solution for optimizing the Mobile IP protocol must address the issue of backward compatibility until we come up with a clear and permanent solution for this issue. Please see more comments inline. Regards; Ahmad Muhanna > Hi > > see my comments below... > > > >Now: > >Here is the conflict: > > > >A Foreign Agent which supports regional tunneling management > MUST support > >registrations according to Mobile IPv4 [9]. In other words, > this FA MUST > >set both the 'F' and 'I' bits. > >I hope you agree. > > Yes. > > >The problem is that you override the requirement of RFC3220 > " Which is a > >MUST" > >by allowing the FA to set the only included care-of address to ZERO. > > > >A legacy Mobile Node which does not support regional > tunneling management > >will > >not be able to register with this FA. > > Correct. > > >Please let me know of what you think? > >Thanks for consideration. > > You are right. If a FA is configured not to address any CoA, > it will not > support "pure RFC 3220" MN:s. It is up to the administrator > of the network > to decide if this is OK or not. We want to support backwards > compatibility, > but we also want to support optimisations, and that's why the draft > includes both options. > Good point. However, you are putting the blame on the end user (carrier) while I believe that a robust protocol will avoid enabling the end user to unintentionally block all RFC3220 compliant MN, It is a standard too!!. I thought we are optimizing RFC3220 anyway. I do not see any point of having this option available. Why the care-of Address needs to be set to Zero in Agent Advertisement message. One more very serious issue in this regard: In section 3.3: " If the `I' bit is set, and there is only one care-of address, it is the address of the GFA. When only the GFA address is present, and thus the local foreign agent is not advertising its care-of address, the FA-NAI (see section 7.2) SHOULD also be present to enable the mobile node to determine whether or not it has changed foreign agent (so that a new regional registration may be initiated). The mobile node also uses the FA-NAI to decide whether or not it is in its home domain. The decision is based on whether the realm part of the advertised FA-NAI matches the mobile node's realm. If the `I' bit is set, and there are multiple care-of addresses, the first care-of address is the local FA, and the last care-of address is the GFA. " If the FA is advertising Only one Care-of address, it is the GFA Care-of Address, this means that All Legacy MN will never detect that they were handing over to a new FA since they do not understand the FA-NAI extension and the care-of address in the Agent Advertisement is always the same. Thanks; Ahmad > /Annika > > >Ahmad Muhanna > > ------_=_NextPart_001_01C1EA1A.582518C0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt

Hi Annika;
I believe that any solution for optimizing the Mobile IP protocol
must address the issue of backward compatibility until we come up
with a clear and permanent solution for this issue.

Please see more comments inline.

Regards;
Ahmad Muhanna


> Hi
>
> see my comments below...
>
>
> >Now:
> >Here is the conflict:
> >
> >A Foreign Agent which supports regional tunneling management
> MUST support
> >registrations according to Mobile IPv4 [9]. In other words,
> this FA MUST
> >set both the 'F' and 'I' bits.
> >I hope you agree.
>
> Yes.
>
> >The problem is that you override the requirement of RFC3220
> " Which is a
> >MUST"
> >by allowing the FA to set the only included care-of address to ZERO.
> >
> >A legacy Mobile Node which does not support regional
> tunneling management
> >will
> >not be able to register with this FA.
>
> Correct.
>
> >Please let me know of what you think?
> >Thanks for consideration.
>
> You are right. If a FA is configured not to address any CoA,
> it will not
> support "pure RFC 3220" MN:s. It is up to the administrator
> of the network
> to decide if this is OK or not. We want to support backwards
> compatibility,
> but we also want to support optimisations, and that's why the draft
> includes both options.
>

Good point. However, you are putting the blame on the end user (carrier) while
I believe that a robust protocol will avoid enabling the end user to
unintentionally block all RFC3220 compliant MN, It is a standard too!!.
I thought we are optimizing RFC3220 anyway.
I do not see any point of having this option available. Why the care-of
Address needs to be set to Zero in Agent Advertisement message.


One more very serious issue in this regard:
In section 3.3:
"
   If the `I' bit is set, and there is only one care-of address, it is
   the address of the GFA. When only the GFA address is present, and
   thus the local foreign agent is not advertising its care-of address,
   the FA-NAI (see section 7.2) SHOULD also be present to enable the
   mobile node to determine whether or not it has changed foreign agent
   (so that a new regional registration may be initiated).  The mobile
   node also uses the FA-NAI to decide whether or not it is in its home
   domain.  The decision is based on whether the realm part of the
   advertised FA-NAI matches the mobile node's realm.  If the `I' bit
   is set, and there are multiple care-of addresses, the first care-of
   address is the local FA, and the last care-of address is the GFA.
"
If the FA is advertising Only one Care-of address, it is the GFA Care-of Address,
this means that All Legacy MN will never detect that they were handing over to a new FA
since they do not understand the FA-NAI extension and the care-of address in the
Agent Advertisement is always the same.

Thanks;
Ahmad

> /Annika
>
> >Ahmad Muhanna
>
>

------_=_NextPart_001_01C1EA1A.582518C0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:07:10 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05921 for ; Mon, 22 Apr 2002 14:07:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23988; Mon, 22 Apr 2002 11:06:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13986; Mon, 22 Apr 2002 11:06:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI40Gs005058 for ; Mon, 22 Apr 2002 11:04:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI3xbc005054 for mobile-ip-dist; Mon, 22 Apr 2002 11:03:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI3KH8004941 for ; Mon, 22 Apr 2002 11:03:28 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12244 for ; Mon, 22 Apr 2002 08:19:09 -0700 (PDT) Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08249 for ; Mon, 22 Apr 2002 08:19:08 -0700 (PDT) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3MFMJgL027264; Mon, 22 Apr 2002 17:22:19 +0200 From: "Fredrik Johansson" To: "Ahmad Muhanna" , Cc: , Subject: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt Date: Mon, 22 Apr 2002 17:19:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C1EA21.D724D460" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCBFF@zrc2c013.us.nortel.com> Importance: Normal X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C1EA21.D724D460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A Question about:draft-ietf-mobileip-aaa-nai-00.txtAhmad, please see comments inline /fredrik -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: den 19 april 2002 17:56 To: mobile-ip@sunroof.eng.sun.com Cc: 'fredrik@ipunplugged.com'; 'tony.johansson@ericsson.com' Subject: A Question about:draft-ietf-mobileip-aaa-nai-00.txt Hello All; I would like to address the following two points: I. Mobile Node and the new HA NAI extension: In section 4. It reads: " A mobile node MUST provide this in every registration request sent when re-authenticating, or when requesting a specific IP address at initial authentication." 1. Does this mean that whenever the mobile Node include a specific Static Home IP address, Mobile Node MUST provide the AAA NAI extension with Subtype 1? [->] yes 2. Does this mean when the MN change point of attachment due to Inter-FA handoff It MUST include this extension. [->] yes If 1 & 2 are true? Where is the backward compatibility with legacy Mobile Node? [->] Isn't it the same as with any extension needed to authenticate through an AAA infrastructure, e.g. the MN-AAA Authentication extension must be present in order for the FA/HA to authenticate via AAA? II. Home Agent handling of AAAH Identity Subtype extension: In section 5. It reads: "The home agent MUST provide this in every registration reply if using the AAA server ." I would prefer more explicit sentence similar to one used earlier: "The home agent MUST provide this in every registration reply sent to the mobile node destined through the AAA infrastructure." [->]You mean so don't have to send it every time? I have no problem with that. /Fredrik Thanks for consideration. Regards; Ahmad Muhanna ------=_NextPart_000_002C_01C1EA21.D724D460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A Question = about:draft-ietf-mobileip-aaa-nai-00.txt
Ahmad, =
 
please = see comments=20 inline
/fredrik
-----Original Message-----
From: Ahmad Muhanna=20 [mailto:amuhanna@nortelnetworks.com]
Sent: den 19 april 2002 = 17:56
To: mobile-ip@sunroof.eng.sun.com
Cc:=20 'fredrik@ipunplugged.com'; = 'tony.johansson@ericsson.com'
Subject: A=20 Question about:draft-ietf-mobileip-aaa-nai-00.txt

Hello All;
I would like to = address the=20 following two points:

I. Mobile Node and the new HA NAI extension: =

In section 4. It reads:
" = A mobile=20 node MUST provide this in every registration request sent =
   when re-authenticating, or when requesting a = specific IP=20 address at
   initial=20 authentication."

        1. Does = this mean=20 that whenever the mobile Node include a specific Static=20
        Home IP = address,=20 Mobile Node MUST provide the AAA NAI extension with Subtype 1?=20
[->] yes 

        2. Does = this mean=20 when the MN change point of attachment due to Inter-FA handoff=20
        It MUST = include=20 this extension.
[->] yes 

If 1 & 2 are true?
Where is the=20 backward compatibility with legacy Mobile Node?
[->] Isn't it the=20 same as with any extension needed to authenticate through an AAA=20 infrastructure, e.g. the MN-AAA Authentication=20 extension must be present in order for the FA/HA to authenticate = via=20 AAA?

II. Home Agent handling of AAAH Identity Subtype=20 extension:

In section 5. It reads:

"The home agent MUST provide this in every = registration reply=20 if using
   the AAA server = ."

I would prefer more explicit sentence similar to one = used=20 earlier:

"The home agent MUST provide this in every = registration reply=20 sent to
  the mobile node destined = through the=20 AAA infrastructure." 
 
[->]You mean so don't = have to=20 send it every time? I have no problem with that. =

/Fredrik

 Thanks = for=20 consideration.

Regards;
Ahmad = Muhanna=20

------=_NextPart_000_002C_01C1EA21.D724D460-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:11:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06147 for ; Mon, 22 Apr 2002 14:11:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05024; Mon, 22 Apr 2002 12:11:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16623; Mon, 22 Apr 2002 11:10:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI6xHe005251 for ; Mon, 22 Apr 2002 11:07:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHfFRv004285 for mobile-ip-dist; Mon, 22 Apr 2002 10:41:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHf5Gw004253 for ; Mon, 22 Apr 2002 10:41:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28583 for ; Mon, 22 Apr 2002 09:50:58 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16023 for ; Mon, 22 Apr 2002 10:50:58 -0600 (MDT) Message-ID: <00e601c1ea1d$a067c170$8e6015ac@T23KEMPF> From: "James Kempf" To: "Dana L. Blair" , "Milind Kulkarni" , "Madhavi W. Chandra" Cc: "Charles E. Perkins" , References: Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Mon, 22 Apr 2002 09:49:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dana, > Please clarify some confusion that I have and I know a few > others have. > > When you say "such as was done with the MIPv4 fast handoff draft itself", > specifically which draft are you referencing ? Please provide > the full name of the draft. > It is, in fact, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt. There is some question whether we need two handoff techniques, one of which, from the experimental evidence, doesn't work very well if the mobile node moves too fast. In order to clarify the situation, the authors, WG chairs, and ADs have agreed to move it to experimental. I see a similar situation with draft-ietf-mobileip-reg-tunnel-06.txt, which is why I made the suggestion. There are other techniques that may work better, but we don't know yet. > When I commented on draft-ietf-mobileip-reg-tunnel-06.txt, I suggested > the problem should be solved in > draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt which is not > in experimental state as far as I can tell. > > Also, as Basavaraj as stated in a later email, I don't think this > should move to experimental. We may need to discuss it more. > There may be some merit but we need to understand under what > specific circumstances an extra layer of fixed heirarchy is needed. > Fine. I believe a draft is required about how to use the mechanisms in draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt and forwarding from previous care-of address for regional registration. I do not believe that the description should go into draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt itself because that draft is already too big. As for draft-ietf-mobileip-reg-tunnel-06.txt, I'm curious how many people are really going to implement it. Is there any interest in 3GPP2 in it? This question was put for draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt and the answer was "no one", which was another reason why it was taken to experimental. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:11:19 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06199 for ; Mon, 22 Apr 2002 14:11:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05141; Mon, 22 Apr 2002 12:11:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16671; Mon, 22 Apr 2002 11:10:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI6xHg005251 for ; Mon, 22 Apr 2002 11:07:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHkN6u004493 for mobile-ip-dist; Mon, 22 Apr 2002 10:46:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHkCGs004463 for ; Mon, 22 Apr 2002 10:46:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01452 for ; Mon, 22 Apr 2002 09:30:39 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18476 for ; Mon, 22 Apr 2002 10:30:37 -0600 (MDT) Message-ID: <009201c1ea1a$c92a81e0$8e6015ac@T23KEMPF> From: "James Kempf" To: "Brett Pentland" , "Francis Dupont" Cc: "Erik Nordmark" , References: <200204191310.g3JDAKT36329@givry.rennes.enst-bretagne.fr> <3CC3C44D.176E8512@eng.monash.edu.au> Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality Date: Mon, 22 Apr 2002 09:28:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think one could say that only one router on the link should respond this way. The others should be configured to delay. jak ----- Original Message ----- From: "Brett Pentland" To: "Francis Dupont" Cc: "Erik Nordmark" ; "James Kempf" ; Sent: Monday, April 22, 2002 1:05 AM Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality > Francis Dupont wrote: > > > > > Ideally, we could insert some text into the MIPv6 spec saying that this > > > behavior needs to be modified for routers that are handling wireless > > > links, but this would be somewhat counter to the trend in MIPv6 of > > > integrating MIP more tightly with standard IPv6 mechanisms. > > > Alternatively, we could do a separate draft that modified the text in > > > RFC 2461 to make the random delay behavior a SHOULD, or add rate > > > limiting behavior instead (i.e. make the random delay behavior be a > > > function of the incoming SolRA rate). > > > > Pre-RFC versions of neighbor discovery had a the ability (if my memory serves > > me) for routers to immediately unicast a RA in response to a RS, but > > randomly delay and rate limit any multicast RAs send it response to RSs. > > > > Having a mechanisms to select between an immediate unicast response and > > a delayed multicast response seemed not worth the effort at the time, but > > that is an avenue that can be explored now. > > For instance, if the last RS was received less than 3 seconds ago > > the router could do the randomly delayed multicast RA; otherwise > > an immediate unicast RA. > > > > => I disagree with the reasonning because it uses the assumption there is > > only one router: if RAs are immediately sent (unicasted or multicasted, > > this doesn't matter) at the reception of a multicasted RS, then they will > > collide. So I agree the bit approach is not good, but the right approach > > (to unicast the RS) has some difficulties... > > (PS: I can't see a better alternative to trigger though the link layer a RA) > > A good point. Perhaps a small delay is still required to prevent collisions > (unless implementation of small random delays is too tricky) or possibly > better still, if sending fast responses was made configurable then it could > be enabled only on access routers where faster handovers are desirable and > then only on one router on any given link. > > Regards, > Brett. > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:11:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06248 for ; Mon, 22 Apr 2002 14:11:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06085; Mon, 22 Apr 2002 12:11:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16898; Mon, 22 Apr 2002 11:11:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI6xHQ005251 for ; Mon, 22 Apr 2002 11:07:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI3AYI004937 for mobile-ip-dist; Mon, 22 Apr 2002 11:03:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI24He004727 for ; Mon, 22 Apr 2002 11:02:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07916 for ; Mon, 22 Apr 2002 07:32:49 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26719 for ; Mon, 22 Apr 2002 08:32:48 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MEWe0E010259; Mon, 22 Apr 2002 16:32:40 +0200 (MEST) Received: from research-gs4iel.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA16549; Mon, 22 Apr 2002 16:32:39 +0200 Message-Id: <5.0.0.25.0.20020422153922.023168a0@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 22 Apr 2002 16:32:37 +0200 To: "Alan O'Neill" , mobile-ip@sunroof.eng.sun.com From: Annika Jonsson Subject: Re: [mobile-ip] Last Call: Regional Tunneling input In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46C3A3CC@ftmail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Alan, I have read your suggestions, and I have a few comments. First, regarding the dynamic allocation of HA: we do support that in the current draft. We assume that it is the GFA that participates in the authentication procedure as AAA client and not the FA (see section 3.1.2). The reason for this is that it is the GFA that acts as FA towards the HA, and therfore needs the keys for securing registration messages. So, in this way, a AAA server can dynamically allocate an HA, and the GFA will be informed about this. Second, the problem with how to handle different addressing plans between FA - GFA and GFA - HA. I agree that this should be supported. Let's see if I understand your suggestion correctly: * The GFA address advertised in the Agent Advertisement should be the "local" address of the GFA, where it can be reached from the FA. * A Home registration from a MN should never include any CoA address * The FA sends the registration req. on to the GFA "local" address * The GFA allocates CoA to the MN * The GFA IP extension (forget the name change for now...) should be used to transport the selected CoA to the HA and to carry the selected CoA back to the MN, as is already the case in the draft. I agree that dynamically allocating the CoA is the best way, and it seems resonable that this is the responsibility of the GFA and not the FA. But, the reason why we didn't specify that all MN:s must use that method is that we wanted to be backwards compatible wiht HA:s that does'nt specifically support Regional registrations (or rather, the GFA IP extension). If MN:s are allowed to put the CoA in the Registration request, the HA will never need to know that the visited network uses regional registrations, and the GFA will look lika a normal FA. I still think this is a good feature. To allow this, the FA must advertise a publicly routable GFA (CoA) address. If the FA and GFA belongs to a private address domain, the FA needs to have a mapping from the public CoA address to the private GFA address that it should use to send the Registration request to. I think this solves the problem. To summarise, I suggest that we: * clarify that dynamic allocation of CoA is preferable * add that the FA might use another address to communicate with a GFA than the CoA advertised, and that it in that case needs a mapping between these two addresses * change the allocation of CoA and use of the GFA IP address extension, by saying that it is the responsibility of the FA to select GFA, but not to include any GFA IP extension, because it is the responsibility of the GFA to allocate CoA, and it will add the GFA IP extension. Do you agree that this solves the problems you raised? /Annika At 22:23 2002-04-15 -0400, Alan O'Neill wrote: >Below is the abstract for the draft that makes last call suggestions on >Regional tunneling. > >see >http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mods-00.txt > >Abstract > > Regional Registration modifies the normal MIP Registration signalling > back to the HA so that the signalling can traverse an intermediate > Gateway Foreign Agent (GFA). The registered binding is between the Home > Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent > (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the GFA. > Two extensions are defined to support this new Registration processing > these being the Hierarchical Foreign Agent extension (HFAext) and the GFA > > IP address extension (GFAIPext). The former is used to carry the FA CoA > to the GFA and the latter is used by the FA to allocate a GFA to the MN, > and by the FA, GFA, HA to securely return the GFA IP address to the MN. > > The present processing rules for the HA registration enable the FA to > advertise the GFA to the MN in a Foreign Agent Advertisement (FAA) and > for the MN to include that GFA address into the CoA field of the MIP home > > Registration. This however assumes a number of things about the GFA > address in the FAA and the addressing realms between the FA-GFA and GFA- > HA.. Specifically, the GFA CoA and the GFA IP address must potentially be > > from two different addressing plans and hence cannot be in the same FAA. > This draft describes the issues and suggests a solution that requires > slight modifications to the required extensions, that generalises the > Home Registration signalling for arbitrary intermediate MIP nodes, and > only slightly modifies the processing rules for the MIP Home > Registration. This draft also describes a way to support dynamic HA > allocation along-side Regional Registrations. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:11:56 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06260 for ; Mon, 22 Apr 2002 14:11:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00278; Mon, 22 Apr 2002 12:11:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20404; Mon, 22 Apr 2002 11:11:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIAWGs005595 for ; Mon, 22 Apr 2002 11:10:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MIAV9x005594 for mobile-ip-dist; Mon, 22 Apr 2002 11:10:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIAJGs005574 for ; Mon, 22 Apr 2002 11:10:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06095 for ; Mon, 22 Apr 2002 11:10:19 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05036 for ; Mon, 22 Apr 2002 12:10:19 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MI6Np23288; Mon, 22 Apr 2002 13:06:24 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TYFDN>; Mon, 22 Apr 2002 13:06:21 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC16@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Annika Jonsson'" , "'Charles E. Perkins'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt Date: Mon, 22 Apr 2002 13:06:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA28.63ECF6B0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EA28.63ECF6B0 Content-Type: text/plain; charset="iso-8859-1" Hi Annika; I am resending this message for the second time. It never made it to the mailing list. I believe that any solution for optimizing the Mobile IP protocol must address the issue of backward compatibility until we come up with a clear and permanent solution for this issue. Please see more comments inline. Regards; Ahmad Muhanna > > Hi > > see my comments below... > > > >Now: > >Here is the conflict: > > > >A Foreign Agent which supports regional tunneling management > MUST support > >registrations according to Mobile IPv4 [9]. In other words, > this FA MUST > >set both the 'F' and 'I' bits. > >I hope you agree. > > Yes. > > >The problem is that you override the requirement of RFC3220 > " Which is a > >MUST" > >by allowing the FA to set the only included care-of address to ZERO. > > > >A legacy Mobile Node which does not support regional > tunneling management > >will > >not be able to register with this FA. > > Correct. > > >Please let me know of what you think? > >Thanks for consideration. > > You are right. If a FA is configured not to address any CoA, > it will not > support "pure RFC 3220" MN:s. It is up to the administrator > of the network > to decide if this is OK or not. We want to support backwards > compatibility, > but we also want to support optimisations, and that's why the draft > includes both options. Good point. However, you are putting the blame on the end user (carrier) while I believe that a robust protocol will avoid enabling the end user to unintentionally block all RFC3220 compliant MN, It is a standard too!!. I thought we are optimizing RFC3220 anyway. I do not see any point of having this option available. Why the care-of Address needs to be set to Zero in Agent Advertisement message. One more very serious issue in this regard: In section 3.3: " If the `I' bit is set, and there is only one care-of address, it is the address of the GFA. When only the GFA address is present, and thus the local foreign agent is not advertising its care-of address, the FA-NAI (see section 7.2) SHOULD also be present to enable the mobile node to determine whether or not it has changed foreign agent (so that a new regional registration may be initiated). The mobile node also uses the FA-NAI to decide whether or not it is in its home domain. The decision is based on whether the realm part of the advertised FA-NAI matches the mobile node's realm. If the `I' bit is set, and there are multiple care-of addresses, the first care-of address is the local FA, and the last care-of address is the GFA. " If the FA is advertising Only one Care-of address, it is the GFA Care-of Address, this means that All Legacy MN will never detect that they were handing over to a new FA since they do not understand the FA-NAI extension and the care-of address in the Agent Advertisement is always the same. Thanks; Ahmad > > /Annika > > >Ahmad Muhanna > > ------_=_NextPart_001_01C1EA28.63ECF6B0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt

Hi Annika;
I am resending this message for the second time. It never made it to the mailing list.

I believe that any solution for optimizing the Mobile IP protocol
must address the issue of backward compatibility until we come up
with a clear and permanent solution for this issue.

Please see more comments inline.

Regards;
Ahmad Muhanna

>
> Hi
>
> see my comments below...
>
>
> >Now:
> >Here is the conflict:
> >
> >A Foreign Agent which supports regional tunneling management
> MUST support
> >registrations according to Mobile IPv4 [9]. In other words,
> this FA MUST
> >set both the 'F' and 'I' bits.
> >I hope you agree.
>
> Yes.
>
> >The problem is that you override the requirement of RFC3220
> " Which is a
> >MUST"
> >by allowing the FA to set the only included care-of address to ZERO.
> >
> >A legacy Mobile Node which does not support regional
> tunneling management
> >will
> >not be able to register with this FA.
>
> Correct.
>
> >Please let me know of what you think?
> >Thanks for consideration.
>
> You are right. If a FA is configured not to address any CoA,
> it will not
> support "pure RFC 3220" MN:s. It is up to the administrator
> of the network
> to decide if this is OK or not. We want to support backwards
> compatibility,
> but we also want to support optimisations, and that's why the draft
> includes both options.

Good point. However, you are putting the blame on the end user (carrier) while
I believe that a robust protocol will avoid enabling the end user to
unintentionally block all RFC3220 compliant MN, It is a standard too!!.
I thought we are optimizing RFC3220 anyway.
I do not see any point of having this option available. Why the care-of
Address needs to be set to Zero in Agent Advertisement message.


One more very serious issue in this regard:
In section 3.3:
"
   If the `I' bit is set, and there is only one care-of address, it is
   the address of the GFA. When only the GFA address is present, and
   thus the local foreign agent is not advertising its care-of address,
   the FA-NAI (see section 7.2) SHOULD also be present to enable the
   mobile node to determine whether or not it has changed foreign agent
   (so that a new regional registration may be initiated).  The mobile
   node also uses the FA-NAI to decide whether or not it is in its home
   domain.  The decision is based on whether the realm part of the
   advertised FA-NAI matches the mobile node's realm.  If the `I' bit
   is set, and there are multiple care-of addresses, the first care-of
   address is the local FA, and the last care-of address is the GFA.
"
If the FA is advertising Only one Care-of address, it is the GFA Care-of Address,
this means that All Legacy MN will never detect that they were handing over to a new FA
since they do not understand the FA-NAI extension and the care-of address in the
Agent Advertisement is always the same.

Thanks;
Ahmad

>
> /Annika
>
> >Ahmad Muhanna
>
>

------_=_NextPart_001_01C1EA28.63ECF6B0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:12:32 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06311 for ; Mon, 22 Apr 2002 14:12:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22737; Mon, 22 Apr 2002 11:12:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17018; Mon, 22 Apr 2002 11:11:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI6xHS005251 for ; Mon, 22 Apr 2002 11:07:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI3AT8004936 for mobile-ip-dist; Mon, 22 Apr 2002 11:03:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI24Hc004727 for ; Mon, 22 Apr 2002 11:02:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06007 for ; Mon, 22 Apr 2002 07:26:45 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23508 for ; Mon, 22 Apr 2002 08:26:45 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3MEQC2q017719; Mon, 22 Apr 2002 07:26:13 -0700 (PDT) Received: from DBLAIRW2K (atlanta-dhcp-idf81-56.cisco.com [161.44.123.56]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACS27241; Mon, 22 Apr 2002 07:26:30 -0700 (PDT) From: "Dana L. Blair" To: "James Kempf" , "Milind Kulkarni" , "Madhavi W. Chandra" Cc: "Charles E. Perkins" , Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Mon, 22 Apr 2002 10:26:30 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <007201c1e91b$200127e0$446015ac@T23KEMPF> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of James Kempf > Sent: Sunday, April 21, 2002 5:59 AM > To: James Kempf; Milind Kulkarni; Madhavi W. Chandra > Cc: Charles E. Perkins; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] WG Last Call: > draft-ietf-mobileip-reg-tunnel-06.txt > > > So it sounds like there is some amount of opposition to this draft going > to draft standard, and there is also the possibility of an alternative > and maybe simpler solution leveraging fast handoff, though the details > of such a solution need to be fleshed out. > > Would there be any objection to moving this to experimental, such as was > done with the MIPv4 fast handoff draft itself, until these issues are > resolved? Please clarify some confusion that I have and I know a few others have. When you say "such as was done with the MIPv4 fast handoff draft itself", specifically which draft are you referencing ? Please provide the full name of the draft. When I commented on draft-ietf-mobileip-reg-tunnel-06.txt, I suggested the problem should be solved in draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt which is not in experimental state as far as I can tell. Also, as Basavaraj as stated in a later email, I don't think this should move to experimental. We may need to discuss it more. There may be some merit but we need to understand under what specific circumstances an extra layer of fixed heirarchy is needed. thanks, Dana > > jak > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:12:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06329 for ; Mon, 22 Apr 2002 14:12:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22834; Mon, 22 Apr 2002 11:12:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17024; Mon, 22 Apr 2002 11:11:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI6xHc005251 for ; Mon, 22 Apr 2002 11:07:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MHkOmI004494 for mobile-ip-dist; Mon, 22 Apr 2002 10:46:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MHkCGu004463 for ; Mon, 22 Apr 2002 10:46:13 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28475 for ; Mon, 22 Apr 2002 09:23:57 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29330 for ; Mon, 22 Apr 2002 10:23:56 -0600 (MDT) Message-ID: <006c01c1ea19$d67b95b0$8e6015ac@T23KEMPF> From: "James Kempf" To: , , Cc: , , "Dana L. Blair" References: <697DAA22C5004B4596E033803A7CEF44A12CD6@daebe007.NOE.Nokia.com> Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Date: Mon, 22 Apr 2002 09:21:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Raj, Dana has already expressed his opposition to it going forward as standard, based on his belief that the function it is trying to perform can be performed with considerably less mechanism using the fast handoff techniques. I certainly believe we need to continue the discussion, and support that, but I also believe there is enough question about the draft's value as a standard that we should consider other avenues for publication. My own feeling is that the fast handoff techniques and forwarding from previous care of address for those mobile nodes that don't implement the fast handoff techniques can, in fact, perform the functions in the draft with considerably less mechanism, but, of course, we need a draft to describe how. The mechanisms outlined in the draft introduce a VLR-like functionality for Mobile IP, and they will require expensive infrastructure to support it, because it will require replication to provide reliability, and such equipment is always expensive. I really don't want to see such functionality introduced into IP networks. However, just as with route optimization, I don't believe that this draft will see widespread deployment, because the basic infrastructure for Mobile IPv4 is pretty much set, even though the draft doesn't require changes in other IP nodes. The only concern is that it may serve as a precedent for Mobile IPv6, where the issue is more important, due to the lack of a large installed base. I'm categorically opposed to introducing any hint of VLR-like functionality into Mobile IPv6 networks unless there is no other way to provide the functionality and it is critically needed. jak ----- Original Message ----- From: To: ; ; Cc: ; Sent: Sunday, April 21, 2002 10:23 PM Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt > > James, > > Obviously the authors of the draft need to address the concerns that > have been raised by WG members. Lets not jump the gun and simply > go forward with making this I-D an experimental RFC. I do not believe > that will be of any real value. Lets continue this discussion some more > and give the authors a chance to clarify the problem statement as well > as other details. And if we see that there is no WG consensus after that, > we can drop the I-D (or make it experimental if the WG wants to do so). > > -Basavaraj > > > > > So it sounds like there is some amount of opposition to this > > draft going > > to draft standard, and there is also the possibility of an alternative > > and maybe simpler solution leveraging fast handoff, though the details > > of such a solution need to be fleshed out. > > > > Would there be any objection to moving this to experimental, > > such as was > > done with the MIPv4 fast handoff draft itself, until these issues are > > resolved? > > > > jak > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:16:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06488 for ; Mon, 22 Apr 2002 14:16:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08953; Mon, 22 Apr 2002 12:16:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18733; Mon, 22 Apr 2002 11:16:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI6xHs005251 for ; Mon, 22 Apr 2002 11:14:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MAVZnV003520 for mobile-ip-dist; Mon, 22 Apr 2002 03:31:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MAVWGs003513 for ; Mon, 22 Apr 2002 03:31:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16945 for ; Mon, 22 Apr 2002 03:00:14 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10045 for ; Mon, 22 Apr 2002 03:00:11 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MA0As7029383 for ; Mon, 22 Apr 2002 12:00:10 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 11:57:15 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 11:49:29 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF092@esealnt117> From: "Karim El-Malki (ERA)" To: "'Basavaraj.Patil@nokia.com '" , "'kempf@docomolabs-usa.com '" , "'mkulkarn@cisco.com '" , "'mchandra@cisco.com '" Cc: "'charliep@iprg.nokia.com '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt Date: Mon, 22 Apr 2002 11:57:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I agree. There's no reason for jumping to experimental at this point. Regional registrations are used as part of a Fast Handoffs4 solution (as explained in Low Latency v4 draft), but that's different from saying that they're solving the same problem or that fast handoffs provides an alternative to regreg. In any case the authors are in the best position to clarify the problem statement and it is premature to draw conclusions. /Karim -----Original Message----- From: Basavaraj.Patil@nokia.com To: kempf@docomolabs-usa.com; mkulkarn@cisco.com; mchandra@cisco.com Cc: charliep@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com Sent: 2002-04-22 07:23 Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt James, Obviously the authors of the draft need to address the concerns that have been raised by WG members. Lets not jump the gun and simply go forward with making this I-D an experimental RFC. I do not believe that will be of any real value. Lets continue this discussion some more and give the authors a chance to clarify the problem statement as well as other details. And if we see that there is no WG consensus after that, we can drop the I-D (or make it experimental if the WG wants to do so). -Basavaraj > > So it sounds like there is some amount of opposition to this > draft going > to draft standard, and there is also the possibility of an alternative > and maybe simpler solution leveraging fast handoff, though the details > of such a solution need to be fleshed out. > > Would there be any objection to moving this to experimental, > such as was > done with the MIPv4 fast handoff draft itself, until these issues are > resolved? > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:19:34 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06651 for ; Mon, 22 Apr 2002 14:19:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04901; Mon, 22 Apr 2002 12:19:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20393; Mon, 22 Apr 2002 11:19:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIIiGs006223 for ; Mon, 22 Apr 2002 11:18:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MIIiNR006222 for mobile-ip-dist; Mon, 22 Apr 2002 11:18:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIIfGs006215 for ; Mon, 22 Apr 2002 11:18:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20050 for ; Mon, 22 Apr 2002 11:18:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27370 for ; Mon, 22 Apr 2002 11:18:41 -0700 (PDT) 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 LAA08178; Mon, 22 Apr 2002 11:18:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MIIeh27161; Mon, 22 Apr 2002 11:18:40 -0700 X-mProtect: <200204221818> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYN4HJG; Mon, 22 Apr 2002 11:18:38 PDT Message-ID: <3CC453FE.2E219344@iprg.nokia.com> Date: Mon, 22 Apr 2002 11:18:38 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Annika Jonsson CC: Ahmad Muhanna , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call:draft-ietf-mobileip-reg-tunnel-06.t xt References: <5.0.0.25.0.20020422163410.02396980@era-t.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Annika, I would like to add something to your comment... Annika Jonsson wrote: > You are right. If a FA is configured not to address any CoA, it will not > support "pure RFC 3220" MN:s. It is up to the administrator of the network > to decide if this is OK or not. We want to support backwards compatibility, > but we also want to support optimisations, and that's why the draft > includes both options. The care-of address offered by a foreign agent is almost definitionally something that is configured by an administrator. If the administrator configures the foreign agent to not have any advertised care-of addresses, then that administrator has already decided not to support RFC 3220 mobile nodes. This would, for instance, enable local network support for Mobile IP but with foreign agents that only have private addresses. Thus, it is not a way to disable existing foreign agent functionality. It is a way to offer new foreign agent functionality in situations where RFC 3220 foreign agents might impractical. So I'd say that's somewhat different than an "optimization". Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:24:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06893 for ; Mon, 22 Apr 2002 14:24:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07343; Mon, 22 Apr 2002 12:24:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22745; Mon, 22 Apr 2002 11:24:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MINQGs006417 for ; Mon, 22 Apr 2002 11:23:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MINP2P006416 for mobile-ip-dist; Mon, 22 Apr 2002 11:23:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MINMGs006409 for ; Mon, 22 Apr 2002 11:23:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28236 for ; Mon, 22 Apr 2002 11:23:22 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13452 for ; Mon, 22 Apr 2002 12:23:22 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MINBp25832; Mon, 22 Apr 2002 13:23:11 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TYFQK>; Mon, 22 Apr 2002 13:23:09 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC17@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Charles E. Perkins'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt Date: Mon, 22 Apr 2002 13:22:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA2A.BAA9F0F0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EA2A.BAA9F0F0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie; I assumed that you already read the discussion of all backward compatibility issues that I have raised earlier. That what I meant by affecting existing Mobile Ipv4 implementation. On this thread at least 5 issues been identified to cause backward compatibility issues with Mobile Node and Home Agents. I hope I made myself clear. Regards; Ahmad Muhanna > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Monday, April 22, 2002 1:11 PM > To: Muhanna, Ahmad [RICH1:2Q20:EXCH] > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] WG Last Call: > draft-ietf-mobileip-reg-tunnel-06.txt > > > > Hello Ahmad, > > >> It is important to keep regional registration separate from > >> Mobile IPv6, > >> and from Mobile IPv4 for that matter. I don't think anyone > > > > I respectfully disagree. Your proposed solution in this > draft affects existing > > Mobile IPv4 implementation in many aspects!!! > > How do you mean that? Regional agents can handle existing Mobile IPv4 > mobile nodes -- the mobile nodes just can't then use regional > messages. > Mobile nodes that run the new protocol do not disturb other mobile > entities. If the home agent supports the ability to handle the > non-mandatory extensions for zero care-of address, then the mobile > node can use this feature. If not, then the mobile node can either > not use regional registration. This would be a matter for > preconfiguration > just as with the mobile security association. > > The regional registration protocol is a new protocol, with new > messages and extensions, that works well with Mobile IPv4. > If there was a way to do it with Mobile IPv4, then we wouldn't > have to make the draft. Otherwise, aren't changes required in > at least some implementation somewhere? > > Regards, > Charlie P. > ------_=_NextPart_001_01C1EA2A.BAA9F0F0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt

Hello Charlie;

I assumed that you already read the discussion of all backward compatibility
issues that I have raised earlier. That what I meant by affecting existing Mobile Ipv4
implementation.
On this thread at least 5 issues been identified to cause backward compatibility issues
with Mobile Node and Home Agents.

I hope I made myself clear.

Regards;
Ahmad Muhanna



> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Monday, April 22, 2002 1:11 PM
> To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] WG Last Call:
> draft-ietf-mobileip-reg-tunnel-06.txt
>
>
>
> Hello Ahmad,
>
> >> It is important to keep regional registration separate from
> >> Mobile IPv6,
> >> and from Mobile IPv4 for that matter.  I don't think anyone
> >
> > I respectfully disagree. Your proposed solution in this
> draft affects existing
> > Mobile IPv4 implementation in many aspects!!!
>
> How do you mean that?  Regional agents can handle existing Mobile IPv4
> mobile nodes -- the mobile nodes just can't then use regional
> messages.
> Mobile nodes that run the new protocol do not disturb other mobile
> entities.  If the home agent supports the ability to handle the
> non-mandatory extensions for zero care-of address, then the mobile
> node can use this feature.  If not, then the mobile node can either
> not use regional registration.  This would be a matter for
> preconfiguration
> just as with the mobile security association.
>
> The regional registration protocol is a new protocol, with new
> messages and extensions, that works well with Mobile IPv4.
> If there was a way to do it with Mobile IPv4, then we wouldn't
> have to make the draft.  Otherwise, aren't changes required in
> at least some implementation somewhere?
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C1EA2A.BAA9F0F0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:32:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07377 for ; Mon, 22 Apr 2002 14:32:42 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19035; Mon, 22 Apr 2002 12:32:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03726; Mon, 22 Apr 2002 11:32:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIVxGs006518 for ; Mon, 22 Apr 2002 11:32:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MIVxC1006517 for mobile-ip-dist; Mon, 22 Apr 2002 11:31:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIVuGs006510 for ; Mon, 22 Apr 2002 11:31:56 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03371 for ; Mon, 22 Apr 2002 11:31:57 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09597 for ; Mon, 22 Apr 2002 11:31:56 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MIVts7018222 for ; Mon, 22 Apr 2002 20:31:55 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 20:31:54 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTS9VF>; Mon, 22 Apr 2002 20:31:55 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF097@esealnt117> From: "Karim El-Malki (ERA)" To: "'James Kempf'" , "Dana L. Blair" , Milind Kulkarni , "Madhavi W. Chandra" Cc: "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt Date: Mon, 22 Apr 2002 20:29:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Please clarify some confusion that I have and I know a few > > others have. > > > > When you say "such as was done with the MIPv4 fast handoff draft > itself", > > specifically which draft are you referencing ? Please provide > > the full name of the draft. > > > > It is, in fact, > draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt. There > is > some question whether we need two handoff techniques, one of which, > from the experimental evidence, doesn't work very well if the mobile > node moves too fast. That's a bit of a biased comment isn't it? In particular there was more than one person who questioned your experiments. > In order to clarify the situation, the > authors, WG > chairs, and ADs have agreed to move it to experimental. This question wasn't posed to the WG. This is what I had asked when I was informed that the fate of the low latency draft was being discussed in a group which I believe you (James) were part of. Just to clarify, I wasn't part of this decision process so I had little choice other than to agree. /Karim From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 14:45:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07966 for ; Mon, 22 Apr 2002 14:45:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26359; Mon, 22 Apr 2002 12:45:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11565; Mon, 22 Apr 2002 11:45:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIidGs006632 for ; Mon, 22 Apr 2002 11:44:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MIidhk006631 for mobile-ip-dist; Mon, 22 Apr 2002 11:44:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIiaGs006624 for ; Mon, 22 Apr 2002 11:44:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10979 for ; Mon, 22 Apr 2002 11:44:37 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12739 for ; Mon, 22 Apr 2002 11:44:36 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3MIiKpG023622; Mon, 22 Apr 2002 11:44:21 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA03587; Mon, 22 Apr 2002 14:44:20 -0400 (EDT) Date: Mon, 22 Apr 2002 14:44:20 -0400 From: "Madhavi W. Chandra" To: Charlie Perkins Cc: James Kempf , Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt Message-ID: <20020422144420.A3578@cisco.com> References: <697DAA22C5004B4596E033803A7CEF44A12CD6@daebe007.NOE.Nokia.com> <006c01c1ea19$d67b95b0$8e6015ac@T23KEMPF> <3CC43D2A.4CD1A1F4@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC43D2A.4CD1A1F4@iprg.nokia.com>; from charliep@iprg.nokia.com on Mon, Apr 22, 2002 at 09:41:14AM -0700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie and Raj, On Mon, Apr 22, 2002 at 09:41:14AM -0700, Charlie Perkins wrote: > Hello Jim and Basavaraj, > > James Kempf wrote: > > > Raj, > > > > Dana has already expressed his opposition to it going forward as > > standard, based on his belief that the function it is trying to perform > > can be performed with considerably less mechanism using the fast handoff > > techniques > > As I tried to explain in my last note, these techniques are different, > and solve different problems which are both related to handover > performance. > Handovers are affected by a number of factors, and > it's not appropriate to expect that every factor will be solved by > the same mechanism. Agreed, that not all scenarios will be solved by the same mechanism. I am still grappling, however, with what exact scenario the regional registration solution will 'benefit'. I guess much of my doubt stems from trying to weigh the performance benefit of reg. registration with the implementation overhead. Reg. Registration is now introducing another single point of failure (namely, the GFA)...requiring much more awareness in the MN...adding another MIP element.... As I remarked in another email, it is not as easy to say that the RFC doesn't have to be implemented after it takes on a life as a standard. Thus, it may be prudent to reevaluate the applicability of the regional registration draft with respect to developments in MIP since it's inception. For all I know, it may be the case that the regional registration draft is alleviating an issue that cannot otherwise be addressed by FH or dynamic home agent allocation. It just seems to me that the latter two mechanisms will provide a solution that will no longer make the long haul signaling to the HA a major issue. > > > > I certainly believe we need to continue the discussion, and > > support that, but I also believe there is enough question about the > > draft's value as a standard that we should consider other avenues for > > publication. > > Publication as Proposed Standard is appropriate, because the work > has been done, implemented, and shown to work. > > > The only concern is that > > it may serve > > as a precedent for Mobile IPv6, where the issue is more important, due > > to the lack of a large installed base. I'm categorically opposed to > > introducing any hint of VLR-like functionality into Mobile IPv6 > > networks unless there is no other way to provide the functionality and > > it is critically needed. > > It is important to keep regional registration separate from Mobile IPv6, > and from Mobile IPv4 for that matter. This will be hard to do...especially for MIPv4. Standardizing the regional registration draft has an implicit suggestion that base MIP needs added architecture. Even though it may not be explicitly stated anywhere, it will no doubt be the message that is conveyed. Otherwise, customers/vendors may wonder why a regional registration draft is needed. > I don't think anyone is suggesting > that such protocol become mandatory to implement. True. However, as a community that is trying to get MIP 'off the ground', we should be careful about what we standardize so as to not complicate the MIP protocol...or at least, ensure that there is a real need for the added architecture. Regards, Madhavi > > If the protocol is done, works, and is useful for some systems, then > that is enough reason for publication. If your Mobile IPv6 system > does not need it, then you should not put it in -- nor would anyone > expect you to do so. > > Also, characterizing the solution as "VLR"-like is prejudicial > and inaccurate in my opinion. VLRs are a lot different, and > only become similar at a very very high level view. > > Regards, > Charlie P. > From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 15:11:08 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06209 for ; Mon, 22 Apr 2002 14:11:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26639; Mon, 22 Apr 2002 11:10:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16540; Mon, 22 Apr 2002 11:10:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI6xHU005251 for ; Mon, 22 Apr 2002 11:07:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MI36cZ004932 for mobile-ip-dist; Mon, 22 Apr 2002 11:03:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MI24HU004727 for ; Mon, 22 Apr 2002 11:02:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17281 for ; Mon, 22 Apr 2002 08:03:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29987 for ; Mon, 22 Apr 2002 09:03:38 -0600 (MDT) 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 IAA25505; Mon, 22 Apr 2002 08:03:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MF3Zl25984; Mon, 22 Apr 2002 08:03:35 -0700 X-mProtect: <200204221503> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5Zx0LF; Mon, 22 Apr 2002 08:03:33 PDT Message-ID: <3CC4263C.E5B1D41E@iprg.nokia.com> Date: Mon, 22 Apr 2002 08:03:24 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020419152031.A29507@cisco.com> <3CC07279.CFA48B8@iprg.nokia.com> <20020419172904.B16284@cisco.com> <3CC096D2.BE322956@cisco.com> <000401c1e87e$3a586740$a96015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, James Kempf wrote: > I think there is still a problem with HA registration latency regardless > of whether you optimize handoff. The handoff signaling optimizes out the > movement detection algorithm, RegReg optimizes HA registration latency. > So there are two different problems. That said, RegReg is one solution > to optimizing HA registration, there are other solutions that leverage > fast handoff somewhat better and therefore would require less mechanism. > The RegReg solution was concieved and developed prior to the fast > handoff algorithms, so it is not suprising that it did not consider this > possibility. This inference is untrue unless you assign very particular meaning to the phrase "the fast handoff algorithms". There have been quite a few fast handover algorithms, and the differences between them does not materially affect their overall ability to interact with the regional registration algorithm. In other words, using fair terminology, the designers of the Regional Registration draft _did_ consider the interactions with fast handovers. In fact, there is an interesting generalization that I think I have discussed with you in the past: - Fast handover has to do with the local address (IP access address, care-of address, ...) - Regional Registration has to do with the home address. This is a fundamental and very interesting difference. Furthermore, the _manner_ in which the two techniques optimizes the handover latency is _substantially different_. While they are harmonious and SHOULD work together, they are subject to different constraints and fail or succeed separately. .......... > Would be interesting to compare a RegReg implementation for localized > registration to an implementation that leveraged fast handoff. Again, I believe that there is no easy comparison, and that the answers will always depend on various parameters that are not naturally related to each other. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Apr 22 15:14:14 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09167 for ; Mon, 22 Apr 2002 15:14:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29268; Mon, 22 Apr 2002 12:13:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10125; Mon, 22 Apr 2002 12:13:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJCnGs006760 for ; Mon, 22 Apr 2002 12:12:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MJCnAQ006759 for mobile-ip-dist; Mon, 22 Apr 2002 12:12:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJCjGs006752 for ; Mon, 22 Apr 2002 12:12:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00752 for ; Mon, 22 Apr 2002 12:12:46 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14976 for ; Mon, 22 Apr 2002 13:12:45 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3MJCJV13700; Mon, 22 Apr 2002 14:12:19 -0500 (CDT) Message-ID: <3CC460AA.50803@alcatel.com> Date: Mon, 22 Apr 2002 14:12:42 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Madhavi W. Chandra" CC: Charlie Perkins , James Kempf , Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt References: <697DAA22C5004B4596E033803A7CEF44A12CD6@daebe007.NOE.Nokia.com> <006c01c1ea19$d67b95b0$8e6015ac@T23KEMPF> <3CC43D2A.4CD1A1F4@iprg.nokia.com> <20020422144420.A3578@cisco.com> Content-Type: multipart/alternative; boundary="------------050003050608050509080705" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------050003050608050509080705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Madhavi, You seem to be constrained by the present deployment of MIPv4 which seems to be only in 1XRTT networks, at PDSN nodes, etc. In order to apply LMM to these architectures another level needs to be added to create a regional organization of PDSN routers or the like, which of course will not happen. By keeping FAs at the edge of the network, the 3G architectures are achieving part of what LMM is trying to do anyways. The above is certainly great, but does not in my opinion mean that WG should limit its work into this architecture and state-of-art (or should it, Raj?). I think this is the issue being raised by the problem statement questioning people. Regards, Madhavi W. Chandra wrote: >> >> --behcet --------------050003050608050509080705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Madhavi,
  You seem to be constrained by the present deployment of MIPv4 which seems to be only in 1XRTT networks, at PDSN nodes, etc.
  In order to apply LMM to these architectures another level needs to be added to create a regional organization of PDSN routers or the like, which of course will not happen.
   By keeping FAs at the edge of the network, the 3G architectures are achieving part of what LMM is trying to do anyways.
  The above is certainly great, but does not in my opinion mean that WG should limit its work into this architecture and state-of-art (or should it, Raj?).

  I think this is the issue being raised by the problem statement questioning people.

Regards,
Madhavi W. Chandra wrote:

  

    
   

    

    

    

--behcet

    
    

--------------050003050608050509080705--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 15:17:48 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09304
	for ; Mon, 22 Apr 2002 15:17:43 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13804;
	Mon, 22 Apr 2002 13:17:40 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12675;
	Mon, 22 Apr 2002 12:17:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJGQGs006831
	for ; Mon, 22 Apr 2002 12:16:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MJGQxp006830
	for mobile-ip-dist; Mon, 22 Apr 2002 12:16:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJGGGs006820
	for ; Mon, 22 Apr 2002 12:16:17 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11320
	for ; Mon, 22 Apr 2002 12:15:37 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13071
	for ; Mon, 22 Apr 2002 13:15:36 -0600 (MDT)
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 MAA11784;
	Mon, 22 Apr 2002 12:15:36 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MJFZk18014;
	Mon, 22 Apr 2002 12:15:35 -0700
X-mProtect: <200204221915> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpddek8on; Mon, 22 Apr 2002 12:15:18 PDT
Message-ID: <3CC4613F.61AA72FD@iprg.nokia.com>
Date: Mon, 22 Apr 2002 12:15:11 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Madhavi W. Chandra" 
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
References: <697DAA22C5004B4596E033803A7CEF44A12CD6@daebe007.NOE.Nokia.com> <006c01c1ea19$d67b95b0$8e6015ac@T23KEMPF> <3CC43D2A.4CD1A1F4@iprg.nokia.com> <20020422144420.A3578@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Madhavi,

"Madhavi W. Chandra" wrote:

> Agreed, that not all scenarios will be solved by the same mechanism.

O.K.  The direct implication of this is that not all systems
have to implement the same protocols.

 
> I am still grappling, however, with what exact scenario the regional
> registration solution will 'benefit'.  I guess much of my doubt stems
> from trying to weigh the performance benefit of reg. registration with
> the implementation overhead.  Reg. Registration is now introducing
> another single point of failure (namely, the GFA)...requiring much
> more awareness in the MN...adding another MIP element....

Performance improvements always come at the cost of additional
implementation.  So, I think they should be considered optional,
except where the health of the Internet is at stake.  For systems
where the performance improvement is immaterial, the implementation
cost should not be undertaken.  The scenarios where regional
registration provides benefits are those where localized signaling
is important for cost reduction (if traffic across the Internet
gateway is expensive for any reason).  It is also possible that
some systems may not be amenable for inclusion of fast handover
techniques, and in such circumstances the regional registration
would be helpful although not as good as regional registration
plus fast handover.

> As I remarked in another email, it is not as easy to say that the RFC
> doesn't have to be implemented after it takes on a life as a standard.

I don't believe this, and to the extent that it ever becomes true
it is a problem.  I think that protocols should always be implemented
based on the requirements of the underlying system.

> Thus, it may be prudent to reevaluate the applicability of the
> regional registration draft with respect to developments in MIP since
> it's inception.  For all I know, it may be the case that the regional
> registration draft is alleviating an issue that cannot otherwise be
> addressed by FH or dynamic home agent allocation.  It just seems to me
> that the latter two mechanisms will provide a solution that will no
> longer make the long haul signaling to the HA a major issue.

Dynamic home agent allocation is a lot more complicated that
regional registration, and carries with it a lot of other
implications (e.g., on domain names).  Fast handover is, in a
word, different.  I truly hope that we can get to an understanding
of the applicability of multiple different but non-competing solutions.
That way, we can get the best possible performance for handover
systems.



> > >                                                   The only concern is that
> > > it may serve
> > > as a precedent for Mobile IPv6, where the issue is more important, due
> > > to the lack of a large installed base. I'm categorically opposed to
> > > introducing any hint of VLR-like functionality into  Mobile IPv6
> > > networks unless there is no other way to provide the functionality and
> > > it is critically needed.
> >
> > It is important to keep regional registration separate from Mobile IPv6,
> > and from Mobile IPv4 for that matter.
> 
> This will be hard to do...especially for MIPv4.  Standardizing the
> regional registration draft has an implicit suggestion that base MIP
> needs added architecture.

I do not like this formulation.  Every protocol has a particular
realm of applicability.  Mobile IPv4 is just fine for a wide range
of applications.  Regional registration extends that to still more
scenarios.  That doesn't mean that the original protocol is at all
inadequate for the range of applicability it was designed for.  And,
conversely, it doesn't mean that we should be inhibited from finding
solutions to apply mobile networking techniques in places where
Mobile IPv4 doesn't work as well.  It's not a slur on Mobile IPv4.
I'm not a person who would do that!

>                       Even though it may not be explicitly stated
> anywhere, it will no doubt be the message that is conveyed.
> Otherwise, customers/vendors may wonder why a regional registration
> draft is needed.

Then, I guess we need to make that clear in the draft.  That way,
anyone who wanted to know why the protocol was needed, would just
have to look at the protocol document to see why.

>> I don't think anyone is suggesting
>> that such protocol become mandatory to implement.
>
> True.  However, as a community that is trying to get MIP 'off the
> ground', we should be careful about what we standardize so as to not
> complicate the MIP protocol...or at least, ensure that there is a real
> need for the added architecture.

This protocol does not complicate RFC 3220, for the reason that it
is not part of RFC 3220 and is not mandatory.  It will only matter
for systems where people find that signaling volume and latency
and cost are problems to be reckoned with.  It could be that the
majority of Mobile IPv4 implementations will not have that problem.
I don't see this to be at odds with getting Mobile IPv4 started!

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 15:19:26 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09357
	for ; Mon, 22 Apr 2002 15:19:25 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14862;
	Mon, 22 Apr 2002 13:19:26 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13803;
	Mon, 22 Apr 2002 12:19:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJIYGs006884
	for ; Mon, 22 Apr 2002 12:18:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MJIYXn006883
	for mobile-ip-dist; Mon, 22 Apr 2002 12:18:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJIVGs006876
	for ; Mon, 22 Apr 2002 12:18:31 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13288
	for ; Mon, 22 Apr 2002 12:18:32 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17808
	for ; Mon, 22 Apr 2002 13:18:32 -0600 (MDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MJEap12980;
	Mon, 22 Apr 2002 14:14:36 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2Y3TYG6V>; Mon, 22 Apr 2002 14:14:34 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC18@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Annika Jonsson'" ,
        "'Charlie Perkins'"
	 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] RE: [mobile-imp] WG Last Call: draft-ietf-mobilei
	p-reg-tunnel-06. txt
Date: Mon, 22 Apr 2002 14:14:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EA31.EA46F360"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EA31.EA46F360
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Annika;

You are proposing a solution for a specific problem. 
You are making this great claim that this solution supports existing Mobile
IPv4 implementation. 

"
   Foreign agents that support regional registrations are also required
   to support registrations according to Mobile IPv4 [9].  If there is
   a foreign agent address announced in the Agent Advertisement, the
   mobile node may register that foreign agent care-of address with its
   home agent [9].  
"

Not only this, BUT you also make another great claim without demonstrating
HOW!!!
"
   For mobile nodes that cannot process a NAI, or with mobility agents
   that are not configured to advertise their NAI, regional registration
   is still useful, but the lack of certain features may result in less
   than optimal results.
"

On the other hand, it seems that you assume that the whole network will 
be upgraded at the same time to accommodate your solution.

We are dealing with at least three different entities, MN, FA, and HA. you
added another one GFA.
There is a great absolute possibility that those entities do not belong to
the same operator.
Unless your draft addresses clearly how these entities would know what the
others support in reference
to what you are proposing or offering a smooth solution without violating
the existing entities,
there will continue to be backward compatibility issues and your first claim
is not justified.

I hope I made myself clear here in order to address these backward
compatibility issues.

Regards;
Ahmad Muhanna

> 
> 
> Hi,
> 
> you are right in all cases, but it only matters in one case 
> in my opinion. 
> It is the difficult balance between backwards compatibility 
> and optimisations.
> 
> That the GFA IP extension and zero CoA field is not backwards 
> compatible is 
> obvious, but this is an optimisation, since it is better for 
> the visited 
> network to be able to allocate GFA and CoA dynamically. I 
> think we should 
> allow this, but not as the only solution. That is why I would 
> like to keep 
> the possibility for the MN to include the CoA address in my answer to 
> Alan's suggestions.
> 
> The first issue that you bring up is more critical, namely 
> what happens if 
> a HA doesn't support these new extensions? The 
> "UNSUPPORTED_EXTENSION" 
> doesn't exist, as you say. So the HA will probably answer 
> with e.g.  128 
> reason unspecified, or 129 administratively prohibited , or 
> 134 poorly 
> formed Request. We should correct this, and clarify that if 
> the MN receives 
> such a reply, it should try to send a new registration using 
> the advertised 
> CoA.
> 
> /Annika
> 
> 
> 
> At 22:35 2002-04-21 -0500, Ahmad Muhanna wrote:
> 
> >Well, me too. I am not sure what I was doing in 1998.
> >
> >I believe the scope of this discussion is really absolutely too late.
> >However, I would like to continue to raise technical issues about
> >this draft which mostly related to backward compatibility.
> >
> >In section 4.4: Home Agent Considerations:
> >
> >Issue No. 1:
> >"
> >    A Registration Request that does not contain a GFA IP Address
> >    extension or a Replay Protection Style extension is processed
> >    by the home agent as described in [9].  If the home agent
> >    receives a Registration Request with one of these extensions,
> >    and the home agent does not support the extension, the home
> >    agent must return a Registration Reply with the Code value set to
> >    UNSUPPORTED_EXTENSION [9].
> >"
> >
> >This section mandates that a legacy HA rejects any 
> Registration Request which
> >contains a GFA IP Address extension or a Replay Protection 
> Style extension 
> >with
> >an error code of UNSUPPORTED_EXTENSION. Where is the 
> backward compatibility
> >here. Also, it references RFC3220 while RFC3220 does not 
> have an error 
> >code of
> >UNSUPPORTED_EXTENSION.!!!
> >
> >Issue No. 2:
> >"
> >    If a home agent receives a Registration
> >    Request message with the care-of address set to zero, and a GFA
> >    IP Address extension, it MUST register the IP address of the GFA
> >    as the care-of address of the mobile node in its mobility binding
> >    list.
> >"
> >
> >This section also mandates that a legacy HA to accept a 
> Registration Request
> >with Care-of Address set to zero and a GFA IP Address 
> extension and to 
> >include
> >the GFA IP address as the care-of address in the binding table.
> >Is this backward compatible solution!!!!!
> >
> >Issue No. 3:
> >"
> >If a home agent
> >    receives a Registration Request message with the care-of 
> address set
> >    to zero, but no GFA IP Address extension, it MUST deny 
> the request
> >    by sending a Registration Reply message with the Code 
> field set to
> >    ZERO_CAREOF_ADDRESS (see section 8.4).
> >"
> >
> >This section also mandates that a legacy HA rejects a 
> Registration Request
> >which contains a care-of address field of zero by sending a 
> Registration 
> >Reply
> >message with error code of ZERO_CAREOF_ADDRESS.
> >Again, where is the backward compatibility here or we are 
> asking all carriers
> >to update their HAs in order to be standard compliant by not 
> supporting this
> >feature!!!
> >
> >I hope that there is someone out there who have an answer 
> for these issues.
> >
> >Regards;
> >Ahmad Muhanna
> >
> >
> 
> 

------_=_NextPart_001_01C1EA31.EA46F360
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] RE: [mobile-imp] WG Last Call: draft-ietf-mobileip-reg-tunnel-06. txt




Hi Annika;




You are proposing a solution for a specific problem. 

You are making this great claim that this solution supports existing Mobile IPv4 implementation. 




"

   Foreign agents that support regional registrations are also required

   to support registrations according to Mobile IPv4 [9].  If there is

   a foreign agent address announced in the Agent Advertisement, the

   mobile node may register that foreign agent care-of address with its

   home agent [9].  

"




Not only this, BUT you also make another great claim without demonstrating HOW!!!

"

   For mobile nodes that cannot process a NAI, or with mobility agents

   that are not configured to advertise their NAI, regional registration

   is still useful, but the lack of certain features may result in less

   than optimal results.

"




On the other hand, it seems that you assume that the whole network will 

be upgraded at the same time to accommodate your solution.




We are dealing with at least three different entities, MN, FA, and HA. you added another one GFA.

There is a great absolute possibility that those entities do not belong to the same operator.

Unless your draft addresses clearly how these entities would know what the others support in reference

to what you are proposing or offering a smooth solution without violating the existing entities,

there will continue to be backward compatibility issues and your first claim is not justified.




I hope I made myself clear here in order to address these backward compatibility issues.




Regards;

Ahmad Muhanna




> 

> 

> Hi,

> 

> you are right in all cases, but it only matters in one case 

> in my opinion. 

> It is the difficult balance between backwards compatibility 

> and optimisations.

> 

> That the GFA IP extension and zero CoA field is not backwards 

> compatible is 

> obvious, but this is an optimisation, since it is better for 

> the visited 

> network to be able to allocate GFA and CoA dynamically. I 

> think we should 

> allow this, but not as the only solution. That is why I would 

> like to keep 

> the possibility for the MN to include the CoA address in my answer to 

> Alan's suggestions.

> 

> The first issue that you bring up is more critical, namely 

> what happens if 

> a HA doesn't support these new extensions? The 

> "UNSUPPORTED_EXTENSION" 

> doesn't exist, as you say. So the HA will probably answer 

> with e.g.  128 

> reason unspecified, or 129 administratively prohibited , or 

> 134 poorly 

> formed Request. We should correct this, and clarify that if 

> the MN receives 

> such a reply, it should try to send a new registration using 

> the advertised 

> CoA.

> 

> /Annika

> 

> 

> 

> At 22:35 2002-04-21 -0500, Ahmad Muhanna wrote:

> 

> >Well, me too. I am not sure what I was doing in 1998.

> >

> >I believe the scope of this discussion is really absolutely too late.

> >However, I would like to continue to raise technical issues about

> >this draft which mostly related to backward compatibility.

> >

> >In section 4.4: Home Agent Considerations:

> >

> >Issue No. 1:

> >"

> >    A Registration Request that does not contain a GFA IP Address

> >    extension or a Replay Protection Style extension is processed

> >    by the home agent as described in [9].  If the home agent

> >    receives a Registration Request with one of these extensions,

> >    and the home agent does not support the extension, the home

> >    agent must return a Registration Reply with the Code value set to

> >    UNSUPPORTED_EXTENSION [9].

> >"

> >

> >This section mandates that a legacy HA rejects any 

> Registration Request which

> >contains a GFA IP Address extension or a Replay Protection 

> Style extension 

> >with

> >an error code of UNSUPPORTED_EXTENSION. Where is the 

> backward compatibility

> >here. Also, it references RFC3220 while RFC3220 does not 

> have an error 

> >code of

> >UNSUPPORTED_EXTENSION.!!!

> >

> >Issue No. 2:

> >"

> >    If a home agent receives a Registration

> >    Request message with the care-of address set to zero, and a GFA

> >    IP Address extension, it MUST register the IP address of the GFA

> >    as the care-of address of the mobile node in its mobility binding

> >    list.

> >"

> >

> >This section also mandates that a legacy HA to accept a 

> Registration Request

> >with Care-of Address set to zero and a GFA IP Address 

> extension and to 

> >include

> >the GFA IP address as the care-of address in the binding table.

> >Is this backward compatible solution!!!!!

> >

> >Issue No. 3:

> >"

> >If a home agent

> >    receives a Registration Request message with the care-of 

> address set

> >    to zero, but no GFA IP Address extension, it MUST deny 

> the request

> >    by sending a Registration Reply message with the Code 

> field set to

> >    ZERO_CAREOF_ADDRESS (see section 8.4).

> >"

> >

> >This section also mandates that a legacy HA rejects a 

> Registration Request

> >which contains a care-of address field of zero by sending a 

> Registration 

> >Reply

> >message with error code of ZERO_CAREOF_ADDRESS.

> >Again, where is the backward compatibility here or we are 

> asking all carriers

> >to update their HAs in order to be standard compliant by not 

> supporting this

> >feature!!!

> >

> >I hope that there is someone out there who have an answer 

> for these issues.

> >

> >Regards;

> >Ahmad Muhanna

> >

> >

> 

> 





------_=_NextPart_001_01C1EA31.EA46F360--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 15:49:38 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10501
	for ; Mon, 22 Apr 2002 15:49:37 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00843;
	Mon, 22 Apr 2002 13:49:38 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00511;
	Mon, 22 Apr 2002 12:49:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJmZGs007135
	for ; Mon, 22 Apr 2002 12:48:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MJmZqS007134
	for mobile-ip-dist; Mon, 22 Apr 2002 12:48:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJmVGs007127
	for ; Mon, 22 Apr 2002 12:48:31 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00134
	for ; Mon, 22 Apr 2002 12:48:32 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00346
	for ; Mon, 22 Apr 2002 13:48:32 -0600 (MDT)
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 MAA13639;
	Mon, 22 Apr 2002 12:48:31 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MJmUC23383;
	Mon, 22 Apr 2002 12:48:30 -0700
X-mProtect: <200204221948> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdYcfOCe; Mon, 22 Apr 2002 12:48:29 PDT
Message-ID: <3CC4690D.CDC4AD30@iprg.nokia.com>
Date: Mon, 22 Apr 2002 12:48:29 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Ahmad Muhanna 
CC: "'Annika Jonsson'" ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RE: [mobile-imp] WG Last Call: 
 draft-ietf-mobileip-reg-tunnel-06. txt
References: <6B49EDFE974BD51197D70002A56079D801AFCC18@zrc2c013.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Ahmad,

I'll try to make some answers here.

> You are proposing a solution for a specific problem.
> You are making this great claim that this solution supports existing Mobile
> IPv4 implementation.
> 
> "
>    Foreign agents that support regional registrations are also required
>    to support registrations according to Mobile IPv4 [9].  If there is
>    a foreign agent address announced in the Agent Advertisement, the
>    mobile node may register that foreign agent care-of address with its
>    home agent [9].
> "

This is O.K., right?  What does it mean, "great claim"?

> Not only this, BUT you also make another great claim without demonstrating
> HOW!!!
> "
>    For mobile nodes that cannot process a NAI, or with mobility agents
>    that are not configured to advertise their NAI, regional registration
>    is still useful, but the lack of certain features may result in less
>    than optimal results.
> "

If the mobile node cannot process NAI, then it can still do regional
registration.  Why not?  Also, isn't it better to write down where
additional configuration at the mobility agents can help to get the
best results?  I think it's better to fully explain as much as possible
here.


> On the other hand, it seems that you assume that the whole network will
> be upgraded at the same time to accommodate your solution.

Not true!  It is possible to mix regional foreign agents with regular
foreign agents, and so on.

> We are dealing with at least three different entities, MN, FA, and HA. you
> added another one GFA.

Well, if you don't have a GFA, then you don't have regional registration.
Do you mean to suggest otherwise?

> There is a great absolute possibility that those entities do not belong to the
> same operator.
> Unless your draft addresses clearly how these entities would know what the
> others support in reference
> to what you are proposing or offering a smooth solution without violating the
> existing entities,
> there will continue to be backward compatibility issues and your first claim
> is not justified.

As far as I can remember, regional registration has been targeted mainly
at domains (regions) operated by the same operator.  Maybe there are
more considerations with multi-operator domain, but that really was not
on our radar.

> I hope I made myself clear here in order to address these backward
> compatibility issues.

I think that the places where new features are enabled by mechanism that
is not able to be parsed by RFC 3220 mobile nodes should not necessarily
be given as examples of the lack of backward compatibility.  Mobile nodes
that don't do regional registrations should be able to be served by
foreign agents that do offer regional registrations in addtion to
home registrations.  I am not aware of a place in the draft that would
make this untrue.

Mobile nodes that wish to use regional registration with foreign agents
that do not support it, will not succeed.  Mobile nodes that wish to use
zero care-of addresses with home agents that do not support it, will
not succeed.  Mobile nodes that cannot use advertisements unless the
advertisement contains a care-of address, cannot register with a
foreign agent that does not offer a care-of address.  These are not
examples of backward incompatibility.  After all, to take the latter
case, if the foreign agent doesn't offer a care-of address, it just
is not running RFC3220, presumably for some good reason from the
perspective of the local operator.  The mobile node that only run
RFC3220 should just cannot use that foreign agent.

We have attempted to preserve backwards compatibility, while allowing
the regional registration to offer new features and thus extend to
scenarios where RFC 3220 would not work anyway.  That has to be
considered O.K.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 15:54:59 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10747
	for ; Mon, 22 Apr 2002 15:54:58 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23362;
	Mon, 22 Apr 2002 13:54:55 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02983;
	Mon, 22 Apr 2002 12:54:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJrtGs007232
	for ; Mon, 22 Apr 2002 12:53:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MJrsZ3007231
	for mobile-ip-dist; Mon, 22 Apr 2002 12:53:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJrpGs007224
	for ; Mon, 22 Apr 2002 12:53:51 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20772
	for ; Mon, 22 Apr 2002 12:53:53 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20529
	for ; Mon, 22 Apr 2002 12:53:52 -0700 (PDT)
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3MJrll01009;
	Mon, 22 Apr 2002 14:53:47 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3MJrlc00255;
	Mon, 22 Apr 2002 14:53:47 -0500 (CDT)
Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA23392; Mon, 22 Apr 2002 14:53:47 -0500 (CDT)
Received: from ericsson.com ([138.85.159.114])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA24320;
	Mon, 22 Apr 2002 14:53:46 -0500 (CDT)
Message-ID: <3CC4698B.931CBAF8@ericsson.com>
Date: Mon, 22 Apr 2002 12:50:35 -0700
From: Tony Johansson 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ahmad Muhanna 
CC: "'Fredrik Johansson'" ,
        mobile-ip@sunroof.eng.sun.com, fredrik@ipunplugged.com
Subject: Re: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
References: <6B49EDFE974BD51197D70002A56079D801AFCC12@zrc2c013.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Ahmad,

Ahmad Muhanna wrote:


> I do not think that It is the same!!
> RFC3012 introduced a new way of authenticating the MN to the FA
> without violating
> backward compatibility of RFC2002 or later RFC3220.
> Mobile Node does not know which way or the standard the foreign agent
> uses to
> authenticate it. It could be through RADIUS, AAA, Diameter who knows.

>
> The point here is that this draft mandates that every Mobile Node
> include AAA NAI extension
> with subtype of 1 whenever it requests static Mobile IP or during
> Inter-FA handoff.
> Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile Node which
> exist right now,
> does not do this.
> After this draft becomes a standard, according to this section, MN is
> not following the
> standard by not sending AAA NAI extension in initial Registration
> Request or during re-authentication.!!!
>
> This is not backward compatible!!!!

Okay, so how about adding the following statement to the introduction:

"The AAA NAI extension MUST only be used with the Diameter Mobile IPv4
application and MUST NOT be used with any other AAA protocol."



/Tony




From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 16:00:52 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10904
	for ; Mon, 22 Apr 2002 16:00:51 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23768;
	Mon, 22 Apr 2002 13:00:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06007;
	Mon, 22 Apr 2002 13:00:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJx2Gs007363
	for ; Mon, 22 Apr 2002 12:59:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MJx2BK007362
	for mobile-ip-dist; Mon, 22 Apr 2002 12:59:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MJwxGs007355
	for ; Mon, 22 Apr 2002 12:58:59 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05399
	for ; Mon, 22 Apr 2002 12:58:55 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05519
	for ; Mon, 22 Apr 2002 13:58:55 -0600 (MDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MJwrp20240;
	Mon, 22 Apr 2002 14:58:53 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2Y3TY2DZ>; Mon, 22 Apr 2002 14:58:50 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC1A@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Tony Johansson'" 
Cc: "'Fredrik Johansson'" ,
        mobile-ip@sunroof.eng.sun.com, fredrik@ipunplugged.com
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-
	00.txt
Date: Mon, 22 Apr 2002 14:58:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EA38.1975E730"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EA38.1975E730
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Tony;
YES; this solves the problem.

Regards;
Ahmad Muhanna


> -----Original Message-----
> From: Tony Johansson [mailto:tony.johansson@ericsson.com]
> Sent: Monday, April 22, 2002 2:51 PM
> To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
> Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
> fredrik@ipunplugged.com
> Subject: Re: [mobile-ip] RE: A Question
> about:draft-ietf-mobileip-aaa-nai-00.txt
> 
> 
> Hello Ahmad,
> 
> Ahmad Muhanna wrote:
> 
> 
> > I do not think that It is the same!!
> > RFC3012 introduced a new way of authenticating the MN to the FA
> > without violating
> > backward compatibility of RFC2002 or later RFC3220.
> > Mobile Node does not know which way or the standard the 
> foreign agent
> > uses to
> > authenticate it. It could be through RADIUS, AAA, Diameter 
> who knows.
> 
> >
> > The point here is that this draft mandates that every Mobile Node
> > include AAA NAI extension
> > with subtype of 1 whenever it requests static Mobile IP or during
> > Inter-FA handoff.
> > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile 
> Node which
> > exist right now,
> > does not do this.
> > After this draft becomes a standard, according to this 
> section, MN is
> > not following the
> > standard by not sending AAA NAI extension in initial Registration
> > Request or during re-authentication.!!!
> >
> > This is not backward compatible!!!!
> 
> Okay, so how about adding the following statement to the introduction:
> 
> "The AAA NAI extension MUST only be used with the Diameter Mobile IPv4
> application and MUST NOT be used with any other AAA protocol."
> 
> 
> 
> /Tony
> 
> 
> 

------_=_NextPart_001_01C1EA38.1975E730
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt




Hello Tony;

YES; this solves the problem.




Regards;

Ahmad Muhanna






> -----Original Message-----

> From: Tony Johansson [mailto:tony.johansson@ericsson.com]

> Sent: Monday, April 22, 2002 2:51 PM

> To: Muhanna, Ahmad [RICH1:2Q20:EXCH]

> Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;

> fredrik@ipunplugged.com

> Subject: Re: [mobile-ip] RE: A Question

> about:draft-ietf-mobileip-aaa-nai-00.txt

> 

> 

> Hello Ahmad,

> 

> Ahmad Muhanna wrote:

> 

> 

> > I do not think that It is the same!!

> > RFC3012 introduced a new way of authenticating the MN to the FA

> > without violating

> > backward compatibility of RFC2002 or later RFC3220.

> > Mobile Node does not know which way or the standard the 

> foreign agent

> > uses to

> > authenticate it. It could be through RADIUS, AAA, Diameter 

> who knows.

> 

> >

> > The point here is that this draft mandates that every Mobile Node

> > include AAA NAI extension

> > with subtype of 1 whenever it requests static Mobile IP or during

> > Inter-FA handoff.

> > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile 

> Node which

> > exist right now,

> > does not do this.

> > After this draft becomes a standard, according to this 

> section, MN is

> > not following the

> > standard by not sending AAA NAI extension in initial Registration

> > Request or during re-authentication.!!!

> >

> > This is not backward compatible!!!!

> 

> Okay, so how about adding the following statement to the introduction:

> 

> "The AAA NAI extension MUST only be used with the Diameter Mobile IPv4

> application and MUST NOT be used with any other AAA protocol."

> 

> 

> 

> /Tony

> 

> 

> 





------_=_NextPart_001_01C1EA38.1975E730--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 17:00:58 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12950
	for ; Mon, 22 Apr 2002 17:00:57 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00595;
	Mon, 22 Apr 2002 14:00:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03490;
	Mon, 22 Apr 2002 14:00:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MKxLGs007646
	for ; Mon, 22 Apr 2002 13:59:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MKxLHL007645
	for mobile-ip-dist; Mon, 22 Apr 2002 13:59:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MKxHGs007638
	for ; Mon, 22 Apr 2002 13:59:17 -0700 (PDT)
Received: from onion.east.sun.com (onion [129.148.174.110])
	by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3MKxHg25222
	for ; Mon, 22 Apr 2002 16:59:17 -0400 (EDT)
Date: Mon, 22 Apr 2002 17:00:16 -0400 (EDT)
From: "Steven M. Glass" 
Reply-To: "Steven M. Glass" 
Subject: [mobile-ip] Minor list problem 'details'
To: mobile-ip@sunroof.eng.sun.com
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

    There seems to have been at least one hickup in the distribution of email
from ~10:32 to ~17:41 GMT, and perhaps an earlier hickup sometime between
~6:18 and ~10:32 GMT.  It appears, and I'm still verifying this for each
apparently affected email by careful study of the headers, that the emails
were queued, but not delivered until later, starting around 18:00 GMT.

    The bottom line is even though the messages weren't distributed promptly
there's no need to repost (though some reposts seem to have been made).  If
anyone posted something that didn't ultimately appear in the external archives:

        playground.sun.com/mobile-ip/WG-archives

    please let me know and I'll see if it's in our internal set of archives
(note: you don't [necessarily] get copies of your own posts)!

                              Cheers,
                                  Steve
                                  list-retentive



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 17:00:59 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12962
	for ; Mon, 22 Apr 2002 17:00:58 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00626;
	Mon, 22 Apr 2002 14:00:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03538;
	Mon, 22 Apr 2002 14:00:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MKxUGs007656
	for ; Mon, 22 Apr 2002 13:59:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MKxUdh007655
	for mobile-ip-dist; Mon, 22 Apr 2002 13:59:30 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MKxQGs007648
	for ; Mon, 22 Apr 2002 13:59:26 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23294
	for ; Mon, 22 Apr 2002 13:59:26 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29784
	for ; Mon, 22 Apr 2002 13:59:26 -0700 (PDT)
Message-ID: <009001c1ea40$505ea130$836015ac@T23KEMPF>
From: "James Kempf" 
To: "Karim El-Malki \(ERA\)" ,
        "Dana L. Blair" ,
        "Milind Kulkarni" ,
        "Madhavi W. Chandra" 
Cc: "Charles E. Perkins" ,
        
References: <795A014AF92DD21182AF0008C7A404320DFBF097@esealnt117>
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Mon, 22 Apr 2002 13:57:24 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> That's a bit of a biased comment isn't it?
> In particular there was more than one person who questioned
> your experiments.
>

Karim, we have collected data showing that it performs lousy on IS-2000
RAN and it performs about as good as standard MIP handoff optimized to
use a Link Up trigger and Posthandover Mobile Initiated Tunneling on
802.11. What more do you want? I'll be happy to send you the slides if
the IPCN people agree to allow me to republish them. And, if you want to
perform the experiments yourself, we can give you the description and
you can replicate them.

> >  In order to clarify the situation, the
>  > authors, WG
>  > chairs, and ADs have agreed to move it to experimental.
>
> This question wasn't posed to the WG. This is what I had asked when I
was
> informed that the fate of the low latency draft was being discussed in
a
> group which I believe you (James) were part of. Just to clarify, I
wasn't part
> of this decision process so I had little choice other than to agree.
>

My recollection was that Hesham asked this question in Minneapolis and I
agreed that this was what we had decided on. Are you suggesting now that
we not do this?

            jak



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 17:09:23 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13287
	for ; Mon, 22 Apr 2002 17:09:21 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00272;
	Mon, 22 Apr 2002 15:09:23 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08033;
	Mon, 22 Apr 2002 14:09:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ML8UGs007853
	for ; Mon, 22 Apr 2002 14:08:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ML8Tbb007852
	for mobile-ip-dist; Mon, 22 Apr 2002 14:08:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ML8QGs007845
	for ; Mon, 22 Apr 2002 14:08:26 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07744
	for ; Mon, 22 Apr 2002 14:08:26 -0700 (PDT)
Received: from hosting-network.com (NODE1.HOSTING-NETWORK.COM [66.216.6.1] (may be forged))
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA05339
	for ; Mon, 22 Apr 2002 14:08:26 -0700 (PDT)
Received: (qmail 17242 invoked from network); 22 Apr 2002 21:09:44 -0000
Received: from unknown (HELO dell8100rjm) (12.251.150.156)
  by node-28.hosting-network.com with SMTP; 22 Apr 2002 21:09:44 -0000
Reply-To: 
From: "Robert J Marks" 
To: "'Ahmad Muhanna'" ,
        "'Tony Johansson'" 
Cc: "'Fredrik Johansson'" ,
        , 
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
Date: Mon, 22 Apr 2002 16:05:26 -0500
Organization: Marks Mobile Consulting, LLC
Message-ID: <007a01c1ea41$6d720f90$6501a8c0@dell8100rjm>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_007B_01C1EA17.849C0790"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC1A@zrc2c013.us.nortel.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_007B_01C1EA17.849C0790
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Perhaps someone can explain how the MN knows the type of AAA
infrastructure used by the FA nd HA. I don't believe any information is
included in any advertisement. Does this "solution" rely only upon MN
configuration, or am I missing something here? Thanks.
 
Bob
 
-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna
Sent: Monday, April 22, 2002 1:59 PM
To: 'Tony Johansson'
Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
fredrik@ipunplugged.com
Subject: RE: [mobile-ip] RE: A Question
about:draft-ietf-mobileip-aaa-nai-00.txt



Hello Tony; 
YES; this solves the problem. 

Regards; 
Ahmad Muhanna 


> -----Original Message----- 
> From: Tony Johansson [mailto:tony.johansson@ericsson.com] 
> Sent: Monday, April 22, 2002 2:51 PM 
> To: Muhanna, Ahmad [RICH1:2Q20:EXCH] 
> Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> fredrik@ipunplugged.com 
> Subject: Re: [mobile-ip] RE: A Question 
> about:draft-ietf-mobileip-aaa-nai-00.txt 
> 
> 
> Hello Ahmad, 
> 
> Ahmad Muhanna wrote: 
> 
> 
> > I do not think that It is the same!! 
> > RFC3012 introduced a new way of authenticating the MN to the FA 
> > without violating 
> > backward compatibility of RFC2002 or later RFC3220. 
> > Mobile Node does not know which way or the standard the 
> foreign agent 
> > uses to 
> > authenticate it. It could be through RADIUS, AAA, Diameter 
> who knows. 
> 
> > 
> > The point here is that this draft mandates that every Mobile Node 
> > include AAA NAI extension 
> > with subtype of 1 whenever it requests static Mobile IP or during 
> > Inter-FA handoff. 
> > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile 
> Node which 
> > exist right now, 
> > does not do this. 
> > After this draft becomes a standard, according to this 
> section, MN is 
> > not following the 
> > standard by not sending AAA NAI extension in initial Registration 
> > Request or during re-authentication.!!! 
> > 
> > This is not backward compatible!!!! 
> 
> Okay, so how about adding the following statement to the introduction:

> 
> "The AAA NAI extension MUST only be used with the Diameter Mobile IPv4

> application and MUST NOT be used with any other AAA protocol." 
> 
> 
> 
> /Tony 
> 
> 
> 


------=_NextPart_000_007B_01C1EA17.849C0790
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




Message




Perhaps someone can explain how the MN knows the type of AAA=20
infrastructure used by the FA nd HA. I don't believe any information is =
included=20
in any advertisement. Does this "solution" rely only upon MN =
configuration, or=20
am I missing something here? Thanks.


 


Bob


 




-----Original Message-----
From:=20
owner-mobile-ip@sunroof.eng.sun.com =
[mailto:owner-mobile-ip@sunroof.eng.sun.com]=20
On Behalf Of Ahmad Muhanna
Sent: Monday, April 22, 2002 =
1:59=20
PM
To: 'Tony Johansson'
Cc: 'Fredrik Johansson';=20
mobile-ip@sunroof.eng.sun.com; =
fredrik@ipunplugged.com
Subject: RE:=20
[mobile-ip] RE: A Question=20
about:draft-ietf-mobileip-aaa-nai-00.txt



Hello Tony; 
YES; this solves =
the=20
problem. 


Regards; 
Ahmad =
Muhanna 



> -----Original Message----- 
>=20
From: Tony Johansson [mailto:tony.johansson@ericsso=
n.com]=20

> Sent: Monday, April 22, 2002 2:51 PM =

> To: Muhanna, Ahmad [RICH1:2Q20:EXCH] 
>=20
Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> fredrik@ipunplugged.com 
> =
Subject: Re:=20
[mobile-ip] RE: A Question 
>=20
about:draft-ietf-mobileip-aaa-nai-00.txt 
>=20

> 
> Hello =
Ahmad,=20

> 
> Ahmad Muhanna =
wrote:=20

> 
> 
>=20
> I do not think that It is the same!! 
> =
>=20
RFC3012 introduced a new way of authenticating the MN to the FA =

> > without violating 
> > =
backward=20
compatibility of RFC2002 or later RFC3220. 
> >=20
Mobile Node does not know which way or the standard the 
> foreign agent 
> > uses =
to=20

> > authenticate it. It could be through =
RADIUS, AAA,=20
Diameter 
> who knows. 
>=20

> > 
> > =
The point=20
here is that this draft mandates that every Mobile Node 
> > include AAA NAI extension 
> >=20
with subtype of 1 whenever it requests static Mobile IP or during =


> > Inter-FA handoff. 
> >=20
Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile =

> Node which 
> > exist right =
now,=20

> > does not do this. 
> >=20
After this draft becomes a standard, according to this 
> section, MN is 
> > not =
following=20
the 
> > standard by not sending AAA NAI =
extension=20
in initial Registration 
> > Request or =
during=20
re-authentication.!!! 
> > =

> > This is not backward compatible!!!! 
> 
> Okay, so how about adding =
the following=20
statement to the introduction: 
> =

> "The AAA NAI extension MUST only be used with the Diameter =
Mobile=20
IPv4 
> application and MUST NOT be used =
with any=20
other AAA protocol." 
> 
>=20

> 
> =
/Tony 
> 
> 
>=20



------=_NextPart_000_007B_01C1EA17.849C0790--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 17:19:01 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13591
	for ; Mon, 22 Apr 2002 17:19:01 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19266;
	Mon, 22 Apr 2002 15:18:58 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12464;
	Mon, 22 Apr 2002 14:18:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MLI8Gs007945
	for ; Mon, 22 Apr 2002 14:18:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MLI7eV007944
	for mobile-ip-dist; Mon, 22 Apr 2002 14:18:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MLI4Gs007937
	for ; Mon, 22 Apr 2002 14:18:04 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03877
	for ; Mon, 22 Apr 2002 14:18:04 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18793
	for ; Mon, 22 Apr 2002 15:18:04 -0600 (MDT)
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3MLI1l26013;
	Mon, 22 Apr 2002 16:18:01 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3MLI1c06562;
	Mon, 22 Apr 2002 16:18:01 -0500 (CDT)
Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA27134; Mon, 22 Apr 2002 16:18:00 -0500 (CDT)
Received: from ericsson.com (busam55.berkeley.us.am.ericsson.se [138.85.159.205])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA25765;
	Mon, 22 Apr 2002 16:17:56 -0500 (CDT)
Message-ID: <3CC47D42.B2F428CF@ericsson.com>
Date: Mon, 22 Apr 2002 14:14:42 -0700
From: Tony Johansson 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: bob@marksmob.com
CC: "'Ahmad Muhanna'" ,
        "'Fredrik Johansson'" ,
        mobile-ip@sunroof.eng.sun.com, fredrik@ipunplugged.com
Subject: Re: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
References: <007a01c1ea41$6d720f90$6501a8c0@dell8100rjm>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Bob,

Yes, it's based on MN configuration and FA configuration. Same as e.g
the handling of RFC3012/RFC3012bis and the
draft-ietf-mobileip-aaa-key-09.txt.

The advertisements will not tell you anything reading this.

/Tony

Robert J Marks wrote:

>  Perhaps someone can explain how the MN knows the type of AAA
> infrastructure used by the FA nd HA. I don't believe any information
> is included in any advertisement. Does this "solution" rely only upon
> MN configuration, or am I missing something here? Thanks.Bob
> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad
> Muhanna
> Sent: Monday, April 22, 2002 1:59 PM
> To: 'Tony Johansson'
> Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
> fredrik@ipunplugged.com
> Subject: RE: [mobile-ip] RE: A Question
> about:draft-ietf-mobileip-aaa-nai-00.txt
>
> Hello Tony;
> YES; this solves the problem.
>
> Regards;
> Ahmad Muhanna
>
> > -----Original Message-----
> > From: Tony Johansson [mailto:tony.johansson@ericsson.com]
> > Sent: Monday, April 22, 2002 2:51 PM
> > To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
> > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
> > fredrik@ipunplugged.com
> > Subject: Re: [mobile-ip] RE: A Question
> > about:draft-ietf-mobileip-aaa-nai-00.txt
> >
> >
> > Hello Ahmad,
> >
> > Ahmad Muhanna wrote:
> >
> >
> > > I do not think that It is the same!!
> > > RFC3012 introduced a new way of authenticating the MN to the FA
> > > without violating
> > > backward compatibility of RFC2002 or later RFC3220.
> > > Mobile Node does not know which way or the standard the
> > foreign agent
> > > uses to
> > > authenticate it. It could be through RADIUS, AAA, Diameter
> > who knows.
> >
> > >
> > > The point here is that this draft mandates that every Mobile Node
> > > include AAA NAI extension
> > > with subtype of 1 whenever it requests static Mobile IP or during
> > > Inter-FA handoff.
> > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile
> > Node which
> > > exist right now,
> > > does not do this.
> > > After this draft becomes a standard, according to this
> > section, MN is
> > > not following the
> > > standard by not sending AAA NAI extension in initial Registration
> > > Request or during re-authentication.!!!
> > >
> > > This is not backward compatible!!!!
> >
> > Okay, so how about adding the following statement to the
> introduction:
> >
> > "The AAA NAI extension MUST only be used with the Diameter Mobile
> IPv4
> > application and MUST NOT be used with any other AAA protocol."
> >
> >
> >
> > /Tony
> >
> >
> >



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 17:26:54 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14164
	for ; Mon, 22 Apr 2002 17:26:54 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23393;
	Mon, 22 Apr 2002 15:26:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16152;
	Mon, 22 Apr 2002 14:26:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MLQDGs008087
	for ; Mon, 22 Apr 2002 14:26:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MLQDG9008086
	for mobile-ip-dist; Mon, 22 Apr 2002 14:26:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MLQAGs008079
	for ; Mon, 22 Apr 2002 14:26:10 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15899
	for ; Mon, 22 Apr 2002 14:26:10 -0700 (PDT)
Received: from hosting-network.com (NODE1.HOSTING-NETWORK.COM [66.216.6.1] (may be forged))
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA22955
	for ; Mon, 22 Apr 2002 15:26:09 -0600 (MDT)
Received: (qmail 20317 invoked from network); 22 Apr 2002 21:27:29 -0000
Received: from unknown (HELO dell8100rjm) (12.251.150.156)
  by node-28.hosting-network.com with SMTP; 22 Apr 2002 21:27:29 -0000
Reply-To: 
From: "Robert J Marks" 
To: "'Tony Johansson'" 
Cc: "'Ahmad Muhanna'" ,
        "'Fredrik Johansson'" ,
        , 
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
Date: Mon, 22 Apr 2002 16:23:11 -0500
Organization: Marks Mobile Consulting, LLC
Message-ID: <008301c1ea43$e7f2ec10$6501a8c0@dell8100rjm>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CC47D42.B2F428CF@ericsson.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Thanks, Tony. 

However, considering that a MN will likely roam into many different
areas served by different FAs, how can it possibly be configured
correctly for all FAs?

I guess the answer must be that all FAs that the MN is likely to use
will support this, or else none will support this.

Bob

Tony Johansson wrote:

Hi Bob,

Yes, it's based on MN configuration and FA configuration. Same as e.g
the handling of RFC3012/RFC3012bis and the
draft-ietf-mobileip-aaa-key-09.txt.

The advertisements will not tell you anything reading this.

/Tony

Robert J Marks wrote:

>  Perhaps someone can explain how the MN knows the type of AAA
> infrastructure used by the FA nd HA. I don't believe any information
> is included in any advertisement. Does this "solution" rely only upon
> MN configuration, or am I missing something here? Thanks.Bob
> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad
> Muhanna
> Sent: Monday, April 22, 2002 1:59 PM
> To: 'Tony Johansson'
> Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
> fredrik@ipunplugged.com
> Subject: RE: [mobile-ip] RE: A Question
> about:draft-ietf-mobileip-aaa-nai-00.txt
>
> Hello Tony;
> YES; this solves the problem.
>
> Regards;
> Ahmad Muhanna
>
> > -----Original Message-----
> > From: Tony Johansson [mailto:tony.johansson@ericsson.com]
> > Sent: Monday, April 22, 2002 2:51 PM
> > To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
> > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
> > fredrik@ipunplugged.com
> > Subject: Re: [mobile-ip] RE: A Question
> > about:draft-ietf-mobileip-aaa-nai-00.txt
> >
> >
> > Hello Ahmad,
> >
> > Ahmad Muhanna wrote:
> >
> >
> > > I do not think that It is the same!!
> > > RFC3012 introduced a new way of authenticating the MN to the FA
> > > without violating
> > > backward compatibility of RFC2002 or later RFC3220.
> > > Mobile Node does not know which way or the standard the
> > foreign agent
> > > uses to
> > > authenticate it. It could be through RADIUS, AAA, Diameter
> > who knows.
> >
> > >
> > > The point here is that this draft mandates that every Mobile Node
> > > include AAA NAI extension
> > > with subtype of 1 whenever it requests static Mobile IP or during
> > > Inter-FA handoff.
> > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile
> > Node which
> > > exist right now,
> > > does not do this.
> > > After this draft becomes a standard, according to this
> > section, MN is
> > > not following the
> > > standard by not sending AAA NAI extension in initial Registration
> > > Request or during re-authentication.!!!
> > >
> > > This is not backward compatible!!!!
> >
> > Okay, so how about adding the following statement to the
> introduction:
> >
> > "The AAA NAI extension MUST only be used with the Diameter Mobile
> IPv4
> > application and MUST NOT be used with any other AAA protocol."
> >
> >
> >
> > /Tony
> >
> >
> >




From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 17:39:24 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14927
	for ; Mon, 22 Apr 2002 17:39:23 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21633;
	Mon, 22 Apr 2002 14:38:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22646;
	Mon, 22 Apr 2002 14:38:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MLc6Gs008227
	for ; Mon, 22 Apr 2002 14:38:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MLc6sS008226
	for mobile-ip-dist; Mon, 22 Apr 2002 14:38:06 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MLc3Gs008219
	for ; Mon, 22 Apr 2002 14:38:03 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08110
	for ; Mon, 22 Apr 2002 14:38:03 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21147
	for ; Mon, 22 Apr 2002 14:38:03 -0700 (PDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MLc2p24359;
	Mon, 22 Apr 2002 16:38:02 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2Y3TYK6Y>; Mon, 22 Apr 2002 16:37:59 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC1B@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Tony Johansson'" , bob@marksmob.com
Cc: "'Fredrik Johansson'" ,
        mobile-ip@sunroof.eng.sun.com, fredrik@ipunplugged.com
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-
	00.txt
Date: Mon, 22 Apr 2002 16:37:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EA45.F4C1A920"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EA45.F4C1A920
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Bob;

Let me add to what Tony just said.
I do not think that any MN needs to know anything about the type
of AAA infrastructure the FA and HA are using to authenticate the MN.
However, the MN Application is developed with certain standard in mind. 
(certain method of authentication)

for example:
1. ONLY RFC2002 Compliant MN:
It assumes that it has a security association with both the FA and the
HA. If it visit any FA where it shares a security association with, MN sends
RRQ message with MN-FA Authentication extension and it works just fine.

2. ONLY RFC2002 & RFC3012 Compliant MN:

RFC 3012 addressed properly the case of MN in 1 but offered a new
mechanism for authenticating the MN to the FA using the FA Challenge
and MN-AAA authentication extension.

3. Now Latest MN with all of the above (RFC3220) and diameter compliant:
MN includes AAA NAI extension and those FA which support diameter 
will use process it and those FA which does not support AAA NAI (skippable)
will continue to use either method in 2 or 1.


Regards;
Ahmad Muhanna


> -----Original Message-----
> From: Tony Johansson [mailto:tony.johansson@ericsson.com]
> Sent: Monday, April 22, 2002 4:15 PM
> To: bob@marksmob.com
> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Fredrik Johansson';
> mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com
> Subject: Re: [mobile-ip] RE: A Question
> about:draft-ietf-mobileip-aaa-nai-00.txt
> 
> 
> Hi Bob,
> 
> Yes, it's based on MN configuration and FA configuration. Same as e.g
> the handling of RFC3012/RFC3012bis and the
> draft-ietf-mobileip-aaa-key-09.txt.
> 
> The advertisements will not tell you anything reading this.
> 
> /Tony
> 
> Robert J Marks wrote:
> 
> >  Perhaps someone can explain how the MN knows the type of AAA
> > infrastructure used by the FA nd HA. I don't believe any information
> > is included in any advertisement. Does this "solution" rely 
> only upon
> > MN configuration, or am I missing something here? Thanks.Bob
> > -----Original Message-----
> > From: owner-mobile-ip@sunroof.eng.sun.com
> > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad
> > Muhanna
> > Sent: Monday, April 22, 2002 1:59 PM
> > To: 'Tony Johansson'
> > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
> > fredrik@ipunplugged.com
> > Subject: RE: [mobile-ip] RE: A Question
> > about:draft-ietf-mobileip-aaa-nai-00.txt
> >
> > Hello Tony;
> > YES; this solves the problem.
> >
> > Regards;
> > Ahmad Muhanna
> >
> > > -----Original Message-----
> > > From: Tony Johansson [mailto:tony.johansson@ericsson.com]
> > > Sent: Monday, April 22, 2002 2:51 PM
> > > To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
> > > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
> > > fredrik@ipunplugged.com
> > > Subject: Re: [mobile-ip] RE: A Question
> > > about:draft-ietf-mobileip-aaa-nai-00.txt
> > >
> > >
> > > Hello Ahmad,
> > >
> > > Ahmad Muhanna wrote:
> > >
> > >
> > > > I do not think that It is the same!!
> > > > RFC3012 introduced a new way of authenticating the MN to the FA
> > > > without violating
> > > > backward compatibility of RFC2002 or later RFC3220.
> > > > Mobile Node does not know which way or the standard the
> > > foreign agent
> > > > uses to
> > > > authenticate it. It could be through RADIUS, AAA, Diameter
> > > who knows.
> > >
> > > >
> > > > The point here is that this draft mandates that every 
> Mobile Node
> > > > include AAA NAI extension
> > > > with subtype of 1 whenever it requests static Mobile IP 
> or during
> > > > Inter-FA handoff.
> > > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile
> > > Node which
> > > > exist right now,
> > > > does not do this.
> > > > After this draft becomes a standard, according to this
> > > section, MN is
> > > > not following the
> > > > standard by not sending AAA NAI extension in initial 
> Registration
> > > > Request or during re-authentication.!!!
> > > >
> > > > This is not backward compatible!!!!
> > >
> > > Okay, so how about adding the following statement to the
> > introduction:
> > >
> > > "The AAA NAI extension MUST only be used with the Diameter Mobile
> > IPv4
> > > application and MUST NOT be used with any other AAA protocol."
> > >
> > >
> > >
> > > /Tony
> > >
> > >
> > >
> 
> 

------_=_NextPart_001_01C1EA45.F4C1A920
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt




Hi Bob;




Let me add to what Tony just said.

I do not think that any MN needs to know anything about the type

of AAA infrastructure the FA and HA are using to authenticate the MN.

However, the MN Application is developed with certain standard in mind. 

(certain method of authentication)




for example:

1. ONLY RFC2002 Compliant MN:

It assumes that it has a security association with both the FA and the

HA. If it visit any FA where it shares a security association with, MN sends

RRQ message with MN-FA Authentication extension and it works just fine.




2. ONLY RFC2002 & RFC3012 Compliant MN:




RFC 3012 addressed properly the case of MN in 1 but offered a new

mechanism for authenticating the MN to the FA using the FA Challenge

and MN-AAA authentication extension.




3. Now Latest MN with all of the above (RFC3220) and diameter compliant:

MN includes AAA NAI extension and those FA which support diameter 

will use process it and those FA which does not support AAA NAI (skippable)

will continue to use either method in 2 or 1.






Regards;

Ahmad Muhanna






> -----Original Message-----

> From: Tony Johansson [mailto:tony.johansson@ericsson.com]

> Sent: Monday, April 22, 2002 4:15 PM

> To: bob@marksmob.com

> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Fredrik Johansson';

> mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com

> Subject: Re: [mobile-ip] RE: A Question

> about:draft-ietf-mobileip-aaa-nai-00.txt

> 

> 

> Hi Bob,

> 

> Yes, it's based on MN configuration and FA configuration. Same as e.g

> the handling of RFC3012/RFC3012bis and the

> draft-ietf-mobileip-aaa-key-09.txt.

> 

> The advertisements will not tell you anything reading this.

> 

> /Tony

> 

> Robert J Marks wrote:

> 

> >  Perhaps someone can explain how the MN knows the type of AAA

> > infrastructure used by the FA nd HA. I don't believe any information

> > is included in any advertisement. Does this "solution" rely 

> only upon

> > MN configuration, or am I missing something here? Thanks.Bob

> > -----Original Message-----

> > From: owner-mobile-ip@sunroof.eng.sun.com

> > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad

> > Muhanna

> > Sent: Monday, April 22, 2002 1:59 PM

> > To: 'Tony Johansson'

> > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;

> > fredrik@ipunplugged.com

> > Subject: RE: [mobile-ip] RE: A Question

> > about:draft-ietf-mobileip-aaa-nai-00.txt

> >

> > Hello Tony;

> > YES; this solves the problem.

> >

> > Regards;

> > Ahmad Muhanna

> >

> > > -----Original Message-----

> > > From: Tony Johansson [mailto:tony.johansson@ericsson.com]

> > > Sent: Monday, April 22, 2002 2:51 PM

> > > To: Muhanna, Ahmad [RICH1:2Q20:EXCH]

> > > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;

> > > fredrik@ipunplugged.com

> > > Subject: Re: [mobile-ip] RE: A Question

> > > about:draft-ietf-mobileip-aaa-nai-00.txt

> > >

> > >

> > > Hello Ahmad,

> > >

> > > Ahmad Muhanna wrote:

> > >

> > >

> > > > I do not think that It is the same!!

> > > > RFC3012 introduced a new way of authenticating the MN to the FA

> > > > without violating

> > > > backward compatibility of RFC2002 or later RFC3220.

> > > > Mobile Node does not know which way or the standard the

> > > foreign agent

> > > > uses to

> > > > authenticate it. It could be through RADIUS, AAA, Diameter

> > > who knows.

> > >

> > > >

> > > > The point here is that this draft mandates that every 

> Mobile Node

> > > > include AAA NAI extension

> > > > with subtype of 1 whenever it requests static Mobile IP 

> or during

> > > > Inter-FA handoff.

> > > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile

> > > Node which

> > > > exist right now,

> > > > does not do this.

> > > > After this draft becomes a standard, according to this

> > > section, MN is

> > > > not following the

> > > > standard by not sending AAA NAI extension in initial 

> Registration

> > > > Request or during re-authentication.!!!

> > > >

> > > > This is not backward compatible!!!!

> > >

> > > Okay, so how about adding the following statement to the

> > introduction:

> > >

> > > "The AAA NAI extension MUST only be used with the Diameter Mobile

> > IPv4

> > > application and MUST NOT be used with any other AAA protocol."

> > >

> > >

> > >

> > > /Tony

> > >

> > >

> > >

> 

> 





------_=_NextPart_001_01C1EA45.F4C1A920--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 17:55:12 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15888
	for ; Mon, 22 Apr 2002 17:55:11 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08419;
	Mon, 22 Apr 2002 15:55:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01048;
	Mon, 22 Apr 2002 14:55:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MLsLGs008404
	for ; Mon, 22 Apr 2002 14:54:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MLsLmb008403
	for mobile-ip-dist; Mon, 22 Apr 2002 14:54:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MLsHGs008396
	for ; Mon, 22 Apr 2002 14:54:18 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00644
	for ; Mon, 22 Apr 2002 14:54:18 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04051
	for ; Mon, 22 Apr 2002 15:54:17 -0600 (MDT)
Received: from tom by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian))
	id 16zll0-0007Yl-00; Tue, 23 Apr 2002 00:53:58 +0300
Date: Tue, 23 Apr 2002 00:53:58 +0300
From: Tom K Weckstrom 
To: James Kempf 
Cc: "Dana L. Blair" , Milind Kulkarni ,
        "Madhavi W. Chandra" ,
        "Charles E. Perkins" ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Message-ID: <20020422215357.GP12913@muminmamman.lifix.fi>
References:  <00e601c1ea1d$a067c170$8e6015ac@T23KEMPF>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <00e601c1ea1d$a067c170$8e6015ac@T23KEMPF>
User-Agent: Mutt/1.3.25i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Hello, all.

I join this thread rather late - it's 2002-04-23 here, but 2002-04-22
still somewhere on this globe, so I didn't miss the deadline,
right. ;)

On Mon, Apr 22, 2002 at 09:49:04AM -0700, James Kempf wrote:
> 
> As for draft-ietf-mobileip-reg-tunnel-06.txt, I'm curious how many
> people are really going to implement it. Is there any interest in
> 3GPP2 in it?
---end quoted text---

I have been working around the regional registration, localised
mobility management, etc. since 1998 first in the Dynamics group and
later on at Lifix Systems and YES, we are still interested in
implementing the standard for regional registrations, especially, if
we can change it a bit before it gets to RFC. ;)

Dynamics group has implemented the regional registrations into the
current Dynamics - HUT Mobile IP implementation after a rather long
research and trial period. The protocol is definitely not identical to
the current proposal available in
draft-ietf-mobileip-reg-tunnel-06.txt. Please, read Jouni Malinen's
thesis from
http://www.cs.hut.fi/Research/Dynamics/publications/jkmaline_thesis.ps.gz to understand how Dynamics does regional registrations.

Lifix Systems is willing to move from the "Dynamics type" regional
registrations protocol to an RFC compliant solution, if we can agree
on the protocol to be standardised. We have good experiences on
localising the mobility management and also research results are
available.

More comments to follow.

Regards,
	Tom


-- 
Tom Weckström                   PGP id:  E1DB55E9
Lifix Systems Oy        Mobile: +358 50 350 5997
Yliopistonkatu 5       3rd floor               FIN-00100 Helsinki


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 18:05:21 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16288
	for ; Mon, 22 Apr 2002 18:05:21 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14840;
	Mon, 22 Apr 2002 16:05:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06903;
	Mon, 22 Apr 2002 15:05:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MM4AGs008506
	for ; Mon, 22 Apr 2002 15:04:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MM4Aag008505
	for mobile-ip-dist; Mon, 22 Apr 2002 15:04:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MM47Gs008498
	for ; Mon, 22 Apr 2002 15:04:07 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09240
	for ; Mon, 22 Apr 2002 18:04:07 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA11617
	for mobile-ip@sunroof.eng.sun.com; Mon, 22 Apr 2002 18:05:06 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3KInhGs000635
	for ; Sat, 20 Apr 2002 11:49:43 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07595
	for ; Sat, 20 Apr 2002 08:10:57 -0700 (PDT)
Received: from babbage.csee.usf.edu (babbage.csee.usf.edu [131.247.3.2])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18023
	for ; Sat, 20 Apr 2002 08:10:56 -0700 (PDT)
Received: from KJC.csee.usf.edu (kjc [131.247.3.42])
	by babbage.csee.usf.edu (8.9.3/8.9.3) with ESMTP id KAA04287;
	Sat, 20 Apr 2002 10:47:43 -0400 (EDT)
Message-Id: <5.1.0.14.2.20020420103707.00b55f18@babbage.csee.usf.edu>
X-Sender: christen@babbage.csee.usf.edu
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 20 Apr 2002 10:44:38 -0400
To: christen@csee.usf.edu
From: Ken Christensen 
Subject: [mobile-ip] Call for Papers - Workshop on High-Speed Local Networks (HSLN)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
                            CALL FOR PAPERS
              Workshop on High-Speed Local Networks (HSLN)
                   as part of the IEEE LCN conference
                      http://www.hcs.ufl.edu/hsln
                        http://www.ieeelcn.org

                          November 6 - 8, 2002
                   Embassy Suites USF, Tampa, Florida

Important dates and contact:
----------------------------
   Paper submission: June 10, 2002
   Notification of acceptance: July 15, 2002
   Camera-ready copy due: August 16, 2002
   General Chair: Alan D. George (george@hcs.ufl.edu)

General Information:
--------------------
The High-Speed Local Networks (HSLN) workshop, within the 27th IEEE
Conference on Local Computer Networks (LCN), focuses on the design,
analysis, implementation, and exploitation of new concepts, techno-
logies, and applications related to high-performance networks on a
local scale.  This workshop will bring together networking researchers,
engineers, and practitioners from across the spectrum of high-speed
local networks, with participants from industry, academia, and
government.  Original papers that present research results, case
studies, technology development or deployment experience, work in
progress, etc. are solicited, as are survey articles.

Specific areas of interest include (but are not limited to):
- High-speed LANs (e.g. Gigabit Ethernet, 10 Gigabit Ethernet)
- System-area networks (e.g. SCI, Myrinet, ServerNet)
- Storage-area networks (e.g. Fibre Channel) and I/O interconnects
- High-speed networks in embedded systems (e.g. avionics, space systems)
- Protocols, services, and topologies for high-speed local networks
- Routing and switch architectures for high-speed local networks
- Quality of Service (QoS) in high-speed local networks
- Performance analysis of high-speed local networks and systems
- Modeling and simulation of high-speed local networks
- Middleware for high-speed local network communication
- Applications for high-speed local networks (e.g. video on demand)

Paper Submission Instructions:
------------------------------
Authors are invited to submit papers of up to ten camera-ready pages,
in PDF or Postscript format, for presentation at the workshop and
publication in the conference proceedings.  Papers should be
submitted by email to the workshop at hsln@hcs.ufl.edu on or before
June 10, 2002.  Alternatively, send five hard copies via postal mail
to:

   Dr. Alan D. George
   HSLN General Chair
   Department of Electrical and Computer Engineering
   University of Florida
   PO Box 116200, 327 Larsen Hall
   Gainesville, FL 32611-6200

HSLN Organizing Committee:
--------------------------
Workshop Chair:      Industry Chair:               Program Chair:
A.D. George          J.L. Meier                    K.J. Christensen
ECE Department       Advanced Technology Center    CSE Department
Univ of Florida      Rockwell Collins, Inc.        Univ of South Florida
george@hcs.ufl.edu   jlmeier@rockwellcollins.com   christen@csee.usf.edu

HSLN Program Committee:
-----------------------

Jay Bragg (awbragg@yahoo.com)
Consultant

Ron Brightwell (bright@cs.sandia.gov)
Sandia National Labs, NM

Wayne Chang (wchang@arl.army.mil)
Army Research Laboratory

Helen Chen (hycsw@california.sandia.gov)
Sandia National Labs, CA

Patrick W. Dowd (dowd@lts.ncsc.mil)
University of Maryland at College Park and U.S. Department of Defense
College Park, MD

Mike Foster (michael.s.foster@boeing.com)
Boeing Corporation

Michael A. Hoard (hoardm@us.ibm.com)
IBM
Beaverton, OR

Cynthia S. Hood (hood@iit.edu)
Illinois Institute of Technology
Chicago, IL

Anestis Karasaridis (karasaridis@att.com)
Network Design and Performance Analysis Dept.
AT&T Labs, Middletown, NJ

Fred Kuhns (fredk@arl.wustl.edu)
Washington University
St. Louis, MO

Michael McKee (mckee026@umn.edu)
University of Minnesota, Rochester
Rochester, MN

Knut Omang (knuto@fast.no)
University of Oslo
Oslo, Norway

Sarp Oral (oral@hcs.ufl.edu)
University of Florida
Gainesville, FL

D. K. Panda (panda@cis.ohio-state.edu)
Ohio State University
Columbus, OH

Anthony Skjellum (tony@MPI-SoftTech.Com)
Mississippi State University
Starkville, MS

Norm Strole (ncstrole@us.ibm.com)
IBM
Research Triangle Park, NC

Rollins Turner (rturner@paradyne.com)
Paradyne Corporation
Largo, FL

William White (wwhite@siue.edu)
Southern Illinois University
Edwardsville, IL

Tim Wilcox (tim.wilcox@dolphinics.com)
Technical Director, Dolphin Interconnect

---




From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 18:09:39 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16390
	for ; Mon, 22 Apr 2002 18:09:38 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08607;
	Mon, 22 Apr 2002 15:09:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08964;
	Mon, 22 Apr 2002 15:09:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MM7lGs008612
	for ; Mon, 22 Apr 2002 15:07:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MM7ltZ008611
	for mobile-ip-dist; Mon, 22 Apr 2002 15:07:47 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MM7ZGs008601
	for ; Mon, 22 Apr 2002 15:07:35 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10103
	for ; Mon, 22 Apr 2002 18:07:28 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA11631
	for mobile-ip@sunroof.eng.sun.com; Mon, 22 Apr 2002 18:08:27 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3M7CgGs003192;
	Mon, 22 Apr 2002 00:12:42 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21866;
	Mon, 22 Apr 2002 00:12:14 -0700 (PDT)
Received: from nero.informatik.uni-wuerzburg.de (wi3x05.informatik.uni-wuerzburg.de [132.187.106.5])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13402;
	Mon, 22 Apr 2002 00:12:12 -0700 (PDT)
Received: from PROMETHEUS (prometheus.informatik.uni-wuerzburg.de [132.187.106.139])
	by nero.informatik.uni-wuerzburg.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with SMTP id g3M786P07465;
	Mon, 22 Apr 2002 09:08:06 +0200
Message-ID: <003a01c1e9cd$66769720$8b6abb84@PROMETHEUS>
From: "Kurt Tutschku" 
To: "mpls \(ietf\)" , "sigtran \(ietf\)" ,
        "end2end \(irtf\)" ,
        "ITC list" , "nsis \(ietf\)" ,
        "cost 279" ,
        "ppvpn \(ietf\)" ,
        "ITG Fachtagung Messung, Modellierung und Bewertung" ,
        "ITG 524" ,
        "ITG 523" ,
        "ITG 521" ,
        "cost 257" ,
        "Onno Boxma" ,
        "Joachim Charzinski" ,
        "Jon Crowcroft" ,
        "Christophe Diot" ,
        "Serge Fdida" ,
        "Anja Feldmann" ,
        "Markus Fiedler" ,
        "Richard Harris" ,
        "Gunnar Karlsson" ,
        "Konosuke Kawashima" ,
        "Edward Knightly" ,
        "Udo Krieger" ,
        =?iso-8859-1?Q?Paul_K=FChn?= ,
        "Guy Latouche" ,
        "Ralf Lehnert" ,
        "Debasis Mitra" ,
        "Sandor Molnar" ,
        "Ilkka Norros" , "Vern Paxson" ,
        "Michal Pioro" ,
        "Jennifer Rexford" ,
        "James Roberts" ,
        "Hideaki Takagi" ,
        "Don Townsley" ,
        "Jorma Virtamo" ,
        "Patricia Wirth" ,
        "ipo \(ietf\)" ,
        "tewg \(ietf\)" ,
        "ippm \(ietf\)" ,
        "mobileip \(ietf\)" ,
        "manet \(ietf\)" ,
        "nmrg \(irtf\)" ,
        "rr \(irtf\)" ,
        "ccamp \(ietf\)" ,
        "ipv6 \(ietf\)" ,
        "disman \(ietf\)" ,
        =?iso-8859-1?Q?Paul_Schl=FCter?= ,
        "Notker Gerlich" ,
        "Hans Schwefel" ,
        "Thomas Reim" ,
        "Stefan Schneeberger" ,
        "Michael Schopp" ,
        "Franz Hartleb" ,
        "Klaus Dolzer" ,
        "Bart Sanders" ,
        =?iso-8859-1?Q?Michael_S=F6llner?= ,
        "Wolfgang Wagner" ,
        "Walter Leonhardt" ,
        "Norbert Rauh" ,
        =?iso-8859-1?Q?Silvia_Sch=E4ffler?= ,
        "Wolfgang Stegmann" ,
        "Andreas Lamsa" ,
        "Karl Heinz Allgeyer" ,
        "Lothar Lux" ,
        =?iso-8859-1?Q?Bernd_Schr=F6der?= ,
        "Albert Weller" ,
        =?iso-8859-1?Q?J=FCrgen_Tenckhoff?= ,
        "Norbert Schultze" ,
        =?iso-8859-1?Q?Norbert_Schl=FCter?= ,
        "Laslo Slawitschka" ,
        "Gabriel Zgunea" ,
        "Bernhard Liesenfeld" ,
        =?iso-8859-1?Q?J=FCrgen_Beyer?= ,
        "Zhongrong Liu" ,
        "Bernd Pfeiffer" ,
        "Hans Barth" ,
        "Wolf Mende" ,
        "Wolfgang Urmoneit" ,
        "Dieter Marger" ,
        "Charles E. Perkins" ,
        "Ake Arvidsson" ,
        =?iso-8859-1?Q?Angelika_M=FCller?= ,
        "Armin Heindl" ,
        "Bo Friis Nielsen" ,
        "Holger Hermanns" ,
        "Jacques Resing" ,
        "Jose Brazio" ,
        "Stephen Hanly" ,
        "Matthew Roughan" ,
        "Reinhard German" ,
        "Rudolf Mathar" ,
        "Ulrich Herzog" ,
        "Dieter Baum" ,
        "Lothar Breuer" ,
        "Marie-Ange Remiche" ,
        "Markus Siegle" ,
        "Nikhil Jain" ,
        "Peter Taylor" ,
        "Sem Borst" ,
        "Ute Kohlhaas" 
Subject: [mobile-ip] ITC Specialist seminar: full paper submission deadline extended
Date: Mon, 22 Apr 2002 09:14:29 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0037_01C1E9DE.1B8754F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01C1E9DE.1B8754F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear colleagues,

due to multiple requests, the full paper submission deadline was =
extended to Friday, April 26th. Late papers can still be submitted at:

http://vitus.informatik.uni-wuerzburg.de:8080/submit.html.


For more information about the 15th ITC Specialist Seminar, please visit =
our homepage at

http://www.itcspecialistseminar.com


Best Regards
Phuoc Tran-Gia (Seminar Co-Chair)
Jim Roberts    (Seminar Co-Chair)
Kurt Tutschku  (Organizing Committee Chair)


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
Phuoc Tran-Gia
Professor, Chair, Distributed Systems
Computer Science, University of Wuerzburg
Am Hubland, D-97074 Wuerzburg, Germany
Tel.: +49-931-8886630 , Fax.: +49-931-8886632
mailto:trangia@informatik.uni-wuerzburg.de
www: http://www-info3.informatik.uni-wuerzburg.de
Phuoc Tran-Gia
CEO, infosim Networking Solutions AG
Sedanstr. 27, D-97082 Wuerzburg, Germany
mailto:trangia@infosim.net
www: http://www.infosim.net

------=_NextPart_000_0037_01C1E9DE.1B8754F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear colleagues,


 


due to multiple requests, the full =
paper=20
submission deadline was extended to Friday, April 26th. Late papers can =
still be=20
submitted at:


 


http://vitus.informatik.uni-wuerzburg.de:8080/submit.html=
.


 


 


For more information about the 15th =
ITC=20
Specialist Seminar, please visit our homepage at


 



 


 


Best Regards
Phuoc Tran-Gia =
(Seminar=20
Co-Chair)
Jim Roberts    (Seminar Co-Chair)
Kurt=20
Tutschku  (Organizing Committee=20
Chair)


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Phuoc=20
Tran-Gia
Professor, Chair, Distributed Systems
Computer Science,=20
University of Wuerzburg
Am Hubland, D-97074 Wuerzburg, =
Germany
Tel.:=20
+49-931-8886630 , Fax.: +49-931-8886632
mailto:trangia@informatik.uni-wuerzburg.de
www: http://www-info3.informatik.uni-wuerzburg.de
Phuoc Tran-Gia
CEO, infosim Networking =
Solutions=20
AG
Sedanstr. 27, D-97082 Wuerzburg, Germany
mailto:trangia@infosim.net
www:=20
http://www.infosim.net


------=_NextPart_000_0037_01C1E9DE.1B8754F0--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 18:31:31 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16818
	for ; Mon, 22 Apr 2002 18:31:30 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15253;
	Mon, 22 Apr 2002 15:31:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18311;
	Mon, 22 Apr 2002 15:31:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MMUXGs008865
	for ; Mon, 22 Apr 2002 15:30:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MMUXJs008864
	for mobile-ip-dist; Mon, 22 Apr 2002 15:30:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MMULGs008857
	for ; Mon, 22 Apr 2002 15:30:21 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26473
	for ; Mon, 22 Apr 2002 15:30:22 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18187
	for ; Mon, 22 Apr 2002 15:30:22 -0700 (PDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MMQRp06632;
	Mon, 22 Apr 2002 17:26:27 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2Y3TYLXS>; Mon, 22 Apr 2002 17:26:25 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC1C@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Charles E. Perkins'" 
Cc: "'Annika Jonsson'" ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] RE: [mobile-imp] WG Last Call:  draft-ietf-mobile
	ip-reg-tunnel-06. txt
Date: Mon, 22 Apr 2002 17:26:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EA4C.B7F93060"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EA4C.B7F93060
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Charlie;

I still believe that those backward compatibility issues
have not been answered YET.
I will compile another response which includes all issues at once.

Regards;
Ahmad Muhanna

> 
> Hello Ahmad,
> 
> I'll try to make some answers here.
> 
> > You are proposing a solution for a specific problem.
> > You are making this great claim that this solution supports 
> existing Mobile
> > IPv4 implementation.
> > 
> > "
> >    Foreign agents that support regional registrations are 
> also required
> >    to support registrations according to Mobile IPv4 [9].  
> If there is
> >    a foreign agent address announced in the Agent Advertisement, the
> >    mobile node may register that foreign agent care-of 
> address with its
> >    home agent [9].
> > "
> 
> This is O.K., right?  What does it mean, "great claim"?
> 
> > Not only this, BUT you also make another great claim 
> without demonstrating
> > HOW!!!
> > "
> >    For mobile nodes that cannot process a NAI, or with 
> mobility agents
> >    that are not configured to advertise their NAI, regional 
> registration
> >    is still useful, but the lack of certain features may 
> result in less
> >    than optimal results.
> > "
> 
> If the mobile node cannot process NAI, then it can still do regional
> registration.  Why not?  Also, isn't it better to write down where
> additional configuration at the mobility agents can help to get the
> best results?  I think it's better to fully explain as much 
> as possible
> here.
> 
> 
> > On the other hand, it seems that you assume that the whole 
> network will
> > be upgraded at the same time to accommodate your solution.
> 
> Not true!  It is possible to mix regional foreign agents with regular
> foreign agents, and so on.
> 
> > We are dealing with at least three different entities, MN, 
> FA, and HA. you
> > added another one GFA.
> 
> Well, if you don't have a GFA, then you don't have regional 
> registration.
> Do you mean to suggest otherwise?
> 
> > There is a great absolute possibility that those entities 
> do not belong to the
> > same operator.
> > Unless your draft addresses clearly how these entities 
> would know what the
> > others support in reference
> > to what you are proposing or offering a smooth solution 
> without violating the
> > existing entities,
> > there will continue to be backward compatibility issues and 
> your first claim
> > is not justified.
> 
> As far as I can remember, regional registration has been 
> targeted mainly
> at domains (regions) operated by the same operator.  Maybe there are
> more considerations with multi-operator domain, but that 
> really was not
> on our radar.
> 
> > I hope I made myself clear here in order to address these backward
> > compatibility issues.
> 
> I think that the places where new features are enabled by 
> mechanism that
> is not able to be parsed by RFC 3220 mobile nodes should not 
> necessarily
> be given as examples of the lack of backward compatibility.  
> Mobile nodes
> that don't do regional registrations should be able to be served by
> foreign agents that do offer regional registrations in addtion to
> home registrations.  I am not aware of a place in the draft that would
> make this untrue.
> 
> Mobile nodes that wish to use regional registration with 
> foreign agents
> that do not support it, will not succeed.  Mobile nodes that 
> wish to use
> zero care-of addresses with home agents that do not support it, will
> not succeed.  Mobile nodes that cannot use advertisements unless the
> advertisement contains a care-of address, cannot register with a
> foreign agent that does not offer a care-of address.  These are not
> examples of backward incompatibility.  After all, to take the latter
> case, if the foreign agent doesn't offer a care-of address, it just
> is not running RFC3220, presumably for some good reason from the
> perspective of the local operator.  The mobile node that only run
> RFC3220 should just cannot use that foreign agent.
> 
> We have attempted to preserve backwards compatibility, while allowing
> the regional registration to offer new features and thus extend to
> scenarios where RFC 3220 would not work anyway.  That has to be
> considered O.K.
> 
> Regards,
> Charlie P.
> 

------_=_NextPart_001_01C1EA4C.B7F93060
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] RE: [mobile-imp] WG Last Call:  draft-ietf-mobileip-reg-tunnel-06. txt




Hello Charlie;




I still believe that those backward compatibility issues

have not been answered YET.

I will compile another response which includes all issues at once.




Regards;

Ahmad Muhanna




> 

> Hello Ahmad,

> 

> I'll try to make some answers here.

> 

> > You are proposing a solution for a specific problem.

> > You are making this great claim that this solution supports 

> existing Mobile

> > IPv4 implementation.

> > 

> > "

> >    Foreign agents that support regional registrations are 

> also required

> >    to support registrations according to Mobile IPv4 [9].  

> If there is

> >    a foreign agent address announced in the Agent Advertisement, the

> >    mobile node may register that foreign agent care-of 

> address with its

> >    home agent [9].

> > "

> 

> This is O.K., right?  What does it mean, "great claim"?

> 

> > Not only this, BUT you also make another great claim 

> without demonstrating

> > HOW!!!

> > "

> >    For mobile nodes that cannot process a NAI, or with 

> mobility agents

> >    that are not configured to advertise their NAI, regional 

> registration

> >    is still useful, but the lack of certain features may 

> result in less

> >    than optimal results.

> > "

> 

> If the mobile node cannot process NAI, then it can still do regional

> registration.  Why not?  Also, isn't it better to write down where

> additional configuration at the mobility agents can help to get the

> best results?  I think it's better to fully explain as much 

> as possible

> here.

> 

> 

> > On the other hand, it seems that you assume that the whole 

> network will

> > be upgraded at the same time to accommodate your solution.

> 

> Not true!  It is possible to mix regional foreign agents with regular

> foreign agents, and so on.

> 

> > We are dealing with at least three different entities, MN, 

> FA, and HA. you

> > added another one GFA.

> 

> Well, if you don't have a GFA, then you don't have regional 

> registration.

> Do you mean to suggest otherwise?

> 

> > There is a great absolute possibility that those entities 

> do not belong to the

> > same operator.

> > Unless your draft addresses clearly how these entities 

> would know what the

> > others support in reference

> > to what you are proposing or offering a smooth solution 

> without violating the

> > existing entities,

> > there will continue to be backward compatibility issues and 

> your first claim

> > is not justified.

> 

> As far as I can remember, regional registration has been 

> targeted mainly

> at domains (regions) operated by the same operator.  Maybe there are

> more considerations with multi-operator domain, but that 

> really was not

> on our radar.

> 

> > I hope I made myself clear here in order to address these backward

> > compatibility issues.

> 

> I think that the places where new features are enabled by 

> mechanism that

> is not able to be parsed by RFC 3220 mobile nodes should not 

> necessarily

> be given as examples of the lack of backward compatibility.  

> Mobile nodes

> that don't do regional registrations should be able to be served by

> foreign agents that do offer regional registrations in addtion to

> home registrations.  I am not aware of a place in the draft that would

> make this untrue.

> 

> Mobile nodes that wish to use regional registration with 

> foreign agents

> that do not support it, will not succeed.  Mobile nodes that 

> wish to use

> zero care-of addresses with home agents that do not support it, will

> not succeed.  Mobile nodes that cannot use advertisements unless the

> advertisement contains a care-of address, cannot register with a

> foreign agent that does not offer a care-of address.  These are not

> examples of backward incompatibility.  After all, to take the latter

> case, if the foreign agent doesn't offer a care-of address, it just

> is not running RFC3220, presumably for some good reason from the

> perspective of the local operator.  The mobile node that only run

> RFC3220 should just cannot use that foreign agent.

> 

> We have attempted to preserve backwards compatibility, while allowing

> the regional registration to offer new features and thus extend to

> scenarios where RFC 3220 would not work anyway.  That has to be

> considered O.K.

> 

> Regards,

> Charlie P.

> 





------_=_NextPart_001_01C1EA4C.B7F93060--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 19:17:53 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17596
	for ; Mon, 22 Apr 2002 19:17:53 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05028;
	Mon, 22 Apr 2002 16:17:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07523;
	Mon, 22 Apr 2002 16:17:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MNGNGs009012
	for ; Mon, 22 Apr 2002 16:16:24 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MNGNcC009011
	for mobile-ip-dist; Mon, 22 Apr 2002 16:16:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MNGIGs009004
	for ; Mon, 22 Apr 2002 16:16:21 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18852
	for ; Mon, 22 Apr 2002 19:16:12 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11810
	for mobile-ip@sunroof.eng.sun.com; Mon, 22 Apr 2002 19:17:10 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MMmjGs008972
	for ; Mon, 22 Apr 2002 15:48:45 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02075
	for ; Mon, 22 Apr 2002 15:48:46 -0700 (PDT)
Received: from bscmail1.bionetrix.com (bscmail1.bionetrix.com [63.98.170.4])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23035
	for ; Mon, 22 Apr 2002 15:48:46 -0700 (PDT)
Received: by bscmail1.bionetrix.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 22 Apr 2002 18:52:59 -0400
Message-ID: 
From: Bikram Bakshi 
To: Bikram Bakshi 
Subject: [mobile-ip] Call For Papers: LCN  2002 - The 27th Annual IEEE Local Computer 
	Networks Conference
Date: Mon, 22 Apr 2002 18:52:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

------------------------------------------------------
 Our apologies if you have received multiple copies.
------------------------------------------------------

                             LCN 2002
                 The 27th Annual IEEE Conference on
                   Local Computer Networks (LCN)
                       http://www.ieeelcn.org

                          Tampa, Florida
                        November 6-8, 2002

               Sponsored by the IEEE Computer Society
                with support from the University of 
               South Florida College of Engineering.

                         CALL FOR PAPERS

The IEEE LCN conference is the premier conference on leading
edge and practical computer networking. We encourage
you to submit original papers describing research results or
practical solutions. Paper topics include, but are not limited
to:

Personal Area Networks           High Speed Networks
Wearable Networks                Network Management
Wireless Networks                Network Security
Always On / Always Connected     Network Reliability
Mobility Management              Network to the Home
Location-dependant services      QOS/Congestion Control
Local Area Networks              Adaptive Applications
Home Networks                    Anything-over-IP
Small Office Networks            IP-over-Anything
Storage Area Networks            Performance Eval./Measurements
Optical Networks                 Protocol Design and Validation

Authors are invited to submit full or short papers for
presentation at the conference. Full papers (no more than 10
camera-ready pages) should present novel perspectives within
the general scope of the conference. Short papers are an
opportunity to present preliminary or interim results and are
limited to 2 camera-ready pages in length. A best paper will
be selected based on the quality of research and results, as
well as on the quality of presentation by the primary author.
Several student travel scholarships may be available courtesy
of the LCN corporate supporters.  All papers must include title,
complete contact information for all authors, abstract, and
keywords on the cover page. The correspondence author must be
clearly identified.

PAPER SUBMISSION:
Papers must be submitted electronically. Manuscript submission
instructions can be found at http://lcn2002.cs.bonn.edu/.
Authors for whom electronic submission presents a severe
problem should contact the program chair or co-chair:

Bikram Bakshi                    Prof. Dr. Burkhard Stiller
BioNetrix Systems Inc.           ETH Zurich, TIK
1953 Gallows Road                Gloriastrasse 35
Vienna, VA 22182                 CH-8092 Zurich, Switzerland
E-mail: bbakshi@bionetrix.com    E-mail: stiller@tik.ee.ethz.ch

IMPORTANT DATES:
Paper submission deadline: May 17, 2002
Notification of acceptance: July 15, 2002
Camera-ready paper due: August 16, 2002
Author registration deadline: August 16, 2002

FOR MORE INFORMATION:
Please visit the conference website http://www.ieeelcn.org


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 19:50:16 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18431
	for ; Mon, 22 Apr 2002 19:50:15 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17749;
	Mon, 22 Apr 2002 16:49:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21298;
	Mon, 22 Apr 2002 16:49:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MNmXGs009205
	for ; Mon, 22 Apr 2002 16:48:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MNmXL2009204
	for mobile-ip-dist; Mon, 22 Apr 2002 16:48:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MNmUGs009197
	for ; Mon, 22 Apr 2002 16:48:30 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23890
	for ; Mon, 22 Apr 2002 16:48:32 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27892
	for ; Mon, 22 Apr 2002 17:48:30 -0600 (MDT)
Received: from tom by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian))
	id 16znXp-0001Zo-00; Tue, 23 Apr 2002 02:48:29 +0300
Date: Tue, 23 Apr 2002 02:48:29 +0300
From: Tom K Weckstrom 
To: mobile-ip@sunroof.eng.sun.com
Cc: Tom K Weckstrom 
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Message-ID: <20020422234829.GT12913@muminmamman.lifix.fi>
References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020422223042.GQ12913@muminmamman.lifix.fi>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="VxBmi9VgMIlnmxn8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20020422223042.GQ12913@muminmamman.lifix.fi>
User-Agent: Mutt/1.3.25i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--VxBmi9VgMIlnmxn8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello all.

My previous attempt with all the old emails did not pass the mailing
list policies (the email was over 40kB). I'll now retry with some
reduced amount of text.

On Mon, Apr 08, 2002 at 03:30:37PM -0500, Basavaraj.Patil@nokia.com wrote:
>
> This is a WG last call for: Mobile IP Regional Registration -
> draft-ietf-mobileip-reg-tunnel-06.txt
> This draft is a standards track WG document.
>
> Please send in your comments by April 22nd, 2002 to the authors or
> to the WG discussion list.
---end quoted text---

I have read through the draft-ietf-mobileip-reg-tunnel-06.txt and have
a multitude of comments. Some of them I see in the v06 last call
thread already, some of them I mentioned in my previous email
regarding the last call of version 03 of this same draft in October
2000. Unfortunately, the playgorund's MIP archives only go back to
2001-02, so I had to include my previous concerns to this email. Some,
but only a few, of my concerns from 2000-10 have been corrected. The
authors did give justifications for the solution back in 2000, but I
still have open questions regarding the solution. For some issues I
noticed in 2000, I would not be so strict with my comments any
more. The attached emails are for a "small" history study. I'll soon
send my v06 comments in another email.

Regards, Tom

-- 
Tom Weckström                   PGP id:  E1DB55E9
Lifix Systems Oy        Mobile: +358 50 350 5997
Yliopistonkatu 5       3rd floor               FIN-00100 Helsinki

















--VxBmi9VgMIlnmxn8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="2000-10-21.txt"
Content-Transfer-Encoding: 8bit

From tweckstr@cc.hut.fi Sat Oct 21 23:55:10 2000
Date: Sat, 21 Oct 2000 23:55:08 +0300
To: Satwant Kaur 
CC: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] WG Last Call-(draft-ietf-mobileip-reg-tunnel-03.txt)


Hi,

In my opinion, additional messages makes the protocol partly clearer,
but partly more complex.

Here are my questions (please point me to the appropriate messages, if
these questions have already been discussed :)

- Is it possible/needed that a FA does not know the GFA or GFAs above
it?
I think FAs and GFAs should have trust relationships = knowledge of
each other.

- Why do we need to add intelligence to the mobile node?
Having a totally transparent hierarchy is possible. The MN would speak
standard RFC2002 MIP and would still get the best efficiency in
registrations through the regionalized handoffs. By defining new
messages we do add intelligence to MN. It must know what kind of
registrations to send.

And my totally subjective opinion:
  ;-)
Despite the lively discussion about regionalized handoffs etc., I
still have not seen many transparent, fast and *implemented*
approaches. If the ideas in the drafts have been implemented, please
provide the community some links to the material. Dynamics  - HUT
Mobile IP has been rocking for 1.5 years now. Dynamics is transparent
to the Mobile Node and still provides fast handoffs.

Should we write a competing draft? ;-) We didn't do it in the first
place because we felt it would just slow down the fast handoff design
process. Unfortunately the process has been unbelievably slow. I am
really looking forward to a solution in this issue.

Regards,
	Tom

-- 
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                dynamics@cs.hut.fi
				http://www.cs.hut.fi/Research/Dynamics/


Satwant Kaur wrote:
> 
> Hello,
> 
> I am implementing the Regional Registration
> (draft-ietf-mobileip-reg-tunnel-03.txt), and I agree with Annika that it is
> important for FA and GFA to be able to make the distinction between the Home
> Registration Request (type 1) and Regional Registration Request (type 2)
> messages. Furthermore, the mobility Agents should also be able to make a
> distinction between Registration Reply (type 3) and Regional registration
> reply (type 4).
> 
> Another case where a similar problem would arise:
> 
> Suppose MN wants to do Home Registration with a FA who does not advertise
> itself. MN wants to be assigned a GFA and so it sends a Home Registration
> Request (type 1) with careof field as 0, and HA address in the Home Agent
> field.
> 
> Now, if we do not have additional message types to be able to make a
> distinction between type 1 and type 2 Registration requests, the FA will
> have no way of knowing if (1) It is a home Registration with MN asking to be
> assigned a GFA for home Registration, or (2) It is a Regional Registration
> (with FA set to 0, since FA did not advertise itself).
> 
> FA can (mis)interpret it as type 2 message. It will incorrectly assume that
> the HA address is really the GFA that the MN wants to register with. It will
> then forward the request to its HA address under the assumption it is really
> the GFA, instead of assigning a GFA address, and forwarding the registration
> to the assigned GFA.
> 
> The above problem arose since FA reads the registration requests sent by MN,
> and forwards them to GFA. In the absence of the message type that would
> enable FA to make a distinction between home registration request (type 1)
> and regional registration request (type 2), the FA does not know where to
> send the request to. The GFA address lies in the Home Agent field in case of
> type 2 and in the careof field in case of type 1 message. If the additional
> type 2 message is not there, FA cannot make the distinction between Home Vs
> Regional Registration Request.
> 
> Similar problems will arise at GFA level, since when the GFA reads the
> Registration Requests sent out by FA, and either forwards them to HA (in
> case of Home Registration) or sends the reply back to FA (in case of
> Regional Registration). If the type 2 message type is not there, GFA cannot
> make the distinction between Home and Regional Registration. And it would
> not know whether to send it forward to HA, or to send reply back to FA.
> 
> Similar problems will also arise on the way back for Registration Reply
> messages at FA and GFA, if type 4 is not present.
> 
> Apart from the problems in the above special cases, I also do not favor
> using anything other than message types to understand what type of
> registration /registration reply it is. The reason is if one uses some other
> characteristics of the packets (in this case, the extensions) other than its
> "type" to identify the type of packets, it is against the spirit of
> assigning the right job to the right field. It may also give us grief down
> the road as it would restrict our freedom to use extensions in different and
> more creative ways in future.


--VxBmi9VgMIlnmxn8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="2000-10-25.txt"
Content-Transfer-Encoding: 8bit

Date: 	Wed, 25 Oct 2000 02:02:19 +0300
From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" 
To: Charlie Perkins 
CC: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM,
        Annika Jonsson 
Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt)

Hello Charlie,

Here comes my lengthy comments about reg-tunnel-03. Sorry for a long
email, but there were lots of things to comment.
I hope the ASCII graphics is not distorted.
I found quite many issues.
Some of them might be possible to solve with more explanations (maybe
I just did not get the ideas). Some of the issues should be solved in
other ways. More ideas below. Read on.

Regards,
	Tom


COMMENTS TO draft-ietf-mobileip-reg-tunnel-03.txt

Tom Weckström

Legend:
+ = A positive note
- = A negative note, criticism
? = A question
! = Exclamation, either a critical issue or an important suggestion
idea
--> = conclusion mark

Ch 1.
+ Decision power at MN: regional or home registration possible
? Is it always good to let the MN deicde what kind of registration to
use?
? What are the benefits in giving the MN the right to decide?

- Different registration types makes the protocol more complex
  - Changes to std RFC2002 MN
  - Changes to FAs

Ch 3.1
? Is there a possibility to make a HA hierarchy as well?
  If not, why then?
--> Possibly another draft. Could be derived from J.K.Malinen's
thesis.

3.1.1.
? Why only assume two levels of FAs in the visited domain?

? Is the protocol fully flexible in its current form to support
N-level hierarchies? It should be. More comments after Appendix B.

"We assume that there exist established
   security associations between a GFA and the regional foreign
   agents beneath it."
---> This implies the RFAs HAVE to know their GFA.
---> Satwant Kaur's scenario with RFA not knowing the GFA is
impossible.
---> No need for different message types for regional and home
registration.
---> More transparency and simpleness achieved.

3.3.

" If the `I' bit is set, there MUST be at least one care-of address in
the Agent Advertisement message."
"If the `I' bit is set, and there is only one care-of address, it is
   the address of the GFA."
---> If so, there cannot be a situation where GFA is not known at the
     moment of registration. (Provided the address is real, not zero.)

---> The text could be clarified to mention about the relationships of
     the FAs in the hierarchy. Do they all know each other? Do they
     only know who's above and who's below them?.


3.4.1.

+ Setting GFA IP to zero improves flexibility.

"If the `I' bit is set, but the GFA
   address is zero (0), the mobile node MUST check to make sure that
it
   receives a GFA IP address extension as part of any home
registration,
   or else send its home registration using the care-of address of
some
   previously known GFA in the same visited domain."

? This makes the possible topologies more cumbersome.
---> Eg. GFA1, ..., GFA4 are all connected to RFA1 and RFA2 and RFA3
and RFA4.
? Why is this needed? For load balancing type of activities?

? Does the possibility to set GFA address to zero in the request open
new holes in the security?  E.g. Mallory acts as an additional GFA in
the hierarchy and captures MN's reg.reg. coming from RFA1. This gives
a possibility to intrude as a GFA into MIP signaling. However,
additional bonuses are few. And eventually Mallory could set up his
own ISP.

3.4.2.

" If the care-of address field is set to zero, the foreign agent
   assigns a GFA to the mobile node, by some means not described in
   this specification, and adds a GFA IP Address extension to the
   Registration Request message."

? RFA selects the GFA? RFA has no knowledge of GFA conditions (load,
etc.). How could an RFA make the decision? This could be solved with
the topology or by other means, but involves more protocol
intelligence anyway and whence adds to complexity.


"and it SHOULD be protected by an FA-FA Authentication extension."
? Where is FA-FA auth ext described? In another draft, I suppose.


3.5.1.

" it is necessary to distinguish regional registrations from home
   registration.  Thus, we introduce new message types for the
   Regional Registration messages."

? Could we make the distinction by defining that every registration
with a valid MN-FA auth ext is a regional registration? Furthermore,
if there is no MN-FA auth ext or if that extension is invalid, the FAs
forward the message upwards in the hierarchy.
Example: Consider an N-level hierarchy. See image below:

                                 ------
                                 | HA |
                                 ------
                                   |
                               (Internet)
                                   |
                                -------
                                | GFA |
                                -------
                              /         \
                      -------             -------
                      | FA1 |             | FA2 |
                      -------             -------
                       /   \               /   \
                 -------   -------   -------   -------
                 | FA3 |   | FA4 |   | FA5 |   | FA6 |
                 -------   -------   -------   -------
                                  \
                                   \
                                 ------
                                 | MN |
                                 ------

                  Figure 1: Mobility Agent Hierarchy


! Now, if MN is registered to FA4 and changes to FA6, then it sends
the
registration request to FA6 and FA6 does not know the MN-FA auth ext
in the registration neither has it heard of MN before (no mobility
bindings existing for MN). Then FA6 jsut forwards the request upwards
to FA2. FA2 also does not have a clue about MN, so it too forwards the
request upwards. Finally, GFA knows the MN from its bindings and also
can validate the MN-FA auth ext. Eventually, this registration became
regional. Now, if there were no MN-FA auth ext, or if it was invalid,
also the GFA would have forwarded the message - now to the HA.  Maybe
an invalid auth extensions should result in request denial if the MN
is known to the FA (i.e. there is a binding for the MN in the
FA). After all the MN is known, and the authentication does not match.

! Anyway, there seems to be no need for separate regional and home
registration messages. The MN still has the choice to either include
the FA-MN auth ext or leave it away.

! NOTE, that this is directly applicable to N-level hierarchies!


3.5.2.

" The only difference is that there is the GFA IP address instead of
   the address of the home agent."

? Does this mean that the Home Agent field in the RFC2002 compliant
registration request field has the IP addr of GFA? Section
6.1. verified this assumption. This could be more clearly stated
already in section 3.5.2.



4.2.

"By comparing the domain part of the foreign agent NAI with the domain
   part of its own NAI, the mobile node can determine whether it is in
   its home domain or in a visited domain, and whether it has changed
   domain since it last registered."

+ Exactly! Good. :)


6.1.


"
  GFA IP Address
      The IP address of the Gateway Foreign Agent.  (Replaces
       Home Agent field in Registration Request message
       in [9].)

      Care-of Address
                 Care-of address of local foreign agent; MAY be set to
                 zero.
"

? Why should the HA field be replaced? There is the COA field to
be used for the GFA IP addr. The FAs in the hierarchy can use
extensions or directly the source IP of the outer header to get the
address of the "lower" agent in the hierarchy as the registration
traverses upwards.

? Why is the COA field filled with the local COA?  The lowest FA
always knows behind which interface the MN is.  The FA aboe the lowest
FA knows the interface from which the first reg.request came and also
the IP of the lowest FA. This continues from the bottom of the FA tree
to the top, i.e., the GFA. ALL that is needed in MIP sense is the GFA
IP in the COA field and this is for the HA. The hierarchy of FAs
handles the tunneling in the hierarhcy by other means.




A.

" - a mobile node must be able to distinguish between regional
     registrations and home registrations, because when it uses
     regional registration, the nounces are not synchronized with its
     home agent;"

! Dynamics works with nonces also, and it supports regional
registrations. I have to find out how the nonce synchronization is
done in Dynamics. Perhaps the lack of FA-MN auth ext (again) is enough
for the MN to control between home and regional registrations.


B.2.
"
 This process is repeated in each RFA in the hierarchy, until an RFA
   recognizes the mobile node as already registered.  This RFA may be
   the GFA, or any RFA beneath it in the hierarchy.  If the mobile
node
   is already registered with this RFA, the RFA generates a Regional
   Registration Reply and sends it to the next lower-level RFA in the
   hierarchy.  The lifetime field in the Regional Registration Reply
is
   set to the remaining lifetime that was earlier agreed upon between
   the mobile node and the GFA. If the lifetime of the GFA
registration
   has expired, the Regional Registration Request is relayed all the
way
   to the GFA.

   If the hierarchy between the advertising foreign agent and the GFA
is
   announced in the Agent Advertisement, the mobile node may generate
   a Regional Registration Request not destined to the GFA, but to the
   closest RFA with which it can register.
"

? So, if the FA hierarchy is not revealed in the advertisements, then
the regional registrations always go to the GFA?

! There are drawbacks with this approach:

  - The hierarchy is not transparent anymore
    --> A security issue
    --> Needs more functionality in MN

  - The advertisements become some bytes larger because of the
    hierarchy information in them.

  - IF the hierarchy is not revealed, then the GFA is loaded because
    of ALL the regional registrations coming to it.

--> SUGGESTION:

!    Make the MN add a "previous FA NAI" extension to its
registrations
    intended for regional handling. See more info from Jouni Malinen's
    thesis (p. 29-30) available on Dynamics HUT MIP web site. This
    removes the rece condition inherent in for example Dynamics v. 0.5
    which used specific tear down messages. This also keeps the
    hierarhcy completely transparent and does NOT require any complex
    intelligence from the MN, e.g. to claculate the closest "common"
    RFA that could be the target for a regional registration. Adding
    the previous FA NAI extension is very straightforward and does not
    require any additional intelligence from the MN.


B.2.1.

"   recognizes the mobile node as already registered, may generate a
   Regional Registration Reply, not all Regional Registration Requests
   will reach the GFA. Therefore, if old locations are not
deregistered,
   it is possible that tunnels are not correctly redirected when a
   mobile node moves back to a previous foreign agent."

! I think Jouni Malinen solved this issue in his thesis, too. The
solution is tied to the "previous FA NAI extension". Jouni's thesis,
pages 29-30 at least, clarify this solution.
 


" In case (3), the mobile node sends a Regional Registration Request
to
   its new foreign agent.  If the mobile node does not request smooth
   handoff, the previous foreign agent is not notified.  The Regional
   Registration Request is relayed upwards in the hierarchy until it
   reaches a foreign agent that recognizes the mobile node as already
   registered.  This foreign agent generates a Regional Registration
   Reply and sends it downwards in the hierarchy toward the new
location
   of the mobile node, updating its own visitor list.  At the same
time,
   it also sends a Binding Update with a zero lifetime to the previous
   care-of address it had registered for the mobile node.  The Binding
   Update is authenticated by the FA-FA Authentication extension. 
Each
   foreign agent receiving the Binding Update removes the mobile node
   from its visitor lists.  The Binding Update is relayed down to the
   care-of address of the mobile node known to that foreign agent, and
   each foreign agent in the hierarchy receiving this notification
   removes the mobile node from its visitor list.
"

! This results in the race condition I mentioned before. Dynamics v
0.5
had similar kind of message with zero binding lifetime. We called this
a "tear down" message, because it tore down the old bindings and
tunnels. There is a race condition in this, when for example tear down
messages are lost. The state of the FA hierarchy is not up to date a
fter one missed tear down message. Use "previous FA NAI" extension
instead. This, too, has a possible problem, also mentioned in Jouni's
thesis, if the reg.reply is lost and MN moves forward to another FA
that may think it can actually answer the request. This can be soved
as in Jouni's thesis or by only using the NAI of that FA from which we
previously have received a positive reg.reply....


" If the mobile node uses a co-located care-of address for its
regional registration, there is no need to deregister its previous
location when it moves, since regional registrations with a co-located
care-of address are performed directly with the GFA."

! I would say this is a limitation of your architecture. The GFA MUST
NOT be automatically burdened by this kind of registrations. If this
is not fixed, then we lose a part of the whole idea of using
hierarchies - to distribute and localize the registration handling as
much as possible.



Charlie Perkins wrote:
> 
> Hello Tom,
> 
> > I discovered the 'hidden' assumption of RFAs and their GFA knowing
> > abouit each other from the draft. :-)
> 
> It wasn't intended to be hidden.  How can we make it more explicit?
> 
> > I will check the security association issue more closely.
> > I am not completely convinced that there needs to be a separate
> > message type for different uses of security associations.
> > Why couldn't the FAs automatically consider the registration as a home
> > reg if there is not acceptable sec association used for FA-MN
> > authentication?
> 
> Because the mobile node is very likely to want to send a home
> registration whenever it feels like renewing its current care-of
> address, thereby increasing the lifetime.  We do not want to make
> any implicit judgements about type of registration based on the
> remaining registratoin lifetime.  That sounds like a really bad idea.
> 
> At any time, the mobile node should be allowed to send either a
> home registration or a regional registration, subject only to the
> constraint that the lifetime of the regional registration should not
> exceed the lifetime of the regional registration.
> 
> > I will send my comment later.
> > Hopefully not too late. :-/
> > When does the last call end?
> 
> I think formally it might have ended a month ago, but the purpose
> after all is to find out if the draft is ready for advancement.  So,
> I think it's just fine to ask questions.  So far, the main comments
> we have gotten about necessary changes is to put in more details
> about running in the mode where the "first" foreign agent becomes
> the GFA (what others have called "anchoring").
> 
> Other than that, I think we're ready to go depending on your
> comments.
> 
> Regards,
> Charlie P.

-- 
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                dynamics@cs.hut.fi
                               
http://www.cs.hut.fi/Research/Dynamics/





--VxBmi9VgMIlnmxn8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="2000-10-27.txt"
Content-Transfer-Encoding: 8bit

Date:         Fri, 27 Oct 2000 00:07:57 +0300
From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" 
Subject:      Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt)

Hi,

I am slowly starting to "buy" the idea of separate message types for
regional and home registrations... More comments below.

I am waiting your reply about the other issues I mentioned. Here is a
brief checklist of issues not handled in this email (or in your
reply).

        - Revealing the hierarchy in advertisements
                        vs
        - Using previous FA NAI extensions


        * Limiting the solution to 2 levels
                        vs
        * Making generic solution that is ready for N-levels.


        o Forcing registrations from co-located COA to GFA
                        vs
        o Always using the optimal RFA for handling the registrations


        x Possibility to use HA hirarchies (possibly another draft).



Annika Jonsson wrote:
>
> These comments are all about the issue of different message types for
> regional registrations. Summary: I still think it's the best way. See my
> arguments below.
>
> /Annika
> >
> >COMMENTS TO draft-ietf-mobileip-reg-tunnel-03.txt
> >

>
> It has nothing to do with benefits. As I see it it is a _necessity_ for the
> MN to know who will process the registration, the HA or an FA, because it
> needs to know what security association to use (I feel I am repeating
> myself;-). It is possible that it could be solved by having the MN add both
> the home and the visited authentication and both the home and the visited
> replay protection (in case of nounces), and then let the network take the
> actual decision, but that introduces even more complexity in the MN.
>
> 
>
> >"We assume that there exist established
> >   security associations between a GFA and the regional foreign
> >   agents beneath it."
> >---> This implies the RFAs HAVE to know their GFA.
> >---> Satwant Kaur's scenario with RFA not knowing the GFA is
> >impossible.
> >---> No need for different message types for regional and home
> >registration.
> >---> More transparency and simpleness achieved.
> >
>
> You are right, but my example still holds! I will repeat it here:
>
> "The MN is allowed to try
> to do a regional registration to the GFA it has been using, even though
> that GFA is not advertised by the new FA. In this case, if the FA does not
> know this GFA it must send back an error to the MN. If the FA didn't know
> that this was a regional registration, it would assume that the old GFA is
> the MN:s HA, and that this was a normal RFC2002 registration, and the
> registration would fail."

Yes, MN needs to be able to control what kind of registration it
requests.

Your problem in the example above comes from a case where you would
use GFA's IP in the HA field and only one type of registration
message. That is the wrong way, we both know that.

We end up to two alternatives already presented, but I write them here
to make WG "voting" easier:

A)      Use separate message types for regional and home registrations.
        Use FA IP in the "HA field" of the regional registration.
        Actually, if this is a separate message type, then the RFC's
        sepcification is not misused, because we are talking about an
        entiryl new message here. :)

B)      Use only one registration request message type.
        Add FA-MN auth.ext. to registration, if regional registration
        is requested. Always use HA IP in its field.
        The registration can still be forwarded up to HA, if FAs decide so.
        MN will know the "destiny" of the registration only when regreply
        arrives. (with Home auth ext. or with foreign auth ext.)


> 
>
> >3.5.1.
> >
> >" it is necessary to distinguish regional registrations from home
> >   registration.  Thus, we introduce new message types for the
> >   Regional Registration messages."
> >
> >? Could we make the distinction by defining that every registration
> >with a valid MN-FA auth ext is a regional registration? Furthermore,
> >if there is no MN-FA auth ext or if that extension is invalid, the FAs
> >forward the message upwards in the hierarchy.
> >Example: Consider an N-level hierarchy. See image below:



>
> I agree, it could be done in this way, but you still need a change to an
> RFC2002 MN, since it will always include the MN-FA auth. ext if it has an
> SA with the FA (that is mandatory). Secondly, one argument that persuaded
> us that different message types is a "cleaner" solution is that we didn't
> like the idea to use e.g. the auth. ext. to let an FA decide what it
> "thinks" that the MN wants. This is why: normally if the authentication
> fails, this error should be reported back to the MN and no registration be
> made. The authentication could fail for several reasons! It feels wrong,
> both "decisionwise" and "securitywise", to use this failure to authenticate
> the message as an indication of something that the MN wants the FA to do.

Couple of additional comments:

- Changes to RFC2002 MN would still be needed - True. We need an MN
taht can leave the foreign euth ext away on purpose to force
registration to HA (when we are using approach B above).

- It would be good that a RFC2002 MN would be using regional
registrations by default when adding the MN-FA auth.ext. by default.
As an Internet user I would be concerned, if a proposed standard would
not act optimally, but rather consumed bandwidth from the Internet
with its non-optimal registration sequences.

- "Failure to authenticate" would for me be: there was a foreign auth
ext. but we could not verify its authenticity.
--> Direct regreply with correct reason code to MN.

- Lack of the auth ext. would not mean "failure", but the FA would
forward the request onwards.


> >? Why should the HA field be replaced?
>
> Why use extensions when we don't have to? In a regional registration the HA
> address is not needed, so we reuse that field. Actually, the GFA kind of
> acts as a "local HA", so doing it in this way makes it very consistent with
> RFC2002.

We come back to options A and B.
As I said, using GFA IP in the new message in option A is OK, since it
is not anymore a RFC2002 registration request but a new type of
request.

> >A.
> >
> >" - a mobile node must be able to distinguish between regional
> >     registrations and home registrations, because when it uses
> >     regional registration, the nounces are not synchronized with its
> >     home agent;"
> >
> >! Dynamics works with nonces also, and it supports regional
> >registrations. I have to find out how the nonce synchronization is
> >done in Dynamics. Perhaps the lack of FA-MN auth ext (again) is enough
> >for the MN to control between home and regional registrations.


I discussed with Jouni. Dynamics can uses nonces for home
registrations, i.e., registration requests without MN-FA auth ext. but
only timestamps are used in registrations with FA-MN auth. ext. This
eliminates the possibility of uncontrolled nonce asynchronization.

> It would be interesting to see your solution.

:-)
Download Dynamics from the URL in my signature.
You are also welcome to visit Finland to see it work.
Unfortunately we do not have any conference papers in pipeline or
budget to travel to WG meetings.

Best regards,
                Tom

--
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                dynamics@cs.hut.fi

http://www.cs.hut.fi/Research/Dynamics/


--VxBmi9VgMIlnmxn8--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 19:54:31 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18533
	for ; Mon, 22 Apr 2002 19:54:30 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00309;
	Mon, 22 Apr 2002 17:54:24 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23072;
	Mon, 22 Apr 2002 16:54:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MNrVGs009288
	for ; Mon, 22 Apr 2002 16:53:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MNrVi3009287
	for mobile-ip-dist; Mon, 22 Apr 2002 16:53:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MNrSGs009280
	for ; Mon, 22 Apr 2002 16:53:28 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22856
	for ; Mon, 22 Apr 2002 16:53:29 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA21911
	for ; Mon, 22 Apr 2002 17:53:28 -0600 (MDT)
Received: from tom by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian))
	id 16zncc-0001gA-00; Tue, 23 Apr 2002 02:53:26 +0300
Date: Tue, 23 Apr 2002 02:53:26 +0300
From: Tom K Weckstrom 
To: Tom K Weckstrom 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Message-ID: <20020422235326.GU12913@muminmamman.lifix.fi>
References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020422223042.GQ12913@muminmamman.lifix.fi> <20020422234829.GT12913@muminmamman.lifix.fi>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="AOcQtsuew1iUDr5s"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20020422234829.GT12913@muminmamman.lifix.fi>
User-Agent: Mutt/1.3.25i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--AOcQtsuew1iUDr5s
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello.

Please, read the attached text file for my comments on
draft-ietf-mobileip-reg-tunnel-06.txt.

Please, consider this as a first stage and by no means exhaustive
"issue list". I'll get back with concrete proposals later this week.

On Tue, Apr 23, 2002 at 02:48:29AM +0300, Tom K Weckstrom wrote:
> Hello all.
> 
> I have read through the draft-ietf-mobileip-reg-tunnel-06.txt and have
> a multitude of comments.

...

> I'll soon send my v06 comments in another email.
---end quoted text---


Regards, Tom


-- 
Tom Weckström                   PGP id:  E1DB55E9
Lifix Systems Oy        Mobile: +358 50 350 5997
Yliopistonkatu 5       3rd floor               FIN-00100 Helsinki

--AOcQtsuew1iUDr5s
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="2002-04-22-reg-tun-06-comments.txt"
Content-Transfer-Encoding: 8bit


TITLE:	Comments on draft-ietf-mobileip-reg-tunnel-06.txt
Author: Tom Weckström
Date:	2002-04-23
-------------------------------------------------------------------

Terms:
	xFA	Crossover FA
	pFA	previous FA
	nFA	new FA
	RFA	Regional FA
	FA	Any FA, also often the leaf FA in the hierarchy


General comments:

- There are very many optional ways to act. Many optional next steps
  will make the state machine complicated and the protocol more error
  prone. e.g.
	- Using zero COA in RRQ
	- Advertising the hierarchy in FA advs
	- Registering to a certain RFA/FA, "anchoring"
  More questions about the specific optional features below.

- A single registration requires two roundtrips from the MN to the
  crossover FA (xFA) within the hierarchy. One roundtrip for the
  reg.req. and another one for the BU and BU ACK. Using the smooth HO
  option doubles the number of signaling packets involved in each HO
  compared to a model, where BUs and BU ACKs are not used. For a
  really large hierarchy with e.g. 10 000 MNs moving once per second
  on average, the proposed solution reguires 20 000 mesages to be send
  per second. Let's takeg an alternative solution: Only the
  reg.request and reply are send as MNs move and FAs learn about the
  other FAs beneath them in the branch with a certain registration
  protocol occasionally - and definitely not sent as often as 10 000
  messages per second. An average number with the above mobility specs
  and a FA registration protocol would result in 10 000 + 50/10 = 10
  005 send messages in a hierarchy of 50 FAs each advertising its
  presence to the other FAs on the road to GFA and 10 000 MNS moving
  once per second. An improvement of nearly 50%. If there was a
  hierarchy whose FAs would know their children in the tree, BUs up
  the old path and BU ACKs from xFA to pFA would not be needed. For HO
  optimisation reasons, a BU and BU ACK between nFA and pFA MAY be
  used.

- Eventhough adding new MIP messages for regional reg.req. and
  reg.reply may be OK, the draft leaves me sitting confused and
  thinking about all the other necessary changes to be made my MN work
  in every provider's MIPv4 network and with any provider's HA/FA.

- As was implied in one of Charlie's emails today, the issue of shared
  administration of a large hierarchy has not been considered at
  all. Shared administration will give very interesting business
  opportunities to carriers with fast backbone connections and to
  smaller ISPs or even cafés willing to implement their service alone
  or by leasing it from the carrier.

- After reading the draft, I really do not know:
  - What MUST each FA know about its surroindung FAs?
  - What MUST, SHOULD, MAY and actually will be sent in the signaling
    messages (too many options, as I said above)

- Some sort of backwards compatibility with RFC 3220 implementations
  is a MUST. Whatever the administrator decides to configure in the FA
  hierarchy, a single hierarchy MUST be able to serve MNs with an
  ability to send regional reg.reqs and MNs without that ability. The
  backwards compatibility is not an option, it MUST be there. The same
  performance gain does not need to be provided to all MNs. If
  backwards comp. is not taken into account, then IMO, we are not
  talking about MIP any more.


- Why would the MN need to request a specific GFA to serve it?

      - As opposed to MN selecting the GFA to register to, I vote for
        a model, where the actual GFA (process&HW) to handle the
        request is selected transparently to the registering MN, if
        any dynamic GFA selection is needed.



More detailed comments with some references to chapters:

- Ch 4.2, sec 3: I understood from this chapter that it is possible to
  cut the hierarchy by delivering the RRQ from a FA/RFA directly to the
  HA? IMHO, this should not be allowed for these reasons:
	- a FA lower in the hierarchy cannot have a private IPv4 address
	- How can this be combined with the "anchoring" feature?

- Ch 11: Did I understood correctly that only the extensions specific
  to the signaling inside the FA hierarchy are to be defined
  non-skippable, but no other extensions will be made non.skippable?

- App B. sec 2: Why is the key distribution inside the FA hierarchy
  not specified?
	- Leaving this unspecified leads to variance and
          incompatibility in implementations
	- Using simple method just like between HA and MN would be
          just fine.


- Why should a FA send the IP addrs of the RFAs in its advertisements?
	- This leads to large advertisement packets
	- The size of adv packets will be dependent on the size of the
          hierarchy
	- The size of the hierarchy may be practically limited to a
          certain size due to the dependence on the adv packet size.
	- The advertising FA needs to know the RFAs above it. How does
          the FA get to know those? This needs to be
          specified. Statical configuration is not a sufficient
          solution.
	- Only sending the GFA IP would be enough. The FA would need
          to send its NAI in advs, though. I'd be ready to mandate that...

- The use of Route Optimisation with the regional registrations
  requires that the routing is well specified within the entire
  hierarchy.
	- How does this work with a geographically wide spread hierarchy?

	- This requires well defined IPv4 address space within the
          entire hierarchy, i.e., a sub hierarhcy cannot be
          administered by a third party and addressed with a private
          IPv4 address space.

	- How does the crossover FA deliver the BU ACK back to the
          previous FA and the new FA?


- I'd like to know what is needed in practice, when a new hierarchy is
  established?
	- IP address space planning
	- Routing planning for the hierarchy
	- FA-FA trust relationships

- What is included in the BU sent by the new FA to the previous FA?
	- Is the entire path from the new FA to the GFA included as
          GNAI extensions?

- Why would a FA want to send the IP addresses of its ancestors in the
  hierarchy in the advertisements?


CONCLUSIONS:

	- Separate message types for regional reg. are not necassary,
          but an acceptable solution.

	- Using BUs and sending them back to xFA through the old path
          does not seem to scale the same way as a model where FAs
          know the FAs below them in the hierarchy.

	- The draft is confusing and does not make a clear picture
          what CAN, MUST, SHOULD or MAY be done and how different
          combinations of the optional ways of signaling do cooperate.

	- I will have to re-read the ID and send more questions
          later. Maenwhile, the authorts could comment my concerns and
          also make the draft more clear.

--AOcQtsuew1iUDr5s--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 22 21:43:06 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21220
	for ; Mon, 22 Apr 2002 21:43:05 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06865;
	Mon, 22 Apr 2002 19:43:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17602;
	Mon, 22 Apr 2002 11:13:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIBcGs005681
	for ; Mon, 22 Apr 2002 11:11:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3MIBcIP005680
	for mobile-ip-dist; Mon, 22 Apr 2002 11:11:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3MIBUGs005652
	for ; Mon, 22 Apr 2002 11:11:30 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20071
	for ; Mon, 22 Apr 2002 11:11:31 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22190
	for ; Mon, 22 Apr 2002 11:11:25 -0700 (PDT)
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 LAA07126;
	Mon, 22 Apr 2002 11:11:25 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MIBPm31344;
	Mon, 22 Apr 2002 11:11:25 -0700
X-mProtect: <200204221811> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdltFWus; Mon, 22 Apr 2002 11:11:23 PDT
Message-ID: <3CC4524B.F5F642BA@iprg.nokia.com>
Date: Mon, 22 Apr 2002 11:11:23 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Ahmad Muhanna 
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
References: <6B49EDFE974BD51197D70002A56079D801AFCC15@zrc2c013.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Ahmad,

>> It is important to keep regional registration separate from
>> Mobile IPv6,
>> and from Mobile IPv4 for that matter.  I don't think anyone
> 
> I respectfully disagree. Your proposed solution in this draft affects existing
> Mobile IPv4 implementation in many aspects!!!

How do you mean that?  Regional agents can handle existing Mobile IPv4
mobile nodes -- the mobile nodes just can't then use regional messages.
Mobile nodes that run the new protocol do not disturb other mobile
entities.  If the home agent supports the ability to handle the
non-mandatory extensions for zero care-of address, then the mobile
node can use this feature.  If not, then the mobile node can either
not use regional registration.  This would be a matter for preconfiguration
just as with the mobile security association.

The regional registration protocol is a new protocol, with new
messages and extensions, that works well with Mobile IPv4.
If there was a way to do it with Mobile IPv4, then we wouldn't
have to make the draft.  Otherwise, aren't changes required in
at least some implementation somewhere?

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 02:52:42 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07873
	for ; Tue, 23 Apr 2002 02:52:42 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07287;
	Mon, 22 Apr 2002 23:52:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA11190;
	Mon, 22 Apr 2002 23:52:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N6pEGs010259
	for ; Mon, 22 Apr 2002 23:51:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N6pEdH010258
	for mobile-ip-dist; Mon, 22 Apr 2002 23:51:14 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N6pBGs010251
	for ; Mon, 22 Apr 2002 23:51:11 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07555
	for ; Mon, 22 Apr 2002 23:51:11 -0700 (PDT)
Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10707
	for ; Tue, 23 Apr 2002 00:51:10 -0600 (MDT)
Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54])
	by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3N6sKgL009423;
	Tue, 23 Apr 2002 08:54:21 +0200
From: "Fredrik Johansson" 
To: "Ahmad Muhanna" ,
        
Cc: 
Subject: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
Date: Tue, 23 Apr 2002 08:51:22 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003B_01C1EAA4.0B1C8880"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC12@zrc2c013.us.nortel.com>
X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw)
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_003B_01C1EAA4.0B1C8880
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txtAhmad,

Now I understand what you mean, I'll go ahead and add text according to Tony's
suggestion

thanks
/Fredrik
  -----Original Message-----
  From: Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com]
  Sent: den 22 april 2002 17:55
  To: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com
  Cc: fredrik@ipunplugged.com; tony.johansson@ericsson.com
  Subject: RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt


  Hi Fredrik;

  Please see my comments inline.

  Regards;
  Ahmad Muhanna




  Ahmad,

  please see comments inline
  /fredrik



  Hello All;
  I would like to address the following two points:
  I. Mobile Node and the new HA NAI extension:
  In section 4. It reads:
  " A mobile node MUST provide this in every registration request sent
     when re-authenticating, or when requesting a specific IP address at
     initial authentication."
          1. Does this mean that whenever the mobile Node include a specific
Static
          Home IP address, Mobile Node MUST provide the AAA NAI extension with
Subtype 1?
  [->] yes
          2. Does this mean when the MN change point of attachment due to Inter-FA
handoff
          It MUST include this extension.
  [->] yes
  If 1 & 2 are true?
  Where is the backward compatibility with legacy Mobile Node?

  [->] Isn't it the same as with any extension needed to authenticate through an
  AAA infrastructure, e.g. the MN-AAA Authentication extension must be present
  in order for the FA/HA to authenticate via AAA?

  ************
  I do not think that It is the same!!
  RFC3012 introduced a new way of authenticating the MN to the FA without
violating
  backward compatibility of RFC2002 or later RFC3220.
  Mobile Node does not know which way or the standard the foreign agent uses to
  authenticate it. It could be through RADIUS, AAA, Diameter who knows.

  The point here is that this draft mandates that every Mobile Node include AAA
NAI extension
  with subtype of 1 whenever it requests static Mobile IP or during Inter-FA
handoff.
  Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile Node which exist
right now,
  does not do this.
  After this draft becomes a standard, according to this section, MN is not
following the
  standard by not sending AAA NAI extension in initial Registration Request or
during re-authentication.!!!

  This is not backward compatible!!!!



  Thanks;
  Ahmad
  *****************

  II. Home Agent handling of AAAH Identity Subtype extension:
  In section 5. It reads:
  "The home agent MUST provide this in every registration reply if using
     the AAA server ."
  I would prefer more explicit sentence similar to one used earlier:
  "The home agent MUST provide this in every registration reply sent to
    the mobile node destined through the AAA infrastructure."

  [->]You mean so don't have to send it every time? I have no problem with that.
  /Fredrik
   Thanks for consideration.
  Regards;
  Ahmad Muhanna


------=_NextPart_000_003B_01C1EAA4.0B1C8880
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: A Question =
about:draft-ietf-mobileip-aaa-nai-00.txt




Ahmad,


 


Now I=20
understand what you mean, I'll go ahead and add text according to Tony's =

suggestion


 


thanks


/Fredrik


  
-----Original Message-----
From: Ahmad Muhanna=20
  [mailto:amuhanna@nortelnetworks.com]
Sent: den 22 april 2002 =

  17:55
To: 'Fredrik Johansson';=20
  mobile-ip@sunroof.eng.sun.com
Cc: fredrik@ipunplugged.com;=20
  tony.johansson@ericsson.com
Subject: RE: A Question=20
  about:draft-ietf-mobileip-aaa-nai-00.txt


  
Hi Fredrik; 

  
Please see my comments inline. 

  
Regards; 
Ahmad Muhanna=20
  



  
Ahmad, 
  =

please see comments inline 
/fredrik=20
  


  
Hello All; 
I would like to =
address the=20
  following two points: 
I. Mobile Node and the =
new HA=20
  NAI extension: 
In section 4. It reads:=20
  
" A mobile node MUST provide this in every=20
  registration request sent 
   when=20
  re-authenticating, or when requesting a specific IP address at=20
  
   initial authentication." =

        1. Does this mean =
that=20
  whenever the mobile Node include a specific Static 
        Home IP address, =
Mobile Node=20
  MUST provide the AAA NAI extension with Subtype 1? 
[->] yes 
        2. Does this mean =
when the=20
  MN change point of attachment due to Inter-FA handoff 
        It MUST include =
this=20
  extension. 
[->] yes 
If 1=20
  & 2 are true? 
Where is the backward =
compatibility=20
  with legacy Mobile Node? 

  
[->] Isn't it the same as with any extension =
needed to=20
  authenticate through an 
AAA infrastructure, =
e.g. the=20
  MN-AAA Authentication extension must be present 
in=20
  order for the FA/HA to authenticate via AAA? 

  
************ 
I do not =
think that It is=20
  the same!! 
RFC3012 introduced a new way of=20
  authenticating the MN to the FA without violating 
backward compatibility of RFC2002 or later RFC3220. =

Mobile Node does not know which way or the standard the =
foreign agent=20
  uses to 
authenticate it. It could be through =
RADIUS,=20
  AAA, Diameter who knows. 

  
The point here is that this draft mandates that =
every Mobile=20
  Node include AAA NAI extension 
with subtype =
of 1=20
  whenever it requests static Mobile IP or during Inter-FA handoff.=20
  
Now: (Standard Compliant RFC3220, =
RFC3012bis) Legacy=20
  Mobile Node which exist right now, 
does not =
do=20
  this. 
After this draft becomes a standard, =
according=20
  to this section, MN is not following the 
standard by=20
  not sending AAA NAI extension in initial Registration Request or =
during=20
  re-authentication.!!! 

  
This is not backward compatible!!!! 


  
Thanks; 
Ahmad =

***************** 

  
II. Home Agent handling of AAAH Identity Subtype =
extension:=20
  
In section 5. It reads: 
"The=20
  home agent MUST provide this in every registration reply if using=20
  
   the AAA server ." =

I would prefer more explicit sentence similar to one used =
earlier:=20
  
"The home agent MUST provide this in every=20
  registration reply sent to 
  the mobile =
node=20
  destined through the AAA infrastructure." 
  
[->]You mean so don't =
have to send it=20
  every time? I have no problem with that. 
/Fredrik 
 Thanks for =
consideration.=20
  
Regards; 
Ahmad =
Muhanna=20
  


------=_NextPart_000_003B_01C1EAA4.0B1C8880--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 04:06:50 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08897
	for ; Tue, 23 Apr 2002 04:06:49 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06319;
	Tue, 23 Apr 2002 01:06:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02913;
	Tue, 23 Apr 2002 01:06:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N856Gs010449
	for ; Tue, 23 Apr 2002 01:05:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N856ON010448
	for mobile-ip-dist; Tue, 23 Apr 2002 01:05:06 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N84xGs010441
	for ; Tue, 23 Apr 2002 01:04:59 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23454
	for ; Tue, 23 Apr 2002 01:05:00 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08711
	for ; Tue, 23 Apr 2002 02:04:54 -0600 (MDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3N84os7012012
	for ; Tue, 23 Apr 2002 10:04:50 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 23 10:04:47 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Apr 2002 09:54:14 +0200
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACA5@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "Karim El-Malki (ERA)" ,
        "''James Kempf' '" ,
        "'Dana L. Blair '"
	 ,
        "'Milind Kulkarni '" ,
        "'Madhavi W. Chandra '" 
Cc: "'Charles E. Perkins '" ,
        "'mobile-ip@sunroof.eng.sun.com '" 
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t
	 xt
Date: Tue, 23 Apr 2002 10:04:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Subscribe: 
List-Unsubscribe: > > Please clarify some confusion that I have and I know a few> > others have.> >> > When you say "such as was done with the MIPv4 fast handoff draft> itself",> > specifically which draft are you referencing ?  Please provide> > the full name of the draft.> >> > It is, in fact, > draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt. There> is> some question whether we need two handoff techniques, one of which,> from the experimental evidence, doesn't work very well if the mobile> node moves too fast.
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

That's a bit of a biased comment isn't it?
In particular there was more than one person who questioned
your experiments.

>  In order to clarify the situation, the 
 > authors, WG
 > chairs, and ADs have agreed to move it to experimental.

This question wasn't posed to the WG. This is what I had asked when I
was
informed that the fate of the low latency draft was being discussed in a
group which I believe you (James) were part of. Just to clarify, I
wasn't part
of this decision process so I had little choice other than to agree.

=> I am another author who didn't want to agree with
this, but was simply told that after some discussion
(that was not on this list) this seems to be the way 
to go forward. And I only agreed to it because I don't
have the cycles for a long discussion and because we should
move the draft forward. 

Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 04:22:10 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09078
	for ; Tue, 23 Apr 2002 04:22:09 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16554;
	Tue, 23 Apr 2002 02:22:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07386;
	Tue, 23 Apr 2002 01:21:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N8KiGs010607
	for ; Tue, 23 Apr 2002 01:20:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N8KTJ8010606
	for mobile-ip-dist; Tue, 23 Apr 2002 01:20:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N8KPGs010599
	for ; Tue, 23 Apr 2002 01:20:26 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01700
	for ; Tue, 23 Apr 2002 01:20:27 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21103
	for ; Tue, 23 Apr 2002 02:20:26 -0600 (MDT)
Message-ID: <00c401c1ea9f$72287c00$396015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        "Karim El-Malki \(ERA\)" ,
        "'Dana L. Blair '" ,
        "'Milind Kulkarni '" ,
        "'Madhavi W. Chandra '" 
Cc: "'Charles E. Perkins '" ,
        
References: <4DA6EA82906FD511BE2F00508BCF053802C6ACA5@Esealnt861.al.sw.ericsson.se>
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt
Date: Tue, 23 Apr 2002 01:18:23 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> => I am another author who didn't want to agree with
> this, but was simply told that after some discussion
> (that was not on this list) this seems to be the way
> to go forward. And I only agreed to it because I don't
> have the cycles for a long discussion and because we should
> move the draft forward.
>

I am certainly not opposed to re-opening the question of whether the
draft should go to standards track or not, but I don't believe it should
be advanced until there is at least one other independent implementation
of both techniques, besides the one Jon Wood did, and there have been
the same kinds of performance measurements we've made on at least a
handover emulator, and more preferably on a cellular and WLAN protocol
as well, as we've done together with Motorola. This should give the
working group enough data to decide, should it finally choose at that
point to make a decision. I realize that IETF doesn't require this level
of implementation except for routing protocols (which, arguably, these
protocols are), but I believe if a protocol makes a performance claim,
then it is incumbent upon the WG to prove that claim, and describe under
what conditions the claim holds and where it breaks down (if it does).

            jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 04:23:48 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09124
	for ; Tue, 23 Apr 2002 04:23:48 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13097;
	Tue, 23 Apr 2002 01:23:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07765;
	Tue, 23 Apr 2002 01:23:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N8MjGs010644
	for ; Tue, 23 Apr 2002 01:22:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N8MiWh010643
	for mobile-ip-dist; Tue, 23 Apr 2002 01:22:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N8MfGs010636
	for ; Tue, 23 Apr 2002 01:22:41 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07638
	for ; Tue, 23 Apr 2002 01:22:42 -0700 (PDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22606
	for ; Tue, 23 Apr 2002 02:22:41 -0600 (MDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3N8Me0E016855
	for ; Tue, 23 Apr 2002 10:22:40 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 23 10:22:40 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Apr 2002 10:12:06 +0200
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACA7@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'James Kempf '" ,
        "'Dana L. Blair '"
	 ,
        "'Milind Kulkarni '" ,
        "'Madhavi W. Chandra '" 
Cc: "'Charles E. Perkins '" ,
        "'mobile-ip@sunroof.eng.sun.com '" 
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t
	xt
Date: Tue, 23 Apr 2002 10:22:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Subscribe: 
List-Unsubscribe: 
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3N8MfGs010637
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 
Content-Transfer-Encoding: 8bit

As for draft-ietf-mobileip-reg-tunnel-06.txt, I'm curious how many
people are really going to implement it. Is there any interest in
3GPP2 in it? This question was put for
draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt and the
answer was "no one", which was another reason why it
was taken to experimental.

=> I would like to take this opportuntiy to re-interate
a couple of facts: 

- We don't develop protocols in IETF for 3GPP or 
  3GPP2 only. 

- We don't have requirements in IETF to show product
  plans to get a draft to proposed standard. 

I don¨t think the rules should be tailored per
draft. 

Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 05:52:52 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10171
	for ; Tue, 23 Apr 2002 05:52:51 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23473;
	Tue, 23 Apr 2002 02:52:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12856;
	Tue, 23 Apr 2002 02:52:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N9pOGs010886
	for ; Tue, 23 Apr 2002 02:51:24 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3N9pOIf010885
	for mobile-ip-dist; Tue, 23 Apr 2002 02:51:24 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3N9pLGs010878
	for ; Tue, 23 Apr 2002 02:51:21 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12615
	for ; Tue, 23 Apr 2002 02:51:23 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00596
	for ; Tue, 23 Apr 2002 03:51:22 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3N9oqQ20537;
	Tue, 23 Apr 2002 11:50:53 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA21901;
	Tue, 23 Apr 2002 11:50:52 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3N9ooT64848;
	Tue, 23 Apr 2002 11:50:50 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204230950.g3N9ooT64848@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: greg.daley@eng.monash.edu.au
cc: Erik Nordmark ,
        James Kempf , mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
In-reply-to: Your message of Mon, 22 Apr 2002 08:50:34 +1000.
             <3CC3423A.AC4B2F20@eng.monash.edu.au> 
Date: Tue, 23 Apr 2002 11:50:50 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   > => I disagree with the reasonning because it uses the assumption there is
   > only one router: if RAs are immediately sent (unicasted or multicasted,
   > this doesn't matter) at the reception of a multicasted RS, then they will
   > collide. So I agree the bit approach is not good, but the right approach
   > (to unicast the RS) has some difficulties...
   > (PS: I can't see a better alternative to trigger though the link layer a RA)
   
   It would be straightforward to ensure that only one
   router on any link is using the 'Fast Response' bit.

=> I am not convinced this would be so "straightforward":
 - this assumption defeats the goal to have several available routers
 - if a router is by some ways made "special" why not to allow it
   to answer to NSs without delay? (in this case the FR bit is
   simply useless).
To come back to Erik's comment, I agree there is a good solution
in ND itself which keeps to original RFC 2461 goals...

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 06:01:16 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10267
	for ; Tue, 23 Apr 2002 06:01:15 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27216;
	Tue, 23 Apr 2002 03:00:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14244;
	Tue, 23 Apr 2002 03:00:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NA07Gs011002
	for ; Tue, 23 Apr 2002 03:00:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NA07vV011001
	for mobile-ip-dist; Tue, 23 Apr 2002 03:00:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NA04Gs010994
	for ; Tue, 23 Apr 2002 03:00:04 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26663
	for ; Tue, 23 Apr 2002 03:00:04 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04160
	for ; Tue, 23 Apr 2002 04:00:03 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3N9xpQ21842;
	Tue, 23 Apr 2002 11:59:51 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA22039;
	Tue, 23 Apr 2002 11:59:51 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3N9xpT64895;
	Tue, 23 Apr 2002 11:59:51 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204230959.g3N9xpT64895@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Brett Pentland 
cc: James Kempf , mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
In-reply-to: Your message of Mon, 22 Apr 2002 16:01:59 +1100.
             <3CC39947.D76F7F0@eng.monash.edu.au> 
Date: Tue, 23 Apr 2002 11:59:51 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   Thanks for your response; I hadn't really pursued that line of thought. In
   any case, the method you describe requires significant infrastructure to
   work.

=> I don't believe this infrastructure is "significant" and (more important)
in many cases it is already there, for instance as soon as you have
common layer two "AAA" features. And don't forget easy cases like PPP.

   I think that in cases where that infrastructure is not in place, if a
   mobile node is aware that a layer two handover has occured then it is
   desirable that it be able to perform a handover at layer three quickly.
   
=> I'd like to know how "a mobile node is aware that a layer two
handover has occured"...

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 10:03:10 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18222
	for ; Tue, 23 Apr 2002 10:03:09 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09713;
	Tue, 23 Apr 2002 08:03:10 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29454;
	Tue, 23 Apr 2002 07:03:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NE1oGs012450
	for ; Tue, 23 Apr 2002 07:01:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NE1nvX012449
	for mobile-ip-dist; Tue, 23 Apr 2002 07:01:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NE1kGs012442
	for ; Tue, 23 Apr 2002 07:01:46 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06197
	for ; Tue, 23 Apr 2002 07:01:46 -0700 (PDT)
From: rene.purnadi@nokia.com
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01594
	for ; Tue, 23 Apr 2002 08:01:44 -0600 (MDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3NE22s22535
	for ; Tue, 23 Apr 2002 09:02:03 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 23 Apr 2002 07:01:42 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 23 Apr 2002 09:01:13 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
Date: Tue, 23 Apr 2002 09:01:13 -0500
Message-ID: <748E8123D183394982E32A511DB3E73610B12A@daebe005.NOE.Nokia.com>
Thread-Topic: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
Thread-Index: AcHqrmARg09SDh/IRDWf4CR5MlenGwAIAkQg
To: , 
Cc: , 
X-OriginalArrivalTime: 23 Apr 2002 14:01:13.0823 (UTC) FILETIME=[5466AEF0:01C1EACF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3NE1lGs012443
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Hi Francis,

A mobile node should aware that a layer 2 handover has occurred. For example, in cellular, the MN is given a radio resources information in the target access point to be acquired. Once it acquires the radio link in the target access point, the mobile node can start the layer 3 procedure. I don't know what is the motivation for the mobile node to perform L3 handover quickly, but definitely the mobile node know that L2 handover has been completed (in UMTS the mobile node even send L2 message). 

Thanks.

Rene Purnadi
Phone: +1 972.894.4897
Mobile: +1 972.342.3503
e-mail: rene.purnadi@nokia.com


-----Original Message-----
From: ext Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
Sent: Tuesday, April 23, 2002 5:00 AM
To: Brett Pentland
Cc: James Kempf; mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance
Fatality 


   Thanks for your response; I hadn't really pursued that line of thought. In
   any case, the method you describe requires significant infrastructure to
   work.

=> I don't believe this infrastructure is "significant" and (more important)
in many cases it is already there, for instance as soon as you have
common layer two "AAA" features. And don't forget easy cases like PPP.

   I think that in cases where that infrastructure is not in place, if a
   mobile node is aware that a layer two handover has occured then it is
   desirable that it be able to perform a handover at layer three quickly.
   
=> I'd like to know how "a mobile node is aware that a layer two
handover has occured"...

Thanks

Francis.Dupont@enst-bretagne.fr



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 10:21:04 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18977
	for ; Tue, 23 Apr 2002 10:21:03 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21991;
	Tue, 23 Apr 2002 07:20:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04652;
	Tue, 23 Apr 2002 07:20:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NEJXGs012586
	for ; Tue, 23 Apr 2002 07:19:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NEJXre012585
	for mobile-ip-dist; Tue, 23 Apr 2002 07:19:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NEJUGs012578
	for ; Tue, 23 Apr 2002 07:19:30 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02373
	for ; Tue, 23 Apr 2002 07:19:30 -0700 (PDT)
Received: from web21302.mail.yahoo.com (web21302.mail.yahoo.com [216.136.173.210])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA21347
	for ; Tue, 23 Apr 2002 08:19:30 -0600 (MDT)
Message-ID: <20020423141928.93903.qmail@web21302.mail.yahoo.com>
Received: from [149.112.94.169] by web21302.mail.yahoo.com via HTTP; Tue, 23 Apr 2002 07:19:28 PDT
Date: Tue, 23 Apr 2002 07:19:28 -0700 (PDT)
From: SatishK Amara 
Subject: [mobile-ip] Security Design in mobile-ip@sunroof.eng.sun.com
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi,
   I am wondering why is the scope of security design
specified in draft-ietf-mobileip-ipv6-16.txt is
limited to on only RR protocol. I think the security
design should be extendable to any other protocols
like CAM or IPSEC based on PKI. 

Satish Amara

=====
In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world 
           -- Alan Kay

__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 10:26:05 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19164
	for ; Tue, 23 Apr 2002 10:26:04 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24986;
	Tue, 23 Apr 2002 07:25:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06232;
	Tue, 23 Apr 2002 07:25:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NEOxGs012679
	for ; Tue, 23 Apr 2002 07:24:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NEOxFF012678
	for mobile-ip-dist; Tue, 23 Apr 2002 07:24:59 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NEOtGs012671
	for ; Tue, 23 Apr 2002 07:24:56 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06049
	for ; Tue, 23 Apr 2002 07:24:56 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13201
	for ; Tue, 23 Apr 2002 08:24:55 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3NEOfB05237;
	Tue, 23 Apr 2002 16:24:42 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA26704;
	Tue, 23 Apr 2002 16:24:42 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3NEOfT65815;
	Tue, 23 Apr 2002 16:24:41 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204231424.g3NEOfT65815@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: rene.purnadi@nokia.com
cc: brett.pentland@eng.monash.edu.au, kempf@docomolabs-usa.com,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
In-reply-to: Your message of Tue, 23 Apr 2002 09:01:13 CDT.
             <748E8123D183394982E32A511DB3E73610B12A@daebe005.NOE.Nokia.com> 
Date: Tue, 23 Apr 2002 16:24:41 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   A mobile node should aware that a layer 2 handover has
  occurred. For example, in cellular, the MN is given a radio resources
  information in the target access point to be acquired. Once it
  acquires the radio link in the target access point, the mobile node
  can start the layer 3 procedure. I don't know what is the motivation
  for the mobile node to perform L3 handover quickly, but definitely the
  mobile node know that L2 handover has been completed (in UMTS the
  mobile node even send L2 message).
   
=> in your description it is very cler than the target access point
knows the handover occurs. So it can help to make L3 handover faster,
for instance by caching a RA, by triggering a RA by sending itself a RS,
etc. One can imagine many ways, all of them are better than to mess
the neighbor discovery protocol.
About UMTS, if the context type is PPP the peer is the access router,
if it is IPv6 the GGSN is the access router: in all cases a RA will be sent
without a RS and the L3 handover as quick as possible without FMIPv6.

Thanks
   
Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 10:59:25 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21181
	for ; Tue, 23 Apr 2002 10:59:25 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15020;
	Tue, 23 Apr 2002 08:59:25 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11757;
	Tue, 23 Apr 2002 07:59:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NEwHGs012877
	for ; Tue, 23 Apr 2002 07:58:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NEwGDw012876
	for mobile-ip-dist; Tue, 23 Apr 2002 07:58:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NEwDGs012869
	for ; Tue, 23 Apr 2002 07:58:13 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23445
	for ; Tue, 23 Apr 2002 07:58:14 -0700 (PDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02101
	for ; Tue, 23 Apr 2002 08:58:12 -0600 (MDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3NEvlx25788;
	Tue, 23 Apr 2002 09:57:47 -0500 (CDT)
Message-ID: <3CC57681.4070004@alcatel.com>
Date: Tue, 23 Apr 2002 09:58:09 -0500
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Francis Dupont 
CC: rene.purnadi@nokia.com, brett.pentland@eng.monash.edu.au,
        kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality
References: <200204231424.g3NEOfT65815@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Francis,
  This is an interesting subject!
I wonder in which context are considering the application of FMIPv6? Is 
it for fast handover inside UMTS domain? Probably it is more interesting 
to consider intertechnology handovers using FMIPv6?

Francis Dupont wrote:

>
>=> in your description it is very cler than the target access point
>knows the handover occurs. So it can help to make L3 handover faster,
>for instance by caching a RA, by triggering a RA by sending itself a RS,
>etc. One can imagine many ways, all of them are better than to mess
>the neighbor discovery protocol.
>About UMTS, if the context type is PPP the peer is the access router,
>if it is IPv6 the GGSN is the access router: in all cases a RA will be sent
>without a RS and the L3 handover as quick as possible without FMIPv6.
>
I wonder what Hesham says to this?

>
>Thanks
>   
>Francis.Dupont@enst-bretagne.fr
>
Regards,

-- 
Behcet 





From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 11:51:29 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24391
	for ; Tue, 23 Apr 2002 11:51:28 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18894;
	Tue, 23 Apr 2002 08:51:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08246;
	Tue, 23 Apr 2002 08:50:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NFo7Gs012991
	for ; Tue, 23 Apr 2002 08:50:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NFo7eL012990
	for mobile-ip-dist; Tue, 23 Apr 2002 08:50:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NFo3Gs012983
	for ; Tue, 23 Apr 2002 08:50:03 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26678
	for ; Tue, 23 Apr 2002 08:50:05 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14619
	for ; Tue, 23 Apr 2002 09:50:04 -0600 (MDT)
Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3NFnqjR029630;
	Tue, 23 Apr 2002 08:49:52 -0700 (PDT)
Received: from DBLAIRW2K (rtp-vpn2-525.cisco.com [10.82.242.13])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id ACS54446;
	Tue, 23 Apr 2002 08:49:51 -0700 (PDT)
From: "Dana L. Blair" 
To: "Charlie Perkins" 
Cc: 
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Tue, 23 Apr 2002 11:49:50 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3CC423F9.BFE5704C@iprg.nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Monday, April 22, 2002 10:54 AM
> To: Dana L. Blair
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] WG Last Call:
> draft-ietf-mobileip-reg-tunnel-06.txt
>
>
>
> Hello Dana,
>
> "Dana L. Blair" wrote:
>
> > > > 9. Regional Registration Message Formats
> > > >    
> > > >    These messages are used by the mobile node instead of the
> > > >    existing Registration Request and Registration Reply, in
> > > >    order (1) to make registration work faster, and also
> > > >    (2) to reduce network load for Mobile IP registration.
> >
> > Charles,
> >
> > Under what circmstances does registration not work fast enough ?
> >
> > Under what circumstances does the network load for Mobile IP
> > registration need to be reduced ?
> >
> > This draft implies that Mobile IP is not scalable without
> > additional infrastructure elements.  I completely disagree with
> > this implication.
>
> I didn't see that implication in the draft.  It wouldn't be something
> that I would write, as you may guess.  The circumstances you
> request are those for which the additional registration traffic
> is undesirable.  For instance, it could be that an access network

We need to explore the cases where it is desireable.

> has an Internet Gateway that is expensive for traffic in and out
> of the network.

What type of expense are you referring to ?

I don't believe the occassional mobile IP re-registration is
so expensive as to warrant a new layer of fixed heirarchy.
Is there some other traffic that would be too expensive ?

>
> > > First, regional registration is not mandatory.  If your
> > > product is not intended to be sold into a market that needs
> > > it, you do not have to implement.
> >
> > If the draft is solving a unique problem, then it may be useful.
> >
> > However, if implementing the draft is optional,
> > and there is no circumstance where the option is needed,
> > then we don't need an RFC for the option.
>
> Surely you didn't mean that.  Surely you can allow for the
> existence of RFCs to specify features that you do not have to
> implement.

I did mean that.  The circumstance that needs this is still not clear.
Without that we don't need a standard.  They only case that
is mentioned in the draft is handover, and it says "MAY" improve
performance.

>
> The option is needed where systems can be made to have
> better performance by localizing registrations.  Results have
> been published to show this, and it's intuitively obvious.

Performance by what criteria.  They typical criteria are:
CPU, Memory, Delay, Bandwidth.  You may have considered others.
Which criteria and under what circumstances is performance improved ?

No one is saying that a system can't implement the protocols and insert
a new layer of fixed heirarchy if the company chooses too.  Any company
is free to implement what they prefer.

But just because something is implemented, does not mean it should be a
standard.  We are discussing the merits for creating an IETF standard
which where benefits of implementing the standard should be obvious.
They aren't obvious or intuitively obvious with this draft.

But they could be if the right circumstance were described.

>
> > > Second, there are many distinct techniques that each produce
> > > some performance improvement.  You do not have to implement
> > > all of them or any of them, but I don't believe that means
> > > that the opportunity should be removed for those people who
> > > may need the additional performance improvement.
> >
> > The case for performance improvement in a specific circumstance
> > has not been made in this draft.
>
> Are you arguing now for a "Performance Considerations"?
> Does this go before or after the "IANA Considerations"?
> Can you point to other Proposed Standards with such text?

No, I am not arguing for "Performance Considerations".  Your draft
is arguing for performance considerations.  From the Introduction:
" By registering locally, the signaling delay is reduced, and this may
  improve the performance of handover."

The draft is claiming that it MAY improve performance for handover.

If it doesn't improve performance then we don't need the draft.

I don't think it improves performance.

But even if it does, it should be in the handover draft.

Otherwise, the handover draft is incomplete.

>
> > > Third, it's done.  It's not like we have to make a huge
> > > investment to produce the technology.  We already have it.
> > > There's no reason to prohibit people who want it from using it.
> >
> > By creating a draft that doesn't address any real world circumstance,
> > it looks like there is a problem with mobile IP when there is none.
> > This creates alot of confusion when it comes down to what protocols
> > and functions should be implemented.
>
> I'm not confused, and we have implemented systems where the
> protocol improves performance.  You don't have to, and from your
> comments I would guess you would not recommend doing so.

You can sell your systems.  You don't need an rfc to accomplish
that.

>
> >
> > > Fourth, regional registration does not reduce the frequency
> > > of handover.  It only localizes the resulting signaling.
> >
> > Looks like you are saying handover won't work without regional
> > registration.  I disagree with this.  If there is an issue not
> > addressed by the handover draft(s), it should be fixed there.
> > No need for another RFC.
>
> I did not say this.  I only say that handovers can work better and
> less expensively with regional registration.  Furthermore, I very

The handover draft is still a work in progress.  We should improve
that draft, not create another one.

> much disagree that every issue with handovers needs to be solved
> in one draft.  There are many techniques for improvement, and
> they should (MUST, even!) be treated separately.

If the handover draft was in rfc status, then I might agree.
But it's not.  We need to get handover working to the satisfaction
of the interested parties.  Anything that we know that makes handover
better should be in the handover draft.  At this point I am not convinced
that this draft makes handover better.

thanks,
Dana

>
> Regards,
> Charlie P.
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 12:04:30 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25117
	for ; Tue, 23 Apr 2002 12:04:29 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22869;
	Tue, 23 Apr 2002 09:04:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13842;
	Tue, 23 Apr 2002 09:03:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NG30Gs013091
	for ; Tue, 23 Apr 2002 09:03:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NG302K013090
	for mobile-ip-dist; Tue, 23 Apr 2002 09:03:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NG2wGs013083
	for ; Tue, 23 Apr 2002 09:02:58 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08329
	for ; Tue, 23 Apr 2002 12:02:59 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA12090
	for mobile-ip@sunroof.eng.sun.com; Tue, 23 Apr 2002 12:03:58 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NENDGs012648
	for ; Tue, 23 Apr 2002 07:23:13 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11683
	for ; Tue, 23 Apr 2002 07:23:14 -0700 (PDT)
From: Hemant.Chaskar@nokia.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23550
	for ; Tue, 23 Apr 2002 07:23:13 -0700 (PDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3NEPuH20828
	for ; Tue, 23 Apr 2002 09:25:57 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Tue, 23 Apr 2002 07:23:11 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 23 Apr 2002 09:23:10 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EAD2.64EDAD7B"
Subject: [mobile-ip] MIP QoS requirements draft - modification proposal for Section 3.3.2
Date: Tue, 23 Apr 2002 10:23:10 -0400
Message-ID: 
Thread-Topic: MIP QoS requirements draft - modification proposal for Section 3.3.2 
Thread-Index: AcHqNDQ65uuu1j4tQ4WuZBhJMq4cBQAnguWg
To: 
X-OriginalArrivalTime: 23 Apr 2002 14:23:10.0745 (UTC) FILETIME=[65590890:01C1EAD2]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1EAD2.64EDAD7B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

 Sorry, if you received multiple copies of this -
=20
 Hi:
=20
I received some comments privately that the text in Section 3.3.2 of =
draft-ietf-mobileip-qos-requirements-02.txt, is not clear enough. In =
response to that, I propose the following modification to this text. =
Please let me know if you have any comments, else I will go ahead and =
incorporate it in the next version (03) of the draft.
=20
Thanks,
Hemant
=20
Old text:
----------
=20
2. Interactions with link-layer support for QoS:
=20
The QoS mechanism MAY provide some information to the link layers for =
them to support the required QoS. Since a vast number of devices using =
Mobile IP will be connected to the Internet via wireless links, QoS =
parameters relevant for wireless links, such as error rate, MAY have to =
be included in the set of IP-level QoS parameters to be possibly =
considered by the underlying link layer.
=20
An example scenario will be two UDP streams requiring different levels =
of error protection at the link layer. For such cases, an IP-layer QoS =
mechanism may indicate some generic parameters such as acceptable IP =
packet loss rate to link layers.
=20
New text:
-----------
=20
2. Interactions with wireless link-layer support for QoS:
=20
Since a vast number of devices using Mobile IP will be connected to the =
Internet via wireless links, the QoS mechanism for Mobile IP MAY provide =
some information to the wireless link layers for them to support the =
required QoS.=20
  =20
An example scenario that may benefit from such information is that of =
the two UDP streams associated with the same media, but requiring =
different levels of error protection at the wireless link layer due to =
certain characteristics of their respective encoding schemes. The =
packets of these two streams are equally delay sensitive (so as to =
maintain playout synchronization at the receiver), and hence, may be =
treated equally (as regards queuing) by IP layer. But they may need to =
be transmitted on wireless channels of different error =
characteristics(say different FEC coding or power levels).
  =20
The QoS information included for the benefit of wireless link layers =
SHOULD be such that it is meaningful both ways: to applications that =
reside over IP so that they can choose the IP service of certain QoS =
characteristics and to wireless link QoS managers so that they can then =
map this information to the details of lower layer mechanisms and their =
parameters.
=20
In the example scenario described above, such a QoS information could be =
expressed as the acceptable loss rate of IP packets in the UDP stream. =
This parameter enables the UDP application to choose the IP service =
having QoS that matches its requirements, and it also enables the =
wireless link QoS managers to choose the right wireless channel to =
transmit the packets of this UDP stream.


------_=_NextPart_001_01C1EAD2.64EDAD7B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











 Sorry, if you received multiple copies of this=20
-


 


 Hi:


 


I received some comments privately =
that the text=20
in Section 3.3.2 of draft-ietf-mobileip-qos-requirements-02.txt, is not =
clear=20
enough. In response to that, I propose the following modification to =
this text.=20
Please let me know if you have any comments, else I will go ahead and=20
incorporate it in the next version (03) of the draft.


 


Thanks,
Hemant


 


Old text:
----------


 


2. Interactions with link-layer =
support for=20
QoS:


 


The QoS mechanism MAY provide some =
information to=20
the link layers for them to support the required QoS. Since a vast =
number of=20
devices using Mobile IP will be connected to the Internet via wireless =
links,=20
QoS parameters relevant for wireless links, such as error rate, MAY have =
to be=20
included in the set of IP-level QoS parameters to be possibly considered =
by the=20
underlying link layer.


 


An example scenario will be two UDP =
streams=20
requiring different levels of error protection at the link layer. For =
such=20
cases, an IP-layer QoS mechanism may indicate some generic parameters =
such as=20
acceptable IP packet loss rate to link layers.


 


New text:
-----------


 


2. Interactions with wireless =
link-layer support=20
for QoS:


 


Since a vast number of devices using =
Mobile IP=20
will be connected to the Internet via wireless links, the QoS mechanism =
for=20
Mobile IP MAY provide some information to the wireless link layers for =
them to=20
support the required QoS. 
   
An example scenario that =
may=20
benefit from such information is that of the two UDP streams associated =
with the=20
same media, but requiring different levels of error protection at the =
wireless=20
link layer due to certain characteristics of their respective encoding =
schemes.=20
The packets of these two streams are equally delay sensitive (so as to =
maintain=20
playout synchronization at the receiver), and hence, may be treated =
equally (as=20
regards queuing) by IP layer. But they may need to be transmitted on =
wireless=20
channels of different error characteristics(say different FEC coding or =
power=20
levels).
   
The QoS information included for the =
benefit of=20
wireless link layers SHOULD be such that it is meaningful both ways: to=20
applications that reside over IP so that they can choose the IP service =
of=20
certain QoS characteristics and to wireless link QoS managers so that =
they can=20
then map this information to the details of lower layer mechanisms and =
their=20
parameters.


 


In the example scenario described =
above, such a=20
QoS information could be expressed as the acceptable loss rate of IP =
packets in=20
the UDP stream. This parameter enables the UDP application to choose the =
IP=20
service having QoS that matches its requirements, and it also enables =
the=20
wireless link QoS managers to choose the right wireless channel to =
transmit the=20
packets of this UDP stream.


------_=_NextPart_001_01C1EAD2.64EDAD7B--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 12:18:36 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25858
	for ; Tue, 23 Apr 2002 12:18:35 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10570;
	Tue, 23 Apr 2002 10:18:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20562;
	Tue, 23 Apr 2002 09:18:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NGHWGs013283
	for ; Tue, 23 Apr 2002 09:17:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NGHW5B013282
	for mobile-ip-dist; Tue, 23 Apr 2002 09:17:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NGHTGs013275
	for ; Tue, 23 Apr 2002 09:17:29 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24410
	for ; Tue, 23 Apr 2002 09:17:30 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01537
	for ; Tue, 23 Apr 2002 09:17:30 -0700 (PDT)
Message-ID: <001001c1eae2$1cd5b2c0$356015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        "'Dana L. Blair '" ,
        "'Milind Kulkarni '" ,
        "'Madhavi W. Chandra '" 
Cc: "'Charles E. Perkins '" ,
        
References: <4DA6EA82906FD511BE2F00508BCF053802C6ACA7@Esealnt861.al.sw.ericsson.se>
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Tue, 23 Apr 2002 09:15:35 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

> => I would like to take this opportuntiy to re-interate
> a couple of facts:
>
> - We don't develop protocols in IETF for 3GPP or
>   3GPP2 only.
>
> - We don't have requirements in IETF to show product
>   plans to get a draft to proposed standard.
>
> I don¨t think the rules should be tailored per
> draft.
>


These aren't facts, they are policies.

As for 1, agreed,  but we do standards for implementation not research.
If nobody is planning on implementing something,
there is not much point in doing a standard, and,
as a practical matter, there is less grounds for people to
be reasonable and therefore more occasion to quibble about minor
points. The prospect of having to get a product out tends to focus
people's minds. Since the IETF really has enough to do, one
can question to wisdom of doing standards for something nobody
is planning on implementing.

But this is a judgement call and is entirely at the discretion of
the WG chairs. And, yes, they can change the rules per
draft if they want (which doesn't mean the WG members
can't complain about it :-)

            jak




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 12:40:31 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26876
	for ; Tue, 23 Apr 2002 12:40:30 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14112;
	Tue, 23 Apr 2002 10:40:27 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00302;
	Tue, 23 Apr 2002 09:40:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NGdTGs013407
	for ; Tue, 23 Apr 2002 09:39:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NGdT8V013406
	for mobile-ip-dist; Tue, 23 Apr 2002 09:39:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NGdQGs013399
	for ; Tue, 23 Apr 2002 09:39:26 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14307
	for ; Tue, 23 Apr 2002 09:39:27 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13485
	for ; Tue, 23 Apr 2002 10:39:27 -0600 (MDT)
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 JAA07557;
	Tue, 23 Apr 2002 09:39:26 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3NGdPR29377;
	Tue, 23 Apr 2002 09:39:25 -0700
X-mProtect: <200204231639> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdQjtFpO; Tue, 23 Apr 2002 09:39:23 PDT
Message-ID: <3CC58E3C.86B0C472@iprg.nokia.com>
Date: Tue, 23 Apr 2002 09:39:24 -0700
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Alper E. YEGIN" 
CC: James Kempf ,
        Manolis Sifalakis ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> <046701c1e804$7016f330$736015ac@AlperVAIO>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Alper and Jim,

Ok. This clarifies.. What happens if FBU is not received
but the old AR gets Link Down ? I think the old AR must not
tunnel packets then.

Regards,

-Rajeev


"Alper E. YEGIN" wrote:

> Rajeev,
>
> > > If the router gets a Link Down, this can be used to reduce the packet
> > > loss
> > > to just the L2 handover blackout period. Of course, if this trigger is
> > > not available, then the FBU must be used.
> > >
> > > Or was there some other reason why you feel the FBU must be the
> > > tunnel setup trigger?
> > >
> >
> > My concern is redirecting traffic without explicit consent from the
> > MN. Is "Link Down" enough authorization to start forwarding
> > traffic on the tunnel ? I am not sure.. The base protocol itself has to
> > operate with FBU, which authorizes the AR to refirect traffic.
>
> F-BU is always a must. The feature is: if the network supports
> link-down trigger, oldAR can further wait (after receiving F-BU)
> for this trigger to change the routing.
>
>  So, this is an additional optimization to change the routing at
> the exact point in time (L2 event), and relies on link-layer triggers.
>
> We must already have this stated (probably not clear enough) in the draft.
>
> alper



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 13:00:08 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27563
	for ; Tue, 23 Apr 2002 13:00:08 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25190;
	Tue, 23 Apr 2002 11:00:09 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09736;
	Tue, 23 Apr 2002 09:59:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NGxCGs013568
	for ; Tue, 23 Apr 2002 09:59:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NGxBpU013567
	for mobile-ip-dist; Tue, 23 Apr 2002 09:59:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NGx8Gs013560
	for ; Tue, 23 Apr 2002 09:59:08 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21365
	for ; Tue, 23 Apr 2002 09:59:10 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02045
	for ; Tue, 23 Apr 2002 09:59:10 -0700 (PDT)
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 JAA08815;
	Tue, 23 Apr 2002 09:59:10 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3NGx9026066;
	Tue, 23 Apr 2002 09:59:09 -0700
X-mProtect: <200204231659> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdQkvtMX; Tue, 23 Apr 2002 09:59:06 PDT
Message-ID: <3CC592DA.FE0FC950@iprg.nokia.com>
Date: Tue, 23 Apr 2002 09:59:06 -0700
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Francis Dupont 
CC: rene.purnadi@nokia.com, brett.pentland@eng.monash.edu.au,
        kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality
References: <200204231424.g3NEOfT65815@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis Dupont wrote:

>    A mobile node should aware that a layer 2 handover has
>   occurred. For example, in cellular, the MN is given a radio resources
>   information in the target access point to be acquired. Once it
>   acquires the radio link in the target access point, the mobile node
>   can start the layer 3 procedure. I don't know what is the motivation
>   for the mobile node to perform L3 handover quickly, but definitely the
>   mobile node know that L2 handover has been completed (in UMTS the
>   mobile node even send L2 message).
>
> => in your description it is very cler than the target access point
> knows the handover occurs. So it can help to make L3 handover faster,
> for instance by caching a RA, by triggering a RA by sending itself a RS,
> etc. One can imagine many ways, all of them are better than to mess
> the neighbor discovery protocol.
> About UMTS, if the context type is PPP the peer is the access router,
> if it is IPv6 the GGSN is the access router: in all cases a RA will be sent
> without a RS and the L3 handover as quick as possible without FMIPv6.
>

Some comments on the last sentence..

- quickly receiving an RA is not equivalent to fast handover (in case you
implied it that way).  Anyway, a fast IP handover problem can be
characterized as "how quickly the MN can send _and_ receive IP
packets at its new point of attachment".

- regarding the ability to send packets as soon as possible, quickly
getting an RA helps. In general however, the address acquisition latency
depends on ND including DAD which imposes substantial latency.

- regarding the ability to receive packets as soon as a new link is
available, you need to consider the route-update (BU) latency. FMIPv6
moves BU out of time-sensitive path by having a tunnel from previous
router to the new one. Here, quickly getting an RA can help to the extent
of expediting the transmission of BU. However, packets sent by a CN
before the new IP address is registered at the CN are lost without a
forwarding path from previous router to the new one.

Regards,

-Rajeev


>
> Thanks
>
> Francis.Dupont@enst-bretagne.fr



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 13:40:13 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28840
	for ; Tue, 23 Apr 2002 13:40:13 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16781;
	Tue, 23 Apr 2002 11:40:14 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29719;
	Tue, 23 Apr 2002 10:40:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NHdCGs013735
	for ; Tue, 23 Apr 2002 10:39:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NHdC14013734
	for mobile-ip-dist; Tue, 23 Apr 2002 10:39:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NHd8Gs013727
	for ; Tue, 23 Apr 2002 10:39:08 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29005
	for ; Tue, 23 Apr 2002 10:39:08 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20118
	for ; Tue, 23 Apr 2002 10:39:08 -0700 (PDT)
Message-ID: <00d801c1eaed$87f47c20$356015ac@T23KEMPF>
From: "James Kempf" 
To: "Rajeev Koodli" ,
        "Alper E. YEGIN" 
Cc: "Manolis Sifalakis" ,
        
References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> <046701c1e804$7016f330$736015ac@AlperVAIO> <3CC58E3C.86B0C472@iprg.nokia.com>
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
Date: Tue, 23 Apr 2002 10:37:20 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Rajeev,

I suppose your reasoning for this is because the tunnel terminates at
the MN and not the AR, correct? So the FBU is the indication that the MN
is ready to take packets at the new CoA. Without that, the AR acting as
an on-link HA doesn't know that the MN is established on the new link.

If that is it, then I agree.

            jak

----- Original Message -----
From: "Rajeev Koodli" 
To: "Alper E. YEGIN" 
Cc: "James Kempf" ; "Manolis Sifalakis"
; 
Sent: Tuesday, April 23, 2002 9:39 AM
Subject: Re: [mobile-ip] some questions about
draft-ietf-mobileip-fast-mipv6-04


>
> Hello Alper and Jim,
>
> Ok. This clarifies.. What happens if FBU is not received
> but the old AR gets Link Down ? I think the old AR must not
> tunnel packets then.
>
> Regards,
>
> -Rajeev
>
>
> "Alper E. YEGIN" wrote:
>
> > Rajeev,
> >
> > > > If the router gets a Link Down, this can be used to reduce the
packet
> > > > loss
> > > > to just the L2 handover blackout period. Of course, if this
trigger is
> > > > not available, then the FBU must be used.
> > > >
> > > > Or was there some other reason why you feel the FBU must be the
> > > > tunnel setup trigger?
> > > >
> > >
> > > My concern is redirecting traffic without explicit consent from
the
> > > MN. Is "Link Down" enough authorization to start forwarding
> > > traffic on the tunnel ? I am not sure.. The base protocol itself
has to
> > > operate with FBU, which authorizes the AR to refirect traffic.
> >
> > F-BU is always a must. The feature is: if the network supports
> > link-down trigger, oldAR can further wait (after receiving F-BU)
> > for this trigger to change the routing.
> >
> >  So, this is an additional optimization to change the routing at
> > the exact point in time (L2 event), and relies on link-layer
triggers.
> >
> > We must already have this stated (probably not clear enough) in the
draft.
> >
> > alper
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 16:57:38 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06505
	for ; Tue, 23 Apr 2002 16:57:38 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14851;
	Tue, 23 Apr 2002 14:57:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22708;
	Tue, 23 Apr 2002 13:57:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NKu8Gs014502
	for ; Tue, 23 Apr 2002 13:56:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NKu81p014501
	for mobile-ip-dist; Tue, 23 Apr 2002 13:56:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NKu5Gs014494
	for ; Tue, 23 Apr 2002 13:56:05 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22196
	for ; Tue, 23 Apr 2002 13:56:05 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14442
	for ; Tue, 23 Apr 2002 13:56:05 -0700 (PDT)
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 NAA24682;
	Tue, 23 Apr 2002 13:56:05 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3NKu2200769;
	Tue, 23 Apr 2002 13:56:02 -0700
X-mProtect: <200204232056> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdThtMiJ; Tue, 23 Apr 2002 13:56:00 PDT
Message-ID: <3CC5CA61.E210D29F@iprg.nokia.com>
Date: Tue, 23 Apr 2002 13:56:01 -0700
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: "Alper E. YEGIN" ,
        Manolis Sifalakis ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> <046701c1e804$7016f330$736015ac@AlperVAIO> <3CC58E3C.86B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Jim,

James Kempf wrote:

> Rajeev,
>
> I suppose your reasoning for this is because the tunnel terminates at
> the MN and not the AR, correct? So the FBU is the indication that the MN
> is ready to take packets at the new CoA. Without that, the AR acting as
> an on-link HA doesn't know that the MN is established on the new link.
>

Right. More generally, FBU must authorize packet forwarding
on the tunnel independent of where the tunnel terminates as long as the
packets are destined for the MN. The issue is who has control over the
forwarding of MN's packets. If a MN has chosen a node as its AR, that
node has an obligation to forward packets to the MN. If the MN moves to a
new
location, it is the IP layer at the MN that is responsible for authorizing
the redirection to the new location. At least, IP layer authorization is
what
is of relevance to FMIPv6. Of course, if link-specific optimizations are
feasible, they should be available as options. They cannot be used as
substitutes for FBU for traffic redirection however.

Regards,

-Rajeev


>
> If that is it, then I agree.
>
>             jak
>
> ----- Original Message -----
> From: "Rajeev Koodli" 
> To: "Alper E. YEGIN" 
> Cc: "James Kempf" ; "Manolis Sifalakis"
> ; 
> Sent: Tuesday, April 23, 2002 9:39 AM
> Subject: Re: [mobile-ip] some questions about
> draft-ietf-mobileip-fast-mipv6-04
>
> >
> > Hello Alper and Jim,
> >
> > Ok. This clarifies.. What happens if FBU is not received
> > but the old AR gets Link Down ? I think the old AR must not
> > tunnel packets then.
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> > "Alper E. YEGIN" wrote:
> >
> > > Rajeev,
> > >
> > > > > If the router gets a Link Down, this can be used to reduce the
> packet
> > > > > loss
> > > > > to just the L2 handover blackout period. Of course, if this
> trigger is
> > > > > not available, then the FBU must be used.
> > > > >
> > > > > Or was there some other reason why you feel the FBU must be the
> > > > > tunnel setup trigger?
> > > > >
> > > >
> > > > My concern is redirecting traffic without explicit consent from
> the
> > > > MN. Is "Link Down" enough authorization to start forwarding
> > > > traffic on the tunnel ? I am not sure.. The base protocol itself
> has to
> > > > operate with FBU, which authorizes the AR to refirect traffic.
> > >
> > > F-BU is always a must. The feature is: if the network supports
> > > link-down trigger, oldAR can further wait (after receiving F-BU)
> > > for this trigger to change the routing.
> > >
> > >  So, this is an additional optimization to change the routing at
> > > the exact point in time (L2 event), and relies on link-layer
> triggers.
> > >
> > > We must already have this stated (probably not clear enough) in the
> draft.
> > >
> > > alper
> >
> >



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 17:57:31 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07744
	for ; Tue, 23 Apr 2002 17:57:31 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07345;
	Tue, 23 Apr 2002 15:57:31 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18635;
	Tue, 23 Apr 2002 14:57:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NLtbGs014698
	for ; Tue, 23 Apr 2002 14:55:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NLtb76014697
	for mobile-ip-dist; Tue, 23 Apr 2002 14:55:37 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NLtWGs014690
	for ; Tue, 23 Apr 2002 14:55:32 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06389
	for ; Tue, 23 Apr 2002 14:55:30 -0700 (PDT)
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15212
	for ; Tue, 23 Apr 2002 15:55:29 -0600 (MDT)
Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP id 7936D16A4
	for ; Tue, 23 Apr 2002 14:59:42 -0700 (PDT)
Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162])
	by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id BCF1C1A12
	for ; Tue, 23 Apr 2002 17:55:27 -0400 (EDT)
Received: from compaq.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM)
	id RAA0001503737; Tue, 23 Apr 2002 17:55:27 -0400 (EDT)
Message-ID: <3CC5D84F.157CBA29@compaq.com>
Date: Tue, 23 Apr 2002 17:55:27 -0400
From: Brian Haley 
Organization: Tru64 UNIX Networking
X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V5.1 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile ip 
Subject: [mobile-ip] S-bit and building a link-local address
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi,

I have an issue with the use of the S-bit in Binding Updates.

I'll start with a hard question:

Where can I find the spec/RFC that defines how to build a link-local address
from a global unicast address?

The BU only has the global address, and I think everyone's assuming /64 prefix
lengths, but according to the addressing architecture
(draft-ietf-ipngwg-addr-arch-v3-07.txt, soon to update RFC 2373), that's not
the case:

Section 2.5.4 on Global Unicast Addresses

  "All global unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in section 2.5.1.  Global unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field."

I've been struggling with this one for a while, but it doesn't seem like we
can just mask-off the upper 64 bits, stuff an FE80 in there, and call it a
link-local address.  This isn't even considering the IPv6-over-foo RFCs.

So if that question can't be answered, I feel the S-bit must be removed
from the draft, unless someone is willing to write-up the method in
question, but since building link-local addresses has media type
implications, I wasn't going to go there.

This also has ramifications with the D-bit since Section 9.1 of the
Mobile IPv6 spec says we must do DAD for the link-local address.

Am I missing something here?

-Brian



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 18:06:42 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07941
	for ; Tue, 23 Apr 2002 18:06:42 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27815;
	Tue, 23 Apr 2002 16:06:43 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22239;
	Tue, 23 Apr 2002 15:06:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NM5kGs014822
	for ; Tue, 23 Apr 2002 15:05:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NM5ktI014821
	for mobile-ip-dist; Tue, 23 Apr 2002 15:05:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NM5hGs014814
	for ; Tue, 23 Apr 2002 15:05:43 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21894
	for ; Tue, 23 Apr 2002 15:05:44 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20349
	for ; Tue, 23 Apr 2002 16:05:43 -0600 (MDT)
Message-ID: <004501c1eb12$036abcb0$396015ac@AlperVAIO>
From: "Alper E. YEGIN" 
To: "Rajeev Koodli" 
Cc: "James Kempf" ,
        "Manolis Sifalakis" ,
        
References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> <046701c1e804$7016f330$736015ac@AlperVAIO> <3CC58E3C.86B0C472@iprg.nokia.com>
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
Date: Tue, 23 Apr 2002 14:58:30 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

>
> Hello Alper and Jim,
>
> Ok. This clarifies.. What happens if FBU is not received
> but the old AR gets Link Down ? I think the old AR must not
> tunnel packets then.

yes.

alper


>
> Regards,
>
> -Rajeev
>
>
> "Alper E. YEGIN" wrote:
>
> > Rajeev,
> >
> > > > If the router gets a Link Down, this can be used to reduce the
packet
> > > > loss
> > > > to just the L2 handover blackout period. Of course, if this trigger
is
> > > > not available, then the FBU must be used.
> > > >
> > > > Or was there some other reason why you feel the FBU must be the
> > > > tunnel setup trigger?
> > > >
> > >
> > > My concern is redirecting traffic without explicit consent from the
> > > MN. Is "Link Down" enough authorization to start forwarding
> > > traffic on the tunnel ? I am not sure.. The base protocol itself has
to
> > > operate with FBU, which authorizes the AR to refirect traffic.
> >
> > F-BU is always a must. The feature is: if the network supports
> > link-down trigger, oldAR can further wait (after receiving F-BU)
> > for this trigger to change the routing.
> >
> >  So, this is an additional optimization to change the routing at
> > the exact point in time (L2 event), and relies on link-layer triggers.
> >
> > We must already have this stated (probably not clear enough) in the
draft.
> >
> > alper
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 18:53:56 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08954
	for ; Tue, 23 Apr 2002 18:53:55 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03965;
	Tue, 23 Apr 2002 15:53:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02329;
	Tue, 23 Apr 2002 15:53:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NMpUGs014953
	for ; Tue, 23 Apr 2002 15:51:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NMpUaU014952
	for mobile-ip-dist; Tue, 23 Apr 2002 15:51:30 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NMpRGs014945
	for ; Tue, 23 Apr 2002 15:51:27 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01831
	for ; Tue, 23 Apr 2002 15:51:28 -0700 (PDT)
Received: from hosting-network.com (NODE1.HOSTING-NETWORK.COM [66.216.6.1] (may be forged))
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA09892
	for ; Tue, 23 Apr 2002 16:51:28 -0600 (MDT)
Received: (qmail 90596 invoked from network); 23 Apr 2002 22:52:52 -0000
Received: from unknown (HELO dell8100rjm) (12.251.150.156)
  by node-28.hosting-network.com with SMTP; 23 Apr 2002 22:52:52 -0000
Reply-To: 
From: "Robert J Marks" 
To: "'Ahmad Muhanna'" ,
        "'Tony Johansson'" 
Cc: "'Fredrik Johansson'" ,
        , 
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
Date: Tue, 23 Apr 2002 17:48:21 -0500
Organization: Marks Mobile Consulting, LLC
Message-ID: <00e201c1eb18$f8a35240$6401a8c0@dell8100rjm>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00E3_01C1EAEF.0FCD4A40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC1B@zrc2c013.us.nortel.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_00E3_01C1EAEF.0FCD4A40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Ahmad,
 
I'm still not totally comfortable with this new technique and its impact
on bandwidth-constrained links.
 
For RFC2002, the MN sent only the authentication extensions it knew it
needed. It knew if it had a
security association with the FA, and had to have a security association
with the HA.
 
For RFC3012, the MN could use the presence (or absence) of the Challenge
to determine which
extensions and parameters (like NAI) it included in the Registration
Request.
 
But for this new I-D, the MN does not get any clue at all. Therefore it
needs to include the extension
because it might be needed. This, it seems to me, is not so good for
bandwidth-constrained links.
As Tony pointed out, it seems that the MN must be configured to send or
not to send - I'd rather the
FA provided some clue.
 
Bob
 
-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna
Sent: Monday, April 22, 2002 3:38 PM
To: 'Tony Johansson'; bob@marksmob.com
Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
fredrik@ipunplugged.com
Subject: RE: [mobile-ip] RE: A Question
about:draft-ietf-mobileip-aaa-nai-00.txt



Hi Bob; 

Let me add to what Tony just said. 
I do not think that any MN needs to know anything about the type 
of AAA infrastructure the FA and HA are using to authenticate the MN. 
However, the MN Application is developed with certain standard in mind. 
(certain method of authentication) 

for example: 
1. ONLY RFC2002 Compliant MN: 
It assumes that it has a security association with both the FA and the 
HA. If it visit any FA where it shares a security association with, MN
sends 
RRQ message with MN-FA Authentication extension and it works just fine. 

2. ONLY RFC2002 & RFC3012 Compliant MN: 

RFC 3012 addressed properly the case of MN in 1 but offered a new 
mechanism for authenticating the MN to the FA using the FA Challenge 
and MN-AAA authentication extension. 

3. Now Latest MN with all of the above (RFC3220) and diameter compliant:

MN includes AAA NAI extension and those FA which support diameter 
will use process it and those FA which does not support AAA NAI
(skippable) 
will continue to use either method in 2 or 1. 


Regards; 
Ahmad Muhanna 


> -----Original Message----- 
> From: Tony Johansson [mailto:tony.johansson@ericsson.com] 
> Sent: Monday, April 22, 2002 4:15 PM 
> To: bob@marksmob.com 
> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Fredrik Johansson'; 
> mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com 
> Subject: Re: [mobile-ip] RE: A Question 
> about:draft-ietf-mobileip-aaa-nai-00.txt 
> 
> 
> Hi Bob, 
> 
> Yes, it's based on MN configuration and FA configuration. Same as e.g 
> the handling of RFC3012/RFC3012bis and the 
> draft-ietf-mobileip-aaa-key-09.txt. 
> 
> The advertisements will not tell you anything reading this. 
> 
> /Tony 
> 
> Robert J Marks wrote: 
> 
> >  Perhaps someone can explain how the MN knows the type of AAA 
> > infrastructure used by the FA nd HA. I don't believe any information

> > is included in any advertisement. Does this "solution" rely 
> only upon 
> > MN configuration, or am I missing something here? Thanks.Bob 
> > -----Original Message----- 
> > From: owner-mobile-ip@sunroof.eng.sun.com 
> > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad 
> > Muhanna 
> > Sent: Monday, April 22, 2002 1:59 PM 
> > To: 'Tony Johansson' 
> > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> > fredrik@ipunplugged.com 
> > Subject: RE: [mobile-ip] RE: A Question 
> > about:draft-ietf-mobileip-aaa-nai-00.txt 
> > 
> > Hello Tony; 
> > YES; this solves the problem. 
> > 
> > Regards; 
> > Ahmad Muhanna 
> > 
> > > -----Original Message----- 
> > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] 
> > > Sent: Monday, April 22, 2002 2:51 PM 
> > > To: Muhanna, Ahmad [RICH1:2Q20:EXCH] 
> > > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> > > fredrik@ipunplugged.com 
> > > Subject: Re: [mobile-ip] RE: A Question 
> > > about:draft-ietf-mobileip-aaa-nai-00.txt 
> > > 
> > > 
> > > Hello Ahmad, 
> > > 
> > > Ahmad Muhanna wrote: 
> > > 
> > > 
> > > > I do not think that It is the same!! 
> > > > RFC3012 introduced a new way of authenticating the MN to the FA 
> > > > without violating 
> > > > backward compatibility of RFC2002 or later RFC3220. 
> > > > Mobile Node does not know which way or the standard the 
> > > foreign agent 
> > > > uses to 
> > > > authenticate it. It could be through RADIUS, AAA, Diameter 
> > > who knows. 
> > > 
> > > > 
> > > > The point here is that this draft mandates that every 
> Mobile Node 
> > > > include AAA NAI extension 
> > > > with subtype of 1 whenever it requests static Mobile IP 
> or during 
> > > > Inter-FA handoff. 
> > > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile 
> > > Node which 
> > > > exist right now, 
> > > > does not do this. 
> > > > After this draft becomes a standard, according to this 
> > > section, MN is 
> > > > not following the 
> > > > standard by not sending AAA NAI extension in initial 
> Registration 
> > > > Request or during re-authentication.!!! 
> > > > 
> > > > This is not backward compatible!!!! 
> > > 
> > > Okay, so how about adding the following statement to the 
> > introduction: 
> > > 
> > > "The AAA NAI extension MUST only be used with the Diameter Mobile 
> > IPv4 
> > > application and MUST NOT be used with any other AAA protocol." 
> > > 
> > > 
> > > 
> > > /Tony 
> > > 
> > > 
> > > 
> 
> 


------=_NextPart_000_00E3_01C1EAEF.0FCD4A40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




Message




Hello=20
Ahmad,


 


I'm=20
still not totally comfortable with this new technique and its impact on=20
bandwidth-constrained links.


 


For=20
RFC2002, the MN sent only the authentication extensions it knew it =
needed. It=20
knew if it had a


security association with the FA, and had to have a security =
association=20
with the HA.


 


For=20
RFC3012, the MN could use the presence (or absence) of the Challenge to=20
determine which


extensions and parameters (like NAI) it included in the =
Registration=20
Request.


 


But=20
for this new I-D, the MN does not get any clue at all. Therefore it =
needs to=20
include the extension


because it might be needed. This, it seems to me, is not so =
good for=20
bandwidth-constrained links.


As=20
Tony pointed out, it seems that the MN must be configured to send or not =
to send=20
- I'd rather the


FA=20
provided some clue.


 


Bob


 




-----Original Message-----
From:=20
owner-mobile-ip@sunroof.eng.sun.com =
[mailto:owner-mobile-ip@sunroof.eng.sun.com]=20
On Behalf Of Ahmad Muhanna
Sent: Monday, April 22, 2002 =
3:38=20
PM
To: 'Tony Johansson'; bob@marksmob.com
Cc: =
'Fredrik=20
Johansson'; mobile-ip@sunroof.eng.sun.com;=20
fredrik@ipunplugged.com
Subject: RE: [mobile-ip] RE: A =
Question=20
about:draft-ietf-mobileip-aaa-nai-00.txt



Hi Bob; 


Let me add to what Tony just said. 
I do=20
not think that any MN needs to know anything about the type =

of AAA infrastructure the FA and HA are using to authenticate =
the=20
MN. 
However, the MN Application is developed =
with=20
certain standard in mind. 
(certain method of=20
authentication) 


for example: 
1. ONLY RFC2002 =
Compliant=20
MN: 
It assumes that it has a security =
association with=20
both the FA and the 
HA. If it visit any FA =
where it=20
shares a security association with, MN sends 
RRQ message=20
with MN-FA Authentication extension and it works just fine. 


2. ONLY RFC2002 & RFC3012 Compliant MN: =



RFC 3012 addressed properly the case of MN in 1 but =
offered a=20
new 
mechanism for authenticating the MN to the =
FA using=20
the FA Challenge 
and MN-AAA authentication=20
extension. 


3. Now Latest MN with all of the above (RFC3220) and =
diameter=20
compliant: 
MN includes AAA NAI extension and =
those FA=20
which support diameter 
will use process it and =
those FA=20
which does not support AAA NAI (skippable) 
will continue=20
to use either method in 2 or 1. 



Regards; 
Ahmad =
Muhanna 



> -----Original Message----- 
>=20
From: Tony Johansson [mailto:tony.johansson@ericsso=
n.com]=20

> Sent: Monday, April 22, 2002 4:15 PM =

> To: bob@marksmob.com 
> Cc: =
Muhanna, Ahmad=20
[RICH1:2Q20:EXCH]; 'Fredrik Johansson'; 
>=20
mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com 
> Subject: Re: [mobile-ip] RE: A Question 
>=20
about:draft-ietf-mobileip-aaa-nai-00.txt 
>=20

> 
> Hi =
Bob,=20

> 
> Yes, it's based =
on MN=20
configuration and FA configuration. Same as e.g 
> the=20
handling of RFC3012/RFC3012bis and the 
>=20
draft-ietf-mobileip-aaa-key-09.txt. 
>=20

> The advertisements will not tell you =
anything=20
reading this. 
> 
>=20
/Tony 
> 
> =
Robert J Marks=20
wrote: 
> 
> =
> =20
Perhaps someone can explain how the MN knows the type of AAA =

> > infrastructure used by the FA nd HA. I don't believe =
any=20
information 
> > is included in any =
advertisement.=20
Does this "solution" rely 
> only =
upon=20

> > MN configuration, or am I missing something =
here?=20
Thanks.Bob 
> > -----Original =
Message-----=20

> > From: =
owner-mobile-ip@sunroof.eng.sun.com=20

> > [mailto:owner-mobile-i=
p@sunroof.eng.sun.com]=20
On Behalf Of Ahmad 
> > Muhanna =

> > Sent: Monday, April 22, 2002 1:59 PM 
> > To: 'Tony Johansson' 
> =
> Cc:=20
'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
>=20
> fredrik@ipunplugged.com 
> > =
Subject: RE:=20
[mobile-ip] RE: A Question 
> >=20
about:draft-ietf-mobileip-aaa-nai-00.txt 
>=20
> 
> > Hello Tony; 
>=20
> YES; this solves the problem. 
> =
>=20

> > Regards; 
> =
> Ahmad=20
Muhanna 
> > 
> > >=20
-----Original Message----- 
> > > =
From: Tony=20
Johansson [mailto:tony.johansson@ericsso=
n.com]=20

> > > Sent: Monday, April 22, 2002 2:51 =
PM=20

> > > To: Muhanna, Ahmad =
[RICH1:2Q20:EXCH]=20

> > > Cc: 'Fredrik Johansson';=20
mobile-ip@sunroof.eng.sun.com; 
> > >=20
fredrik@ipunplugged.com 
> > > =
Subject: Re:=20
[mobile-ip] RE: A Question 
> > >=20
about:draft-ietf-mobileip-aaa-nai-00.txt 
> =
>=20
> 
> > > 
> >=20
> Hello Ahmad, 
> > > =

> > > Ahmad Muhanna wrote: 
> >=20
> 
> > > 
> >=20
> > I do not think that It is the same!! 
> >=20
> > RFC3012 introduced a new way of authenticating the MN to the =
FA=20

> > > > without violating =

> > > > backward compatibility of RFC2002 or later=20
RFC3220. 
> > > > Mobile Node does =
not know=20
which way or the standard the 
> > > =
foreign=20
agent 
> > > > uses to =

> > > > authenticate it. It could be through =
RADIUS, AAA,=20
Diameter 
> > > who knows. =

> > > 
> > > =
>=20

> > > > The point here is that this draft =
mandates=20
that every 
> Mobile Node 
>=20
> > > include AAA NAI extension 
> =
> >=20
> with subtype of 1 whenever it requests static Mobile IP =

> or during 
> > > > =
Inter-FA=20
handoff. 
> > > > Now: (Standard =
Compliant=20
RFC3220, RFC3012bis) Legacy Mobile 
> > =
> Node=20
which 
> > > > exist right =
now,=20

> > > > does not do this. =

> > > > After this draft becomes a standard, =
according to=20
this 
> > > section, MN is =

> > > > not following the 
> >=20
> > standard by not sending AAA NAI extension in initial =

> Registration 
> > > > =
Request or=20
during re-authentication.!!! 
> > > =
>=20

> > > > This is not backward =
compatible!!!!=20

> > > 
> > =
> Okay, so=20
how about adding the following statement to the 
>=20
> introduction: 
> > > =

> > > "The AAA NAI extension MUST only be used with =
the Diameter=20
Mobile 
> > IPv4 
> >=20
> application and MUST NOT be used with any other AAA =
protocol."=20

> > > 
> > =
>=20

> > > 
> > =
>=20
/Tony 
> > > 
> >=20
> 
> > > 
>=20

> 


------=_NextPart_000_00E3_01C1EAEF.0FCD4A40--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 18:58:45 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09122
	for ; Tue, 23 Apr 2002 18:58:45 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16071;
	Tue, 23 Apr 2002 15:58:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04888;
	Tue, 23 Apr 2002 15:58:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NMuvGs015051
	for ; Tue, 23 Apr 2002 15:56:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NMuvau015050
	for mobile-ip-dist; Tue, 23 Apr 2002 15:56:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NMurGs015043
	for ; Tue, 23 Apr 2002 15:56:53 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09542
	for ; Tue, 23 Apr 2002 15:56:55 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13713
	for ; Tue, 23 Apr 2002 16:56:53 -0600 (MDT)
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 PAA02835;
	Tue, 23 Apr 2002 15:56:52 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3NMuox27557;
	Tue, 23 Apr 2002 15:56:50 -0700
X-mProtect: <200204232256> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdF0YAuI; Tue, 23 Apr 2002 15:56:48 PDT
Message-ID: <3CC5E6B1.56C64F31@iprg.nokia.com>
Date: Tue, 23 Apr 2002 15:56:49 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Luca Salgarelli 
CC: Ahmad Muhanna ,
        "'mobile-ip@sunroof.eng.sun.com'" 
Subject: Re: Proposed changes to rfc3012bis [was: RE: [mobile-ip] 
 RFC3012-bis:compatibility issues]
References: <6B49EDFE974BD51197D70002A56079D801AFCB8C@zrc2c013.us.nortel.com>
		<1018366772.14738.32.camel@valjean>  <3CB30E26.FFDB3D6@iprg.nokia.com> <1018368815.14897.51.camel@valjean>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Luca and Ahmad,

I guess it's about time to send out rfc3012bis if possible.

I think the text should be written to improve scalability,
according your original observations, and yet maintain the
most reasonable flexibility for mobile nodes.  I think we
can mandate that mobile nodes MUST NOT use old challenges.
On the other hand, I think we should encourage implementors
to build CHALLENGE_WINDOW always at least 2.  That would
eliminate many failures caused if a mobile node happens to
use a challenge just after the foreign agent changed to a
new challenge.

>    to the Mobile Node, or else advertised as one of the last
>    CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
>    immediately preceding Agent advertisements.  If the Challenge is
>    not one of the recently advertised values, the foreign Agent SHOULD
>    send a Registration Reply with Code value UNKNOWN_CHALLENGE (see
>    section 10). The Foreign Agent SHOULD keep records for all
>    challenges used by a Mobile Node that are still in the valid
>    CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep
>    records for all such previously used challenges, the Foreign Agent
>    MUST set its CHALLENGE_WINDOW to 1.

I would replace the  block as follows:

     The Foreign Agent MUST maintain the last challenge used by
     each Mobile Node that has successfully registered using
     any one of the last CHALLENGE_WINDOW challenge values.
     This last challenge value can be stored as part of the
     mobile node's registration records.

This uses the knowledge that mobile nodes MUST NOT use
previous challenges.  To this end, I would add the following
restriction at the end of section 4:

     Suppose the Mobile Node has successfully registered using one of
     the Challenge Values within the CHALLENGE_WINDOW values advertised
     by the Foreign Agent.  In that case, in any new Registration
     Request the Mobile Node MUST NOT use any Challenge Value which was
     advertised by the Foreign Agent before the Challenge Value in its
     last successful Registration Request.

With these two mandates, the total storage required by the foreign
agent for all Challenge Values amounts to (2N + CHALLENGE_WINDOW),
where N is the number of mobile nodes currently being served by
the Foreign Agent.  N of the stored values are for the "last
challenge used", and the other N may have come from Registration
Reply messages.  It shouldn't be any problem at all to have
the CHALLENGE_WINDOW > 1 (i.e., >= 2).

The foreign agent can use the following algorithm:

current_chal := RegistrationRequest.challenge_extension_value
last_chal := mobile_node_record.last_chal

if (current_chal == mobile_node_record.RegReply_challenge) {
	update (mobile_node_record, current_chal)
	return (OK)
}
else if (current_chal "among" VALID_CHALLENGES[]{
	if (last_chal "among" VALID_CHALLENGES[]) {
		if (current_chal is "before" last_chal) {
			send_error(INVALID_CHALLENGE)
			return (FAILURE)
		}
		else {
			update (mobile_node_record, current_chal)
			return (OK)
		}
	}
	else {
		update (mobile_node_record, current_chal)
		return (OK)

	}
}
else {
	send_error(UNKNOWN_CHALLENGE);
}

What this says, is that the challenge used by the Mobile Node
has to either be the one in the previous Registration Reply, or it
has to be in the set of valid challenges, but not one of the
valid challenges which was advertised previous to the "last"
challenge used by the mobile node.

If you like this algorithm, then I need to create a terminology
for "invalid challenge" and an error message to go with it.
If you _really_ like it, I can include it in an appendix, along
with any bug fixes or revisions you may suggest.

Finally, regarding that sentence in the definition for "stale challenge":

Ahmad Muhanna wrote:

>> --------------
>> Page 2: Delete sentence.
>>
>>       stale challenge
>>                Same as "previously used challenge".  The Foreign Agent
>>                may not be able to keep records for all stale
>> challenges.
>>
>>
>> Delete last sentence. Text becomes:
>>
>>       stale challenge
>>                Same as "previously used challenge".
>>
>
> I do not see why we need to remove this line. This addresses all kinds of
> stale challenges including those which are sent in the unicast
> advertisement and the Registration Reply.  The most important point, I do
> not see any contradiction by leaving this line and your proposed text below.
> Basically, the below text allows what the deleted line suggest BUT put
> some restriction to avoid any security holes for one kind of challenges.
> 
> What do you think?

How about if we put the sentence in question somewhere after the
list of terms in section 1.1?  That way, at least the observation
would not be construed to apply unequally between "stale challenge"
and "previously used challenge".

By the way, I guess up until now nobody mentioned that the
following text in section 1.1 was an incomplete sentence:

   The following additional terminology

In fact, it looks like to me that the section is not finished,
and that there always needed to be a definition for a "valid
challenge".


If this is good enough to close these issues, and if there are no
other issues, I would like to send out rfc3012bis this week.
I do not have any records about other issues that I can find.
If this is O.K., then I think the revised draft will probably
be ready for Last Call.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 19:03:30 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09210
	for ; Tue, 23 Apr 2002 19:03:30 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15156;
	Tue, 23 Apr 2002 17:03:27 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07346;
	Tue, 23 Apr 2002 16:03:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NN24Gs015158
	for ; Tue, 23 Apr 2002 16:02:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NN24jZ015157
	for mobile-ip-dist; Tue, 23 Apr 2002 16:02:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NN21Gs015150
	for ; Tue, 23 Apr 2002 16:02:01 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11540
	for ; Tue, 23 Apr 2002 16:02:02 -0700 (PDT)
Received: from p2.piuha.net (p2.piuha.net [131.160.192.2])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18033
	for ; Tue, 23 Apr 2002 16:02:02 -0700 (PDT)
Received: from piuha.net (p4.piuha.net [131.160.192.4])
	by p2.piuha.net (Postfix) with ESMTP
	id B68526A901; Wed, 24 Apr 2002 02:01:55 +0300 (EEST)
Message-ID: <3CC5E80F.6050803@piuha.net>
Date: Wed, 24 Apr 2002 02:02:39 +0300
From: Jari Arkko 
Reply-To: jari.arkko@piuha.net
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014
X-Accept-Language: en-us
MIME-Version: 1.0
To: Robert Chalmers 
Cc: mobile-ip@sunroof.eng.sun.com,
        "Charles E. Perkins" 
Subject: Re: [mobile-ip] Editorial comments on Draft 16 - Sections 1-5
References: <3CBDFF0E.2679A217@cs.ucsb.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Thanks Robert for your in-depth comments! A few discussion items below:


> C5.1.5:
> The home cookie is a 128-bit field aligned on a 32-bit boundary.  I do
> believe it should be on a 64-bit boundary.


There's a tradeoff on making the cookie aligned on a 64 bit boundary
vs. spending 8 reserved bytes vs. not saving any bits for flags (though
flags can be simulated with options). I'm thinking we should spend the 8
bytes. Comments?


> C5.2.1P8:
> An odd question - if all parameters must start on 8-byte boundaries,
> why don't we make all message end on 8-byte boundaries.  Is is to
> simply make those message without a parameter take up minimum space.
> When considering those that require a parameter, though, does it make
> any since to 'require' padding.  Wouldn't that space be better spent
> as reserved space.

Yes. If we do this, it might make sense to mandate that all parameters
are also multiple of 8 bytes, making pad1 and padn unnecessary. Comments?

Jari



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 19:08:22 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09291
	for ; Tue, 23 Apr 2002 19:08:22 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14536;
	Tue, 23 Apr 2002 17:08:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09525;
	Tue, 23 Apr 2002 16:08:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NN6CGs015245
	for ; Tue, 23 Apr 2002 16:06:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NN6BPI015244
	for mobile-ip-dist; Tue, 23 Apr 2002 16:06:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NN68Gs015237
	for ; Tue, 23 Apr 2002 16:06:08 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08752
	for ; Tue, 23 Apr 2002 16:06:10 -0700 (PDT)
Received: from p2.piuha.net (p2.piuha.net [131.160.192.2])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA17703
	for ; Tue, 23 Apr 2002 17:06:09 -0600 (MDT)
Received: from piuha.net (p4.piuha.net [131.160.192.4])
	by p2.piuha.net (Postfix) with ESMTP
	id 603B66A901; Wed, 24 Apr 2002 02:06:02 +0300 (EEST)
Message-ID: <3CC5E906.1060905@piuha.net>
Date: Wed, 24 Apr 2002 02:06:46 +0300
From: Jari Arkko 
Reply-To: jari.arkko@piuha.net
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014
X-Accept-Language: en-us
MIME-Version: 1.0
To: SatishK Amara 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Security Design in mobile-ip@sunroof.eng.sun.com
References: <20020423141928.93903.qmail@web21302.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

SatishK Amara wrote:

> Hi,
>    I am wondering why is the scope of security design
> specified in draft-ietf-mobileip-ipv6-16.txt is
> limited to on only RR protocol. I think the security
> design should be extendable to any other protocols
> like CAM or IPSEC based on PKI. 


The intention is to define RR as the mandatory mechanism,
but allow future extensions on top or in place of RR.
(Draft 16 text needs work in making this clear.)

Jari



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 23 19:11:49 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09411
	for ; Tue, 23 Apr 2002 19:11:48 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11834;
	Tue, 23 Apr 2002 16:11:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10914;
	Tue, 23 Apr 2002 16:11:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NNA5Gs015324
	for ; Tue, 23 Apr 2002 16:10:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3NNA5RC015323
	for mobile-ip-dist; Tue, 23 Apr 2002 16:10:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3NNA2Gs015316
	for ; Tue, 23 Apr 2002 16:10:02 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10404
	for ; Tue, 23 Apr 2002 16:10:03 -0700 (PDT)
Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA19241
	for ; Tue, 23 Apr 2002 17:10:02 -0600 (MDT)
Received: from splat.its.monash.edu.au ([130.194.1.73])
 by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306)
 with ESMTP id <01KGXQ27HQRO8Y55DT@vaxh.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Wed, 24 Apr 2002 09:09:49 +1000
Received: from splat (unknown [127.0.0.1])	by localhost (Postfix)
 with ESMTP	id 8C780130009; Tue, 23 Apr 2002 23:09:48 +0000 (/etc/localtime)
Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189])
	by splat.its.monash.edu.au (Postfix) with ESMTP	id 1F425130008; Wed,
 24 Apr 2002 09:09:46 +1000 (EST)
Date: Wed, 24 Apr 2002 09:09:46 +1000
From: Greg Daley 
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality
To: Francis Dupont 
Cc: rene.purnadi@nokia.com, brett.pentland@eng.monash.edu.au,
        kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com
Reply-to: greg.daley@eng.monash.edu.au
Message-id: <3CC5E9BA.F5960A31@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <200204231424.g3NEOfT65815@givry.rennes.enst-bretagne.fr>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7BIT

Hi Francis, just a quick comment:

> 
> => in your description it is very cler than the target access point
> knows the handover occurs. So it can help to make L3 handover faster,
> for instance by caching a RA, by triggering a RA by sending itself a RS,
> etc. One can imagine many ways, all of them are better than to mess
> the neighbor discovery protocol.

I know of several systems where the L2
Access Point is not an IP device, and therefore
cannot participate in L3 connectivity (even if it
knows about a new association).

The mobile node, on the other hand, may know of a
change in L2, and may use this information to
check that it is not on a new L3 network.

If there is intelligence in the network to assist
with sending RA's, then I'm happy for that effort to
be explored, but it is not a viable method for some
widely deployed technologies.

Greg Daley



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 02:16:20 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25614
	for ; Wed, 24 Apr 2002 02:16:20 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04376;
	Wed, 24 Apr 2002 00:16:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18596;
	Tue, 23 Apr 2002 23:16:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O6EqGs016215
	for ; Tue, 23 Apr 2002 23:14:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3O6Eqwu016214
	for mobile-ip-dist; Tue, 23 Apr 2002 23:14:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O6ElGs016204
	for ; Tue, 23 Apr 2002 23:14:47 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA22608
	for ; Tue, 23 Apr 2002 23:14:49 -0700 (PDT)
Received: from mail.flarion.com (mail.flarion.com [63.103.94.23])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03789
	for ; Wed, 24 Apr 2002 00:14:48 -0600 (MDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id <20R3S4R9>; Wed, 24 Apr 2002 02:14:47 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3A757@ftmail>
From: "Alan O'Neill" 
To: Annika Jonsson ,
        "Charles E. Perkins"
	 ,
        "Madhavi W. Chandra" ,
        James Kempf , Basavaraj.Patil@nokia.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t
	xt
Date: Wed, 24 Apr 2002 02:14:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

So I thought given the thread I would add some higher layer thoughts behind
Flarions interest in this draft and respond to some of the other comments
raised. I do so coming from an intial viewpoint of seeing absolutely no need
for regional registration for MIP...so am a slightly converted strong
sceptic..as you will see below.

Firstly, I agree with many that avoiding additional points of failure and
the cost/benefit of regional registration makes its usefulness debatable...
I agree that the hand-off aspects of this draft should be split out into the
hand-off work and that additional work is required on the 'home signaling
via regional node plane' to address some of the technical issues, especially
regarding backwards compatibility and GFA CoA assignment (see my previous
response to Annika on the latter and Ahmeds excellent analysis on the
former). Even then, (if I was a neutral), I think I would say that we would
need to see more deployment demand to progress the mechanisms in this draft
on standards track.

However, Flarion has one of the more challenging environments for MIPv4 and
we will deploy something, sometime, somewhere soon (hopefully in huge
volumes ;-) In reviewing a lot of MIP work in anticipation of that
deployment, reviews that are still ongoing and for obvious reasons
commercially sensitive at this time, it is apparent that there are some
missing bits. We plan to continue to write these up and submit them
following discussions and agreement with our core router partners and
customers to then hopefully trigger standards activity where necessary.
RegTunMods and RevTunMods were the first two such drafts and there will be
others unrelated to regional tunneling...

One such missing bit appears to be the need to be able to advertise the
existence of a regional element (the 'I' bit) to the MN, to detect when that
element has changed and to register to a home agent via each new regional
element. We specifically have little interest in the RFA, in the regional
element being a GFA and in the regional registration to the GFA itself. My
analysis of, and feedback on, the RegTun draft in [RegTunMods] was motivated
simply by the desire to be able to re-use the home registration regional
extensions and hence co-exist with GFAs that might already have been
deployed. I am open-minded about them getting deployed, but very unhappy if
the general regional element capability is lost or eventually not
standardised.

I can and will elaborate much further on these points in suitable drafts as
soon as I am able. This will hopefully be a matter of days or at worst a few
weeks. In the absence of that justification and information I would be
supportive of the draft being revised and taken to experimental. I would
however recommend that we try to separate out the home signaling via a
regional element, from the type of regional element and its features, as I
think (well know :-) they are distinct. A generalised address carrier with
sub-types can be used to transport addresses up and down that signalling
plane and be used to trigger address type specific processing..ie a GFA CoA
sub-type means do GFA type things. I think this redesign is a good idea even
just for GFA as who knows what future requirements will come upon us (ours
aside) and nailing up a general capability is unfortunate. This address
carrier should maybe be defined in a separate draft.

I also believe that the regional element should be able to be in the core or
at the edge as alluded to by other responders, although ours will likely be
in the core much to the horror of some of you no doubt. I wouldn't do it
though unless I thought it was absolutely necessary...believe me.

I think we should also finally recognise the extensive and excellent work
that has gone into RegTun, and await both suitable revisions and then
vendor/customer interest before committing this to standards track.

Regards,  Alan.









From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 02:16:28 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25631
	for ; Wed, 24 Apr 2002 02:16:27 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01705;
	Wed, 24 Apr 2002 00:16:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18630;
	Tue, 23 Apr 2002 23:16:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O6EpGs016212
	for ; Tue, 23 Apr 2002 23:14:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3O6EotE016211
	for mobile-ip-dist; Tue, 23 Apr 2002 23:14:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O6EjGs016197
	for ; Tue, 23 Apr 2002 23:14:45 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA20636
	for ; Tue, 23 Apr 2002 23:14:47 -0700 (PDT)
Received: from mail.flarion.com (mail.flarion.com [63.103.94.23])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04077
	for ; Tue, 23 Apr 2002 23:14:47 -0700 (PDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id <20R3S4R8>; Wed, 24 Apr 2002 02:14:45 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3A756@ftmail>
From: "Alan O'Neill" 
To: Annika Jonsson ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Wed, 24 Apr 2002 02:14:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Annika, comments in-line

-----Original Message-----
From: Annika Jonsson [mailto:annika.jonsson@ericsson.com]
Sent: 23 April 2002 00:03
To: Alan O'Neill; mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Last Call: Regional Tunneling input


Hi Alan,

I have read your suggestions, and I have a few comments.

First, regarding the dynamic allocation of HA: we do support that in the 
current draft. We assume that it is the GFA that participates in the 
authentication procedure as AAA client and not the FA (see section 3.1.2). 
The reason for this is that it is the GFA that acts as FA towards the HA, 
and therfore needs the keys for securing registration messages. So, in this 
way, a AAA server can dynamically allocate an HA, and the GFA will be 
informed about this.

AWO> My draft was written from 05 so I'll reread ok and come back on this

Second, the problem with how to handle different addressing plans between 
FA - GFA and GFA - HA. I agree that this should be supported. Let's see if 
I understand your suggestion correctly:
* The GFA address advertised in the Agent Advertisement should be the 
"local" address of the GFA, where it can be reached from the FA.
* A Home registration from a MN should never include any CoA address
* The FA sends the registration req. on to the GFA "local" address
* The GFA allocates CoA to the MN
* The GFA IP extension (forget the name change for now...) should be used 
to transport the selected CoA to the HA and to carry the selected CoA back 
to the MN, as is already the case in the draft.

I agree that dynamically allocating the CoA is the best way, and it seems 
resonable that this is the responsibility of the GFA and not the FA. But, 
the reason why we didn't specify that all MN:s must use that method is that 
we wanted to be backwards compatible wiht HA:s that does'nt specifically 
support Regional registrations (or rather, the GFA IP extension). If MN:s 
are allowed to put the CoA in the Registration request, the HA will never 
need to know that the visited network uses regional registrations, and the 
GFA will look like a normal FA. I still think this is a good feature.

AWO> Yes - I appreciated your motivation.

To allow this, the FA must advertise a publicly routable GFA (CoA) address. 
If the FA and GFA belongs to a private address domain, the FA needs to have 
a mapping from the public CoA address to the private GFA address that it 
should use to send the Registration request to. I think this solves the 
problem.

To summarise, I suggest that we:
* clarify that dynamic allocation of CoA is preferable
* add that the FA might use another address to communicate with a GFA than 
the CoA advertised, and that it in that case needs a mapping between these 
two addresses
* change the allocation of CoA and use of the GFA IP address extension, by 
saying that it is the responsibility of the FA to select GFA, but not to 
include any GFA IP extension, because it is the responsibility of the GFA 
to allocate CoA, and it will add the GFA IP extension.

Do you agree that this solves the problems you raised?

AWO> Not really as this only addresses the case of the MN moving in a
private domain underneath a GFA with a single public interface. When the GFA
has multiple interfaces with a mixture of public and private, or when the
local domain is the public domain and the GFA has a private interface then
it still breaks down. For your scheme to work you need the FA to have
extensive address mapping knowledge. This is essentially also impossible to
achieve when the GFA has multiple interfaces with different address blocks
towards HAs. The FA does not know what to advertise to the MN because it
cannot know which GFA interface the MN RREQ will need to traverse before
seeing the RREQ, and by then it is too late if the MN has already put a GFA
CoA into the CoA field. So to be generally applicable I realy think that the
CoA field should always be zero and that the GFA should insert the GFA CoA
for the HA. 

Now this means that an upgraded HA can always tell if an initial home reg
came via a GFA...a good thing in my book.
Unfortunately, a legacy HA will fail this reg - again a good thing in my
book..more pressure on IT department/operator to upgrade the HA. Remember,
the HA and MN share a unique relationship and having them on widely
different MIP versions for any length of time is somewhat perverse to me.
What is therefore missing is to enable the GFA to insert the assigned GFA
CoA into the RREP for the MN if the HA failed to do so. The second attempt
can therefore still succeed to the legacy HA. Each refresh under the same
GFA also works and we only have a problem again on each GFA change-over
whilst the MN and HA are on such different versions...

Alan.

/Annika

At 22:23 2002-04-15 -0400, Alan O'Neill wrote:
>Below is the abstract for the draft that makes last call suggestions on
>Regional tunneling.
>
>see
>http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mods-00.txt
>
>Abstract
>
>    Regional Registration modifies the normal MIP Registration signalling
>    back to the HA so that the signalling can traverse an intermediate
>    Gateway Foreign Agent (GFA). The registered binding is between the Home
>    Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent
>    (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the
GFA.
>    Two extensions are defined to support this new Registration processing
>    these being the Hierarchical Foreign Agent extension (HFAext) and the
GFA
>
>    IP address extension (GFAIPext). The former is used to carry the FA CoA
>    to the GFA and the latter is used by the FA to allocate a GFA to the
MN,
>    and by the FA, GFA, HA to securely return the GFA IP address to the MN.
>
>    The present processing rules for the HA registration enable the FA to
>    advertise the GFA to the MN in a Foreign Agent Advertisement (FAA) and
>    for the MN to include that GFA address into the CoA field of the MIP
home
>
>    Registration. This however assumes a number of things about the GFA
>    address in the FAA and the addressing realms between the FA-GFA and
GFA-
>    HA.. Specifically, the GFA CoA and the GFA IP address must potentially
be
>
>    from two different addressing plans and hence cannot be in the same
FAA.
>    This draft describes the issues and suggests a solution that requires
>    slight modifications to the required extensions, that generalises the
>    Home Registration signalling for arbitrary intermediate MIP nodes, and
>    only slightly modifies the processing rules for the MIP Home
>    Registration. This draft also describes a way to support dynamic HA
>    allocation along-side Regional Registrations.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 04:25:45 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27401
	for ; Wed, 24 Apr 2002 04:25:45 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29100;
	Wed, 24 Apr 2002 02:25:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18386;
	Wed, 24 Apr 2002 01:25:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O8O4Gs016685
	for ; Wed, 24 Apr 2002 01:24:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3O8O4vt016684
	for mobile-ip-dist; Wed, 24 Apr 2002 01:24:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O8O1Gs016677
	for ; Wed, 24 Apr 2002 01:24:01 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA11588
	for ; Wed, 24 Apr 2002 01:24:01 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28467
	for ; Wed, 24 Apr 2002 02:24:00 -0600 (MDT)
Message-ID: <00c401c1eb69$25179340$b36015ac@T23KEMPF>
From: "James Kempf" 
To: "Rajeev Koodli" 
Cc: "Alper E. YEGIN" ,
        "Manolis Sifalakis" ,
        
References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> <046701c1e804$7016f330$736015ac@AlperVAIO> <3CC58E3C.86B <3CC5CA61.E210D29F@iprg.nokia.com>
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
Date: Wed, 24 Apr 2002 00:55:21 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Rajeev,

> Right. More generally, FBU must authorize packet forwarding
> on the tunnel independent of where the tunnel terminates as long as
the
> packets are destined for the MN.
> The issue is who has control over the
> forwarding of MN's packets. If a MN has chosen a node as its AR, that
> node has an obligation to forward packets to the MN. If the MN moves
to a
> new
> location, it is the IP layer at the MN that is responsible for
authorizing
> the redirection to the new location. At least, IP layer authorization
is
> what
> is of relevance to FMIPv6. Of course, if link-specific optimizations
are
> feasible, they should be available as options. They cannot be used as
> substitutes for FBU for traffic redirection however.
>

I don't think this follows. If the tunnel terminates at new AR, the new
AR may buffer the packets until the MN shows up on the link. In BETH,
the ARs co-operate to set up the routing, so a Link Down on the old AR
is the appropriate trigger for setting up the tunnel. The MN isn't
involved in determining the routing, the routers are. This is consistent
with the basic history and design philosophy of IP routing, namely that
a host doesn't concern itself with the path its packets take through the
network, it is the task of the routers to perform this function. Hosts
have never been responsible for determining routing in IP (modulo source
routes of course) except to select their default router.

In Mobile IP if the old AR is functioning as an on-link HA, as the MIPv6
draft indicates, then the same mechanism used by the MN to communicate
with the HA in the home network are appropriate for indicating to the
old AR when the MN is on the new link, thus the FBU acts as the
indicator for setting the tunnel up to the MN. But this is only because
Mobile IP makes an exception to the standard IP routing design for a
specific case, namely changing the care of address. This case doesn't
occur with BETH because the care of address doesn't change prior to the
Layer 2 handover. BETH uses standard IP routing mechanisms to fix up the
change in link, Mobile IP mechanisms are used after the link switch to
change the care of address as in standard Mobile IP, rather than
changing the care of address before, as in FMIPv6.

So I agree that the FBU is the proper signal for starting the tunnel in
FMIPv6, but I do not agree that it holds as a general principle that a
MN can determine the routing of its packets, as this would be in direct
contradiction of basic Internet routing design principles.

            jak




From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 05:39:12 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28427
	for ; Wed, 24 Apr 2002 05:39:11 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05432;
	Wed, 24 Apr 2002 02:38:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12309;
	Wed, 24 Apr 2002 02:38:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O9bcGs016851
	for ; Wed, 24 Apr 2002 02:37:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3O9bcOC016850
	for mobile-ip-dist; Wed, 24 Apr 2002 02:37:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O9bYGs016843
	for ; Wed, 24 Apr 2002 02:37:34 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25691
	for ; Wed, 24 Apr 2002 02:37:35 -0700 (PDT)
Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22542
	for ; Wed, 24 Apr 2002 03:37:33 -0600 (MDT)
Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54])
	by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3O9eTgL007369;
	Wed, 24 Apr 2002 11:40:29 +0200
From: "Fredrik Johansson" 
To: , "'Ahmad Muhanna'" ,
        "'Tony Johansson'" 
Cc: , 
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
Date: Wed, 24 Apr 2002 11:37:17 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00EA_01C1EB84.62E99450"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <00e201c1eb18$f8a35240$6401a8c0@dell8100rjm>
Importance: Normal
X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw)
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_00EA_01C1EB84.62E99450
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

MessageBob,
  -----Original Message-----
  From: Robert J Marks [mailto:bob@marksmob.com]
  Sent: den 24 april 2002 00:48
  To: 'Ahmad Muhanna'; 'Tony Johansson'
  Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com
  Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt


  Hello Ahmad,

  I'm still not totally comfortable with this new technique and its impact on
bandwidth-constrained links.

  For RFC2002, the MN sent only the authentication extensions it knew it needed.
It knew if it had a
  security association with the FA, and had to have a security association with
the HA.

  For RFC3012, the MN could use the presence (or absence) of the Challenge to
determine which
  extensions and parameters (like NAI) it included in the Registration Request.

  But for this new I-D, the MN does not get any clue at all. Therefore it needs to
include the extension
  because it might be needed. This, it seems to me, is not so good for
bandwidth-constrained links.
  As Tony pointed out, it seems that the MN must be configured to send or not to
send - I'd rather the
  FA provided some clue.
  [->]
  Well, since the extensions are received in the registration reply, the MN should
send them in registration requests. However, it's only necessary to send them when
it's probable that the FA need to go through the AAA mechanism to authenticate.
I.e. there is no need to send them when just doing a tunnel update, but when ,for
example, requesting new session keys or when changing point of attachment it has
to send the nai extensions.

  Is this good enough to not waste to much on bandwidth constrained links?

  /Fredrik

  Bob

  -----Original Message-----
  From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna
  Sent: Monday, April 22, 2002 3:38 PM
  To: 'Tony Johansson'; bob@marksmob.com
  Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com
  Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt


  Hi Bob;

  Let me add to what Tony just said.
  I do not think that any MN needs to know anything about the type
  of AAA infrastructure the FA and HA are using to authenticate the MN.
  However, the MN Application is developed with certain standard in mind.
  (certain method of authentication)

  for example:
  1. ONLY RFC2002 Compliant MN:
  It assumes that it has a security association with both the FA and the
  HA. If it visit any FA where it shares a security association with, MN sends
  RRQ message with MN-FA Authentication extension and it works just fine.

  2. ONLY RFC2002 & RFC3012 Compliant MN:

  RFC 3012 addressed properly the case of MN in 1 but offered a new
  mechanism for authenticating the MN to the FA using the FA Challenge
  and MN-AAA authentication extension.

  3. Now Latest MN with all of the above (RFC3220) and diameter compliant:
  MN includes AAA NAI extension and those FA which support diameter
  will use process it and those FA which does not support AAA NAI (skippable)
  will continue to use either method in 2 or 1.



  Regards;
  Ahmad Muhanna



  > -----Original Message-----
  > From: Tony Johansson [mailto:tony.johansson@ericsson.com]
  > Sent: Monday, April 22, 2002 4:15 PM
  > To: bob@marksmob.com
  > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Fredrik Johansson';
  > mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com
  > Subject: Re: [mobile-ip] RE: A Question
  > about:draft-ietf-mobileip-aaa-nai-00.txt
  >
  >
  > Hi Bob,
  >
  > Yes, it's based on MN configuration and FA configuration. Same as e.g
  > the handling of RFC3012/RFC3012bis and the
  > draft-ietf-mobileip-aaa-key-09.txt.
  >
  > The advertisements will not tell you anything reading this.
  >
  > /Tony
  >
  > Robert J Marks wrote:
  >
  > >  Perhaps someone can explain how the MN knows the type of AAA
  > > infrastructure used by the FA nd HA. I don't believe any information
  > > is included in any advertisement. Does this "solution" rely
  > only upon
  > > MN configuration, or am I missing something here? Thanks.Bob
  > > -----Original Message-----
  > > From: owner-mobile-ip@sunroof.eng.sun.com
  > > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad
  > > Muhanna
  > > Sent: Monday, April 22, 2002 1:59 PM
  > > To: 'Tony Johansson'
  > > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
  > > fredrik@ipunplugged.com
  > > Subject: RE: [mobile-ip] RE: A Question
  > > about:draft-ietf-mobileip-aaa-nai-00.txt
  > >
  > > Hello Tony;
  > > YES; this solves the problem.
  > >
  > > Regards;
  > > Ahmad Muhanna
  > >
  > > > -----Original Message-----
  > > > From: Tony Johansson [mailto:tony.johansson@ericsson.com]
  > > > Sent: Monday, April 22, 2002 2:51 PM
  > > > To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
  > > > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
  > > > fredrik@ipunplugged.com
  > > > Subject: Re: [mobile-ip] RE: A Question
  > > > about:draft-ietf-mobileip-aaa-nai-00.txt
  > > >
  > > >
  > > > Hello Ahmad,
  > > >
  > > > Ahmad Muhanna wrote:
  > > >
  > > >
  > > > > I do not think that It is the same!!
  > > > > RFC3012 introduced a new way of authenticating the MN to the FA
  > > > > without violating
  > > > > backward compatibility of RFC2002 or later RFC3220.
  > > > > Mobile Node does not know which way or the standard the
  > > > foreign agent
  > > > > uses to
  > > > > authenticate it. It could be through RADIUS, AAA, Diameter
  > > > who knows.
  > > >
  > > > >
  > > > > The point here is that this draft mandates that every
  > Mobile Node
  > > > > include AAA NAI extension
  > > > > with subtype of 1 whenever it requests static Mobile IP
  > or during
  > > > > Inter-FA handoff.
  > > > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile
  > > > Node which
  > > > > exist right now,
  > > > > does not do this.
  > > > > After this draft becomes a standard, according to this
  > > > section, MN is
  > > > > not following the
  > > > > standard by not sending AAA NAI extension in initial
  > Registration
  > > > > Request or during re-authentication.!!!
  > > > >
  > > > > This is not backward compatible!!!!
  > > >
  > > > Okay, so how about adding the following statement to the
  > > introduction:
  > > >
  > > > "The AAA NAI extension MUST only be used with the Diameter Mobile
  > > IPv4
  > > > application and MUST NOT be used with any other AAA protocol."
  > > >
  > > >
  > > >
  > > > /Tony
  > > >
  > > >
  > > >
  >
  >


------=_NextPart_000_00EA_01C1EB84.62E99450
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Message




Bob,


  
-----Original Message-----
From: Robert J Marks=20
  [mailto:bob@marksmob.com]
Sent: den 24 april 2002=20
  00:48
To: 'Ahmad Muhanna'; 'Tony Johansson'
Cc: =
'Fredrik=20
  Johansson'; mobile-ip@sunroof.eng.sun.com;=20
  fredrik@ipunplugged.com
Subject: RE: [mobile-ip] RE: A =
Question=20
  about:draft-ietf-mobileip-aaa-nai-00.txt


  
Hello Ahmad,

  
 

  
I'm=20
  still not totally comfortable with this new technique and its impact =
on=20
  bandwidth-constrained links.

  
 

  
For=20
  RFC2002, the MN sent only the authentication extensions it knew it =
needed. It=20
  knew if it had a

  
security association with the FA, and had to have a security=20
  association with the HA.

  
 

  
For=20
  RFC3012, the MN could use the presence (or absence) of the Challenge =
to=20
  determine which

  
extensions and parameters (like NAI) it included in the =
Registration=20
  Request.

  
 

  
But=20
  for this new I-D, the MN does not get any clue at all. Therefore it =
needs to=20
  include the extension

  
because it might be needed. This, it seems to me, is not so =
good for=20
  bandwidth-constrained links.

  
As=20
  Tony pointed out, it seems that the MN must be configured to send or =
not to=20
  send - I'd rather the

  
FA provided some clue.
[->] 

  
Well, =
since the=20
  extensions are received in the registration reply, the MN should =
send=20
  them in registration requests. However, it's only necessary to =
send them=20
  when it's probable that the FA need to go through the AAA =
mechanism to=20
  authenticate. I.e. there is no need to send them when just doing a =
tunnel=20
  update, but when ,for example, requesting new session keys or when =
changing=20
  point of attachment it has to send the nai=20
  extensions.

  
 
  
Is=20
  this good enough to not waste to much on bandwidth constrained=20
  links?

  
 
  
/Fredrik
  
 

  
Bob

  
 

  

  
-----Original Message-----
From:=20
  owner-mobile-ip@sunroof.eng.sun.com=20
  [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad =

  Muhanna
Sent: Monday, April 22, 2002 3:38 PM
To: =
'Tony=20
  Johansson'; bob@marksmob.com
Cc: 'Fredrik Johansson';=20
  mobile-ip@sunroof.eng.sun.com; =
fredrik@ipunplugged.com
Subject: RE:=20
  [mobile-ip] RE: A Question=20
  about:draft-ietf-mobileip-aaa-nai-00.txt


  
Hi Bob; 

  
Let me add to what Tony just said. 
I=20
  do not think that any MN needs to know anything about the type=20
  
of AAA infrastructure the FA and HA are using to =
authenticate=20
  the MN. 
However, the MN Application is =
developed with=20
  certain standard in mind. 
(certain method of =

  authentication) 

  
for example: 
1. ONLY =
RFC2002 Compliant=20
  MN: 
It assumes that it has a security =
association with=20
  both the FA and the 
HA. If it visit any FA =
where it=20
  shares a security association with, MN sends 
RRQ=20
  message with MN-FA Authentication extension and it works just =
fine.=20


  
2. ONLY RFC2002 & RFC3012 Compliant MN: =


  
RFC 3012 addressed properly the case of MN in 1 but =
offered a=20
  new 
mechanism for authenticating the MN to =
the FA=20
  using the FA Challenge 
and MN-AAA =
authentication=20
  extension. 

  
3. Now Latest MN with all of the above (RFC3220) and =
diameter=20
  compliant: 
MN includes AAA NAI extension and =
those FA=20
  which support diameter 
will use process it =
and those=20
  FA which does not support AAA NAI (skippable) 
will=20
  continue to use either method in 2 or 1. 


  
Regards; 
Ahmad =
Muhanna 


  
> -----Original Message----- 
>=20
  From: Tony Johansson [mailto:tony.johansson@ericsso=
n.com]=20
  
> Sent: Monday, April 22, 2002 4:15 PM =

> To: bob@marksmob.com 
> Cc: =
Muhanna,=20
  Ahmad [RICH1:2Q20:EXCH]; 'Fredrik Johansson'; 
>=20
  mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com =

> Subject: Re: [mobile-ip] RE: A Question 
> about:draft-ietf-mobileip-aaa-nai-00.txt =

> 
> 
> Hi=20
  Bob, 
> 
> =
Yes, it's based=20
  on MN configuration and FA configuration. Same as e.g 
> the handling of RFC3012/RFC3012bis and the =

> draft-ietf-mobileip-aaa-key-09.txt. 
>=20
  
> The advertisements will not tell you =
anything=20
  reading this. 
> 
>=20
  /Tony 
> 
> =
Robert J Marks=20
  wrote: 
> 
> =
> =20
  Perhaps someone can explain how the MN knows the type of AAA =

> > infrastructure used by the FA nd HA. I don't =
believe any=20
  information 
> > is included in any=20
  advertisement. Does this "solution" rely 
> only=20
  upon 
> > MN configuration, or am I =
missing=20
  something here? Thanks.Bob 
> > =
-----Original=20
  Message----- 
> > From:=20
  owner-mobile-ip@sunroof.eng.sun.com 
> =
> [mailto:owner-mobile-i=
p@sunroof.eng.sun.com]=20
  On Behalf Of Ahmad 
> > Muhanna =

> > Sent: Monday, April 22, 2002 1:59 PM =

> > To: 'Tony Johansson' 
> =
> Cc:=20
  'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> > fredrik@ipunplugged.com 
> >=20
  Subject: RE: [mobile-ip] RE: A Question 
> =
>=20
  about:draft-ietf-mobileip-aaa-nai-00.txt 
>=20
  > 
> > Hello Tony; 
> > YES; this solves the problem. 
>=20
  > 
> > Regards; 
>=20
  > Ahmad Muhanna 
> > =

> > > -----Original Message----- 
>=20
  > > From: Tony Johansson [mailto:tony.johansson@ericsso=
n.com]=20
  
> > > Sent: Monday, April 22, 2002 2:51 =
PM=20
  
> > > To: Muhanna, Ahmad =
[RICH1:2Q20:EXCH]=20
  
> > > Cc: 'Fredrik Johansson';=20
  mobile-ip@sunroof.eng.sun.com; 
> > =
>=20
  fredrik@ipunplugged.com 
> > > =
Subject: Re:=20
  [mobile-ip] RE: A Question 
> > >=20
  about:draft-ietf-mobileip-aaa-nai-00.txt 
> >=20
  > 
> > > 
> >=20
  > Hello Ahmad, 
> > > =

> > > Ahmad Muhanna wrote: 
> >=20
  > 
> > > 
> >=20
  > > I do not think that It is the same!! 
>=20
  > > > RFC3012 introduced a new way of authenticating the MN =
to the=20
  FA 
> > > > without =
violating=20
  
> > > > backward compatibility of =
RFC2002 or=20
  later RFC3220. 
> > > > Mobile =
Node does=20
  not know which way or the standard the 
> =
> >=20
  foreign agent 
> > > > uses =
to=20
  
> > > > authenticate it. It could be =
through=20
  RADIUS, AAA, Diameter 
> > > who =
knows.=20
  
> > > 
> > =
>=20
  > 
> > > > The point here is =
that this=20
  draft mandates that every 
> Mobile =
Node=20
  
> > > > include AAA NAI =
extension=20
  
> > > > with subtype of 1 whenever it =
requests=20
  static Mobile IP 
> or during =

> > > > Inter-FA handoff. 
> >=20
  > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy =
Mobile=20
  
> > > Node which 
> >=20
  > > exist right now, 
> > > =
> does=20
  not do this. 
> > > > After this =
draft=20
  becomes a standard, according to this 
> =
> >=20
  section, MN is 
> > > > not =
following=20
  the 
> > > > standard by not =
sending AAA=20
  NAI extension in initial 
> =
Registration=20
  
> > > > Request or during=20
  re-authentication.!!! 
> > > =
>=20
  
> > > > This is not backward=20
  compatible!!!! 
> > > =

> > > Okay, so how about adding the following =
statement to=20
  the 
> > introduction: 
> > > 
> > > "The =
AAA NAI=20
  extension MUST only be used with the Diameter Mobile 
> > IPv4 
> > > =
application and=20
  MUST NOT be used with any other AAA protocol." 
>=20
  > > 
> > > 
>=20
  > > 
> > > /Tony =

> > > 
> > =
> 
> > > 
> =

> 


------=_NextPart_000_00EA_01C1EB84.62E99450--



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 05:39:57 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28457
	for ; Wed, 24 Apr 2002 05:39:57 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13921;
	Wed, 24 Apr 2002 03:39:57 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12669;
	Wed, 24 Apr 2002 02:39:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O9cuGs016871
	for ; Wed, 24 Apr 2002 02:38:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3O9cuSI016870
	for mobile-ip-dist; Wed, 24 Apr 2002 02:38:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O9cqGs016863
	for ; Wed, 24 Apr 2002 02:38:53 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10562
	for ; Wed, 24 Apr 2002 02:38:54 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13384
	for ; Wed, 24 Apr 2002 03:38:53 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3O9ZuB22104;
	Wed, 24 Apr 2002 11:35:56 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA08703;
	Wed, 24 Apr 2002 11:35:56 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3O9ZtT68827;
	Wed, 24 Apr 2002 11:35:55 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204240935.g3O9ZtT68827@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Behcet Sarikaya 
cc: rene.purnadi@nokia.com, brett.pentland@eng.monash.edu.au,
        kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
In-reply-to: Your message of Tue, 23 Apr 2002 09:58:09 CDT.
             <3CC57681.4070004@alcatel.com> 
Date: Wed, 24 Apr 2002 11:35:55 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   I wonder in which context are considering the application of FMIPv6? Is 
   it for fast handover inside UMTS domain? Probably it is more interesting 
   to consider intertechnology handovers using FMIPv6?
   
=> by definition FMIPv6 is intertechnology-capable so this doesn't matter.
   
Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 05:49:36 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28544
	for ; Wed, 24 Apr 2002 05:49:36 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10067;
	Wed, 24 Apr 2002 02:49:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15455;
	Wed, 24 Apr 2002 02:49:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O9mLGs017035
	for ; Wed, 24 Apr 2002 02:48:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3O9mLIV017034
	for mobile-ip-dist; Wed, 24 Apr 2002 02:48:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O9mHGs017027
	for ; Wed, 24 Apr 2002 02:48:17 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15233
	for ; Wed, 24 Apr 2002 02:48:19 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02115
	for ; Wed, 24 Apr 2002 03:48:18 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3O9lfB24627;
	Wed, 24 Apr 2002 11:47:41 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA08939;
	Wed, 24 Apr 2002 11:47:41 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3O9lfT68888;
	Wed, 24 Apr 2002 11:47:41 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204240947.g3O9lfT68888@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Rajeev Koodli 
cc: rene.purnadi@nokia.com, brett.pentland@eng.monash.edu.au,
        kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
In-reply-to: Your message of Tue, 23 Apr 2002 09:59:06 PDT.
             <3CC592DA.FE0FC950@iprg.nokia.com> 
Date: Wed, 24 Apr 2002 11:47:41 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   > if it is IPv6 the GGSN is the access router: in all cases a RA will be sent
   > without a RS and the L3 handover as quick as possible without FMIPv6.
   
   Some comments on the last sentence..
   
   - quickly receiving an RA is not equivalent to fast handover (in case you
   implied it that way).

=> we agree, in my message I mean it is the best thing to do when FMIPv6
(aka fast handowver) is not available. So I believe your comment is more
a complement than an objection, isn't it?

   - regarding the ability to receive packets as soon as a new link is
   available, you need to consider the route-update (BU) latency. FMIPv6
   moves BU out of time-sensitive path by having a tunnel from previous
   router to the new one.

=> this is BETH, not FMIPv6 fast handover... (no flame war please about
BETH vs FMIPv6 :-).

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 06:26:24 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28863
	for ; Wed, 24 Apr 2002 06:26:24 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24779;
	Wed, 24 Apr 2002 03:25:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23097;
	Wed, 24 Apr 2002 03:25:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OAP4Gs017169
	for ; Wed, 24 Apr 2002 03:25:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OAP4po017168
	for mobile-ip-dist; Wed, 24 Apr 2002 03:25:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OAP1Gs017161
	for ; Wed, 24 Apr 2002 03:25:01 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22956
	for ; Wed, 24 Apr 2002 03:25:01 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18260
	for ; Wed, 24 Apr 2002 04:25:00 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3OAOiB30476;
	Wed, 24 Apr 2002 12:24:44 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA09626;
	Wed, 24 Apr 2002 12:24:44 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3OAOeT68997;
	Wed, 24 Apr 2002 12:24:44 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204241024.g3OAOeT68997@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Brian Haley 
cc: mobile ip 
Subject: Re: [mobile-ip] S-bit and building a link-local address 
In-reply-to: Your message of Tue, 23 Apr 2002 17:55:27 EDT.
             <3CC5D84F.157CBA29@compaq.com> 
Date: Wed, 24 Apr 2002 12:24:40 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   Where can I find the spec/RFC that defines how to build a link-local address
   from a global unicast address?
   
=> nowhere, the S-bit stuff makes the nasty assumption that the same
interface ID is used for every addresses...

   I've been struggling with this one for a while, but it doesn't seem like we
   can just mask-off the upper 64 bits, stuff an FE80 in there, and call it a
   link-local address.  This isn't even considering the IPv6-over-foo RFCs.
   
=> this is exactly the assumption and I share your bad opinion about it.

   So if that question can't be answered, I feel the S-bit must be removed
   from the draft, unless someone is willing to write-up the method in
   question, but since building link-local addresses has media type
   implications, I wasn't going to go there.
   
=> Many people want to keep it because it makes some cases easier/faster.
We (you and me) don't like it but one can answer we may not use it
so the only thing we can get is no SHOULD (including through bad
wording) for the S-bit in the document.

   This also has ramifications with the D-bit since Section 9.1 of the
   Mobile IPv6 spec says we must do DAD for the link-local address.
   
=> same assumption... and the conclusion is DAD for the link-local
is enough.

   Am I missing something here?
   
=> unfortunately nothing.

Regards

Francis.Dupont@enst-bretagne.fr

PS: I have two reasons to prefer registration for only one address:
 - far simpler
 - the link-local address is available for de-registration when
   the mobile comes back to home.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 06:42:49 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29034
	for ; Wed, 24 Apr 2002 06:42:49 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23526;
	Wed, 24 Apr 2002 04:42:47 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04221;
	Wed, 24 Apr 2002 03:42:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OAfqGs017308
	for ; Wed, 24 Apr 2002 03:41:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OAfpBX017307
	for mobile-ip-dist; Wed, 24 Apr 2002 03:41:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OAfmGs017300
	for ; Wed, 24 Apr 2002 03:41:48 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04173
	for ; Wed, 24 Apr 2002 03:41:48 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15360
	for ; Wed, 24 Apr 2002 04:41:46 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3OAfUB32590;
	Wed, 24 Apr 2002 12:41:31 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA09869;
	Wed, 24 Apr 2002 12:41:31 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3OAfUT69047;
	Wed, 24 Apr 2002 12:41:30 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204241041.g3OAfUT69047@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: greg.daley@eng.monash.edu.au
cc: rene.purnadi@nokia.com, brett.pentland@eng.monash.edu.au,
        kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
In-reply-to: Your message of Wed, 24 Apr 2002 09:09:46 +1000.
             <3CC5E9BA.F5960A31@eng.monash.edu.au> 
Date: Wed, 24 Apr 2002 12:41:30 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   I know of several systems where the L2
   Access Point is not an IP device, and therefore
   cannot participate in L3 connectivity (even if it
   knows about a new association).
   
=> this is (with possible very high arrival rate) the only issue
in the scheme I propose. But there are already some cases where
the L2 access point has to participate to L3 stuff:
 - AAA (insecure networks are not so popular :-)
 - many xxx handover enhancements (to trigger RA sending is in fact
   the first step of possible enhancements).

   If there is intelligence in the network to assist
   with sending RA's, then I'm happy for that effort to
   be explored,

=> we agree about this, and perhaps we agree too about the superiority
of this approach over fast RS/RA one.

   but it is not a viable method for some
   widely deployed technologies.
   
=> you have to give concrete examples and don't forget that if current
IEEE 802.11 networks have no deployed good AAA the reason is the lack
of available solutions, and this hole is being filled very quickly.
(for instance if you use LEAP, the radius server can trigger the RA,
in fact if you use address filtering (very common!) the radius server
is used in order to punch holes in filters (messages with the AP for
MAC filters, with the firewall for IP filters, etc). A very easy way
to implement my proposal is to put the radius server on the same link
than the AP and the MN and to send a RS from it).

Regards

Francis.Dupont@enst-bretagne.fr
   


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 08:01:28 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00563
	for ; Wed, 24 Apr 2002 08:01:28 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15058;
	Wed, 24 Apr 2002 05:00:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12671;
	Wed, 24 Apr 2002 05:00:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OBxgGs017610
	for ; Wed, 24 Apr 2002 04:59:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OBxghQ017609
	for mobile-ip-dist; Wed, 24 Apr 2002 04:59:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OBxdGs017602
	for ; Wed, 24 Apr 2002 04:59:39 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12254
	for ; Wed, 24 Apr 2002 04:59:39 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14480
	for ; Wed, 24 Apr 2002 04:59:39 -0700 (PDT)
Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3OBxbTZ005222;
	Wed, 24 Apr 2002 04:59:38 -0700 (PDT)
Received: from DBLAIRW2K (atlanta-dhcp-idf81-56.cisco.com [161.44.123.56])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id ACS76066;
	Wed, 24 Apr 2002 04:59:36 -0700 (PDT)
From: "Dana L. Blair" 
To: "Alan O'Neill" ,
        "Annika Jonsson" ,
        
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Wed, 24 Apr 2002 07:59:36 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46C3A756@ftmail>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit


snip...

> Do you agree that this solves the problems you raised?
>
> AWO> Not really as this only addresses the case of the MN moving in a
> private domain underneath a GFA with a single public interface.
> When the GFA
> has multiple interfaces with a mixture of public and private, or when the
> local domain is the public domain and the GFA has a private interface then
> it still breaks down. For your scheme to work you need the FA to have
> extensive address mapping knowledge. This is essentially also
> impossible to
> achieve when the GFA has multiple interfaces with different address blocks
> towards HAs. The FA does not know what to advertise to the MN because it
> cannot know which GFA interface the MN RREQ will need to traverse before
> seeing the RREQ, and by then it is too late if the MN has already
> put a GFA
> CoA into the CoA field. So to be generally applicable I realy
> think that the
> CoA field should always be zero and that the GFA should insert the GFA CoA
> for the HA.
>
> Now this means that an upgraded HA can always tell if an initial home reg
> came via a GFA...a good thing in my book.
> Unfortunately, a legacy HA will fail this reg - again a good thing in my
> book..more pressure on IT department/operator to upgrade the HA.

I don't think it's good when protocols deployed to potentially millions
of devices are not backward compatible.  You are making an implicit
assumption about common administration of the MN, FA, GFA, and the HA
by the same entity (IT department, ...).  This is not a valid
assumption for internet connectivity.

Remember,
> the HA and MN share a unique relationship and having them on widely
> different MIP versions for any length of time is somewhat perverse to me.

Disagree for the same reasons again.  If the base mobile IP protocol
is broken (and I don't belive it is), then we should fix it before
it gets too widely deployed.  Otherwise, changes to the MN, FA, and
HA functionality MUST be backward compatible.  I don't believe
introducing a new and unecessary layer of fixed heirarchy
is important enough to break backward compatiblity.

The necessary test for this draft should be backward compatibility.
But that may not be sufficient to warrant a new RFC.

thanks,
Dana

> What is therefore missing is to enable the GFA to insert the assigned GFA
> CoA into the RREP for the MN if the HA failed to do so. The second attempt
> can therefore still succeed to the legacy HA. Each refresh under the same
> GFA also works and we only have a problem again on each GFA change-over
> whilst the MN and HA are on such different versions...
>
> Alan.
>
> /Annika
>
> At 22:23 2002-04-15 -0400, Alan O'Neill wrote:
> >Below is the abstract for the draft that makes last call suggestions on
> >Regional tunneling.
> >
> >see
> >http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mo
> ds-00.txt
> >
> >Abstract
> >
> >    Regional Registration modifies the normal MIP Registration signalling
> >    back to the HA so that the signalling can traverse an intermediate
> >    Gateway Foreign Agent (GFA). The registered binding is
> between the Home
> >    Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent
> >    (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the
> GFA.
> >    Two extensions are defined to support this new Registration
> processing
> >    these being the Hierarchical Foreign Agent extension (HFAext) and the
> GFA
> >
> >    IP address extension (GFAIPext). The former is used to carry
> the FA CoA
> >    to the GFA and the latter is used by the FA to allocate a GFA to the
> MN,
> >    and by the FA, GFA, HA to securely return the GFA IP address
> to the MN.
> >
> >    The present processing rules for the HA registration enable the FA to
> >    advertise the GFA to the MN in a Foreign Agent Advertisement
> (FAA) and
> >    for the MN to include that GFA address into the CoA field of the MIP
> home
> >
> >    Registration. This however assumes a number of things about the GFA
> >    address in the FAA and the addressing realms between the FA-GFA and
> GFA-
> >    HA.. Specifically, the GFA CoA and the GFA IP address must
> potentially
> be
> >
> >    from two different addressing plans and hence cannot be in the same
> FAA.
> >    This draft describes the issues and suggests a solution that requires
> >    slight modifications to the required extensions, that generalises the
> >    Home Registration signalling for arbitrary intermediate MIP
> nodes, and
> >    only slightly modifies the processing rules for the MIP Home
> >    Registration. This draft also describes a way to support dynamic HA
> >    allocation along-side Regional Registrations.



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 10:22:53 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09629
	for ; Wed, 24 Apr 2002 10:22:53 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27497;
	Wed, 24 Apr 2002 08:22:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24140;
	Wed, 24 Apr 2002 07:21:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OEKDGs017882
	for ; Wed, 24 Apr 2002 07:20:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OEKDLm017881
	for mobile-ip-dist; Wed, 24 Apr 2002 07:20:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OEK9Gs017874
	for ; Wed, 24 Apr 2002 07:20:09 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13275
	for ; Wed, 24 Apr 2002 07:20:09 -0700 (PDT)
From: rene.purnadi@nokia.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07605
	for ; Wed, 24 Apr 2002 08:20:08 -0600 (MDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OEMqH26399
	for ; Wed, 24 Apr 2002 09:22:53 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 24 Apr 2002 07:20:04 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 24 Apr 2002 09:18:42 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
Date: Wed, 24 Apr 2002 09:18:41 -0500
Message-ID: <748E8123D183394982E32A511DB3E73610B12B@daebe005.NOE.Nokia.com>
Thread-Topic: [mobile-ip] RA Solicitation Response Delay Performance Fatality 
Thread-Index: AcHrfMJdQrKoEyREQPWQVMeILVDbqQAHLzjQ
To: , 
Cc: , ,
        
X-OriginalArrivalTime: 24 Apr 2002 14:18:42.0357 (UTC) FILETIME=[EFCA0650:01C1EB9A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3OEKAGs017875
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Hi Francis and Greg,

   If there is intelligence in the network to assist
   with sending RA's, then I'm happy for that effort to
   be explored,

=> we agree about this, and perhaps we agree too about the superiority
of this approach over fast RS/RA one.

[RP] I think the access point knows when the L2 handoff has been completed (detect the present of the MN over the wireless link), then the access point can immediately send the RA to the MN over the wireless link. In cellular, the wireless link means the dedicated channel, and in this case the access point can even set an indication not to send RA anymore (to save spectrum) until the lifetime closes to expire or the MN turn to be inactive.
 
Thanks.

Rene Purnadi
Phone: +1 972.894.4897
Mobile: +1 972.342.3503
e-mail: rene.purnadi@nokia.com


-----Original Message-----
From: ext Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
Sent: Wednesday, April 24, 2002 5:42 AM
To: greg.daley@eng.monash.edu.au
Cc: Purnadi Rene (NRC/Dallas); brett.pentland@eng.monash.edu.au;
kempf@docomolabs-usa.com; mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance
Fatality 


 In your previous mail you wrote:

   I know of several systems where the L2
   Access Point is not an IP device, and therefore
   cannot participate in L3 connectivity (even if it
   knows about a new association).
   
=> this is (with possible very high arrival rate) the only issue
in the scheme I propose. But there are already some cases where
the L2 access point has to participate to L3 stuff:
 - AAA (insecure networks are not so popular :-)
 - many xxx handover enhancements (to trigger RA sending is in fact
   the first step of possible enhancements).

   If there is intelligence in the network to assist
   with sending RA's, then I'm happy for that effort to
   be explored,

=> we agree about this, and perhaps we agree too about the superiority
of this approach over fast RS/RA one.

   but it is not a viable method for some
   widely deployed technologies.
   
=> you have to give concrete examples and don't forget that if current
IEEE 802.11 networks have no deployed good AAA the reason is the lack
of available solutions, and this hole is being filled very quickly.
(for instance if you use LEAP, the radius server can trigger the RA,
in fact if you use address filtering (very common!) the radius server
is used in order to punch holes in filters (messages with the AP for
MAC filters, with the firewall for IP filters, etc). A very easy way
to implement my proposal is to put the radius server on the same link
than the AP and the MN and to send a RS from it).

Regards

Francis.Dupont@enst-bretagne.fr
   



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 11:55:44 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19977
	for ; Wed, 24 Apr 2002 11:55:44 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09078;
	Wed, 24 Apr 2002 09:55:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00631;
	Wed, 24 Apr 2002 08:55:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OFsnGs018092
	for ; Wed, 24 Apr 2002 08:54:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OFsmHB018091
	for mobile-ip-dist; Wed, 24 Apr 2002 08:54:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OFsjGs018084
	for ; Wed, 24 Apr 2002 08:54:45 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00287
	for ; Wed, 24 Apr 2002 08:54:46 -0700 (PDT)
Received: from mail.flarion.com (mail.flarion.com [63.103.94.23])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13842
	for ; Wed, 24 Apr 2002 08:54:46 -0700 (PDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 24 Apr 2002 11:54:44 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3734E@ftmail>
From: "Alan O'Neill" 
To: "'Dana L. Blair'" ,
        Annika Jonsson
	 ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Wed, 24 Apr 2002 11:54:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Dana,

Completely sympathise with your position on this. Some clarifications
in-line..

Alan

>
> Now this means that an upgraded HA can always tell if an initial home reg
> came via a GFA...a good thing in my book.
> Unfortunately, a legacy HA will fail this reg - again a good thing in my
> book..more pressure on IT department/operator to upgrade the HA.

I don't think it's good when protocols deployed to potentially millions
of devices are not backward compatible.  You are making an implicit
assumption about common administration of the MN, FA, GFA, and the HA
by the same entity (IT department, ...).  This is not a valid
assumption for internet connectivity.

AWO> No - I am only mentioning not requiring a special relationship between
MN and HA in the administration plane.

Remember,
> the HA and MN share a unique relationship and having them on widely
> different MIP versions for any length of time is somewhat perverse to me.

Disagree for the same reasons again.  If the base mobile IP protocol
is broken (and I don't belive it is), then we should fix it before
it gets too widely deployed.  Otherwise, changes to the MN, FA, and
HA functionality MUST be backward compatible.  I don't believe
introducing a new and unecessary layer of fixed heirarchy
is important enough to break backward compatiblity.

The necessary test for this draft should be backward compatibility.
But that may not be sufficient to warrant a new RFC.

AWO> Sure..see my other e-mail on the higher layer issues...

thanks,
Dana

> What is therefore missing is to enable the GFA to insert the assigned GFA
> CoA into the RREP for the MN if the HA failed to do so. The second attempt
> can therefore still succeed to the legacy HA. Each refresh under the same
> GFA also works and we only have a problem again on each GFA change-over
> whilst the MN and HA are on such different versions...
>
> Alan.
>
> /Annika
>
> At 22:23 2002-04-15 -0400, Alan O'Neill wrote:
> >Below is the abstract for the draft that makes last call suggestions on
> >Regional tunneling.
> >
> >see
> >http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mo
> ds-00.txt
> >
> >Abstract
> >
> >    Regional Registration modifies the normal MIP Registration signalling
> >    back to the HA so that the signalling can traverse an intermediate
> >    Gateway Foreign Agent (GFA). The registered binding is
> between the Home
> >    Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent
> >    (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the
> GFA.
> >    Two extensions are defined to support this new Registration
> processing
> >    these being the Hierarchical Foreign Agent extension (HFAext) and the
> GFA
> >
> >    IP address extension (GFAIPext). The former is used to carry
> the FA CoA
> >    to the GFA and the latter is used by the FA to allocate a GFA to the
> MN,
> >    and by the FA, GFA, HA to securely return the GFA IP address
> to the MN.
> >
> >    The present processing rules for the HA registration enable the FA to
> >    advertise the GFA to the MN in a Foreign Agent Advertisement
> (FAA) and
> >    for the MN to include that GFA address into the CoA field of the MIP
> home
> >
> >    Registration. This however assumes a number of things about the GFA
> >    address in the FAA and the addressing realms between the FA-GFA and
> GFA-
> >    HA.. Specifically, the GFA CoA and the GFA IP address must
> potentially
> be
> >
> >    from two different addressing plans and hence cannot be in the same
> FAA.
> >    This draft describes the issues and suggests a solution that requires
> >    slight modifications to the required extensions, that generalises the
> >    Home Registration signalling for arbitrary intermediate MIP
> nodes, and
> >    only slightly modifies the processing rules for the MIP Home
> >    Registration. This draft also describes a way to support dynamic HA
> >    allocation along-side Regional Registrations.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 12:42:51 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27209
	for ; Wed, 24 Apr 2002 12:42:50 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08589;
	Wed, 24 Apr 2002 10:42:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02104;
	Wed, 24 Apr 2002 09:42:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OGfZGs018316
	for ; Wed, 24 Apr 2002 09:41:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OGfYc1018315
	for mobile-ip-dist; Wed, 24 Apr 2002 09:41:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OGfVGs018308
	for ; Wed, 24 Apr 2002 09:41:31 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01769
	for ; Wed, 24 Apr 2002 09:41:33 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17731
	for ; Wed, 24 Apr 2002 09:41:32 -0700 (PDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3OGbcA18309;
	Wed, 24 Apr 2002 11:37:38 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2Y3TZJRK>; Wed, 24 Apr 2002 11:37:34 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC39@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Charles E. Perkins'" 
Cc: "'Annika Jonsson'" ,
        mobile-ip@sunroof.eng.sun.com,
        "'A.ONeill@flarion.com'"
	 
Subject: RE: [mobile-ip] RE: [mobile-imp] WG Last Call:  draft-ietf-mobile
	 ip-reg-tunnel-06. txt
Date: Wed, 24 Apr 2002 11:37:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EBAE.55AA8540"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EBAE.55AA8540
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Charlie/Annika;

As I mentioned earlier that I will summarize those backward compatibility
issues which
I still believe have not been answered.

My concern here was to make this draft work before it becomes a standard. 
As long as this feature is OPTIONAL and it is 100% BACKWARD COMPATIBLE, I
have no
problem with it.
The more solutions we have for the same problem is the better as long as
they are:
	1. OPTIONAL
	2. 100% BACKWARD COMPATIBLE.

Operators can pick and choose the best for them.

Before moving to the technical issues that I feel this draft MUST address. 
I may agree with you that some of these points can be eliminated with static

configuration or provisioning. However, the draft has two choices here:
    i.  Either clearly mention these provisioning restrictions, or
    ii. Offer a smooth solution for backward compatibility

Now to the technical points:

ISSUE No. 1: FA advertised a GFA of ZERO:

This draft makes it optional for the FA to set the only advertised Care-of
address
to ZERO. You mentioned that operator must know that by doing this he/she is
blocking
all RFC3220 compliant Mobile Node which needs a FA Care-of Address to
register.
I agree with this BUT the draft must clearly include this.

section 3.3. can read as follows:
" The `I' flag (see Section 7) MUST be set to indicate that the domain
   supports regional tunnel management, and that the availability of a
   GFA is advertised in the Agent Advertisement message.  If the `I'
   bit is set, there MUST be at least one care-of address in the Agent
   Advertisement message, but that address MAY be set to zero. 
   However, setting the only advertised care-of address 
   to ZERO will eliminate the mobile IP service to all mobile nodes which 
   do not support regional registration.
"
Or just eliminate the option of sending a ZERO care-of address.
What do you think?


ISSUE No. 2: FA advertised ONLY one care-of address "GFA care-of address":
Also on another location, this draft makes it possible for the FA to
advertise only
one care-of address. It also make it very specific by saying that if this
happens, 
this address is the care-of address of the GFA.

Now, this will cause the legacy Mobile Nodes not to know that it handed over
to a new
FA, because it always receives the same care-of address. May be we need to 
repeat the above restriction again. OR WHAT about reversing the logic. If
there 
is only one care-of address in the Agent Advertisement, it is the FA care-of
address. Now, Mobile Nodes which wants to use this service with this
condition
it sets the GFA to ZERO.

section 3.3: can be read as follows 
"
...
   If the `I' bit is set, and there is only one care-of address, it is
   the address of the FA. If the `I' bit is set, and there are multiple 
   care-of addresses, the first care-of address is the local FA, 
   and the last care-of address is the GFA.
...
"
What do you think?


ISSUE No. 3: Legacy HA receives a Registration Request with 
                     GFA IP Address extension or a Replay Protection Style
extension
"
   A Registration Request that does not contain a GFA IP Address
   extension or a Replay Protection Style extension is processed
   by the home agent as described in [9].  If the home agent 
   receives a Registration Request with one of these extensions,
   and the home agent does not support the extension, the home
   agent must return a Registration Reply with the Code value set to
   UNSUPPORTED_EXTENSION [9].  
"

Now this is a new restriction or demand on the legacy HA and is not
acceptable.
Since those extensions are skippable, HA will process the RRQ as Regular MIP
call. You need to make sure to handle this at the GFA. for example something

like the following can be added to section 4.3.

"
If the GFA relays a Registration Request with GFA IP Address extension or a 
Replay Protection Style extension or both and receives a successful
registration 
reply without any of these extension, the GFA MUST send a registration reply

message to the Mobile node with error code of HOME_AGENT_DOES_NOT_SUPPORT_RR

"
What do you think? 


ISSUE 4 & 5
ZERO_CAREOF_ADDRESS & Care-of Address set to zero and a GFA IP Address
extension

I agree these are covered in the Mobile Node consideration as in section
4.1.
"
    If the mobile node sets the care-of address to zero, the mobile node 
   and its home agent MUST support the GFA IP address extension (see section
8.1).  
"

Thanks;
Ahmad Muhanna

 

Hello Charlie; 
I still believe that those backward compatibility issues 
have not been answered YET. 
I will compile another response which includes all issues at once. 
Regards; 
Ahmad Muhanna 
> 
> Hello Ahmad, 
> 
> I'll try to make some answers here. 
> 
> > You are proposing a solution for a specific problem. 
> > You are making this great claim that this solution supports 
> existing Mobile 
> > IPv4 implementation. 
> > 
> > " 
> >    Foreign agents that support regional registrations are 
> also required 
> >    to support registrations according to Mobile IPv4 [9].  
> If there is 
> >    a foreign agent address announced in the Agent Advertisement, the 
> >    mobile node may register that foreign agent care-of 
> address with its 
> >    home agent [9]. 
> > " 
> 
> This is O.K., right?  What does it mean, "great claim"? 
> 
> > Not only this, BUT you also make another great claim 
> without demonstrating 
> > HOW!!! 
> > " 
> >    For mobile nodes that cannot process a NAI, or with 
> mobility agents 
> >    that are not configured to advertise their NAI, regional 
> registration 
> >    is still useful, but the lack of certain features may 
> result in less 
> >    than optimal results. 
> > " 
> 
> If the mobile node cannot process NAI, then it can still do regional 
> registration.  Why not?  Also, isn't it better to write down where 
> additional configuration at the mobility agents can help to get the 
> best results?  I think it's better to fully explain as much 
> as possible 
> here. 
> 
> 
> > On the other hand, it seems that you assume that the whole 
> network will 
> > be upgraded at the same time to accommodate your solution. 
> 
> Not true!  It is possible to mix regional foreign agents with regular 
> foreign agents, and so on. 
> 
> > We are dealing with at least three different entities, MN, 
> FA, and HA. you 
> > added another one GFA. 
> 
> Well, if you don't have a GFA, then you don't have regional 
> registration. 
> Do you mean to suggest otherwise? 
> 
> > There is a great absolute possibility that those entities 
> do not belong to the 
> > same operator. 
> > Unless your draft addresses clearly how these entities 
> would know what the 
> > others support in reference 
> > to what you are proposing or offering a smooth solution 
> without violating the 
> > existing entities, 
> > there will continue to be backward compatibility issues and 
> your first claim 
> > is not justified. 
> 
> As far as I can remember, regional registration has been 
> targeted mainly 
> at domains (regions) operated by the same operator.  Maybe there are 
> more considerations with multi-operator domain, but that 
> really was not 
> on our radar. 
> 
> > I hope I made myself clear here in order to address these backward 
> > compatibility issues. 
> 
> I think that the places where new features are enabled by 
> mechanism that 
> is not able to be parsed by RFC 3220 mobile nodes should not 
> necessarily 
> be given as examples of the lack of backward compatibility.  
> Mobile nodes 
> that don't do regional registrations should be able to be served by 
> foreign agents that do offer regional registrations in addtion to 
> home registrations.  I am not aware of a place in the draft that would 
> make this untrue. 
> 
> Mobile nodes that wish to use regional registration with 
> foreign agents 
> that do not support it, will not succeed.  Mobile nodes that 
> wish to use 
> zero care-of addresses with home agents that do not support it, will 
> not succeed.  Mobile nodes that cannot use advertisements unless the 
> advertisement contains a care-of address, cannot register with a 
> foreign agent that does not offer a care-of address.  These are not 
> examples of backward incompatibility.  After all, to take the latter 
> case, if the foreign agent doesn't offer a care-of address, it just 
> is not running RFC3220, presumably for some good reason from the 
> perspective of the local operator.  The mobile node that only run 
> RFC3220 should just cannot use that foreign agent. 
> 
> We have attempted to preserve backwards compatibility, while allowing 
> the regional registration to offer new features and thus extend to 
> scenarios where RFC 3220 would not work anyway.  That has to be 
> considered O.K. 
> 
> Regards, 
> Charlie P. 
> 

------_=_NextPart_001_01C1EBAE.55AA8540
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] RE: [mobile-imp] WG Last Call:  draft-ietf-mobile ip-reg-tunnel-06. txt




Hello Charlie/Annika;




As I mentioned earlier that I will summarize those backward compatibility issues which

I still believe have not been answered.




My concern here was to make this draft work before it becomes a standard. 

As long as this feature is OPTIONAL and it is 100% BACKWARD COMPATIBLE, I have no

problem with it.

The more solutions we have for the same problem is the better as long as they are:

        1. OPTIONAL

        2. 100% BACKWARD COMPATIBLE.




Operators can pick and choose the best for them.




Before moving to the technical issues that I feel this draft MUST address. 

I may agree with you that some of these points can be eliminated with static 

configuration or provisioning. However, the draft has two choices here:

    i.  Either clearly mention these provisioning restrictions, or

    ii. Offer a smooth solution for backward compatibility




Now to the technical points:




ISSUE No. 1: FA advertised a GFA of ZERO:




This draft makes it optional for the FA to set the only advertised Care-of address

to ZERO. You mentioned that operator must know that by doing this he/she is blocking

all RFC3220 compliant Mobile Node which needs a FA Care-of Address to register.

I agree with this BUT the draft must clearly include this.




section 3.3. can read as follows:

" The `I' flag (see Section 7) MUST be set to indicate that the domain

   supports regional tunnel management, and that the availability of a

   GFA is advertised in the Agent Advertisement message.  If the `I'

   bit is set, there MUST be at least one care-of address in the Agent

   Advertisement message, but that address MAY be set to zero. 

  <NEW TEXT> However, setting the only advertised care-of address 

   to ZERO will eliminate the mobile IP service to all mobile nodes which 

   do not support regional registration<NEW TEXT>.

"

Or just eliminate the option of sending a ZERO care-of address.

What do you think?






ISSUE No. 2: FA advertised ONLY one care-of address "GFA care-of address":

Also on another location, this draft makes it possible for the FA to advertise only

one care-of address. It also make it very specific by saying that if this happens, 

this address is the care-of address of the GFA.




Now, this will cause the legacy Mobile Nodes not to know that it handed over to a new

FA, because it always receives the same care-of address. May be we need to 

repeat the above restriction again. OR WHAT about reversing the logic. If there 

is only one care-of address in the Agent Advertisement, it is the FA care-of

address. Now, Mobile Nodes which wants to use this service with this condition

it sets the GFA to ZERO.




section 3.3: can be read as follows <some text has been removed>

"

...

   If the `I' bit is set, and there is only one care-of address, it is

   the address of the FA. If the `I' bit is set, and there are multiple 

   care-of addresses, the first care-of address is the local FA, 

   and the last care-of address is the GFA.

...

"

What do you think?






ISSUE No. 3: Legacy HA receives a Registration Request with 

                     GFA IP Address extension or a Replay Protection Style extension

"

   A Registration Request that does not contain a GFA IP Address

   extension or a Replay Protection Style extension is processed

   by the home agent as described in [9].  If the home agent 

   receives a Registration Request with one of these extensions,

   and the home agent does not support the extension, the home

   agent must return a Registration Reply with the Code value set to

   UNSUPPORTED_EXTENSION [9].  

"




Now this is a new restriction or demand on the legacy HA and is not acceptable.

Since those extensions are skippable, HA will process the RRQ as Regular MIP

call. You need to make sure to handle this at the GFA. for example something 

like the following can be added to section 4.3.




"

If the GFA relays a Registration Request with GFA IP Address extension or a 

Replay Protection Style extension or both and receives a successful registration 

reply without any of these extension, the GFA MUST send a registration reply 

message to the Mobile node with error code of HOME_AGENT_DOES_NOT_SUPPORT_RR 

"

What do you think? 






ISSUE 4 & 5

ZERO_CAREOF_ADDRESS & Care-of Address set to zero and a GFA IP Address extension




I agree these are covered in the Mobile Node consideration as in section 4.1.

"

    If the mobile node sets the care-of address to zero, the mobile node 

   and its home agent MUST support the GFA IP address extension (see section 8.1).  

"




Thanks;

Ahmad Muhanna




 




Hello Charlie; 

I still believe that those backward compatibility issues 

have not been answered YET. 

I will compile another response which includes all issues at once. 

Regards; 

Ahmad Muhanna 

> 

> Hello Ahmad, 

> 

> I'll try to make some answers here. 

> 

> > You are proposing a solution for a specific problem. 

> > You are making this great claim that this solution supports 

> existing Mobile 

> > IPv4 implementation. 

> > 

> > " 

> >    Foreign agents that support regional registrations are 

> also required 

> >    to support registrations according to Mobile IPv4 [9].  

> If there is 

> >    a foreign agent address announced in the Agent Advertisement, the 

> >    mobile node may register that foreign agent care-of 

> address with its 

> >    home agent [9]. 

> > " 

> 

> This is O.K., right?  What does it mean, "great claim"? 

> 

> > Not only this, BUT you also make another great claim 

> without demonstrating 

> > HOW!!! 

> > " 

> >    For mobile nodes that cannot process a NAI, or with 

> mobility agents 

> >    that are not configured to advertise their NAI, regional 

> registration 

> >    is still useful, but the lack of certain features may 

> result in less 

> >    than optimal results. 

> > " 

> 

> If the mobile node cannot process NAI, then it can still do regional 

> registration.  Why not?  Also, isn't it better to write down where 

> additional configuration at the mobility agents can help to get the 

> best results?  I think it's better to fully explain as much 

> as possible 

> here. 

> 

> 

> > On the other hand, it seems that you assume that the whole 

> network will 

> > be upgraded at the same time to accommodate your solution. 

> 

> Not true!  It is possible to mix regional foreign agents with regular 

> foreign agents, and so on. 

> 

> > We are dealing with at least three different entities, MN, 

> FA, and HA. you 

> > added another one GFA. 

> 

> Well, if you don't have a GFA, then you don't have regional 

> registration. 

> Do you mean to suggest otherwise? 

> 

> > There is a great absolute possibility that those entities 

> do not belong to the 

> > same operator. 

> > Unless your draft addresses clearly how these entities 

> would know what the 

> > others support in reference 

> > to what you are proposing or offering a smooth solution 

> without violating the 

> > existing entities, 

> > there will continue to be backward compatibility issues and 

> your first claim 

> > is not justified. 

> 

> As far as I can remember, regional registration has been 

> targeted mainly 

> at domains (regions) operated by the same operator.  Maybe there are 

> more considerations with multi-operator domain, but that 

> really was not 

> on our radar. 

> 

> > I hope I made myself clear here in order to address these backward 

> > compatibility issues. 

> 

> I think that the places where new features are enabled by 

> mechanism that 

> is not able to be parsed by RFC 3220 mobile nodes should not 

> necessarily 

> be given as examples of the lack of backward compatibility.  

> Mobile nodes 

> that don't do regional registrations should be able to be served by 

> foreign agents that do offer regional registrations in addtion to 

> home registrations.  I am not aware of a place in the draft that would 

> make this untrue. 

> 

> Mobile nodes that wish to use regional registration with 

> foreign agents 

> that do not support it, will not succeed.  Mobile nodes that 

> wish to use 

> zero care-of addresses with home agents that do not support it, will 

> not succeed.  Mobile nodes that cannot use advertisements unless the 

> advertisement contains a care-of address, cannot register with a 

> foreign agent that does not offer a care-of address.  These are not 

> examples of backward incompatibility.  After all, to take the latter 

> case, if the foreign agent doesn't offer a care-of address, it just 

> is not running RFC3220, presumably for some good reason from the 

> perspective of the local operator.  The mobile node that only run 

> RFC3220 should just cannot use that foreign agent. 

> 

> We have attempted to preserve backwards compatibility, while allowing 

> the regional registration to offer new features and thus extend to 

> scenarios where RFC 3220 would not work anyway.  That has to be 

> considered O.K. 

> 

> Regards, 

> Charlie P. 

> 





------_=_NextPart_001_01C1EBAE.55AA8540--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 12:45:16 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27332
	for ; Wed, 24 Apr 2002 12:45:16 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04718;
	Wed, 24 Apr 2002 09:44:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03647;
	Wed, 24 Apr 2002 09:44:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OGhiGs018345
	for ; Wed, 24 Apr 2002 09:43:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OGhhhE018344
	for mobile-ip-dist; Wed, 24 Apr 2002 09:43:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OGheGs018337
	for ; Wed, 24 Apr 2002 09:43:40 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02980
	for ; Wed, 24 Apr 2002 09:43:41 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09337
	for ; Wed, 24 Apr 2002 10:43:40 -0600 (MDT)
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 JAA12090;
	Wed, 24 Apr 2002 09:43:40 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3OGhcZ05591;
	Wed, 24 Apr 2002 09:43:38 -0700
X-mProtect: <200204241643> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd2fX9ce; Wed, 24 Apr 2002 09:43:37 PDT
Message-ID: <3CC6E0B9.EA27F15F@iprg.nokia.com>
Date: Wed, 24 Apr 2002 09:43:37 -0700
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Francis Dupont 
CC: rene.purnadi@nokia.com, brett.pentland@eng.monash.edu.au,
        kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality
References: <200204240947.g3O9lfT68888@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis Dupont wrote:

>    > if it is IPv6 the GGSN is the access router: in all cases a RA will be sent
>    > without a RS and the L3 handover as quick as possible without FMIPv6.
>
>    Some comments on the last sentence..
>
>    - quickly receiving an RA is not equivalent to fast handover (in case you
>    implied it that way).
>
> => we agree, in my message I mean it is the best thing to do when FMIPv6
> (aka fast handowver) is not available. So I believe your comment is more
> a complement than an objection, isn't it?
>

Right, I was not objecting to your statement. Rather, trying to draw
out the differences between this thread and FMIPv6.

>
>    - regarding the ability to receive packets as soon as a new link is
>    available, you need to consider the route-update (BU) latency. FMIPv6
>    moves BU out of time-sensitive path by having a tunnel from previous
>    router to the new one.
>
> => this is BETH, not FMIPv6 fast handover... (no flame war please about
> BETH vs FMIPv6 :-).
>

Both have tunnel from previous AR to new AR :-)

Regards,

-Rajeev


>
> Thanks
>
> Francis.Dupont@enst-bretagne.fr



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 12:53:54 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27704
	for ; Wed, 24 Apr 2002 12:53:53 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23059;
	Wed, 24 Apr 2002 10:53:40 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07360;
	Wed, 24 Apr 2002 09:53:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OGqYGs018518
	for ; Wed, 24 Apr 2002 09:52:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OGqYbu018517
	for mobile-ip-dist; Wed, 24 Apr 2002 09:52:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OGqVGs018508
	for ; Wed, 24 Apr 2002 09:52:31 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01528
	for ; Wed, 24 Apr 2002 09:52:33 -0700 (PDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17804
	for ; Wed, 24 Apr 2002 10:52:32 -0600 (MDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3OGqW420826
	for ; Wed, 24 Apr 2002 11:52:32 -0500 (CDT)
Message-ID: <3CC6E2E6.1090004@alcatel.com>
Date: Wed, 24 Apr 2002 11:52:54 -0500
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t	xt
References: <8C92E23A3E87FB479988285F9E22BE46C3A757@ftmail>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Alan,


Alan O'Neill wrote:

>
>
>However, Flarion has one of the more challenging environments for MIPv4 and
>we will deploy something, sometime, somewhere soon (hopefully in huge
>volumes ;-)
>
do you mind giving more details?

> In reviewing a lot of MIP work in anticipation of that
>deployment, reviews that are still ongoing and for obvious reasons
>commercially sensitive at this time, it is apparent that there are some
>missing bits. We plan to continue to write these up and submit them
>following discussions and agreement with our core router partners and
>customers to then hopefully trigger standards activity where necessary.
>RegTunMods and RevTunMods were the first two such drafts and there will be
>others unrelated to regional tunneling...
>

-- 
Behcet





From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 13:24:21 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29615
	for ; Wed, 24 Apr 2002 13:24:21 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15257;
	Wed, 24 Apr 2002 10:23:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13804;
	Wed, 24 Apr 2002 10:23:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OHMsGs019206
	for ; Wed, 24 Apr 2002 10:22:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OHMsD2019205
	for mobile-ip-dist; Wed, 24 Apr 2002 10:22:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OHMpGs019198
	for ; Wed, 24 Apr 2002 10:22:51 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18160
	for ; Wed, 24 Apr 2002 10:22:51 -0700 (PDT)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02298
	for ; Wed, 24 Apr 2002 11:22:50 -0600 (MDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3OHMnP11891
	for ; Wed, 24 Apr 2002 12:22:49 -0500 (CDT)
Message-ID: <3CC6E9FF.4090909@alcatel.com>
Date: Wed, 24 Apr 2002 12:23:11 -0500
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality
References: <200204240935.g3O9ZtT68827@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Sorry I thought you were discussing FMIPv6 on UMTS, and Francis is 
arguing that it is not applicable because the base protocol (MIPv6) 
handover would always occur first. That's why I suggested that FMIPv6 
could apply to handovers outside UMTS or the like.

Francis Dupont wrote:

> In your previous mail you wrote:
>
>   I wonder in which context are considering the application of FMIPv6? Is 
>   it for fast handover inside UMTS domain? Probably it is more interesting 
>   to consider intertechnology handovers using FMIPv6?
>   
>=> by definition FMIPv6 is intertechnology-capable so this doesn't matter.
>   
>Thanks
>
>Francis.Dupont@enst-bretagne.fr
>
Regards,

-- 
Behcet 





From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 13:59:09 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01621
	for ; Wed, 24 Apr 2002 13:59:09 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22551;
	Wed, 24 Apr 2002 11:59:09 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12530;
	Wed, 24 Apr 2002 10:59:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OHw8Gs023125
	for ; Wed, 24 Apr 2002 10:58:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OHw8FF023124
	for mobile-ip-dist; Wed, 24 Apr 2002 10:58:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OHw4Gs023110
	for ; Wed, 24 Apr 2002 10:58:04 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03816
	for ; Wed, 24 Apr 2002 10:58:04 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21963
	for ; Wed, 24 Apr 2002 11:58:03 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3OH58TZ025705;
	Wed, 24 Apr 2002 10:05:09 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABN14386;
	Wed, 24 Apr 2002 10:02:16 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA21210; Wed, 24 Apr 2002 10:05:01 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15558.58813.157282.992826@thomasm-u1.cisco.com>
Date: Wed, 24 Apr 2002 10:05:01 -0700 (PDT)
To: "James Kempf" 
Cc: "Rajeev Koodli" ,
        "Alper E. YEGIN" ,
        "Manolis Sifalakis" ,
        
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
In-Reply-To: <00c401c1eb69$25179340$b36015ac@T23KEMPF>
References: <3CB5DB1F.90909@lancaster.ac.uk>
	<012801c1e198$1fcb99c0$7e6015ac@T23KEMPF>
	<3CBDBC62.21C19B77@iprg.nokia.com>
	<000001c1e7b6$9288fd80$746015ac@T23KEMPF>
	<3CC0B44C.DB862958@iprg.nokia.com>
	<046701c1e804$7016f330$736015ac@AlperVAIO>
	<3CC58E3C.86B <3CC5CA61.E210D29F@iprg.nokia.com>
	<00c401c1eb69$25179340$b36015ac@T23KEMPF>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

James Kempf writes:
 > > Right. More generally, FBU must authorize packet forwarding
 > > on the tunnel independent of where the tunnel terminates as long as

 > So I agree that the FBU is the proper signal for starting the tunnel in
 > FMIPv6, but I do not agree that it holds as a general principle that a
 > MN can determine the routing of its packets, as this would be in direct
 > contradiction of basic Internet routing design principles.

   It might be helpful to step back to the non-mobile
   case here. You're correct to say that once I've
   sent a packet, I have no influence over where
   it goes. On the other hand, I do have a great
   deal of influence where I send it to in the first
   place; that is, I choose the interface. Since MIP
   tunnels are essentially virtual interfaces, the
   distinction you're making doesn't seem as cut
   and dried to me. Creating and deleting virtual
   interfaces is definitely new ground from the
   original security/routing premises of the net.

   It seems to me that it should be perfectly
   reasonable for a host to request a forwarding
   service to a co-located address which it
   believes it will arrive on. For that, I agree
   with Rajeev that the mobile node has a part to
   play in the authorization. In the purely
   "network does the routing" model you suggest,
   I believe that you unreasonably constrain the
   mobile node's ability to move, possibly with
   the help of a local forwarding service. This is
   especially unreasonable if you want that
   forwarding service, but the two AR's don't have
   a business relationship with one another. Thus,
   it seems quite reasonable that the mobile node
   should ultimately have some influence in the
   service it is asking the AR to provide. In the
   end, while we might provide support for network
   centric moves (ala cellular), but on the
   Internet, the host is King so any solution 
   MUST have a way to control its destiny first
   and foremost.

   On the other hand, it seems reasonable that an
   AR might want to control the tunnel endpoints
   in some way so as to thwart reflection attacks,
   etc. But I'm not sure that we need to do much
   beyond what we need to do for normal home agent
   like signaling; if the local AR has a way to
   authenticate and authorize a mobile node and/or
   other AR's, isn't that enough? We presumably
   have made our peace with reflection attacks
   through a home agent (? haven't we?) so the
   localized equivalent shouldn't be any
   different. Also: the AR is perfectly at liberty
   to not provide the local forwarding service at
   all -- which is current state of affairs,
   afterall.

   What am I missing?

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 14:56:57 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29459
	for ; Wed, 24 Apr 2002 14:56:56 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13279;
	Wed, 24 Apr 2002 12:56:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06809;
	Wed, 24 Apr 2002 11:55:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OIsdGs029489
	for ; Wed, 24 Apr 2002 11:54:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OIsd0x029487
	for mobile-ip-dist; Wed, 24 Apr 2002 11:54:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OIsZGs029480
	for ; Wed, 24 Apr 2002 11:54:35 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14338
	for ; Wed, 24 Apr 2002 11:54:36 -0700 (PDT)
Received: from hotmail.com (f75.law7.hotmail.com [216.33.237.75])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12046
	for ; Wed, 24 Apr 2002 12:54:35 -0600 (MDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 24 Apr 2002 11:54:35 -0700
Received: from 63.78.179.4 by lw7fd.law7.hotmail.msn.com with HTTP;
	Wed, 24 Apr 2002 18:54:35 GMT
X-Originating-IP: [63.78.179.4]
From: "Hemant Chaskar" 
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] MIP QoS requirements draft - modification to Section 3.3.2 
Date: Wed, 24 Apr 2002 18:54:35 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 24 Apr 2002 18:54:35.0711 (UTC) FILETIME=[7A5B64F0:01C1EBC1]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

I received some comments privately that the text in Section 3.3.2 of 
draft-ietf-mobileip-qos-requirements-02.txt, is not clear enough. In 
response to that, I propose the following modification to this text. Please 
let me know if you have any comments, else I will go ahead and incorporate 
it in the next version (03) of the draft.

Thanks,
Hemant

Old text:
----------

2. Interactions with link-layer support for QoS:

The QoS mechanism MAY provide some information to the link layers for them 
to support the required QoS. Since a vast number of devices using Mobile IP 
will be connected to the Internet via wireless links, QoS parameters 
relevant for wireless links, such as error rate, MAY have to be included in 
the set of IP-level QoS parameters to be possibly considered by the 
underlying link layer.

An example scenario will be two UDP streams requiring different levels of 
error protection at the link layer. For such cases, an IP-layer QoS 
mechanism may indicate some generic parameters such as acceptable IP packet 
loss rate to link layers.

New text:
-----------

2. Interactions with wireless link-layer support for QoS:

Since a vast number of devices using Mobile IP will be connected to the 
Internet via wireless links, the QoS mechanism for Mobile IP MAY provide 
some information to the wireless link layers for them to support the 
required QoS.

An example scenario that may benefit from such information is that of the 
two UDP streams associated with the same media, but requiring different 
levels of error protection at the wireless link layer due to certain 
characteristics of their respective encoding schemes. The packets of these 
two streams are equally delay sensitive (so as to maintain playout 
synchronization at the receiver), and hence, may be treated equally (as 
regards queuing) by IP layer. But they may need to be transmitted on 
wireless channels of different error characteristics(say different FEC 
coding or power levels).

The QoS information included for the benefit of wireless link layers SHOULD 
be such that it is meaningful both ways: to applications that reside over IP 
so that they can choose the IP service of certain QoS characteristics and to 
wireless link QoS managers so that they can then map this information to the 
details of lower layer mechanisms and their parameters.

In the example scenario described above, such a QoS information could be 
expressed as the acceptable loss rate of IP packets in the UDP stream. This 
parameter enables the UDP application to choose the IP service having QoS 
that matches its requirements, and it also enables the wireless link QoS 
managers to choose the right wireless channel to transmit the packets of 
this UDP stream.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 15:00:45 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02876
	for ; Wed, 24 Apr 2002 15:00:45 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05348;
	Wed, 24 Apr 2002 13:00:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09545;
	Wed, 24 Apr 2002 11:59:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OIweGs000059
	for ; Wed, 24 Apr 2002 11:58:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OIweoD000058
	for mobile-ip-dist; Wed, 24 Apr 2002 11:58:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OIwbGs000040
	for ; Wed, 24 Apr 2002 11:58:38 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23391
	for ; Wed, 24 Apr 2002 14:58:38 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA01260
	for mobile-ip@sunroof.eng.sun.com; Wed, 24 Apr 2002 14:59:36 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3O9VHGs016827
	for ; Wed, 24 Apr 2002 02:31:17 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08957
	for ; Wed, 24 Apr 2002 02:31:18 -0700 (PDT)
Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01815
	for ; Wed, 24 Apr 2002 02:31:17 -0700 (PDT)
Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2653.19)
	id ; Wed, 24 Apr 2002 17:31:16 +0800
Message-ID: <858F42BD6D0A8245863391B6894FC8EC2853FE@MBXSRV23.stu.nus.edu.sg>
From: Jing Caoyu 
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Controdiction between F_BACK and use of new CoA
Date: Wed, 24 Apr 2002 17:31:12 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="UTF-8"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi,
 
I am implementing fast handover draft draft-ietf-mobileip-fast-mipv6-04.
 
(1) On page 15, it says that "Upon receipt of the F-BU, the oAR must send a
F-BACK message to MN at its nCoA on nAR"
 
(2) In the next next paragraph, it says that "On the MN, the MN MUST  NOT
use the nCoA address as a source address until it receiveds a F-BACK from
the oAR."
 
Assuming the case in which MN didn't receive F-BACK in the old network, then
it has to receive the copy of F-BACK  forwarded to nCoA at the new network.
However, before the MN recieves the F-BACK, it cannot use nCoA as its source
address, as a result F-BACK with destination (nCoA) can't reach the MN at
ALL. As a result, the MN will never receive a F-BACK.
 
Is there a controdiction between (1) and (2)? Please reply to my message as
I need the information urgently for the implementation I am currently doing.
 
Thank you  very much!
 
 
Best regards,
 
Caoyu Jing
National University of Singapore


From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 15:23:04 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04237
	for ; Wed, 24 Apr 2002 15:23:03 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17198;
	Wed, 24 Apr 2002 13:23:04 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22424;
	Wed, 24 Apr 2002 12:22:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OJM5Gs002764
	for ; Wed, 24 Apr 2002 12:22:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OJM5ch002763
	for mobile-ip-dist; Wed, 24 Apr 2002 12:22:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OJM3Gs002756
	for ; Wed, 24 Apr 2002 12:22:03 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01729
	for ; Wed, 24 Apr 2002 15:22:03 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA01276
	for mobile-ip@sunroof.eng.sun.com; Wed, 24 Apr 2002 15:23:01 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OGrHGs018530
	for ; Wed, 24 Apr 2002 09:53:17 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01883
	for ; Wed, 24 Apr 2002 09:53:17 -0700 (PDT)
Received: from vcsun1.seas.smu.edu (vcsun1.seas.smu.edu [129.119.112.37])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18270
	for ; Wed, 24 Apr 2002 10:53:17 -0600 (MDT)
Received: from [129.119.8.211] (tchenmac.seas.smu.edu [129.119.8.211])
	by vcsun1.seas.smu.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA15616;
	Wed, 24 Apr 2002 11:45:18 -0500 (CDT)
Mime-Version: 1.0
X-Sender: tchen@vcserv.seas.smu.edu
Message-Id: 
Date: Wed, 24 Apr 2002 11:45:45 -0600
To: kgold@firstconf.com, kuvs-elg@fokus.gmd.de,
        lists-mbone-eu-op-out@postman.ripe.net,
        Mail-distributor@KOM.th-darmstadt.de, manet@itd.nrl.navy.mil,
        mbone-eu-op@ripe.net, members@tmforum.org,
        mobile-ip@sunroof.eng.sun.com, multicomm@research.panasonic.com,
        n2k-oc@comsoc.org, netnomics@eco.utexas.edu,
        news-announce-conferences@uunet.uu.net, nichains@bxl.dg13.cec.eu.int
From: Tom Chen 
Subject: [mobile-ip] CFP: IP Operations and Management (IPOM 2002)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
        * Apologies if you receive multiple copies of this *


                        CALL FOR PAPERS

      2002 IEEE Workshop on IP Operations & Management (IPOM 2002)

                      Octiber 29-31, 2002
                       Dallas, Texas USA
              http://snoopy.seas.smu.edu/ipom2002/

           Sponsored by the IEEE Communications Society

The 2002 IEEE Workshop on IP Operations and Management will
be held in Dallas, Texas, near the "Telecom Corridor" constituted by
Nortel Networks, Ericsson, Alcatel, Nokia, Cisco Systems, and other
major industry leaders.  The workshop will include a day of
tutorials and two days of presentations on original research.
The purpose of the workshop is to share research, experiences, and ideas
among researchers, engineers, and service providers involved in
IP-oriented network management and operations.  As IP-based networks
continue to expand from traditional data services to new real-time
and multimedia services, they become more difficult to manage.
At the same time, their proper operation is more important to maintain
for business.  It is vital to find both theoretical and practical
solutions to address these challenges.

Original papers are invited on such topics as (but not limited to):

* Using SNMP to manage networks
* Web-based network management
* Operations of IP networks
* SNMP versus TMN-based approaches
* Integrated management of multilayer networks
* Management of IP over SONET/SDH or WDM networks
* Management of IP over ATM
* Network management platforms
* Management of QoS in IP networks
* Security management for IP networks
* Mobility management, eg, mobile IP
* Management of Voice over IP
* Accounting, tariffing, and billing
* Network monitoring and diagnostics
* Deployment of new IP services, eg, diffserv, multicast, IPv6, etc.
* CORBA/Java-based network management
* Distributed network management and mobile agents
* IP traffic modeling and management
* Network planning and dimensioning
* Policy driven networks
* Scalability issues
* Case studies and experiments

Instructions for Authors:

Full paper submissions should be submitted electronically to one of
the technical program co-chairs in postscript, PDF, or Microsoft Word
format.  Submissions should be limited to 5 pages (standard double-column
IEEE conference format).  An additional title page should contain the
title of the paper, the authors' name(s), affiliation, address, telephone
and fax numbers, and e-mail of the corresponding author.

Questions and submissions may be directed to either of the
technical program co-chairs:

Tom Chen                         Salah Aidarous
SMU, Dept of EE                  NEC America
PO Box 750338                    6555 N State Highway 161
Dallas, Texas 75275-0338 USA     Irving, Texas 75039 USA
Tel: +1 214 768 8541             Tel:  +1 214 262 3230
Fax: +1 214 768 3573             Fax:  +1 214 262 3225
Email: tchen@engr.smu.edu        Email: saidarous@necam.com

Important dates:

Deadline for submissions:   May 10, 2002
Authors notifications:      August 9, 2002
Final manuscripts due:      September 6, 2002

General chair:

G-S Kuo, National Chengchi University, Taiwan
Email: gskuo@ieee.org




From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 17:01:54 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07512
	for ; Wed, 24 Apr 2002 17:01:53 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24515;
	Wed, 24 Apr 2002 15:01:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26496;
	Wed, 24 Apr 2002 14:01:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OL0aGs007286
	for ; Wed, 24 Apr 2002 14:00:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OL0aYN007285
	for mobile-ip-dist; Wed, 24 Apr 2002 14:00:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged))
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OL0WGs007268
	for ; Wed, 24 Apr 2002 14:00:32 -0700 (PDT)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g3OL0WJe002535;
	Wed, 24 Apr 2002 14:00:32 -0700 (PDT)
Message-Id: <200204242100.g3OL0WJe002535@jurassic.eng.sun.com>
Date: Wed, 24 Apr 2002 14:02:51 -0700 (PDT)
From: Samita Chakrabarti 
Reply-To: Samita Chakrabarti 
Subject: Re: [mobile-ip] Editorial comments on Draft 16 - Sections 1-5
To: jari.arkko@piuha.net
Cc: mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Vl3JgRNrX+O7t6VPGwlYuw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hello  Jari,

> > C5.1.5:
> > The home cookie is a 128-bit field aligned on a 32-bit boundary.  I do
> > believe it should be on a 64-bit boundary.
> 
> 
> There's a tradeoff on making the cookie aligned on a 64 bit boundary
> vs. spending 8 reserved bytes vs. not saving any bits for flags (though
> flags can be simulated with options). I'm thinking we should spend the 8
> bytes. Comments?
> 

I am not sure if I understand your point. Could you please clrify ?

The home cookie 128 bit field aligned on a 32-bit boundary seems correct
to me. 

> 
> > C5.2.1P8:
> > An odd question - if all parameters must start on 8-byte boundaries,
> > why don't we make all message end on 8-byte boundaries.  Is is to
> > simply make those message without a parameter take up minimum space.
> > When considering those that require a parameter, though, does it make
> > any since to 'require' padding.  Wouldn't that space be better spent
> > as reserved space.
> 
> Yes. If we do this, it might make sense to mandate that all parameters
> are also multiple of 8 bytes, making pad1 and padn unnecessary. Comments?

The draft 16 specifies that the MH + messages would have to be multiple of
8 bytes or octets. Thus, if there is no parameter value, then only we need
to pad it with 4 bytes to make it multiple of 8 bytes.

Most of the cases, MH message will use parameter values (HOT[I]/COT[I],
 BR, BU, BACK),
so hardly we need to use padding in MH messages. Will the newly proposed
Binding error messages  use any parameters, such as authenticator ?

In that case, I find the current alignment requirement is good for minimum
usage of space (i,e 'MH + messages' are of multiple of 8 bytes).

Thanks,
-Samita



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 17:09:22 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08317
	for ; Wed, 24 Apr 2002 17:09:21 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13717;
	Wed, 24 Apr 2002 15:09:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29730;
	Wed, 24 Apr 2002 14:09:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OL8QGs008333
	for ; Wed, 24 Apr 2002 14:08:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OL8QJi008332
	for mobile-ip-dist; Wed, 24 Apr 2002 14:08:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OL8LGs008311
	for ; Wed, 24 Apr 2002 14:08:21 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29389
	for ; Wed, 24 Apr 2002 14:08:21 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27700
	for ; Wed, 24 Apr 2002 15:08:21 -0600 (MDT)
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 OAA28199;
	Wed, 24 Apr 2002 14:08:19 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3OL8HY03650;
	Wed, 24 Apr 2002 14:08:17 -0700
X-mProtect: <200204242108> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdGS94Ud; Wed, 24 Apr 2002 14:08:16 PDT
Message-ID: <3CC71EC0.97858238@iprg.nokia.com>
Date: Wed, 24 Apr 2002 14:08:16 -0700
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: "Alper E. YEGIN" ,
        Manolis Sifalakis ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> <046701c1e804$7016f330$736015ac@AlperVAIO> <3CC58E3C.86B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi,

>
> I don't think this follows. If the tunnel terminates at new AR, the new
> AR may buffer the packets until the MN shows up on the link. In BETH,
> the ARs co-operate to set up the routing, so a Link Down on the old AR
> is the appropriate trigger for setting up the tunnel. The MN isn't
>

Ok. The difference between BETH and FMIPv6 is noted.

> involved in determining the routing, the routers are. This is consistent
> with the basic history and design philosophy of IP routing, namely that
> a host doesn't concern itself with the path its packets take through the
> network, it is the task of the routers to perform this function. Hosts
> have never been responsible for determining routing in IP (modulo source
> routes of course) except to select their default router.
>

Well, I agree with you that routing (i.e., the way a packet traverses
nodes to reach the destination) is not what hosts typically get
involved in. However, a host has to be able to determine whether
it receives packets or not in the first place, independent of _how_ the
packets arrive.  More to the point, the MN must decide
whether its current AR should redirect traffic or not.


>
> In Mobile IP if the old AR is functioning as an on-link HA, as the MIPv6
> draft indicates, then the same mechanism used by the MN to communicate
> with the HA in the home network are appropriate for indicating to the
> old AR when the MN is on the new link, thus the FBU acts as the
> indicator for setting the tunnel up to the MN. But this is only because
> Mobile IP makes an exception to the standard IP routing design for a
> specific case, namely changing the care of address. This case doesn't
>

I would say that standard IP routing is not affected at all by Mobile IP.
Whether Mobile IP chose to be that way or it was the result of a routing
exception (or both) is another issue. In any case, it is crucial to note
that the
burden of mobility (i.e., being reachable in the presence of handovers and
roaming) is on the mobile node with Mobile IP, that allows it to operate
without special IP routing support.

> occur with BETH because the care of address doesn't change prior to the
> Layer 2 handover. BETH uses standard IP routing mechanisms to fix up the
>

Ok. This distinction between BETH and FMIPv6 is also noted.


> change in link, Mobile IP mechanisms are used after the link switch to
> change the care of address as in standard Mobile IP, rather than
> changing the care of address before, as in FMIPv6.

However, let me point out that a mode in FMIPv6 allows a MN to keep
its old CoA.

>
> So I agree that the FBU is the proper signal for starting the tunnel in
> FMIPv6, but I do not agree that it holds as a general principle that a
> MN can determine the routing of its packets, as this would be in direct
> contradiction of basic Internet routing design principles.
>

As I mentioned above, an end-point must control the destiny of its
packets, if not the way the packets get there (as you point out
above, there is a routing exception: source routing).

In any case, I notice that FMIPv6 and BETH design points are somewhat
different (even though improved handover is the target) including
- who has the control in deciding when forwarding on the tunnel is
   activated
- whether the MN always keeps the old CoA (BETH) or it uses the
   new CoA or the old CoA (FMIPv6)
- whether L2 triggers are used (BETH) or IP messages are used (FMIPv6)
    for handover switching

I think it makes sense to document these and others, at the very least.

Regards,

-Rajeev



>
>             jak



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 18:27:03 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10510
	for ; Wed, 24 Apr 2002 18:27:02 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07676;
	Wed, 24 Apr 2002 16:26:59 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05435;
	Wed, 24 Apr 2002 15:26:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OMPsGs015050
	for ; Wed, 24 Apr 2002 15:25:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3OMPsjE015049
	for mobile-ip-dist; Wed, 24 Apr 2002 15:25:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged))
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3OMPpGs015042
	for ; Wed, 24 Apr 2002 15:25:51 -0700 (PDT)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g3OMPpJe027155;
	Wed, 24 Apr 2002 15:25:51 -0700 (PDT)
Message-Id: <200204242225.g3OMPpJe027155@jurassic.eng.sun.com>
Date: Wed, 24 Apr 2002 15:28:10 -0700 (PDT)
From: Samita Chakrabarti 
Reply-To: Samita Chakrabarti 
Subject: [mobile-ip] More comments on Draft16 -CLARIFICATION
To: jari.arkko@piuha.net
Cc: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 0QBQfvPm+GNhXK+Agek06A==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

After some internal discussions we think, the following items should be
clarified in the next revision of the MIPv6 draft.

BTW, there is one recommendation for adding one more BA status as well.

Here are the comments:

1.
In the draft, we must make sure to clearly specify that reverse tunnel
is mandatory now for mobile node and home agent. I am not sure, which
section this information should go to.

2.
Also, we have had email discussion that only HOT message is sent in
ESP tunnel mode. For symmetry, we should mandate ESP tunnel mode for
both HOT/HOTI messages between MN-HA.

Also, we need to clarify in the draft that ESP tunnel mode must(?) be used
over the MN-HA tunnel for binding update signalling HOTI/HOT traffic
only. The regular data traffic through the same MN-HA tunnel may not 
necessarily be protected by ESP.

3.
section 4.5.5

This section should clarify whether route optimazation through binding
update to a CN is a MUST or optional.
Also, for better understanding and clarification of crypto handling,
it would be very helpful if this section offers several subsections,
for example:

Cookie(Kcn) generation procedure
--------------------------------

Should talk about how Kcn should be generated. It should talk about
the size and data type of Kcn.

Cookie update
---------------

Whether Kcn should be updated periodically. What is the default or
recommended update mechanism ? 
When Kcn value is changed, then how long should one keep the old
Kcn around in order to accept a BU which is on flight while the
Kcn got changed.


Nonce generation procedure
-----------------------------

Nonce index is a 16 bit quantity. So what would be the default 
recommendation for sequence of index values for which the cookie
would be valid ? Should it correspond to COOKIE_MIN_LIFETIME ?

What is data type and size of Nj ?

I understand that Nj == j is acceptable, because Nj is  locally 
known to CN, do we need to document that ? 

A calculation or relationship between COOKIE LIFETIME and 
nonce-index and nonce generation method would be useful for
implementors to maintain interoperability.

Nonce update  
------------
How j values and Nj values should be stored and updated in the
system ?



RR signaling procedure
----------------------

The current 7 steps could be re-written in such a way which can
clearly specify the sequence and parallel steps and which of
them going via HA and which of them are not. BU messge does not
go via HA-right ? It should clarify that here. A diagram may be
useful.


Each HOTI/COTI/HOT/COT/BA/BU/BR messages should specify the source
and destination address of the packet. Whether it's tunneled or
not. If tunneled if there is any security protocol to be used.
It should also specify data type and size of K0, K1 and how they
should be formed in terms of implementation. Each item should
also refer to the Message Authentication section below.


Message Authentication
----------------------
This section  should specify the HMAC-SHA1 and how it could be
used. It should specify how the output value of HMAC-SHA1 be
considered for K0 or K1 (96bit value). What is the input value
size of HMAC_SHA1 function here ?

It's confusing whether MAC-Kcn is meant to use HMAC-SHA1 with key
Kcn, please clarify the notation.


Hash Function
---------------
Should talk about the recommended hash function to compute Kbu.



section 5.1.8  BA messages

I understand that Alt COA and Unique identifier parameters are
optional. Should not we have a BA status value when these parameters
are not supported ?
i,e

146

 Parameter type not supported

--------------------------------------------------------------------

Thanks,
-Samita



From owner-mobile-ip@sunroof.eng.sun.com  Wed Apr 24 19:35:29 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11701
	for ; Wed, 24 Apr 2002 19:35:28 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20011;
	Wed, 24 Apr 2002 17:35:24 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24254;
	Wed, 24 Apr 2002 16:35:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ONYBGs015336
	for ; Wed, 24 Apr 2002 16:34:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ONYBqt015335
	for mobile-ip-dist; Wed, 24 Apr 2002 16:34:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ONY7Gs015328
	for ; Wed, 24 Apr 2002 16:34:07 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23794;
	Wed, 24 Apr 2002 16:34:08 -0700 (PDT)
Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27952;
	Wed, 24 Apr 2002 17:34:07 -0600 (MDT)
Received: from cs.ucsb.edu (vail [128.111.52.30])
	by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3ONY6O29073;
	Wed, 24 Apr 2002 16:34:06 -0700 (PDT)
Message-ID: <3CC740EE.5CF3FC9D@cs.ucsb.edu>
Date: Wed, 24 Apr 2002 16:34:06 -0700
From: Robert Chalmers 
Organization: UCSB Computer Science
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Samita Chakrabarti 
CC: jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Editorial comments on Draft 16 - Sections 1-5
References: <200204242100.g3OL0WJe002535@jurassic.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Samita and Jari,

> > > C5.1.5:
> > > The home cookie is a 128-bit field aligned on a 32-bit boundary.  I do
> > > believe it should be on a 64-bit boundary.
> >
> >
> > There's a tradeoff on making the cookie aligned on a 64 bit boundary
> > vs. spending 8 reserved bytes vs. not saving any bits for flags (though
> > flags can be simulated with options). I'm thinking we should spend the 8
> > bytes. Comments?
> >
> 
> I am not sure if I understand your point. Could you please clrify ?
> 
> The home cookie 128 bit field aligned on a 32-bit boundary seems correct
> to me.
> 
According to RFC 2460, Section 4: 'fields of width n octects are placed
at an integer multiple of n octects from the start of the header, for n
= 1, 2, 4, or 8'

A 128-bit value would be n=16. Alignment is only 'mandated' up to n=8.
So in my mind, any value of n > 8 should be aligned as if n = 8 (a
64-bit boundary). I think if you look at any IPv6 address (128-bit)
that's used in standard headers, they are all aligned on 64-bit
boundaries. I'm not absolutely sure about any of this, of course.

> > > C5.2.1P8:
> > > An odd question - if all parameters must start on 8-byte boundaries,
> > > why don't we make all message end on 8-byte boundaries.  Is is to
> > > simply make those message without a parameter take up minimum space.
> > > When considering those that require a parameter, though, does it make
> > > any since to 'require' padding.  Wouldn't that space be better spent
> > > as reserved space.
> >
> > Yes. If we do this, it might make sense to mandate that all parameters
> > are also multiple of 8 bytes, making pad1 and padn unnecessary. Comments?
> 
> The draft 16 specifies that the MH + messages would have to be multiple of
> 8 bytes or octets. Thus, if there is no parameter value, then only we need
> to pad it with 4 bytes to make it multiple of 8 bytes.
> 
It also states in Section 5.2.1 that parameters must start and end on
8-byte boundaries. That's what I was talking about here. Should the text
be changed to read that that 'set' of parameters must start and end on
8-byte boundaries? Now it reads as each parameter must do so.

So, take the BACK as an example. It ends on a 32-bit boundary (n=4), but
requires that the Authentcation Param be present which must start on a
64-bit boundary (n=8). This absolutely requires 4 bytes of padding in
every BACK message.

> Most of the cases, MH message will use parameter values (HOT[I]/COT[I],
>  BR, BU, BACK),
> so hardly we need to use padding in MH messages. Will the newly proposed
> Binding error messages  use any parameters, such as authenticator ?
> 
> In that case, I find the current alignment requirement is good for minimum
> usage of space (i,e 'MH + messages' are of multiple of 8 bytes).

ttyl,
Bob

-- 
/****************************************************************

 Robert Chalmers
 UCSB Computer Science Doctoral Candidate
 Network and Multimedia Systems Lab (NMSL)

 "My heart is in the code, but my soul lies in the process"
 
 | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 04:35:19 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29288
	for ; Thu, 25 Apr 2002 04:35:18 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28639;
	Thu, 25 Apr 2002 01:34:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19688;
	Thu, 25 Apr 2002 01:34:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3P8XhGs000535
	for ; Thu, 25 Apr 2002 01:33:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3P8Xhih000534
	for mobile-ip-dist; Thu, 25 Apr 2002 01:33:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3P8XdGs000519
	for ; Thu, 25 Apr 2002 01:33:39 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19457
	for ; Thu, 25 Apr 2002 01:33:40 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19414
	for ; Thu, 25 Apr 2002 01:33:39 -0700 (PDT)
Message-ID: <00c101c1ec33$a51c7f40$b36015ac@T23KEMPF>
From: "James Kempf" 
To: "Michael Thomas" 
Cc: "Rajeev Koodli" ,
        "Alper E. YEGIN" ,
        "Manolis Sifalakis" ,
        
References: <3CB5DB1F.90909@lancaster.ac.uk><012801c1e198$1fcb99c0$7e6015ac@T23KEMPF><3CBDBC62.21C19B77@iprg.nokia.com><000001c1e7b6$9288fd80$746015ac@T23KEMPF><3CC0B44C.DB862958@iprg.nokia.com><046701c1e804$7016f330$736015ac@AlperVAIO><3CC58E3C.86B <3CC5CA61.E210D29F@iprg.nokia.com><00c401c1eb69$25179340$b36015ac@T23KEMPF> <15558.58813.157282.992826@thomasm-u1.cisco.com>
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
Date: Thu, 25 Apr 2002 01:04:28 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Michael,

Your analysis is correct if the mobile node knows that a handover is
occuring. I probably didn't make this clear enough, but as I mentioned,
IP hosts have always had the option of choosing their default router,
and if they becme aware that this router is changing, they should have
the option of choosing a new one. Security, to the extent it is possible
with currently unsecured protocols such as ND, should of course also
play a role as you describe.

I was objecting to what I detected  in Rajeev's note that this must
always be the case, even when the mobile did not have any knowledge that
the handover was occuring. In my view, this corresponds to a failure of
a router in the network.

Which occurs depends on how much informatoin is made available to which
entity by the wireless protocol.

Does this make sense?

            jak

PS: BTW, I followed up that reference on routing security. Dan Harkin in
his book on IPSEC mentions on pg. 111 that a separate ISAKAMP DOI for
OSPFv2 and RIPv2 has been written. He says that this is separate from
the IKE DOI and IPSec DOI.

----- Original Message -----
From: "Michael Thomas" 
To: "James Kempf" 
Cc: "Rajeev Koodli" ; "Alper E. YEGIN"
; "Manolis Sifalakis"
; 
Sent: Wednesday, April 24, 2002 10:05 AM
Subject: Re: [mobile-ip] some questions about
draft-ietf-mobileip-fast-mipv6-04


> James Kempf writes:
>  > > Right. More generally, FBU must authorize packet forwarding
>  > > on the tunnel independent of where the tunnel terminates as long
as
>
>  > So I agree that the FBU is the proper signal for starting the
tunnel in
>  > FMIPv6, but I do not agree that it holds as a general principle
that a
>  > MN can determine the routing of its packets, as this would be in
direct
>  > contradiction of basic Internet routing design principles.
>
>    It might be helpful to step back to the non-mobile
>    case here. You're correct to say that once I've
>    sent a packet, I have no influence over where
>    it goes. On the other hand, I do have a great
>    deal of influence where I send it to in the first
>    place; that is, I choose the interface. Since MIP
>    tunnels are essentially virtual interfaces, the
>    distinction you're making doesn't seem as cut
>    and dried to me. Creating and deleting virtual
>    interfaces is definitely new ground from the
>    original security/routing premises of the net.
>
>    It seems to me that it should be perfectly
>    reasonable for a host to request a forwarding
>    service to a co-located address which it
>    believes it will arrive on. For that, I agree
>    with Rajeev that the mobile node has a part to
>    play in the authorization. In the purely
>    "network does the routing" model you suggest,
>    I believe that you unreasonably constrain the
>    mobile node's ability to move, possibly with
>    the help of a local forwarding service. This is
>    especially unreasonable if you want that
>    forwarding service, but the two AR's don't have
>    a business relationship with one another. Thus,
>    it seems quite reasonable that the mobile node
>    should ultimately have some influence in the
>    service it is asking the AR to provide. In the
>    end, while we might provide support for network
>    centric moves (ala cellular), but on the
>    Internet, the host is King so any solution
>    MUST have a way to control its destiny first
>    and foremost.
>
>    On the other hand, it seems reasonable that an
>    AR might want to control the tunnel endpoints
>    in some way so as to thwart reflection attacks,
>    etc. But I'm not sure that we need to do much
>    beyond what we need to do for normal home agent
>    like signaling; if the local AR has a way to
>    authenticate and authorize a mobile node and/or
>    other AR's, isn't that enough? We presumably
>    have made our peace with reflection attacks
>    through a home agent (? haven't we?) so the
>    localized equivalent shouldn't be any
>    different. Also: the AR is perfectly at liberty
>    to not provide the local forwarding service at
>    all -- which is current state of affairs,
>    afterall.
>
>    What am I missing?
>
>    Mike
>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 05:26:30 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29299
	for ; Thu, 25 Apr 2002 04:35:20 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28727;
	Thu, 25 Apr 2002 01:34:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19763;
	Thu, 25 Apr 2002 01:34:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3P8Y8Gs000590
	for ; Thu, 25 Apr 2002 01:34:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3P8Y8bC000589
	for mobile-ip-dist; Thu, 25 Apr 2002 01:34:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3P8Y3Gs000575
	for ; Thu, 25 Apr 2002 01:34:03 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19581
	for ; Thu, 25 Apr 2002 01:34:02 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16409
	for ; Thu, 25 Apr 2002 02:33:56 -0600 (MDT)
Message-ID: <00c301c1ec33$afe2ad00$b36015ac@T23KEMPF>
From: "James Kempf" 
To: "Rajeev Koodli" 
Cc: "Alper E. YEGIN" ,
        "Manolis Sifalakis" ,
        
References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> <046701c1e804$7016f330$736015ac@AlperVAIO> <3CC58E3C.86B <3CC71EC0.97858238@iprg.nokia.com>
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
Date: Thu, 25 Apr 2002 01:17:02 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Rajeev,

One issue is where the information about the failure of routing due to
link handover is available. If the MN knows, then it can take measures.
If the network knows, then it can. FMIPv6 and BETH are two design points
to cover these. These are covered in the draft.

The other issue is when the information is available, before or after
the point of link attachment has been changed (or both). Both FMIPv6 and
BETH cover only the before case. Optimized standard Mobile IP handover,
Forwarding from Previous Care of Address, and Posthandover Mobile
Initiated Tunneling cover after. These are not covered in the draft, but
are in other drafts.

I think all of these are possible cases, unfortunately, and they all
have different preformance characteristics.

            jak

----- Original Message -----
From: "Rajeev Koodli" 
To: "James Kempf" 
Cc: "Alper E. YEGIN" ; "Manolis Sifalakis"
; 
Sent: Wednesday, April 24, 2002 2:08 PM
Subject: Re: [mobile-ip] some questions about
draft-ietf-mobileip-fast-mipv6-04


>
> Hi,
>
> >
> > I don't think this follows. If the tunnel terminates at new AR, the
new
> > AR may buffer the packets until the MN shows up on the link. In
BETH,
> > the ARs co-operate to set up the routing, so a Link Down on the old
AR
> > is the appropriate trigger for setting up the tunnel. The MN isn't
> >
>
> Ok. The difference between BETH and FMIPv6 is noted.
>
> > involved in determining the routing, the routers are. This is
consistent
> > with the basic history and design philosophy of IP routing, namely
that
> > a host doesn't concern itself with the path its packets take through
the
> > network, it is the task of the routers to perform this function.
Hosts
> > have never been responsible for determining routing in IP (modulo
source
> > routes of course) except to select their default router.
> >
>
> Well, I agree with you that routing (i.e., the way a packet traverses
> nodes to reach the destination) is not what hosts typically get
> involved in. However, a host has to be able to determine whether
> it receives packets or not in the first place, independent of _how_
the
> packets arrive.  More to the point, the MN must decide
> whether its current AR should redirect traffic or not.
>
>
> >
> > In Mobile IP if the old AR is functioning as an on-link HA, as the
MIPv6
> > draft indicates, then the same mechanism used by the MN to
communicate
> > with the HA in the home network are appropriate for indicating to
the
> > old AR when the MN is on the new link, thus the FBU acts as the
> > indicator for setting the tunnel up to the MN. But this is only
because
> > Mobile IP makes an exception to the standard IP routing design for a
> > specific case, namely changing the care of address. This case
doesn't
> >
>
> I would say that standard IP routing is not affected at all by Mobile
IP.
> Whether Mobile IP chose to be that way or it was the result of a
routing
> exception (or both) is another issue. In any case, it is crucial to
note
> that the
> burden of mobility (i.e., being reachable in the presence of handovers
and
> roaming) is on the mobile node with Mobile IP, that allows it to
operate
> without special IP routing support.
>
> > occur with BETH because the care of address doesn't change prior to
the
> > Layer 2 handover. BETH uses standard IP routing mechanisms to fix up
the
> >
>
> Ok. This distinction between BETH and FMIPv6 is also noted.
>
>
> > change in link, Mobile IP mechanisms are used after the link switch
to
> > change the care of address as in standard Mobile IP, rather than
> > changing the care of address before, as in FMIPv6.
>
> However, let me point out that a mode in FMIPv6 allows a MN to keep
> its old CoA.
>
> >
> > So I agree that the FBU is the proper signal for starting the tunnel
in
> > FMIPv6, but I do not agree that it holds as a general principle that
a
> > MN can determine the routing of its packets, as this would be in
direct
> > contradiction of basic Internet routing design principles.
> >
>
> As I mentioned above, an end-point must control the destiny of its
> packets, if not the way the packets get there (as you point out
> above, there is a routing exception: source routing).
>
> In any case, I notice that FMIPv6 and BETH design points are somewhat
> different (even though improved handover is the target) including
> - who has the control in deciding when forwarding on the tunnel is
>    activated
> - whether the MN always keeps the old CoA (BETH) or it uses the
>    new CoA or the old CoA (FMIPv6)
> - whether L2 triggers are used (BETH) or IP messages are used (FMIPv6)
>     for handover switching
>
> I think it makes sense to document these and others, at the very
least.
>
> Regards,
>
> -Rajeev
>
>
>
> >
> >             jak
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 05:39:32 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00018
	for ; Thu, 25 Apr 2002 05:39:31 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19479;
	Thu, 25 Apr 2002 02:39:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14052;
	Thu, 25 Apr 2002 02:38:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3P9cAGs008041
	for ; Thu, 25 Apr 2002 02:38:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3P9c9qC008040
	for mobile-ip-dist; Thu, 25 Apr 2002 02:38:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3P9c6Gs008033
	for ; Thu, 25 Apr 2002 02:38:06 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13273
	for ; Thu, 25 Apr 2002 02:38:07 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26673
	for ; Thu, 25 Apr 2002 02:38:05 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3P9bes7012905;
	Thu, 25 Apr 2002 11:37:40 +0200 (MEST)
Received: from research-gs4iel.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id LAA00234; Thu, 25 Apr 2002 11:37:39 +0200
Message-Id: <5.0.0.25.0.20020425111646.01e76100@era-t.ericsson.se>
X-Sender: erajoaa@era-t.ericsson.se
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 25 Apr 2002 11:36:48 +0200
To: "Ahmad Muhanna",
        "'Charles E. Perkins'" 
From: Annika Jonsson 
Subject: RE: [mobile-ip] RE: [mobile-imp] WG Last Call: 
  draft-ietf-mobile ip-reg-tunnel-06. txt
Cc: mobile-ip@sunroof.eng.sun.com,
        "'A.ONeill@flarion.com'" 
In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC39@zrc2c013.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_89382014==_.ALT"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--=====================_89382014==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Ahmad,

I agree with you that we should sort out the backwards compatibility 
issues. See my answers below.

At 11:37 2002-04-24 -0500, Ahmad Muhanna wrote:

>Hello Charlie/Annika;
>
>As I mentioned earlier that I will summarize those backward compatibility 
>issues which
>I still believe have not been answered.
>
>My concern here was to make this draft work before it becomes a standard.
>As long as this feature is OPTIONAL and it is 100% BACKWARD COMPATIBLE, I 
>have no
>problem with it.
>The more solutions we have for the same problem is the better as long as 
>they are:
>         1. OPTIONAL
>         2. 100% BACKWARD COMPATIBLE.
>
>Operators can pick and choose the best for them.
>
>Before moving to the technical issues that I feel this draft MUST address.
>I may agree with you that some of these points can be eliminated with static
>configuration or provisioning. However, the draft has two choices here:
>     i.  Either clearly mention these provisioning restrictions, or
>     ii. Offer a smooth solution for backward compatibility
>
>Now to the technical points:
>
>ISSUE No. 1: FA advertised a GFA of ZERO:
>
>This draft makes it optional for the FA to set the only advertised Care-of 
>address
>to ZERO. You mentioned that operator must know that by doing this he/she 
>is blocking
>all RFC3220 compliant Mobile Node which needs a FA Care-of Address to 
>register.
>I agree with this BUT the draft must clearly include this.
>
>section 3.3. can read as follows:
>" The `I' flag (see Section 7) MUST be set to indicate that the domain
>    supports regional tunnel management, and that the availability of a
>    GFA is advertised in the Agent Advertisement message.  If the `I'
>    bit is set, there MUST be at least one care-of address in the Agent
>    Advertisement message, but that address MAY be set to zero.
>    However, setting the only advertised care-of address
>    to ZERO will eliminate the mobile IP service to all mobile nodes which
>    do not support regional registration.
>"
>Or just eliminate the option of sending a ZERO care-of address.
>What do you think?

I think we should keep the option, and I agree that we should add this 
clarifying text.

>ISSUE No. 2: FA advertised ONLY one care-of address "GFA care-of address":
>Also on another location, this draft makes it possible for the FA to 
>advertise only
>one care-of address. It also make it very specific by saying that if this 
>happens,
>this address is the care-of address of the GFA.
>
>Now, this will cause the legacy Mobile Nodes not to know that it handed 
>over to a new
>FA, because it always receives the same care-of address. May be we need to
>repeat the above restriction again. OR WHAT about reversing the logic. If 
>there
>is only one care-of address in the Agent Advertisement, it is the FA care-of
>address. Now, Mobile Nodes which wants to use this service with this 
>condition
>it sets the GFA to ZERO.
>
>section 3.3: can be read as follows 
>"
>...
>    If the `I' bit is set, and there is only one care-of address, it is
>    the address of the FA. If the `I' bit is set, and there are multiple
>    care-of addresses, the first care-of address is the local FA,
>    and the last care-of address is the GFA.
>...
>"
>What do you think?


Hmmm, yes, I see your point. The reason that we decided that it should be 
the GFA address (if only one) was that that would allow the network between 
the FA:s and the GFA to use for example private addresses, and hide that 
from the MN:s. But that requires a move detection algorithm that doesn't 
rely on the advertised CoA. If this can't be done by "regular" MN:s anyway, 
I agree with you.

So the conclusion is, if you want to use private addresses, or disallow the 
use of the "regular" FA functionality for any other reason, you should 
advertise a zero CoA as above, and then you know that this is not backwards 
compatible.

>ISSUE No. 3: Legacy HA receives a Registration Request with
>                      GFA IP Address extension or a Replay Protection 
> Style extension
>"
>    A Registration Request that does not contain a GFA IP Address
>    extension or a Replay Protection Style extension is processed
>    by the home agent as described in [9].  If the home agent
>    receives a Registration Request with one of these extensions,
>    and the home agent does not support the extension, the home
>    agent must return a Registration Reply with the Code value set to
>    UNSUPPORTED_EXTENSION [9].
>"
>
>Now this is a new restriction or demand on the legacy HA and is not 
>acceptable.
>Since those extensions are skippable, HA will process the RRQ as Regular MIP
>call. You need to make sure to handle this at the GFA. for example something
>like the following can be added to section 4.3.
>
>"
>If the GFA relays a Registration Request with GFA IP Address extension or a
>Replay Protection Style extension or both and receives a successful 
>registration
>reply without any of these extension, the GFA MUST send a registration reply
>message to the Mobile node with error code of HOME_AGENT_DOES_NOT_SUPPORT_RR
>"
>What do you think?

I absolutely agree. Actually, I was about to propose something like that, 
since your previous mail got me thinking about this.

>ISSUE 4 & 5
>ZERO_CAREOF_ADDRESS & Care-of Address set to zero and a GFA IP Address 
>extension
>
>I agree these are covered in the Mobile Node consideration as in section 4.1.
>"
>     If the mobile node sets the care-of address to zero, the mobile node
>    and its home agent MUST support the GFA IP address extension (see 
> section 8.1).
>"

Good.
I hope we have sorted out all backwards compatibility issues now, and 
thanks for your help.
/Annika

>Thanks;
>Ahmad Muhanna
>
>
>
>Hello Charlie;
>I still believe that those backward compatibility issues
>have not been answered YET.
>I will compile another response which includes all issues at once.
>Regards;
>Ahmad Muhanna
> >
> > Hello Ahmad,
> >
> > I'll try to make some answers here.
> >
> > > You are proposing a solution for a specific problem.
> > > You are making this great claim that this solution supports
> > existing Mobile
> > > IPv4 implementation.
> > >
> > > "
> > >    Foreign agents that support regional registrations are
> > also required
> > >    to support registrations according to Mobile IPv4 [9].
> > If there is
> > >    a foreign agent address announced in the Agent Advertisement, the
> > >    mobile node may register that foreign agent care-of
> > address with its
> > >    home agent [9].
> > > "
> >
> > This is O.K., right?  What does it mean, "great claim"?
> >
> > > Not only this, BUT you also make another great claim
> > without demonstrating
> > > HOW!!!
> > > "
> > >    For mobile nodes that cannot process a NAI, or with
> > mobility agents
> > >    that are not configured to advertise their NAI, regional
> > registration
> > >    is still useful, but the lack of certain features may
> > result in less
> > >    than optimal results.
> > > "
> >
> > If the mobile node cannot process NAI, then it can still do regional
> > registration.  Why not?  Also, isn't it better to write down where
> > additional configuration at the mobility agents can help to get the
> > best results?  I think it's better to fully explain as much
> > as possible
> > here.
> >
> >
> > > On the other hand, it seems that you assume that the whole
> > network will
> > > be upgraded at the same time to accommodate your solution.
> >
> > Not true!  It is possible to mix regional foreign agents with regular
> > foreign agents, and so on.
> >
> > > We are dealing with at least three different entities, MN,
> > FA, and HA. you
> > > added another one GFA.
> >
> > Well, if you don't have a GFA, then you don't have regional
> > registration.
> > Do you mean to suggest otherwise?
> >
> > > There is a great absolute possibility that those entities
> > do not belong to the
> > > same operator.
> > > Unless your draft addresses clearly how these entities
> > would know what the
> > > others support in reference
> > > to what you are proposing or offering a smooth solution
> > without violating the
> > > existing entities,
> > > there will continue to be backward compatibility issues and
> > your first claim
> > > is not justified.
> >
> > As far as I can remember, regional registration has been
> > targeted mainly
> > at domains (regions) operated by the same operator.  Maybe there are
> > more considerations with multi-operator domain, but that
> > really was not
> > on our radar.
> >
> > > I hope I made myself clear here in order to address these backward
> > > compatibility issues.
> >
> > I think that the places where new features are enabled by
> > mechanism that
> > is not able to be parsed by RFC 3220 mobile nodes should not
> > necessarily
> > be given as examples of the lack of backward compatibility.
> > Mobile nodes
> > that don't do regional registrations should be able to be served by
> > foreign agents that do offer regional registrations in addtion to
> > home registrations.  I am not aware of a place in the draft that would
> > make this untrue.
> >
> > Mobile nodes that wish to use regional registration with
> > foreign agents
> > that do not support it, will not succeed.  Mobile nodes that
> > wish to use
> > zero care-of addresses with home agents that do not support it, will
> > not succeed.  Mobile nodes that cannot use advertisements unless the
> > advertisement contains a care-of address, cannot register with a
> > foreign agent that does not offer a care-of address.  These are not
> > examples of backward incompatibility.  After all, to take the latter
> > case, if the foreign agent doesn't offer a care-of address, it just
> > is not running RFC3220, presumably for some good reason from the
> > perspective of the local operator.  The mobile node that only run
> > RFC3220 should just cannot use that foreign agent.
> >
> > We have attempted to preserve backwards compatibility, while allowing
> > the regional registration to offer new features and thus extend to
> > scenarios where RFC 3220 would not work anyway.  That has to be
> > considered O.K.
> >
> > Regards,
> > Charlie P.
> >

--=====================_89382014==_.ALT
Content-Type: text/html; charset="us-ascii"


Hi Ahmad,



I agree with you that we should sort out the backwards compatibility
issues. See my answers below.



At 11:37 2002-04-24 -0500, Ahmad Muhanna wrote:




Hello
Charlie/Annika; 



As I mentioned earlier that I will summarize those backward
compatibility issues which 

I still believe have not been answered. 



My concern here was to make this draft work before it
becomes a standard. 

As long as this feature is OPTIONAL and it is 100% BACKWARD
COMPATIBLE, I have no 

problem with it. 

The more solutions we have for the same problem is the
better as long as they are: 

        1.
OPTIONAL 

        2. 100% BACKWARD
COMPATIBLE. 



Operators can pick and choose the best for them.




Before moving to the technical issues that I feel this draft MUST address. 

I may agree with you that some of these points can be eliminated with static 

configuration or provisioning. However, the draft has two choices here: 

    i.  Either clearly mention these provisioning restrictions, or 

    ii. Offer a smooth solution for backward compatibility 



Now to the technical points: 



ISSUE No. 1: FA advertised a GFA of ZERO: 



This draft makes it optional for the FA to set the only advertised Care-of address 

to ZERO. You mentioned that operator must know that by doing this he/she is blocking 

all RFC3220 compliant Mobile Node which needs a FA Care-of Address to register. 

I agree with this BUT the draft must clearly include this. 



section 3.3. can read as follows: 

" The `I' flag (see Section 7) MUST be set to indicate that the domain 

   supports regional tunnel management, and that the availability of a 

   GFA is advertised in the Agent Advertisement message.  If the `I' 

   bit is set, there MUST be at least one care-of address in the Agent 

   Advertisement message, but that address MAY be set to zero. 

  <NEW TEXT> However, setting the only advertised care-of address 

   to ZERO will eliminate the mobile IP service to all mobile nodes which 

   do not support regional registration<NEW TEXT>. 

" 

Or just eliminate the option of sending a ZERO care-of address. 

What do you think? 




I think we should keep the option, and I agree that we should add this clarifying text.




ISSUE No. 2: FA advertised ONLY one care-of address "GFA care-of address": 

Also on another location, this draft makes it possible for the FA to advertise only 

one care-of address. It also make it very specific by saying that if this happens, 

this address is the care-of address of the GFA. 



Now, this will cause the legacy Mobile Nodes not to know that it handed over to a new 

FA, because it always receives the same care-of address. May be we need to 

repeat the above restriction again. OR WHAT about reversing the logic. If there 

is only one care-of address in the Agent Advertisement, it is the FA care-of 

address. Now, Mobile Nodes which wants to use this service with this condition 

it sets the GFA to ZERO. 



section 3.3: can be read as follows <some text has been removed> 

" 

... 

   If the `I' bit is set, and there is only one care-of address, it is 

   the address of the FA. If the `I' bit is set, and there are multiple 

   care-of addresses, the first care-of address is the local FA, 

   and the last care-of address is the GFA. 

... 

" 

What do you think? 






Hmmm, yes, I see your point. The reason that we decided that it should be the GFA address (if only one) was that that would allow the network between the FA:s and the GFA to use for example private addresses, and hide that from the MN:s. But that requires a move detection algorithm that doesn't rely on the advertised CoA. If this can't be done by "regular" MN:s anyway, I agree with you. 



So the conclusion is, if you want to use private addresses, or disallow the use of the "regular" FA functionality for any other reason, you should advertise a zero CoA as above, and then you know that this is not backwards compatible.




ISSUE No. 3: Legacy HA receives a Registration Request with 

                     GFA IP Address extension or a Replay Protection Style extension 

" 

   A Registration Request that does not contain a GFA IP Address 

   extension or a Replay Protection Style extension is processed 

   by the home agent as described in [9].  If the home agent 

   receives a Registration Request with one of these extensions, 

   and the home agent does not support the extension, the home 

   agent must return a Registration Reply with the Code value set to 

   UNSUPPORTED_EXTENSION [9].  

" 



Now this is a new restriction or demand on the legacy HA and is not acceptable. 

Since those extensions are skippable, HA will process the RRQ as Regular MIP 

call. You need to make sure to handle this at the GFA. for example something 

like the following can be added to section 4.3. 



" 

If the GFA relays a Registration Request with GFA IP Address extension or a 

Replay Protection Style extension or both and receives a successful registration 

reply without any of these extension, the GFA MUST send a registration reply 

message to the Mobile node with error code of HOME_AGENT_DOES_NOT_SUPPORT_RR 

" 

What do you think? 




I absolutely agree. Actually, I was about to propose something like that, since your previous mail got me thinking about this.




ISSUE 4 & 5 

ZERO_CAREOF_ADDRESS & Care-of Address set to zero and a GFA IP Address extension 



I agree these are covered in the Mobile Node consideration as in section 4.1. 

" 

    If the mobile node sets the care-of address to zero, the mobile node 

   and its home agent MUST support the GFA IP address extension (see section 8.1).  

" 




Good.

I hope we have sorted out all backwards compatibility issues now, and thanks for your help.

/Annika




Thanks; 

Ahmad Muhanna 



  



Hello Charlie; 

I still believe that those backward compatibility issues 

have not been answered YET. 

I will compile another response which includes all issues at once. 

Regards; 

Ahmad Muhanna 

> 

> Hello Ahmad, 

> 

> I'll try to make some answers here. 

> 

> > You are proposing a solution for a specific problem. 

> > You are making this great claim that this solution supports 

> existing Mobile 

> > IPv4 implementation. 

> > 

> > " 

> >    Foreign agents that support regional registrations are 

> also required 

> >    to support registrations according to Mobile IPv4 [9].  

> If there is 

> >    a foreign agent address announced in the Agent Advertisement, the 

> >    mobile node may register that foreign agent care-of 

> address with its 

> >    home agent [9]. 

> > " 

> 

> This is O.K., right?  What does it mean, "great claim"? 

> 

> > Not only this, BUT you also make another great claim 

> without demonstrating 

> > HOW!!! 

> > " 

> >    For mobile nodes that cannot process a NAI, or with 

> mobility agents 

> >    that are not configured to advertise their NAI, regional 

> registration 

> >    is still useful, but the lack of certain features may 

> result in less 

> >    than optimal results. 

> > " 

> 

> If the mobile node cannot process NAI, then it can still do regional 

> registration.  Why not?  Also, isn't it better to write down where 

> additional configuration at the mobility agents can help to get the 

> best results?  I think it's better to fully explain as much 

> as possible 

> here. 

> 

> 

> > On the other hand, it seems that you assume that the whole 

> network will 

> > be upgraded at the same time to accommodate your solution. 

> 

> Not true!  It is possible to mix regional foreign agents with regular 

> foreign agents, and so on. 

> 

> > We are dealing with at least three different entities, MN, 

> FA, and HA. you 

> > added another one GFA. 

> 

> Well, if you don't have a GFA, then you don't have regional 

> registration. 

> Do you mean to suggest otherwise? 

> 

> > There is a great absolute possibility that those entities 

> do not belong to the 

> > same operator. 

> > Unless your draft addresses clearly how these entities 

> would know what the 

> > others support in reference 

> > to what you are proposing or offering a smooth solution 

> without violating the 

> > existing entities, 

> > there will continue to be backward compatibility issues and 

> your first claim 

> > is not justified. 

> 

> As far as I can remember, regional registration has been 

> targeted mainly 

> at domains (regions) operated by the same operator.  Maybe there are 

> more considerations with multi-operator domain, but that 

> really was not 

> on our radar. 

> 

> > I hope I made myself clear here in order to address these backward 

> > compatibility issues. 

> 

> I think that the places where new features are enabled by 

> mechanism that 

> is not able to be parsed by RFC 3220 mobile nodes should not 

> necessarily 

> be given as examples of the lack of backward compatibility.  

> Mobile nodes 

> that don't do regional registrations should be able to be served by 

> foreign agents that do offer regional registrations in addtion to 

> home registrations.  I am not aware of a place in the draft that would 

> make this untrue. 

> 

> Mobile nodes that wish to use regional registration with 

> foreign agents 

> that do not support it, will not succeed.  Mobile nodes that 

> wish to use 

> zero care-of addresses with home agents that do not support it, will 

> not succeed.  Mobile nodes that cannot use advertisements unless the 

> advertisement contains a care-of address, cannot register with a 

> foreign agent that does not offer a care-of address.  These are not 

> examples of backward incompatibility.  After all, to take the latter 

> case, if the foreign agent doesn't offer a care-of address, it just 

> is not running RFC3220, presumably for some good reason from the 

> perspective of the local operator.  The mobile node that only run 

> RFC3220 should just cannot use that foreign agent. 

> 

> We have attempted to preserve backwards compatibility, while allowing 

> the regional registration to offer new features and thus extend to 

> scenarios where RFC 3220 would not work anyway.  That has to be 

> considered O.K. 

> 

> Regards, 

> Charlie P. 

> 


--=====================_89382014==_.ALT--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 05:47:06 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00132
	for ; Thu, 25 Apr 2002 05:47:05 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00218;
	Thu, 25 Apr 2002 02:46:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16499;
	Thu, 25 Apr 2002 02:46:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3P9jcGs008904
	for ; Thu, 25 Apr 2002 02:45:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3P9jcmO008902
	for mobile-ip-dist; Thu, 25 Apr 2002 02:45:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3P9jZGs008895
	for ; Thu, 25 Apr 2002 02:45:35 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16251
	for ; Thu, 25 Apr 2002 02:45:36 -0700 (PDT)
Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29881
	for ; Thu, 25 Apr 2002 02:45:35 -0700 (PDT)
Received: from ns.iij.ad.jp ([192.168.2.111])
	by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id SAA05637
	for ; Thu, 25 Apr 2002 18:45:35 +0900 (JST)
Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA00939; Thu, 25 Apr 2002 18:45:34 +0900 (JST)
Date: Thu, 25 Apr 2002 18:45:05 +0900 (JST)
Message-Id: <20020425.184505.06470684.keiichi@iij.ad.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] How to process HAO
From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= 
X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi,

May I ask a question about processing a HAO?  I think the processing
is difficult to implement.  I will try to explain why it is difficult.

The latest discussion concludes that a HAO must not be processed
without a valid BCE.  Also, the BU/BA for the home registration must
be protected by the ESP.


1. The home registration.

The BU/BA for home registration must be protected by the ESP.  To do
this, the HA and the MN must have the SA and the SPD properly.  For
example,

On HA:	SA1: HA, MN_HoA, ESP
	SA2: MN_HoA, HA, ESP
	SPD: HA -> MN_HoA, MH, ESP

On MH:	SA1: HA, MN_HoA, ESP
	SA2: MN_HoA, HA, ESP
	SPD: MN_HoA -> HA, MH, ESP

Since we use a MN_HoA as a endpoint of the SA and the SPD, the BU/BA
for the home registration packet must include a HAO.


2. Dropping a packet which contains a HAO without a valid BCE.

The CN must drop packets which contain a HAO without a valid BCE.  The
HA is also a CN.  When processing a BU from a MN, a HA first encounts
a HAO.  Since the HA doesn't have a BCE for the MN, the BU is dropped.


Conclusion: the home registration never be processed.


Condideration:

- Using MN_CoA as an endpoint of the SA/SPD:

Using MN_CoA makes it possible to remove a HAO from a BU.  But, if we
use a MN_CoA, the SA entry and the SPD entry must be updated at each
time when the MN moves.  In addision, it requires some SA
establishment mechanism because the HA never know the new CoA that the
MN gets on the newly visited foreign network.  It seems unrealistic.


- Introduce a flag that indicates 'I saw a HAO'.

Instead of dorpping the packet which contains a HAO without a valid
BCE immediately, just set a flag that means this packet has a HAO.
After all extension headers are processed, check the BCEs.  If we have
no BCE corresponding to the HAO, we drop the packet.

This method works except one inappropliate behaviour.  If the packet
has other exthdr/DOs after a HAO, the exthdr/DOs are processed.
Obviously, those exthdrs/DOs must not be processed because the packets
that has a HAO without a valid BCE must be dropped.


How do you think about this?

If I am missing something, please correct me.

---
Keiichi SHIMA
IIJ Research Laboratory 
KAME Project 



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 08:59:25 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04280
	for ; Thu, 25 Apr 2002 08:59:25 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10357;
	Thu, 25 Apr 2002 06:59:24 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03220;
	Thu, 25 Apr 2002 05:59:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PCwNGs012952
	for ; Thu, 25 Apr 2002 05:58:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PCwNhO012951
	for mobile-ip-dist; Thu, 25 Apr 2002 05:58:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PCwIGs012923
	for ; Thu, 25 Apr 2002 05:58:18 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20102
	for ; Thu, 25 Apr 2002 05:58:18 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25232
	for ; Thu, 25 Apr 2002 06:58:18 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3PCw2pY007296;
	Thu, 25 Apr 2002 05:58:02 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABN33773;
	Thu, 25 Apr 2002 05:55:16 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA21545; Thu, 25 Apr 2002 05:58:01 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15559.64857.612244.267865@thomasm-u1.cisco.com>
Date: Thu, 25 Apr 2002 05:58:01 -0700 (PDT)
To: "James Kempf" 
Cc: "Michael Thomas" , "Rajeev Koodli" ,
        "Alper E. YEGIN" ,
        "Manolis Sifalakis" ,
        
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
In-Reply-To: <00c101c1ec33$a51c7f40$b36015ac@T23KEMPF>
References: <3CB5DB1F.90909@lancaster.ac.uk>
	<012801c1e198$1fcb99c0$7e6015ac@T23KEMPF>
	<3CBDBC62.21C19B77@iprg.nokia.com>
	<000001c1e7b6$9288fd80$746015ac@T23KEMPF>
	<3CC0B44C.DB862958@iprg.nokia.com>
	<046701c1e804$7016f330$736015ac@AlperVAIO>
	<3CC58E3C.86B <3CC5CA61.E210D29F@iprg.nokia.com>
	<00c401c1eb69$25179340$b36015ac@T23KEMPF>
	<15558.58813.157282.992826@thomasm-u1.cisco.com>
	<00c101c1ec33$a51c7f40$b36015ac@T23KEMPF>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

James Kempf writes:
 > Hi Michael,
 > 
 > Your analysis is correct if the mobile node knows that a handover is
 > occuring. I probably didn't make this clear enough, but as I mentioned,
 > IP hosts have always had the option of choosing their default router,
 > and if they becme aware that this router is changing, they should have
 > the option of choosing a new one. Security, to the extent it is possible
 > with currently unsecured protocols such as ND, should of course also
 > play a role as you describe.
 > 
 > I was objecting to what I detected  in Rajeev's note that this must
 > always be the case, even when the mobile did not have any knowledge that
 > the handover was occuring. In my view, this corresponds to a failure of
 > a router in the network.
 > 
 > Which occurs depends on how much informatoin is made available to which
 > entity by the wireless protocol.

   Yes, I understand where you're coming from, but
   my gut level feeling is that Rajeev is right to
   be suspicious because the issues don't seem to be
   100% parallel. What this seems like to me --
   and I might be in left field here -- is
   something more akin to ICMP REDIRECT. That is,
   I'd like you to move elsewhere because it's a
   better route. But in the REDIRECT case, the
   node doesn't have to actually honor it; after a
   few retries, the router gives up and assumes
   they won't move. This isn't entirely unlike
   another scenario where a router has dynamic metrics 
   which for whatever reason it just ignores (say
   it has a static route too). 

   Thus to my mind, the nature of these changes
   are *cooperative* on a hop-by-hop basis. That
   is, I'd like you to do something and you
   oblige. Therefore, if it makes sense in this 
   case -- and I'm not sure because which piqued
   my interest here was the Internet gestalt -- it
   does seem that to mimic the current net, the
   exchange needs to be "may I? yes, please do"
   which sort of favors Rajeev's contention that
   it must be authorized by the MN. The reason
   is because the MN ultimately needs to
   participate in the move (eg, retune its radio,
   etc), right?

		Mike



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 09:13:59 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04788
	for ; Thu, 25 Apr 2002 09:13:59 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03865;
	Thu, 25 Apr 2002 07:13:58 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08420;
	Thu, 25 Apr 2002 06:13:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PDCoGs016887
	for ; Thu, 25 Apr 2002 06:12:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PDCoJM016886
	for mobile-ip-dist; Thu, 25 Apr 2002 06:12:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PDChGs016847
	for ; Thu, 25 Apr 2002 06:12:43 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24362
	for ; Thu, 25 Apr 2002 06:12:44 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03205
	for ; Thu, 25 Apr 2002 07:12:43 -0600 (MDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3PDAus7024586;
	Thu, 25 Apr 2002 15:10:57 +0200 (MEST)
Received: from research-gs4iel.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id PAA06296; Thu, 25 Apr 2002 15:10:55 +0200
Message-Id: <5.0.0.25.0.20020425144954.02378a00@era-t.ericsson.se>
X-Sender: erajoaa@era-t.ericsson.se
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 25 Apr 2002 15:10:51 +0200
To: "Ahmad Muhanna",
        "'Charles E. Perkins'" 
From: Annika Jonsson 
Subject: Fwd: RE: [mobile-ip] RE: [mobile-imp] WG Last Call: 
  draft-ietf-mobile ip-reg-tunnel-06. txt
Cc: mobile-ip@sunroof.eng.sun.com,
        "'A.ONeill@flarion.com'" 
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_6289043==_.ALT"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--=====================_6289043==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Ahamad,

I have thought more about this and realised that we have missed one 
thing... see below.




>>ISSUE No. 3: Legacy HA receives a Registration Request with
>>                      GFA IP Address extension or a Replay Protection 
>> Style extension
>>"
>>    A Registration Request that does not contain a GFA IP Address
>>    extension or a Replay Protection Style extension is processed
>>    by the home agent as described in [9].  If the home agent
>>    receives a Registration Request with one of these extensions,
>>    and the home agent does not support the extension, the home
>>    agent must return a Registration Reply with the Code value set to
>>    UNSUPPORTED_EXTENSION [9].
>>"
>>
>>Now this is a new restriction or demand on the legacy HA and is not 
>>acceptable.
>>Since those extensions are skippable, HA will process the RRQ as Regular MIP
>>call. You need to make sure to handle this at the GFA. for example something
>>like the following can be added to section 4.3.
>>
>>"
>>If the GFA relays a Registration Request with GFA IP Address extension or a
>>Replay Protection Style extension or both and receives a successful 
>>registration
>>reply without any of these extension, the GFA MUST send a registration reply
>>message to the Mobile node with error code of HOME_AGENT_DOES_NOT_SUPPORT_RR
>>"
>>What do you think?

Actually, the HA should not return a successful registration reply, becuse 
if it didn't understand the GFA IP extension it doesn't know where the 
tunnel end-point is since the CoA field is zero. I'm not sure what the HA 
will return in this case but I think the approporiate error code is "poorly 
formed request". If this is the case, the GFA can suspect that the problem 
is that the HA did not understand the GFA IP extension, but it doesn't have 
to tell the MN anything, because the MN can see that error code itself and 
draw the same conclusion. One idea to reslove this would be that the GFA in 
this case added the GFA IP extension in the reply to the MN. Then the MN 
can generate a new registration request with a CoA in it so that the HA can 
accept the registration.

/Annika
--=====================_6289043==_.ALT
Content-Type: text/html; charset="us-ascii"


Hi Ahamad,



I have thought more about this and realised that we have missed one
thing... see below.










ISSUE
No. 3: Legacy HA receives a Registration Request with 

                    
GFA IP Address extension or a Replay Protection Style extension


" 

   A Registration Request that does not contain a
GFA IP Address 

   extension or a Replay Protection Style
extension is processed 

   by the home agent as described in [9].  If
the home agent 

   receives a Registration Request with one of
these extensions, 

   and the home agent does not support the
extension, the home 

   agent must return a Registration Reply with the
Code value set to 

   UNSUPPORTED_EXTENSION [9].  

" 



Now this is a new restriction or demand on the legacy HA and
is not acceptable. 

Since those extensions are skippable, HA will process the
RRQ as Regular MIP 

call. You need to make sure to handle this at the GFA. for
example something 

like the following can be added to section 4.3. 




" 

If the GFA relays a Registration Request with GFA IP Address extension or a 

Replay Protection Style extension or both and receives a successful registration 

reply without any of these extension, the GFA MUST send a registration reply 

message to the Mobile node with error code of HOME_AGENT_DOES_NOT_SUPPORT_RR 

" 

What do you think? 


Actually, the HA should not return a successful registration reply, becuse if it didn't understand the GFA IP extension it doesn't know where the tunnel end-point is since the CoA field is zero. I'm not sure what the HA will return in this case but I think the approporiate error code is "poorly formed request". If this is the case, the GFA can suspect that the problem is that the HA did not understand the GFA IP extension, but it doesn't have to tell the MN anything, because the MN can see that error code itself and draw the same conclusion. One idea to reslove this would be that the GFA in this case added the GFA IP extension in the reply to the MN. Then the MN can generate a new registration request with a CoA in it so that the HA can accept the registration.



/Annika

--=====================_6289043==_.ALT--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 09:39:55 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05526
	for ; Thu, 25 Apr 2002 09:39:54 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13361;
	Thu, 25 Apr 2002 06:39:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16683;
	Thu, 25 Apr 2002 06:39:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PDbYGs023126
	for ; Thu, 25 Apr 2002 06:37:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PDbYaY023124
	for mobile-ip-dist; Thu, 25 Apr 2002 06:37:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PDbTGs023092
	for ; Thu, 25 Apr 2002 06:37:29 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13472
	for ; Thu, 25 Apr 2002 06:37:27 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22017
	for ; Thu, 25 Apr 2002 07:37:25 -0600 (MDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3PDbLs7008210;
	Thu, 25 Apr 2002 15:37:21 +0200 (MEST)
Received: from research-gs4iel.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id PAA07279; Thu, 25 Apr 2002 15:37:20 +0200
Message-Id: <5.0.0.25.0.20020425151932.0236f220@era-t.ericsson.se>
X-Sender: erajoaa@era-t.ericsson.se
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 25 Apr 2002 15:37:19 +0200
To: "Alan O'Neill" , mobile-ip@sunroof.eng.sun.com
From: Annika Jonsson 
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46C3A756@ftmail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Alan,

see below...



>Second, the problem with how to handle different addressing plans between
>FA - GFA and GFA - HA. I agree that this should be supported. Let's see if
>I understand your suggestion correctly:
>* The GFA address advertised in the Agent Advertisement should be the
>"local" address of the GFA, where it can be reached from the FA.
>* A Home registration from a MN should never include any CoA address
>* The FA sends the registration req. on to the GFA "local" address
>* The GFA allocates CoA to the MN
>* The GFA IP extension (forget the name change for now...) should be used
>to transport the selected CoA to the HA and to carry the selected CoA back
>to the MN, as is already the case in the draft.
>
>I agree that dynamically allocating the CoA is the best way, and it seems
>resonable that this is the responsibility of the GFA and not the FA. But,
>the reason why we didn't specify that all MN:s must use that method is that
>we wanted to be backwards compatible wiht HA:s that does'nt specifically
>support Regional registrations (or rather, the GFA IP extension). If MN:s
>are allowed to put the CoA in the Registration request, the HA will never
>need to know that the visited network uses regional registrations, and the
>GFA will look like a normal FA. I still think this is a good feature.
>
>AWO> Yes - I appreciated your motivation.
>
>To allow this, the FA must advertise a publicly routable GFA (CoA) address.
>If the FA and GFA belongs to a private address domain, the FA needs to have
>a mapping from the public CoA address to the private GFA address that it
>should use to send the Registration request to. I think this solves the
>problem.
>
>To summarise, I suggest that we:
>* clarify that dynamic allocation of CoA is preferable
>* add that the FA might use another address to communicate with a GFA than
>the CoA advertised, and that it in that case needs a mapping between these
>two addresses
>* change the allocation of CoA and use of the GFA IP address extension, by
>saying that it is the responsibility of the FA to select GFA, but not to
>include any GFA IP extension, because it is the responsibility of the GFA
>to allocate CoA, and it will add the GFA IP extension.
>
>Do you agree that this solves the problems you raised?
>
>AWO> Not really as this only addresses the case of the MN moving in a
>private domain underneath a GFA with a single public interface. When the GFA
>has multiple interfaces with a mixture of public and private, or when the
>local domain is the public domain and the GFA has a private interface then
>it still breaks down. For your scheme to work you need the FA to have
>extensive address mapping knowledge. This is essentially also impossible to
>achieve when the GFA has multiple interfaces with different address blocks
>towards HAs. The FA does not know what to advertise to the MN because it
>cannot know which GFA interface the MN RREQ will need to traverse before
>seeing the RREQ, and by then it is too late if the MN has already put a GFA
>CoA into the CoA field. So to be generally applicable I realy think that the
>CoA field should always be zero and that the GFA should insert the GFA CoA
>for the HA.

I think that you misunderstood me (or I you). What you say here is more or 
less what I meant. The only difference is that I still think that an FA 
could in most cases advertise a GFA CoA. This should be a public address, 
sort of a "default CoA", that an MN MAY use, e.g. if it's HA doesn't 
support the GFA IP extension. By specifying that an MN SHOULD set the CoA 
field in the Registration request to zero, that method will be used in most 
cases. I agreed that we could change so that the FA only forwards the 
registration to the GFA, and the GFA selects CoA, and adds the GFA IP 
extension.

I don't think that this requires the FA to have an extensive mapping 
knowledge. It needs to know the address to use to send the registration 
request to the GFA, but you can never get away from that.

I hope this is clearer.

/Annika

>Now this means that an upgraded HA can always tell if an initial home reg
>came via a GFA...a good thing in my book.
>Unfortunately, a legacy HA will fail this reg - again a good thing in my
>book..more pressure on IT department/operator to upgrade the HA. Remember,
>the HA and MN share a unique relationship and having them on widely
>different MIP versions for any length of time is somewhat perverse to me.
>What is therefore missing is to enable the GFA to insert the assigned GFA
>CoA into the RREP for the MN if the HA failed to do so. The second attempt
>can therefore still succeed to the legacy HA. Each refresh under the same
>GFA also works and we only have a problem again on each GFA change-over
>whilst the MN and HA are on such different versions...




>Alan.
>
>/Annika
>
>At 22:23 2002-04-15 -0400, Alan O'Neill wrote:
> >Below is the abstract for the draft that makes last call suggestions on
> >Regional tunneling.
> >
> >see
> >http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mods-00.txt
> >
> >Abstract
> >
> >    Regional Registration modifies the normal MIP Registration signalling
> >    back to the HA so that the signalling can traverse an intermediate
> >    Gateway Foreign Agent (GFA). The registered binding is between the Home
> >    Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent
> >    (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the
>GFA.
> >    Two extensions are defined to support this new Registration processing
> >    these being the Hierarchical Foreign Agent extension (HFAext) and the
>GFA
> >
> >    IP address extension (GFAIPext). The former is used to carry the FA CoA
> >    to the GFA and the latter is used by the FA to allocate a GFA to the
>MN,
> >    and by the FA, GFA, HA to securely return the GFA IP address to the MN.
> >
> >    The present processing rules for the HA registration enable the FA to
> >    advertise the GFA to the MN in a Foreign Agent Advertisement (FAA) and
> >    for the MN to include that GFA address into the CoA field of the MIP
>home
> >
> >    Registration. This however assumes a number of things about the GFA
> >    address in the FAA and the addressing realms between the FA-GFA and
>GFA-
> >    HA.. Specifically, the GFA CoA and the GFA IP address must potentially
>be
> >
> >    from two different addressing plans and hence cannot be in the same
>FAA.
> >    This draft describes the issues and suggests a solution that requires
> >    slight modifications to the required extensions, that generalises the
> >    Home Registration signalling for arbitrary intermediate MIP nodes, and
> >    only slightly modifies the processing rules for the MIP Home
> >    Registration. This draft also describes a way to support dynamic HA
> >    allocation along-side Regional Registrations.



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 10:05:59 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06561
	for ; Thu, 25 Apr 2002 10:05:58 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14028;
	Thu, 25 Apr 2002 08:05:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26283;
	Thu, 25 Apr 2002 07:05:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PE4BGs029891
	for ; Thu, 25 Apr 2002 07:04:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PE4BKd029889
	for mobile-ip-dist; Thu, 25 Apr 2002 07:04:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PE42Gs029841
	for ; Thu, 25 Apr 2002 07:04:02 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09978
	for ; Thu, 25 Apr 2002 07:04:01 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25214
	for ; Thu, 25 Apr 2002 08:04:00 -0600 (MDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3PE3hG12062;
	Thu, 25 Apr 2002 09:03:43 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2Y3TZ494>; Thu, 25 Apr 2002 09:03:39 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC40@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Charles E. Perkins'" ,
        Luca Salgarelli
	 
Cc: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: Proposed changes to rfc3012bis [was: RE: [mobile-ip]  RFC3012
	-bis:compatibility issues]
Date: Thu, 25 Apr 2002 09:02:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EC61.DDE72360"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EC61.DDE72360
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Charlie;

Please see my comments inline.

Regards;
Ahmad Muhanna


> 
> Hello Luca and Ahmad,
> 
> I guess it's about time to send out rfc3012bis if possible.
> 
> I think the text should be written to improve scalability,
> according your original observations, and yet maintain the
> most reasonable flexibility for mobile nodes.  I think we
> can mandate that mobile nodes MUST NOT use old challenges.
> On the other hand, I think we should encourage implementors
> to build CHALLENGE_WINDOW always at least 2.  That would
> eliminate many failures caused if a mobile node happens to
> use a challenge just after the foreign agent changed to a
> new challenge.
> 
> >    to the Mobile Node, or else advertised as one of the last
> >    CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
> >    immediately preceding Agent advertisements.  If the Challenge is
> >    not one of the recently advertised values, the foreign Agent SHOULD
> >    send a Registration Reply with Code value UNKNOWN_CHALLENGE (see
> >    section 10). The Foreign Agent SHOULD keep records for all
> >    challenges used by a Mobile Node that are still in the valid
> >    CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep
> >    records for all such previously used challenges, the Foreign Agent
> >    MUST set its CHALLENGE_WINDOW to 1.
> 
> I would replace the  block as follows:
> 
>      The Foreign Agent MUST maintain the last challenge used by
>      each Mobile Node that has successfully registered using
>      any one of the last CHALLENGE_WINDOW challenge values.
>      This last challenge value can be stored as part of the
>      mobile node's registration records.
> 

I believe that the part of the  Luca proposed and I mentioned 
earlier is more than sufficient to eliminate any security threat. 
I still support that text as follows:

           The Foreign Agent SHOULD keep records for all
          challenges used by a Mobile Node that are still in the valid
          CHALLENGE_WINDOW.

Now how user would like to achieve this is up to the user himself. 
What about if some implementors want to choose a 
CHALLENGE_WINDOW of 3 or 1. It is OK. The standard offers flexible
way for the Mobile Node to get good CHALLENGES. 
If a CHALLENGE is used and is no longer valid MN will receive a 
Registration Reply with a valid CHALLENGE which can be used
or it can solicit.

> This uses the knowledge that mobile nodes MUST NOT use
> previous challenges.  To this end, I would add the following
> restriction at the end of section 4:
> 
>      Suppose the Mobile Node has successfully registered using one of
>      the Challenge Values within the CHALLENGE_WINDOW values advertised
>      by the Foreign Agent.  In that case, in any new Registration
>      Request the Mobile Node MUST NOT use any Challenge Value which was
>      advertised by the Foreign Agent before the Challenge Value in its
>      last successful Registration Request.
> 

No problem, BUT may I suggest a slight change here, We need to eliminate 
the successful concept here:

      Suppose the Mobile Node has used a Challenge Value of the 
      CHALLENGE_WINDOW values advertised by the Foreign Agent
      in its last Registration Request.  In that case, in any subsequent 
      Registration Request the Mobile Node MUST NOT use any 
      Challenge Value which was advertised by the Foreign Agent before 
      the Challenge Value in its last Registration Request.



> With these two mandates, the total storage required by the foreign
> agent for all Challenge Values amounts to (2N + CHALLENGE_WINDOW),
> where N is the number of mobile nodes currently being served by
> the Foreign Agent.  N of the stored values are for the "last
> challenge used", and the other N may have come from Registration
> Reply messages.  It shouldn't be any problem at all to have
> the CHALLENGE_WINDOW > 1 (i.e., >= 2).
> 
> The foreign agent can use the following algorithm:
> 
> current_chal := RegistrationRequest.challenge_extension_value
> last_chal := mobile_node_record.last_chal
> 
> if (current_chal == mobile_node_record.RegReply_challenge) {
> 	update (mobile_node_record, current_chal)
> 	return (OK)
> }
> else if (current_chal "among" VALID_CHALLENGES[]{
> 	if (last_chal "among" VALID_CHALLENGES[]) {
> 		if (current_chal is "before" last_chal) {
> 			send_error(INVALID_CHALLENGE)
> 			return (FAILURE)
> 		}
> 		else {
> 			update (mobile_node_record, current_chal)
> 			return (OK)
> 		}
> 	}
> 	else {
> 		update (mobile_node_record, current_chal)
> 		return (OK)
> 
> 	}
> }
> else {
> 	send_error(UNKNOWN_CHALLENGE);
> }
> 
> What this says, is that the challenge used by the Mobile Node
> has to either be the one in the previous Registration Reply, or it
> has to be in the set of valid challenges, but not one of the
> valid challenges which was advertised previous to the "last"
> challenge used by the mobile node.
> 
> If you like this algorithm, then I need to create a terminology
> for "invalid challenge" and an error message to go with it.
> If you _really_ like it, I can include it in an appendix, along
> with any bug fixes or revisions you may suggest.
> 

I am not sure if it is necessary to include this algorithm.

> Finally, regarding that sentence in the definition for "stale 
> challenge":
> 
> Ahmad Muhanna wrote:
> 
> >> --------------
> >> Page 2: Delete sentence.
> >>
> >>       stale challenge
> >>                Same as "previously used challenge".  The 
> Foreign Agent
> >>                may not be able to keep records for all stale
> >> challenges.
> >>
> >>
> >> Delete last sentence. Text becomes:
> >>
> >>       stale challenge
> >>                Same as "previously used challenge".
> >>
> >
> > I do not see why we need to remove this line. This 
> addresses all kinds of
> > stale challenges including those which are sent in the unicast
> > advertisement and the Registration Reply.  The most 
> important point, I do
> > not see any contradiction by leaving this line and your 
> proposed text below.
> > Basically, the below text allows what the deleted line 
> suggest BUT put
> > some restriction to avoid any security holes for one kind 
> of challenges.
> > 
> > What do you think?
> 
> How about if we put the sentence in question somewhere after the
> list of terms in section 1.1?  That way, at least the observation
> would not be construed to apply unequally between "stale challenge"
> and "previously used challenge".
> 

Well, this brings me back to the very old text I proposed and you did not
like.
What about replacing the stale challenge with the following:

stale challenge 
               
        Same as "previously used challenge" and the Foreign Agent still has
a record of.

> By the way, I guess up until now nobody mentioned that the
> following text in section 1.1 was an incomplete sentence:
> 
>    The following additional terminology
> 
> In fact, it looks like to me that the section is not finished,
> and that there always needed to be a definition for a "valid
> challenge".
> 

I think unused challenge is enough. The only thing which is not mentioned
but
explained in the text is the timestamp concept on the Challenge-Window 
challenges.

> 
> If this is good enough to close these issues, and if there are no
> other issues, I would like to send out rfc3012bis this week.
> I do not have any records about other issues that I can find.
> If this is O.K., then I think the revised draft will probably
> be ready for Last Call.
> 
> Regards,
> Charlie P.
> 

------_=_NextPart_001_01C1EC61.DDE72360
Content-Type: text/html;
	charset="iso-8859-1"






RE: Proposed changes to rfc3012bis [was: RE: [mobile-ip]  RFC3012-bis:compatibility issues]




Hello Charlie;




Please see my comments inline.




Regards;

Ahmad Muhanna






> 

> Hello Luca and Ahmad,

> 

> I guess it's about time to send out rfc3012bis if possible.

> 

> I think the text should be written to improve scalability,

> according your original observations, and yet maintain the

> most reasonable flexibility for mobile nodes.  I think we

> can mandate that mobile nodes MUST NOT use old challenges.

> On the other hand, I think we should encourage implementors

> to build CHALLENGE_WINDOW always at least 2.  That would

> eliminate many failures caused if a mobile node happens to

> use a challenge just after the foreign agent changed to a

> new challenge.

> 

> >    to the Mobile Node, or else advertised as one of the last

> >    CHALLENGE_WINDOW (see section 9) Challenge values inserted into the

> >    immediately preceding Agent advertisements.  If the Challenge is

> >    not one of the recently advertised values, the foreign Agent SHOULD

> >    send a Registration Reply with Code value UNKNOWN_CHALLENGE (see

> >    section 10). <NEW-TEXT>The Foreign Agent SHOULD keep records for all

> >    challenges used by a Mobile Node that are still in the valid

> >    CHALLENGE_WINDOW. In the event that a Foreign Agent cannot keep

> >    records for all such previously used challenges, the Foreign Agent

> >    MUST set its CHALLENGE_WINDOW to 1.</NEW-TEXT>

> 

> I would replace the <NEW-TEXT> block as follows:

> 

>      The Foreign Agent MUST maintain the last challenge used by

>      each Mobile Node that has successfully registered using

>      any one of the last CHALLENGE_WINDOW challenge values.

>      This last challenge value can be stored as part of the

>      mobile node's registration records.

> 




I believe that the part of the <NEW TEXT> Luca proposed and I mentioned 

earlier is more than sufficient to eliminate any security threat. 

I still support that text as follows:




          <NEW TEXT> The Foreign Agent SHOULD keep records for all

          challenges used by a Mobile Node that are still in the valid

          CHALLENGE_WINDOW.<NEW TEXT>




Now how user would like to achieve this is up to the user himself. 

What about if some implementors want to choose a 

CHALLENGE_WINDOW of 3 or 1. It is OK. The standard offers flexible

way for the Mobile Node to get good CHALLENGES. 

If a CHALLENGE is used and is no longer valid MN will receive a 

Registration Reply with a valid CHALLENGE which can be used

or it can solicit.




> This uses the knowledge that mobile nodes MUST NOT use

> previous challenges.  To this end, I would add the following

> restriction at the end of section 4:

> 

>      Suppose the Mobile Node has successfully registered using one of

>      the Challenge Values within the CHALLENGE_WINDOW values advertised

>      by the Foreign Agent.  In that case, in any new Registration

>      Request the Mobile Node MUST NOT use any Challenge Value which was

>      advertised by the Foreign Agent before the Challenge Value in its

>      last successful Registration Request.

> 




No problem, BUT may I suggest a slight change here, We need to eliminate 

the successful concept here:




      Suppose the Mobile Node has used a Challenge Value of the 

      CHALLENGE_WINDOW values advertised by the Foreign Agent

      in its last Registration Request.  In that case, in any subsequent 

      Registration Request the Mobile Node MUST NOT use any 

      Challenge Value which was advertised by the Foreign Agent before 

      the Challenge Value in its last Registration Request.








> With these two mandates, the total storage required by the foreign

> agent for all Challenge Values amounts to (2N + CHALLENGE_WINDOW),

> where N is the number of mobile nodes currently being served by

> the Foreign Agent.  N of the stored values are for the "last

> challenge used", and the other N may have come from Registration

> Reply messages.  It shouldn't be any problem at all to have

> the CHALLENGE_WINDOW > 1 (i.e., >= 2).

> 

> The foreign agent can use the following algorithm:

> 

> current_chal := RegistrationRequest.challenge_extension_value

> last_chal := mobile_node_record.last_chal

> 

> if (current_chal == mobile_node_record.RegReply_challenge) {

>       update (mobile_node_record, current_chal)

>       return (OK)

> }

> else if (current_chal "among" VALID_CHALLENGES[]{

>       if (last_chal "among" VALID_CHALLENGES[]) {

>               if (current_chal is "before" last_chal) {

>                       send_error(INVALID_CHALLENGE)

>                       return (FAILURE)

>               }

>               else {

>                       update (mobile_node_record, current_chal)

>                       return (OK)

>               }

>       }

>       else {

>               update (mobile_node_record, current_chal)

>               return (OK)

> 

>       }

> }

> else {

>       send_error(UNKNOWN_CHALLENGE);

> }

> 

> What this says, is that the challenge used by the Mobile Node

> has to either be the one in the previous Registration Reply, or it

> has to be in the set of valid challenges, but not one of the

> valid challenges which was advertised previous to the "last"

> challenge used by the mobile node.

> 

> If you like this algorithm, then I need to create a terminology

> for "invalid challenge" and an error message to go with it.

> If you _really_ like it, I can include it in an appendix, along

> with any bug fixes or revisions you may suggest.

> 




I am not sure if it is necessary to include this algorithm.




> Finally, regarding that sentence in the definition for "stale 

> challenge":

> 

> Ahmad Muhanna wrote:

> 

> >> --------------

> >> Page 2: Delete sentence.

> >>

> >>       stale challenge

> >>                Same as "previously used challenge".  The 

> Foreign Agent

> >>                may not be able to keep records for all stale

> >> challenges.

> >>

> >>

> >> Delete last sentence. Text becomes:

> >>

> >>       stale challenge

> >>                Same as "previously used challenge".

> >>

> >

> > I do not see why we need to remove this line. This 

> addresses all kinds of

> > stale challenges including those which are sent in the unicast

> > advertisement and the Registration Reply.  The most 

> important point, I do

> > not see any contradiction by leaving this line and your 

> proposed text below.

> > Basically, the below text allows what the deleted line 

> suggest BUT put

> > some restriction to avoid any security holes for one kind 

> of challenges.

> > 

> > What do you think?

> 

> How about if we put the sentence in question somewhere after the

> list of terms in section 1.1?  That way, at least the observation

> would not be construed to apply unequally between "stale challenge"

> and "previously used challenge".

> 




Well, this brings me back to the very old text I proposed and you did not like.

What about replacing the stale challenge with the following:




stale challenge 

               

        Same as "previously used challenge" and the Foreign Agent still has a record of.




> By the way, I guess up until now nobody mentioned that the

> following text in section 1.1 was an incomplete sentence:

> 

>    The following additional terminology

> 

> In fact, it looks like to me that the section is not finished,

> and that there always needed to be a definition for a "valid

> challenge".

> 




I think unused challenge is enough. The only thing which is not mentioned but

explained in the text is the timestamp concept on the Challenge-Window 

challenges.




> 

> If this is good enough to close these issues, and if there are no

> other issues, I would like to send out rfc3012bis this week.

> I do not have any records about other issues that I can find.

> If this is O.K., then I think the revised draft will probably

> be ready for Last Call.

> 

> Regards,

> Charlie P.

> 





------_=_NextPart_001_01C1EC61.DDE72360--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 10:21:53 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06960
	for ; Thu, 25 Apr 2002 10:21:53 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05472;
	Thu, 25 Apr 2002 07:21:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29715;
	Thu, 25 Apr 2002 07:21:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEKHGs000874
	for ; Thu, 25 Apr 2002 07:20:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PEKGdM000873
	for mobile-ip-dist; Thu, 25 Apr 2002 07:20:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEKDGs000866
	for ; Thu, 25 Apr 2002 07:20:13 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29412
	for ; Thu, 25 Apr 2002 07:20:12 -0700 (PDT)
Received: from cisco.com (shako.cisco.com [64.102.17.78])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10349
	for ; Thu, 25 Apr 2002 08:17:14 -0600 (MDT)
Received: (from mchandra@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA21989;
	Thu, 25 Apr 2002 10:16:57 -0400 (EDT)
Date: Thu, 25 Apr 2002 10:16:57 -0400
From: "Madhavi W. Chandra" 
To: Annika Jonsson , charliep@iprg.nokia.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Last Call:  Regional Tunneling input
Message-ID: <20020425101657.B17560@cisco.com>
References: <8C92E23A3E87FB479988285F9E22BE46C3A3CC@ftmail> <5.0.0.25.0.20020422153922.023168a0@era-t.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.0.0.25.0.20020422153922.023168a0@era-t.ericsson.se>; from annika.jonsson@ericsson.com on Mon, Apr 22, 2002 at 04:32:37PM +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Annika and Charlie,

Putting RFC issues aside for a moment, please clarify a 
technical doubt...

If the MN sets the CoA field to 0.0.0.0, then the
FA assigns a GFA and appends the GFA IPext to the RRQ.  The
HA extracts the GFA CoA from the GFA IPext, and sets up the
tunnel end point to this GFA CoA.  However, it is not mandatory
to protect the GFA IPext with the FHAE.  I'm wondering what
the security implications of this are...since the tunnel
endpoint may be determined by an unprotected extension.  It
seems more susceptible to MN traffic hijacking by a 
man-in-the-middle.  What are your thoughts?

Thanks,
Madhavi



On Mon, Apr 22, 2002 at 04:32:37PM +0200, Annika Jonsson wrote:
> Hi Alan,
> 
> I have read your suggestions, and I have a few comments.
> 
> First, regarding the dynamic allocation of HA: we do support that in the 
> current draft. We assume that it is the GFA that participates in the 
> authentication procedure as AAA client and not the FA (see section 3.1.2). 
> The reason for this is that it is the GFA that acts as FA towards the HA, 
> and therfore needs the keys for securing registration messages. So, in this 
> way, a AAA server can dynamically allocate an HA, and the GFA will be 
> informed about this.
> 
> Second, the problem with how to handle different addressing plans between 
> FA - GFA and GFA - HA. I agree that this should be supported. Let's see if 
> I understand your suggestion correctly:
> * The GFA address advertised in the Agent Advertisement should be the 
> "local" address of the GFA, where it can be reached from the FA.
> * A Home registration from a MN should never include any CoA address
> * The FA sends the registration req. on to the GFA "local" address
> * The GFA allocates CoA to the MN
> * The GFA IP extension (forget the name change for now...) should be used 
> to transport the selected CoA to the HA and to carry the selected CoA back 
> to the MN, as is already the case in the draft.
> 
> I agree that dynamically allocating the CoA is the best way, and it seems 
> resonable that this is the responsibility of the GFA and not the FA. But, 
> the reason why we didn't specify that all MN:s must use that method is that 
> we wanted to be backwards compatible wiht HA:s that does'nt specifically 
> support Regional registrations (or rather, the GFA IP extension). If MN:s 
> are allowed to put the CoA in the Registration request, the HA will never 
> need to know that the visited network uses regional registrations, and the 
> GFA will look lika a normal FA. I still think this is a good feature.
> 
> To allow this, the FA must advertise a publicly routable GFA (CoA) address. 
> If the FA and GFA belongs to a private address domain, the FA needs to have 
> a mapping from the public CoA address to the private GFA address that it 
> should use to send the Registration request to. I think this solves the 
> problem.
> 
> To summarise, I suggest that we:
> * clarify that dynamic allocation of CoA is preferable
> * add that the FA might use another address to communicate with a GFA than 
> the CoA advertised, and that it in that case needs a mapping between these 
> two addresses
> * change the allocation of CoA and use of the GFA IP address extension, by 
> saying that it is the responsibility of the FA to select GFA, but not to 
> include any GFA IP extension, because it is the responsibility of the GFA 
> to allocate CoA, and it will add the GFA IP extension.
> 
> Do you agree that this solves the problems you raised?
> 
> /Annika
> 
> At 22:23 2002-04-15 -0400, Alan O'Neill wrote:
> >Below is the abstract for the draft that makes last call suggestions on
> >Regional tunneling.
> >
> >see
> >http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mods-00.txt
> >
> >Abstract
> >
> >    Regional Registration modifies the normal MIP Registration signalling
> >    back to the HA so that the signalling can traverse an intermediate
> >    Gateway Foreign Agent (GFA). The registered binding is between the Home
> >    Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent
> >    (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the GFA.
> >    Two extensions are defined to support this new Registration processing
> >    these being the Hierarchical Foreign Agent extension (HFAext) and the GFA
> >
> >    IP address extension (GFAIPext). The former is used to carry the FA CoA
> >    to the GFA and the latter is used by the FA to allocate a GFA to the MN,
> >    and by the FA, GFA, HA to securely return the GFA IP address to the MN.
> >
> >    The present processing rules for the HA registration enable the FA to
> >    advertise the GFA to the MN in a Foreign Agent Advertisement (FAA) and
> >    for the MN to include that GFA address into the CoA field of the MIP home
> >
> >    Registration. This however assumes a number of things about the GFA
> >    address in the FAA and the addressing realms between the FA-GFA and GFA-
> >    HA.. Specifically, the GFA CoA and the GFA IP address must potentially be
> >
> >    from two different addressing plans and hence cannot be in the same FAA.
> >    This draft describes the issues and suggests a solution that requires
> >    slight modifications to the required extensions, that generalises the
> >    Home Registration signalling for arbitrary intermediate MIP nodes, and
> >    only slightly modifies the processing rules for the MIP Home
> >    Registration. This draft also describes a way to support dynamic HA
> >    allocation along-side Regional Registrations.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 10:37:18 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07477
	for ; Thu, 25 Apr 2002 10:37:17 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20489;
	Thu, 25 Apr 2002 08:35:48 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03177;
	Thu, 25 Apr 2002 07:35:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEYjGs000968
	for ; Thu, 25 Apr 2002 07:34:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PEYjf6000967
	for mobile-ip-dist; Thu, 25 Apr 2002 07:34:45 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEYfGs000960
	for ; Thu, 25 Apr 2002 07:34:41 -0700 (PDT)
Received: from lillen (vpn-129-156-96-151.EMEA.Sun.COM [129.156.96.151])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3PEYVg26180;
	Thu, 25 Apr 2002 16:34:32 +0200 (MEST)
Date: Thu, 25 Apr 2002 16:33:59 +0200 (CEST)
From: Erik Nordmark 
Reply-To: Erik Nordmark 
Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication?
To: jari.arkko@piuha.net
Cc: Vijay Devarapalli ,
        Tuomas Aura ,
        "'mobile-ip@sunroof.eng.sun.com'" 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> This is an excellent observation! The sequence number works in
> this case as a sort of a weak cookie, which as you point out,
> the attacker doesn't know. Perhaps this could be enough.

I agree with Vijay that the sequence number in the BA is enough.

> Question: in BR, we don't have a sequence number. If the BR
> is more like a binding refresh request, should we add the sequence
> number also there?

For BA it is sufficient to do an exact match to the sequence number
against the last sent BU.

If you put a sequence number in the BR it isn't obvious to me that an
exact match is sufficient.

Case 1: Lost BU vs. lost BA.

	MN sends BU with sequence number 17 and the A bit set. 
	Retransmits it several times. Never receives a BA.
	This could be because all the BUs where lost, or because the CN
	received (at least) one BU but the BA was lost.

	Should the MN expect that a BR contain seq 17 or 16 (assuming 16
	was the last one it got a BA for).

Case 2: BUs without A bit

	If the MN sends BU seq # 15, 16, 17, etc without asking for a BA
	which sequence number should it expect in the BR?


I think these issues appear if a cookie different that the sequence number
is used to filter out spoofed BRs.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 10:39:23 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07603
	for ; Thu, 25 Apr 2002 10:39:23 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14254;
	Thu, 25 Apr 2002 07:38:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03768;
	Thu, 25 Apr 2002 07:38:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEbxGs001018
	for ; Thu, 25 Apr 2002 07:37:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PEbxYj001017
	for mobile-ip-dist; Thu, 25 Apr 2002 07:37:59 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEbtGs001010
	for ; Thu, 25 Apr 2002 07:37:55 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03629
	for ; Thu, 25 Apr 2002 07:37:55 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21679
	for ; Thu, 25 Apr 2002 08:37:54 -0600 (MDT)
Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3PEbUTZ012809;
	Thu, 25 Apr 2002 07:37:30 -0700 (PDT)
Received: from DBLAIRW2K (rtp-vpn1-523.cisco.com [10.82.226.11])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id ACT03879;
	Thu, 25 Apr 2002 07:37:26 -0700 (PDT)
From: "Dana L. Blair" 
To: "Alan O'Neill" ,
        "Annika Jonsson" ,
        "Charles E. Perkins" ,
        "Madhavi W. Chandra" ,
        "James Kempf" , 
Cc: 
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Thu, 25 Apr 2002 10:37:24 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46C3A757@ftmail>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Nice explaination, but I don't see enough justification in this
email for a "regional element".

Please be aware that I am open to the idea of a "regional element".
However, there must be specific scenarios which have obvious
improvements over current MN, FA, and HA relationships to warrant
an internet standard.

Also, I would hesitate to suggest modifications to a draft which itself
has questionable merit as a standard.  Maybe you should start from
scratch with what you really need instead of creating various
modification drafts.

thanks,
Dana

> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Alan O'Neill
> Sent: Wednesday, April 24, 2002 2:15 AM
> To: Annika Jonsson; Charles E. Perkins; Madhavi W. Chandra; James Kempf;
> Basavaraj.Patil@nokia.com
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] WG Last Call:
> draft-ietf-mobileip-reg-tunnel-06.txt
>
>
> So I thought given the thread I would add some higher layer
> thoughts behind
> Flarions interest in this draft and respond to some of the other comments
> raised. I do so coming from an intial viewpoint of seeing
> absolutely no need
> for regional registration for MIP...so am a slightly converted strong
> sceptic..as you will see below.
>
> Firstly, I agree with many that avoiding additional points of failure and
> the cost/benefit of regional registration makes its usefulness
> debatable...
> I agree that the hand-off aspects of this draft should be split
> out into the
> hand-off work and that additional work is required on the 'home signaling
> via regional node plane' to address some of the technical issues,
> especially
> regarding backwards compatibility and GFA CoA assignment (see my previous
> response to Annika on the latter and Ahmeds excellent analysis on the
> former). Even then, (if I was a neutral), I think I would say
> that we would
> need to see more deployment demand to progress the mechanisms in
> this draft
> on standards track.
>
> However, Flarion has one of the more challenging environments for
> MIPv4 and
> we will deploy something, sometime, somewhere soon (hopefully in huge
> volumes ;-) In reviewing a lot of MIP work in anticipation of that
> deployment, reviews that are still ongoing and for obvious reasons
> commercially sensitive at this time, it is apparent that there are some
> missing bits. We plan to continue to write these up and submit them
> following discussions and agreement with our core router partners and
> customers to then hopefully trigger standards activity where necessary.
> RegTunMods and RevTunMods were the first two such drafts and there will be
> others unrelated to regional tunneling...
>
> One such missing bit appears to be the need to be able to advertise the
> existence of a regional element (the 'I' bit) to the MN, to
> detect when that
> element has changed and to register to a home agent via each new regional
> element. We specifically have little interest in the RFA, in the regional
> element being a GFA and in the regional registration to the GFA itself. My
> analysis of, and feedback on, the RegTun draft in [RegTunMods]
> was motivated
> simply by the desire to be able to re-use the home registration regional
> extensions and hence co-exist with GFAs that might already have been
> deployed. I am open-minded about them getting deployed, but very
> unhappy if
> the general regional element capability is lost or eventually not
> standardised.
>
> I can and will elaborate much further on these points in suitable
> drafts as
> soon as I am able. This will hopefully be a matter of days or at
> worst a few
> weeks. In the absence of that justification and information I would be
> supportive of the draft being revised and taken to experimental. I would
> however recommend that we try to separate out the home signaling via a
> regional element, from the type of regional element and its features, as I
> think (well know :-) they are distinct. A generalised address carrier with
> sub-types can be used to transport addresses up and down that signalling
> plane and be used to trigger address type specific processing..ie
> a GFA CoA
> sub-type means do GFA type things. I think this redesign is a
> good idea even
> just for GFA as who knows what future requirements will come upon us (ours
> aside) and nailing up a general capability is unfortunate. This address
> carrier should maybe be defined in a separate draft.
>
> I also believe that the regional element should be able to be in
> the core or
> at the edge as alluded to by other responders, although ours will
> likely be
> in the core much to the horror of some of you no doubt. I wouldn't do it
> though unless I thought it was absolutely necessary...believe me.
>
> I think we should also finally recognise the extensive and excellent work
> that has gone into RegTun, and await both suitable revisions and then
> vendor/customer interest before committing this to standards track.
>
> Regards,  Alan.
>
>
>
>
>
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 10:56:42 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08279
	for ; Thu, 25 Apr 2002 10:56:42 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26023;
	Thu, 25 Apr 2002 08:56:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09838;
	Thu, 25 Apr 2002 07:56:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEtLGs001603
	for ; Thu, 25 Apr 2002 07:55:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PEtLKo001602
	for mobile-ip-dist; Thu, 25 Apr 2002 07:55:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEtGGs001521
	for ; Thu, 25 Apr 2002 07:55:16 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26670
	for ; Thu, 25 Apr 2002 07:55:00 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02000
	for ; Thu, 25 Apr 2002 08:55:00 -0600 (MDT)
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 HAA08496;
	Thu, 25 Apr 2002 07:54:59 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PEswg11183;
	Thu, 25 Apr 2002 07:54:58 -0700
X-mProtect: <200204251454> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdluLby1; Thu, 25 Apr 2002 07:54:55 PDT
Message-ID: <3CC818C0.1E628F82@iprg.nokia.com>
Date: Thu, 25 Apr 2002 07:54:56 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Dana L. Blair" 
CC: Annika Jonsson ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

"Dana L. Blair" wrote:

 
> Please be aware that I am open to the idea of a "regional element".
> However, there must be specific scenarios which have obvious
> improvements over current MN, FA, and HA relationships to warrant
> an internet standard.
> 
> Also, I would hesitate to suggest modifications to a draft which itself
> has questionable merit as a standard.  Maybe you should start from
> scratch with what you really need instead of creating various
> modification drafts.

Your implication seems to be that our draft has questionable
merit.  I think that statement itself has zero merit.  Furthermore,
I am pretty sure our draft has a lot of merit.  We can go about
fixing the problems it has, but your previous notes seemed to
offer no specific improvements.

I also strongly suggest that we have to allow for separate handover
improvement protocols to be specified in separate documents, which
seems to be contrary to your earlier suggestion.  The protocol
demands for regional registration are qualitatively different
than those for managing connectivity at the edge routers, and
neither one of those protocol solutions belongs in the base
protocol specification for Mobile IP.

Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 10:59:08 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08342
	for ; Thu, 25 Apr 2002 10:59:03 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04664;
	Thu, 25 Apr 2002 08:59:04 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10643;
	Thu, 25 Apr 2002 07:58:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEwAGs002150
	for ; Thu, 25 Apr 2002 07:58:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PEwAd0002149
	for mobile-ip-dist; Thu, 25 Apr 2002 07:58:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PEw5Gs002123
	for ; Thu, 25 Apr 2002 07:58:05 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08240
	for ; Thu, 25 Apr 2002 07:58:04 -0700 (PDT)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23156
	for ; Thu, 25 Apr 2002 07:58:04 -0700 (PDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3PEw3P18958
	for ; Thu, 25 Apr 2002 09:58:03 -0500 (CDT)
Message-ID: <3CC81990.5070904@alcatel.com>
Date: Thu, 25 Apr 2002 09:58:24 -0500
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
References: 
Content-Type: multipart/alternative;
 boundary="------------010503060804080801090504"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------010503060804080801090504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Dana,
  Of course you are entitled to have your own opinion, but I kind of 
like the following view of Ahmad, it is positive and it is going to lead 
to some progress:

> The more solutions we have for the same problem is the better as long 
> as they are:
>         1. OPTIONAL
>         2. 100% BACKWARD COMPATIBLE.
>
> Operators can pick and choose the best for them.
>


Dana L. Blair wrote:

>Nice explaination, but I don't see enough justification in this
>email for a "regional element".
>
>Please be aware that I am open to the idea of a "regional element".
>However, there must be specific scenarios which have obvious
>improvements over current MN, FA, and HA relationships to warrant
>an internet standard.
>
>Also, I would hesitate to suggest modifications to a draft which itself
>has questionable merit as a standard.  Maybe you should start from
>scratch with what you really need instead of creating various
>modification drafts.
>
>thanks,
>Dana
>
Regards,

--behcet

>


--------------010503060804080801090504
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Hello Dana,

  Of course you are entitled to have your own opinion, but I kind of like
the following view of Ahmad, it is positive and it is going to lead to some
progress: 


The more solutions we have for the
same problem is the better as long as they are:

        1. OPTIONAL

        2. 100% BACKWARD COMPATIBLE.
  
Operators can pick and choose the best for them.

  

  

  

Dana L. Blair wrote:

  

    
Nice explaination, but I don't see enough justification in this
email for a "regional element".

Please be aware that I am open to the idea of a "regional element".
However, there must be specific scenarios which have obvious
improvements over current MN, FA, and HA relationships to warrant
an internet standard.

Also, I would hesitate to suggest modifications to a draft which itself
has questionable merit as a standard.  Maybe you should start from
scratch with what you really need instead of creating various
modification drafts.

thanks,
Dana

    

Regards,

    

--behcet

    

      


      

      

      
      

--------------010503060804080801090504--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 11:08:36 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08748
	for ; Thu, 25 Apr 2002 11:08:36 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17686;
	Thu, 25 Apr 2002 09:08:36 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14557;
	Thu, 25 Apr 2002 08:08:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PF7SGs004559
	for ; Thu, 25 Apr 2002 08:07:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PF7RSV004558
	for mobile-ip-dist; Thu, 25 Apr 2002 08:07:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PF7NGs004533
	for ; Thu, 25 Apr 2002 08:07:23 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14207
	for ; Thu, 25 Apr 2002 08:07:22 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11124
	for ; Thu, 25 Apr 2002 09:07:21 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3PF7EB10711;
	Thu, 25 Apr 2002 17:07:14 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA00397;
	Thu, 25 Apr 2002 17:07:14 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3PF7ET73773;
	Thu, 25 Apr 2002 17:07:14 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204251507.g3PF7ET73773@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= 
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO 
In-reply-to: Your message of Thu, 25 Apr 2002 18:45:05 +0900.
             <20020425.184505.06470684.keiichi@iij.ad.jp> 
Date: Thu, 25 Apr 2002 17:07:14 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   The latest discussion concludes that a HAO must not be processed
   without a valid BCE.

=> I disagree: it must not be processed if it is not verified and
there are at least two ways to verify a HAO:
 - BCE check
 - IPsec (the idea is if the HAO is fake the IPsec processing will
   reject the whole packet, look at my ID about IPsec and Mobile IPv6).

   Also, the BU/BA for the home registration must be protected by the ESP.
   
=> so the HAO will be verified and as soon as the next header type is ESP
the BCE check is no more necessary. Unfortunately the SA pair would be used
only for the protection of BU/BA exchange: a waste but it *is* secure!
(this comment is only for the home registration and when the only direct
traffic between the MN and the HA is the mobility signaling).

   ... for the home registration packet must include a HAO.
   
=> note that the situation is very different for ordinary BUs because
the home address is usable at any moment, including before the processing
of the BU.

   The CN must drop packets which contain a HAO without a valid BCE.

=> add "if there is no other way to verify it" and you are saved.

   Conclusion: the home registration never be processed.
   
=> I am not convinced the home registration is really completely handled
in last documents. Your message won't change my opinion (:-).
   
   Condideration:
   
   - Using MN_CoA as an endpoint of the SA/SPD:
   
=> NO, you should use MN_HoA!

   It seems unrealistic.
   
=> because it is!
   
   - Introduce a flag that indicates 'I saw a HAO'.
   
=> too complex. Try my IPsec stuff.

   How do you think about this?
   
=> help me for the next version of my ID (:-)?

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 11:51:57 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24467
	for ; Thu, 25 Apr 2002 11:51:57 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06599;
	Thu, 25 Apr 2002 09:50:04 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02035;
	Thu, 25 Apr 2002 08:49:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PFmjGs016622
	for ; Thu, 25 Apr 2002 08:48:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PFmjB9016621
	for mobile-ip-dist; Thu, 25 Apr 2002 08:48:45 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PFmfGs016614
	for ; Thu, 25 Apr 2002 08:48:41 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01892
	for ; Thu, 25 Apr 2002 08:48:41 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15025
	for ; Thu, 25 Apr 2002 09:48:41 -0600 (MDT)
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 IAA11176;
	Thu, 25 Apr 2002 08:48:40 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PFmWm07506;
	Thu, 25 Apr 2002 08:48:32 -0700
X-mProtect: <200204251548> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdCTgdqS; Thu, 25 Apr 2002 08:48:30 PDT
Message-ID: <3CC8254F.FDF6706A@iprg.nokia.com>
Date: Thu, 25 Apr 2002 08:48:31 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Ahmad Muhanna 
CC: Luca Salgarelli ,
        "'mobile-ip@sunroof.eng.sun.com'" 
Subject: Re: Proposed changes to rfc3012bis [was: RE: [mobile-ip]  
 RFC3012-bis:compatibility issues]
References: <6B49EDFE974BD51197D70002A56079D801AFCC40@zrc2c013.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Ahmad,

Thanks for your comments.  I hope this note will help to
finally resolve the remaining issues.


> Ahmad Muhanna wrote:
>
>> I would replace the  block as follows:
>>
>>      The Foreign Agent MUST maintain the last challenge used by
>>      each Mobile Node that has successfully registered using
>>      any one of the last CHALLENGE_WINDOW challenge values.
>>      This last challenge value can be stored as part of the
>>      mobile node's registration records.
>>
> 
> I believe that the part of the  Luca proposed and I mentioned
> earlier is more than sufficient to eliminate any security threat.
> I still support that text as follows:
> 
>            The Foreign Agent SHOULD keep records for all
>           challenges used by a Mobile Node that are still in the valid
>           CHALLENGE_WINDOW.
> 
> Now how user would like to achieve this is up to the user himself.
> What about if some implementors want to choose a
> CHALLENGE_WINDOW of 3 or 1. It is OK. The standard offers flexible
> way for the Mobile Node to get good CHALLENGES.
> If a CHALLENGE is used and is no longer valid MN will receive a
> Registration Reply with a valid CHALLENGE which can be used
> or it can solicit.

O.K.  Then, would you be willing to propose two sentences for
inclusion in the Security Considerations that describe the
vulnerability when the Foreign Agent does NOT maintain sufficient
records?

Also, I am curious to find out if you think that (2*N + X) is too
much information for the foreign agent to maintain, or if you
think that it is more than (2*N + X).  Here, N == # of mobile_nodes
and X = CHALLENGE_WINDOW.

>> This uses the knowledge that mobile nodes MUST NOT use
>> previous challenges.  To this end, I would add the following
>> restriction at the end of section 4:
                    ..........
>                .............             We need to eliminate
> the successful concept here:
> 
>       Suppose the Mobile Node has used a Challenge Value of the
>       CHALLENGE_WINDOW values advertised by the Foreign Agent
>       in its last Registration Request.  In that case, in any subsequent
>       Registration Request the Mobile Node MUST NOT use any
>       Challenge Value which was advertised by the Foreign Agent before
>       the Challenge Value in its last Registration Request.

Do you then suggest that the foreign agent SHOULD supply a
Challenge in the Registration Reply containing the rejection
indication?


>> The foreign agent can use the following algorithm:

                .......

> I am not sure if it is necessary to include this algorithm.

Well, if the algorithm is correct, then it seemed to me that
others might find it useful, who had not had the benefit of this
fairly extensive discussion.  But if you don't think so, or if
you think it is not useful for other reasons, I will keep it out
of the specification.

> Well, this brings me back to the very old text I proposed and you did not like. 
> What about replacing the stale challenge with the following:
>
> stale challenge
> 
>         Same as "previously used challenge" and the Foreign Agent still has a
> record of.

This is fine with me.  I would reword it as:

 stale challenge
 
         A previously used challenge that is still identifiable
         as such by the Foreign Agent.


>> By the way, I guess up until now nobody mentioned that the
>> following text in section 1.1 was an incomplete sentence:
>>
>>    The following additional terminology
>>
>> In fact, it looks like to me that the section is not finished,
>> and that there always needed to be a definition for a "valid
>> challenge".
>>
> 
> I think unused challenge is enough. The only thing which is not mentioned but
> explained in the text is the timestamp concept on the Challenge-Window
> challenges.

Shall I define "valid challenge" to be the same as "unused challenge",
or alternatively change instances of "valid challenge" to be
"unused challenge" in the text?

Can you suggest what I need to do to fix the problem with the timestamp?

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 12:13:43 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25775
	for ; Thu, 25 Apr 2002 12:13:43 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15102;
	Thu, 25 Apr 2002 09:13:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09979;
	Thu, 25 Apr 2002 09:12:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGC3Gs016756
	for ; Thu, 25 Apr 2002 09:12:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PGC3jq016755
	for mobile-ip-dist; Thu, 25 Apr 2002 09:12:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGC0Gs016748
	for ; Thu, 25 Apr 2002 09:12:00 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00135
	for ; Thu, 25 Apr 2002 09:12:00 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13581
	for ; Thu, 25 Apr 2002 09:12:00 -0700 (PDT)
Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3PGBgTZ012440;
	Thu, 25 Apr 2002 09:11:43 -0700 (PDT)
Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA07338; Thu, 25 Apr 2002 12:11:42 -0400 (EDT)
Date: Thu, 25 Apr 2002 12:11:42 -0400
From: "Madhavi W. Chandra" 
To: "Charles E. Perkins" 
Cc: "Dana L. Blair" ,
        Annika Jonsson ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Message-ID: <20020425121142.A7334@cisco.com>
References:  <3CC818C0.1E628F82@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3CC818C0.1E628F82@iprg.nokia.com>; from charliep@iprg.nokia.com on Thu, Apr 25, 2002 at 07:54:56AM -0700
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Charlie,

On Thu, Apr 25, 2002 at 07:54:56AM -0700, Charles E. Perkins wrote:
> "Dana L. Blair" wrote:
> 
>  
> > Please be aware that I am open to the idea of a "regional element".
> > However, there must be specific scenarios which have obvious
> > improvements over current MN, FA, and HA relationships to warrant
> > an internet standard.
> > 
> > Also, I would hesitate to suggest modifications to a draft which itself
> > has questionable merit as a standard.  Maybe you should start from
> > scratch with what you really need instead of creating various
> > modification drafts.
> 
> Your implication seems to be that our draft has questionable
> merit.  I think that statement itself has zero merit.  Furthermore,
> I am pretty sure our draft has a lot of merit.  We can go about
> fixing the problems it has, but your previous notes seemed to
> offer no specific improvements.

There is no doubt that your draft is the result of extensive
research.  Perhaps if we included a section in the draft 
that outlined the scenarios that would benefit from the 
implementation and added text in the Intro/Abstract to indicate 
clearly that this design is OPTIONAL, it would be more apparent 
that the architecture need not be implemented.  It would also
be clear under what circumstances one would want to implement
this design.  I would also suggest a section on synergies
with Fast Handoffs...to explain the interaction, or separation.

We can certainly help you with text.  I think this is 
independent of the draft status...experimental or not.

Regards,
Madhavi


> I also strongly suggest that we have to allow for separate handover
> improvement protocols to be specified in separate documents, which
> seems to be contrary to your earlier suggestion.  The protocol
> demands for regional registration are qualitatively different
> than those for managing connectivity at the edge routers, and
> neither one of those protocol solutions belongs in the base
> protocol specification for Mobile IP.
> 
> Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 12:21:18 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26123
	for ; Thu, 25 Apr 2002 12:21:18 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27809;
	Thu, 25 Apr 2002 10:21:19 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13688;
	Thu, 25 Apr 2002 09:21:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGKAGs017286
	for ; Thu, 25 Apr 2002 09:20:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PGKAM8017285
	for mobile-ip-dist; Thu, 25 Apr 2002 09:20:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGK6Gs017278
	for ; Thu, 25 Apr 2002 09:20:06 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13078
	for ; Thu, 25 Apr 2002 09:20:06 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08081
	for ; Thu, 25 Apr 2002 10:20:02 -0600 (MDT)
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 JAA13081;
	Thu, 25 Apr 2002 09:19:53 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PGJqw05996;
	Thu, 25 Apr 2002 09:19:52 -0700
X-mProtect: <200204251619> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdL89Pj3; Thu, 25 Apr 2002 09:19:50 PDT
Message-ID: <3CC82CA7.78332B19@iprg.nokia.com>
Date: Thu, 25 Apr 2002 09:19:51 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Madhavi W. Chandra" 
CC: Annika Jonsson ,
        mobile-ip@sunroof.eng.sun.com,
        Eva Gustafsson 
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
References:  <3CC818C0.1E628F82@iprg.nokia.com> <20020425121142.A7334@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Madhavi,

"Madhavi W. Chandra" wrote:

> There is no doubt that your draft is the result of extensive
> research.

In this case, we also have publications, simulations, and
implementations to back up the research.

>             Perhaps if we included a section in the draft
> that outlined the scenarios that would benefit from the
> implementation and added text in the Intro/Abstract to indicate
> clearly that this design is OPTIONAL, it would be more apparent
> that the architecture need not be implemented.  It would also
> be clear under what circumstances one would want to implement
> this design.  I would also suggest a section on synergies
> with Fast Handoffs...to explain the interaction, or separation.

I think this would be great.  I would locate the synergy section
in another Appendix.  I would locate the optionality statement
and scenario description in the first part of the document,
probably within section 3 (perhaps section 3.1).

> We can certainly help you with text.  I think this is
> independent of the draft status...experimental or not.

I hope I am not speaking out of line before consulting my
co-authors, but for myself I would quite appreciate your
help.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 12:34:23 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26604
	for ; Thu, 25 Apr 2002 12:34:22 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28203;
	Thu, 25 Apr 2002 09:33:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20329;
	Thu, 25 Apr 2002 09:33:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGWeGs019011
	for ; Thu, 25 Apr 2002 09:32:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PGWeLx019010
	for mobile-ip-dist; Thu, 25 Apr 2002 09:32:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGWZGs018981
	for ; Thu, 25 Apr 2002 09:32:35 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19808
	for ; Thu, 25 Apr 2002 09:32:35 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27526
	for ; Thu, 25 Apr 2002 09:32:35 -0700 (PDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3PGWTG10799;
	Thu, 25 Apr 2002 11:32:29 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2Y3TZX34>; Thu, 25 Apr 2002 10:42:15 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC42@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'bob@marksmob.com'" ,
        "'Tony Johansson'"
	 
Cc: "'Fredrik Johansson'" ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-
	00.txt
Date: Thu, 25 Apr 2002 10:42:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EC6F.C62C1FB0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EC6F.C62C1FB0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Bob;

I think the whole idea is to prevent this draft from mandating all Mobile
Nodes to include
AAA NAI extension with subtype 1 "HA" in the following scenarios:

1. When the Mobile Node sends a Registration Request for Re-Authentication:
MN will never be able to send the AAA NAI extension in the Registration 
request unless it recognizes and support that extension. Because, it
received 
it from HAAA through the FAAA and the FA in the Registration Reply message.
Legacy MN does not support any feature which requires this anyway.

2. When the Mobile Node request a static Mobile IP call. "specific IP
address"
ONLY those Mobile Node which again support and recognizes this extension
will be able to send it. Because, legacy Mobile Node are not configured with
AAA NAI extension for the HA anyway. Also, legacy MN does not support 
any feature which requires this to be added to the Registration Request.

However, I agree the proposed text may be very broad.

Tony/Bob,
Do you think the following text would be more specific?
It include all the text I proposed so far.

section 4. should read:
"
   The HA identity uses subtype 1 of the AAA NAI Extension.  It contains
   the NAI of the AAA interface of the HA in the form hostname@realm.
   Together the hostname and realm forms the complete FQDN
   (hostname.realm) of the HA's AAA interface.

   The home agent MUST provide HA identity in every registration reply 
   sent to the mobile node destined through the AAA infrastructure.

   A mobile node which support AAA NAI MUST provide HA identity in 
   every registration request sent when re-authenticating, or when 
   requesting a specific IP address at initial authentication.
"

section 5. should read:
"
   The AAAH identity uses subtype 2 of the AAA NAI Extension.  It
   contains the NAI of the home AAA server in the form hostname@realm.
   Together the hostname and realm forms the complete FQDN
   (hostname.realm) of the home AAA servers interface.

   The home agent MUST provide this in every registration reply sent to 
   the mobile node destined through the AAA infrastructure.

   A mobile node which support the AAA NAI extension MUST always 
   save the latest AAAH Identity received in the registration reply message 
   and MUST provide the AAAH Identity in every registration request sent 
    when re-authenticating.

   If the AAAH identity is present, the foreign agent MUST direct an
   authentication request to this home AAA server when authenticating
   the mobile node through the AAA infrastructure by means described in
   [2]
"

This will eliminate the need for the following text:
"The AAA NAI extension MUST only be used with the Diameter Mobile IPv4
application and MUST NOT be used with any other AAA protocol."


Regards; 
Ahmad Muhanna 
****************************************************************************
***************************

Hello Ahmad,
 
I'm still not totally comfortable with this new technique and its impact on
bandwidth-constrained links.
 
For RFC2002, the MN sent only the authentication extensions it knew it
needed. It knew if it had a
security association with the FA, and had to have a security association
with the HA.
 
For RFC3012, the MN could use the presence (or absence) of the Challenge to
determine which
extensions and parameters (like NAI) it included in the Registration
Request.
 
But for this new I-D, the MN does not get any clue at all. Therefore it
needs to include the extension
because it might be needed. This, it seems to me, is not so good for
bandwidth-constrained links.
As Tony pointed out, it seems that the MN must be configured to send or not
to send - I'd rather the
FA provided some clue.
 
Bob
 
 

------_=_NextPart_001_01C1EC6F.C62C1FB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] RE: A Question =
about:draft-ietf-mobileip-aaa-nai-00.txt




Hello Bob;




I think the whole idea is to prevent =
this draft from mandating all Mobile Nodes to include

AAA NAI extension with subtype 1 =
"HA" in the =
following scenarios:




1. When the Mobile Node sends a =
Registration Request for Re-Authentication:

MN will never be able to send the AAA =
NAI extension in the Registration 

request unless it recognizes and =
support that extension. Because, it received 

it from HAAA through the FAAA and the =
FA in the Registration Reply message.

Legacy MN does not support any =
feature which requires this anyway.




2. When the Mobile Node request a =
static Mobile IP call. "specific IP address"

ONLY those Mobile Node which again =
support and recognizes this extension

will be able to send it. Because, =
legacy Mobile Node are not configured with

AAA NAI extension for the HA anyway. =
Also, legacy MN does not support 

any feature which requires this to be =
added to the Registration Request.




However, I agree the proposed text may =
be very broad.




Tony/Bob,

Do you think the following text would be more specific?

It include all the text I proposed so =
far.




section 4. should read:

"

   The HA identity uses =
subtype 1 of the AAA NAI Extension.  It contains

   the NAI of the AAA =
interface of the HA in the form hostname@realm.

   Together the hostname =
and realm forms the complete FQDN

   (hostname.realm) of the =
HA's AAA interface.




   The home agent MUST =
provide HA identity in every registration reply 

   sent to the mobile node =
destined through the AAA infrastructure.




   A mobile node which =
support AAA NAI MUST provide HA identity in 

   every registration =
request sent when re-authenticating, or when 

   requesting a specific IP =
address at initial authentication.

"




section 5. should read:

"

   The AAAH identity uses =
subtype 2 of the AAA NAI Extension.  It

   contains the NAI of the =
home AAA server in the form hostname@realm.

   Together the hostname =
and realm forms the complete FQDN

   (hostname.realm) of the =
home AAA servers interface.




   The home agent MUST =
provide this in every registration reply sent to 

   the mobile node =
destined through the AAA infrastructure.




   A mobile node =
which support the AAA NAI =
extension MUST always 

   save the latest AAAH =
Identity received in the registration reply message 

   and MUST provide the =
AAAH Identity in every registration request sent 

    when =
re-authenticating.




   If the AAAH identity is =
present, the foreign agent MUST direct an

   authentication request =
to this home AAA server when authenticating

   the mobile node through =
the AAA infrastructure by means described in

   [2]

"




This will eliminate the need for =
the following text:

"The AAA NAI extension MUST only =
be used with the Diameter Mobile IPv4

application and MUST NOT be used with =
any other AAA protocol."






Regards; 

Ahmad Muhanna 

*********************************************************=
**********************************************




Hello Ahmad,

 

I'm still not totally comfortable =
with this new technique and its impact on bandwidth-constrained =
links.

 

For RFC2002, the MN sent only the =
authentication extensions it knew it needed. It knew if it had a

security association with the FA, and =
had to have a security association with the HA.

 

For RFC3012, the MN could use the =
presence (or absence) of the Challenge to determine which

extensions and parameters (like NAI) =
it included in the Registration Request.

 

But for this new I-D, the MN does not =
get any clue at all. Therefore it needs to include the extension

because it might be needed. This, it =
seems to me, is not so good for bandwidth-constrained links.

As Tony pointed out, it seems that =
the MN must be configured to send or not to send - I'd rather =
the

FA provided some clue.

 

Bob

 

 





------_=_NextPart_001_01C1EC6F.C62C1FB0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 12:40:38 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26773
	for ; Thu, 25 Apr 2002 12:40:37 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02325;
	Thu, 25 Apr 2002 09:40:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23428;
	Thu, 25 Apr 2002 09:40:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGckGs020152
	for ; Thu, 25 Apr 2002 09:38:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PGck0H020151
	for mobile-ip-dist; Thu, 25 Apr 2002 09:38:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGcgGs020133
	for ; Thu, 25 Apr 2002 09:38:42 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21427
	for ; Thu, 25 Apr 2002 09:38:42 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15037
	for ; Thu, 25 Apr 2002 10:38:42 -0600 (MDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3PGcDG11997;
	Thu, 25 Apr 2002 11:38:14 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2Y3TZX6M>; Thu, 25 Apr 2002 10:59:43 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC43@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Charles E. Perkins'" ,
        Luca Salgarelli
	 
Cc: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: Proposed changes to rfc3012bis [was: RE: [mobile-ip]  RFC3012
	-bis:compatibility issues]
Date: Thu, 25 Apr 2002 10:59:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EC72.361CAB80"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EC72.361CAB80
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Charlie;

Please see my comments inline.
I reposting this. It seems the first one did not go through.

Regards;
Ahmad Muhanna

> 
> Hello Luca and Ahmad,
> 
> I guess it's about time to send out rfc3012bis if possible.
> 
> 
> I would replace the  block as follows:
> 
>      The Foreign Agent MUST maintain the last challenge used by
>      each Mobile Node that has successfully registered using
>      any one of the last CHALLENGE_WINDOW challenge values.
>      This last challenge value can be stored as part of the
>      mobile node's registration records.
>
I believe that the part of the  Luca proposed and I mentioned 
earlier is more than sufficient to eliminate any security threat. 
I still support that text as follows:

           The Foreign Agent SHOULD keep records for all
          challenges used by a Mobile Node that are still in the valid
          CHALLENGE_WINDOW.

Now how user would like to achieve this is up to the user himself. 
What about if some implementors want to choose a 
CHALLENGE_WINDOW of 3 or 1. It is OK. The standard offers flexible
way for the Mobile Node to get good CHALLENGES. 
If a CHALLENGE is used and is no longer valid MN will receive a 
Registration Reply with a valid CHALLENGE which can be used
or it can solicit.
 
> This uses the knowledge that mobile nodes MUST NOT use
> previous challenges.  To this end, I would add the following
> restriction at the end of section 4:
> 
>      Suppose the Mobile Node has successfully registered using one of
>      the Challenge Values within the CHALLENGE_WINDOW values advertised
>      by the Foreign Agent.  In that case, in any new Registration
>      Request the Mobile Node MUST NOT use any Challenge Value which was
>      advertised by the Foreign Agent before the Challenge Value in its
>      last successful Registration Request.
> 

No problem, BUT may I suggest a slight change here, We need to eliminate 
the successful concept here:

      Suppose the Mobile Node has used a Challenge Value of the 
      CHALLENGE_WINDOW values advertised by the Foreign Agent
      in its last Registration Request.  In that case, in any subsequent 
      Registration Request the Mobile Node MUST NOT use any 
      Challenge Value which was advertised by the Foreign Agent before 
      the Challenge Value in its last Registration Request.


> With these two mandates, the total storage required by the foreign
> agent for all Challenge Values amounts to (2N + CHALLENGE_WINDOW),
> where N is the number of mobile nodes currently being served by
> the Foreign Agent.  N of the stored values are for the "last
> challenge used", and the other N may have come from Registration
> Reply messages.  It shouldn't be any problem at all to have
> the CHALLENGE_WINDOW > 1 (i.e., >= 2).
> 

> 
> If you like this algorithm, then I need to create a terminology
> for "invalid challenge" and an error message to go with it.
> If you _really_ like it, I can include it in an appendix, along
> with any bug fixes or revisions you may suggest.
> 

I am not sure if it is necessary to include this algorithm.

> Finally, regarding that sentence in the definition for "stale 
> challenge":
> 
> 
> How about if we put the sentence in question somewhere after the
> list of terms in section 1.1?  That way, at least the observation
> would not be construed to apply unequally between "stale challenge"
> and "previously used challenge".
>

Well, this brings me back to the very old text I proposed.
What about replacing the stale challenge with the following:

stale challenge 
               
        Same as "previously used challenge" and the Foreign Agent still has
a record of.
 
> By the way, I guess up until now nobody mentioned that the
> following text in section 1.1 was an incomplete sentence:
> 
>    The following additional terminology
> 
> In fact, it looks like to me that the section is not finished,
> and that there always needed to be a definition for a "valid
> challenge".
>

I think unused challenge is enough. The only thing which is not mentioned
but
explained in the text is the timestamp concept on the Challenge-Window 
challenges.
 
> 
> If this is good enough to close these issues, and if there are no
> other issues, I would like to send out rfc3012bis this week.
> I do not have any records about other issues that I can find.
> If this is O.K., then I think the revised draft will probably
> be ready for Last Call.
> 
> Regards,
> Charlie P.
> 

------_=_NextPart_001_01C1EC72.361CAB80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Proposed changes to rfc3012bis [was: RE: [mobile-ip]  =
RFC3012-bis:compatibility issues]




Hello Charlie;




Please see my comments inline.

I reposting this. It seems the first one did not go =
through.




Regards;

Ahmad Muhanna




> 

> Hello Luca and Ahmad,

> 

> I guess it's about time to send out rfc3012bis =
if possible.

> 

> 

> I would replace the <NEW-TEXT> block as =
follows:

> 

>      The Foreign Agent =
MUST maintain the last challenge used by

>      each Mobile Node =
that has successfully registered using

>      any one of the =
last CHALLENGE_WINDOW challenge values.

>      This last =
challenge value can be stored as part of the

>      mobile node's =
registration records.

>

I believe that the part of the <NEW TEXT> Luca =
proposed and I mentioned 

earlier is more than sufficient to eliminate any =
security threat. 

I still support that text as follows:




          <NEW =
TEXT> The Foreign Agent SHOULD keep records for all

          =
challenges used by a Mobile Node that are still in the valid

          =
CHALLENGE_WINDOW.<NEW TEXT>




Now how user would like to achieve this is up to the =
user himself. 

What about if some implementors want to choose a =


CHALLENGE_WINDOW of 3 or 1. It is OK. The standard =
offers flexible

way for the Mobile Node to get good CHALLENGES. =


If a CHALLENGE is used and is no longer valid MN =
will receive a 

Registration Reply with a valid CHALLENGE which can =
be used

or it can solicit.

 

> This uses the knowledge that mobile nodes MUST =
NOT use

> previous challenges.  To this end, I would =
add the following

> restriction at the end of section 4:

> 

>      Suppose the =
Mobile Node has successfully registered using one of

>      the Challenge =
Values within the CHALLENGE_WINDOW values advertised

>      by the Foreign =
Agent.  In that case, in any new Registration

>      Request the =
Mobile Node MUST NOT use any Challenge Value which was

>      advertised by the =
Foreign Agent before the Challenge Value in its

>      last successful =
Registration Request.

> 




No problem, BUT may I suggest a slight change here, =
We need to eliminate 

the successful concept here:




      Suppose the Mobile =
Node has used a Challenge Value of the 

      CHALLENGE_WINDOW =
values advertised by the Foreign Agent

      in its last =
Registration Request.  In that case, in any subsequent 

      Registration Request =
the Mobile Node MUST NOT use any 

      Challenge Value which =
was advertised by the Foreign Agent before 

      the Challenge Value =
in its last Registration Request.






> With these two mandates, the total storage =
required by the foreign

> agent for all Challenge Values amounts to (2N + =
CHALLENGE_WINDOW),

> where N is the number of mobile nodes currently =
being served by

> the Foreign Agent.  N of the stored values =
are for the "last

> challenge used", and the other N may have =
come from Registration

> Reply messages.  It shouldn't be any =
problem at all to have

> the CHALLENGE_WINDOW > 1 (i.e., >=3D =
2).

> 




> 

> If you like this algorithm, then I need to =
create a terminology

> for "invalid challenge" and an error =
message to go with it.

> If you _really_ like it, I can include it in an =
appendix, along

> with any bug fixes or revisions you may =
suggest.

> 




I am not sure if it is necessary to include this =
algorithm.




> Finally, regarding that sentence in the =
definition for "stale 

> challenge":

> 

> 

> How about if we put the sentence in question =
somewhere after the

> list of terms in section 1.1?  That way, =
at least the observation

> would not be construed to apply unequally =
between "stale challenge"

> and "previously used =
challenge".

>




Well, this brings me back to the very old text I =
proposed.

What about replacing the stale challenge with the =
following:




stale challenge 

          &nb=
sp;    

        Same as =
"previously used challenge" and the Foreign Agent still has a =
record of.

 

> By the way, I guess up until now nobody =
mentioned that the

> following text in section 1.1 was an incomplete =
sentence:

> 

>    The following additional =
terminology

> 

> In fact, it looks like to me that the section =
is not finished,

> and that there always needed to be a definition =
for a "valid

> challenge".

>




I think unused challenge is enough. The only thing =
which is not mentioned but

explained in the text is the timestamp concept on =
the Challenge-Window 

challenges.

 

> 

> If this is good enough to close these issues, =
and if there are no

> other issues, I would like to send out =
rfc3012bis this week.

> I do not have any records about other issues =
that I can find.

> If this is O.K., then I think the revised draft =
will probably

> be ready for Last Call.

> 

> Regards,

> Charlie P.

> 





------_=_NextPart_001_01C1EC72.361CAB80--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 12:58:14 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27512
	for ; Thu, 25 Apr 2002 12:58:13 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23383;
	Thu, 25 Apr 2002 10:58:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01553;
	Thu, 25 Apr 2002 09:58:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGuRGs023654
	for ; Thu, 25 Apr 2002 09:56:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PGuQcw023647
	for mobile-ip-dist; Thu, 25 Apr 2002 09:56:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PGuKGs023612
	for ; Thu, 25 Apr 2002 09:56:20 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22813
	for ; Thu, 25 Apr 2002 09:56:21 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22027
	for ; Thu, 25 Apr 2002 10:56:20 -0600 (MDT)
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 JAA15422;
	Thu, 25 Apr 2002 09:56:20 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PGuIJ29062;
	Thu, 25 Apr 2002 09:56:18 -0700
X-mProtect: <200204251656> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd6th0wS; Thu, 25 Apr 2002 09:56:16 PDT
Message-ID: <3CC83530.40F4CB65@iprg.nokia.com>
Date: Thu, 25 Apr 2002 09:56:16 -0700
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: "Alper E. YEGIN" ,
        Manolis Sifalakis ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> <046701c1e804$7016f330$736015ac@AlperVAIO> <3CC58E3C.86B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Jim,

James Kempf wrote:

> Rajeev,
>
> One issue is where the information about the failure of routing due to
> link handover is available. If the MN knows, then it can take measures.
> If the network knows, then it can. FMIPv6 and BETH are two design points
> to cover these. These are covered in the draft.
>

Clarification: In FMIPv6, the AR can send ProxyRtAdv without the MN
soliciting it. This covers the scenario when the information about
"routing failure", as you put it, is available at the network. BTW, isn't
"impending link failure" a better descriptor compared to "routing failure"
?
Anyway, this is a terminology nit.


>
> The other issue is when the information is available, before or after
> the point of link attachment has been changed (or both). Both FMIPv6 and
> BETH cover only the before case. Optimized standard Mobile IP handover,
> Forwarding from Previous Care of Address, and Posthandover Mobile
> Initiated Tunneling cover after. These are not covered in the draft, but
> are in other drafts.
>

Agreed. If the MN is already attached to the new link, not much
pre-processing can be done.

Regards,

-Rajeev


>
> I think all of these are possible cases, unfortunately, and they all
> have different preformance characteristics.
>
>             jak
>
> ----- Original Message -----
> From: "Rajeev Koodli" 
> To: "James Kempf" 
> Cc: "Alper E. YEGIN" ; "Manolis Sifalakis"
> ; 
> Sent: Wednesday, April 24, 2002 2:08 PM
> Subject: Re: [mobile-ip] some questions about
> draft-ietf-mobileip-fast-mipv6-04
>
> >
> > Hi,
> >
> > >
> > > I don't think this follows. If the tunnel terminates at new AR, the
> new
> > > AR may buffer the packets until the MN shows up on the link. In
> BETH,
> > > the ARs co-operate to set up the routing, so a Link Down on the old
> AR
> > > is the appropriate trigger for setting up the tunnel. The MN isn't
> > >
> >
> > Ok. The difference between BETH and FMIPv6 is noted.
> >
> > > involved in determining the routing, the routers are. This is
> consistent
> > > with the basic history and design philosophy of IP routing, namely
> that
> > > a host doesn't concern itself with the path its packets take through
> the
> > > network, it is the task of the routers to perform this function.
> Hosts
> > > have never been responsible for determining routing in IP (modulo
> source
> > > routes of course) except to select their default router.
> > >
> >
> > Well, I agree with you that routing (i.e., the way a packet traverses
> > nodes to reach the destination) is not what hosts typically get
> > involved in. However, a host has to be able to determine whether
> > it receives packets or not in the first place, independent of _how_
> the
> > packets arrive.  More to the point, the MN must decide
> > whether its current AR should redirect traffic or not.
> >
> >
> > >
> > > In Mobile IP if the old AR is functioning as an on-link HA, as the
> MIPv6
> > > draft indicates, then the same mechanism used by the MN to
> communicate
> > > with the HA in the home network are appropriate for indicating to
> the
> > > old AR when the MN is on the new link, thus the FBU acts as the
> > > indicator for setting the tunnel up to the MN. But this is only
> because
> > > Mobile IP makes an exception to the standard IP routing design for a
> > > specific case, namely changing the care of address. This case
> doesn't
> > >
> >
> > I would say that standard IP routing is not affected at all by Mobile
> IP.
> > Whether Mobile IP chose to be that way or it was the result of a
> routing
> > exception (or both) is another issue. In any case, it is crucial to
> note
> > that the
> > burden of mobility (i.e., being reachable in the presence of handovers
> and
> > roaming) is on the mobile node with Mobile IP, that allows it to
> operate
> > without special IP routing support.
> >
> > > occur with BETH because the care of address doesn't change prior to
> the
> > > Layer 2 handover. BETH uses standard IP routing mechanisms to fix up
> the
> > >
> >
> > Ok. This distinction between BETH and FMIPv6 is also noted.
> >
> >
> > > change in link, Mobile IP mechanisms are used after the link switch
> to
> > > change the care of address as in standard Mobile IP, rather than
> > > changing the care of address before, as in FMIPv6.
> >
> > However, let me point out that a mode in FMIPv6 allows a MN to keep
> > its old CoA.
> >
> > >
> > > So I agree that the FBU is the proper signal for starting the tunnel
> in
> > > FMIPv6, but I do not agree that it holds as a general principle that
> a
> > > MN can determine the routing of its packets, as this would be in
> direct
> > > contradiction of basic Internet routing design principles.
> > >
> >
> > As I mentioned above, an end-point must control the destiny of its
> > packets, if not the way the packets get there (as you point out
> > above, there is a routing exception: source routing).
> >
> > In any case, I notice that FMIPv6 and BETH design points are somewhat
> > different (even though improved handover is the target) including
> > - who has the control in deciding when forwarding on the tunnel is
> >    activated
> > - whether the MN always keeps the old CoA (BETH) or it uses the
> >    new CoA or the old CoA (FMIPv6)
> > - whether L2 triggers are used (BETH) or IP messages are used (FMIPv6)
> >     for handover switching
> >
> > I think it makes sense to document these and others, at the very
> least.
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> >
> > >
> > >             jak
> >
> >



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 13:47:14 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29067
	for ; Thu, 25 Apr 2002 13:47:13 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23531;
	Thu, 25 Apr 2002 11:47:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03178;
	Thu, 25 Apr 2002 10:47:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PHk3Gs005582
	for ; Thu, 25 Apr 2002 10:46:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PHk3qM005580
	for mobile-ip-dist; Thu, 25 Apr 2002 10:46:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PHjuGs005543
	for ; Thu, 25 Apr 2002 10:45:56 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02443
	for ; Thu, 25 Apr 2002 10:45:55 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23322
	for ; Thu, 25 Apr 2002 11:45:55 -0600 (MDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3PHjuj27730
	for ; Thu, 25 Apr 2002 12:45:56 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 25 Apr 2002 12:43:42 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E035DEA7E@zrc2c012.us.nortel.com>
From: "Glenn Morrow"
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] MIP WG Page Goals and Milestones
Date: Thu, 25 Apr 2002 12:43:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EC80.BD0D0280"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EC80.BD0D0280
Content-Type: text/plain;
	charset="iso-8859-1"

Hello all,
 
I know this isn't technical but could someone please update the goals and
milestone's section of the WG charter with proposed target dates for IESG
submissions for all WG IDs.
 
Thanks,
 
Glenn

------_=_NextPart_001_01C1EC80.BD0D0280
Content-Type: text/html;
	charset="iso-8859-1"









Hello 
all,


 


I know this isn't 
technical but could someone please update the goals and milestone's section of 
the WG charter with proposed target dates for IESG submissions for all 
WG IDs.


 


Thanks,


 


Glenn


------_=_NextPart_001_01C1EC80.BD0D0280--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 13:49:45 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29233
	for ; Thu, 25 Apr 2002 13:49:45 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21391;
	Thu, 25 Apr 2002 10:49:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04543;
	Thu, 25 Apr 2002 10:49:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PHmPGs006256
	for ; Thu, 25 Apr 2002 10:48:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PHmPit006253
	for mobile-ip-dist; Thu, 25 Apr 2002 10:48:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PHmJGs006219
	for ; Thu, 25 Apr 2002 10:48:19 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25902
	for ; Thu, 25 Apr 2002 10:48:19 -0700 (PDT)
Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17084
	for ; Thu, 25 Apr 2002 10:48:18 -0700 (PDT)
Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245])
	by palrel12.hp.com (Postfix) with ESMTP id 8B621E00505
	for ; Thu, 25 Apr 2002 10:48:18 -0700 (PDT)
Received: (from jlau@localhost)
	by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id KAA15733;
	Thu, 25 Apr 2002 10:49:09 -0700 (PDT)
Date: Thu, 25 Apr 2002 10:49:09 -0700 (PDT)
From: Joe Lau 
Message-Id: <200204251749.KAA15733@strtio1.cup.hp.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Wirless interface with HUT's MIPv6 Mobile Node
In-Reply-To: <3CC83530.40F4CB65@iprg.nokia.com>
Cc: jlau@cup.hp.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello,

Has anyone used a wireless interface with HUT' MIPv6 Mobile Node? 
Thanks for the info.

Joe


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 13:55:11 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29420
	for ; Thu, 25 Apr 2002 13:55:10 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28127;
	Thu, 25 Apr 2002 11:55:10 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08739;
	Thu, 25 Apr 2002 10:55:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PHsGGs007838
	for ; Thu, 25 Apr 2002 10:54:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PHsGo3007837
	for mobile-ip-dist; Thu, 25 Apr 2002 10:54:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PHs8Gs007796
	for ; Thu, 25 Apr 2002 10:54:08 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29038
	for ; Thu, 25 Apr 2002 10:54:08 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20503
	for ; Thu, 25 Apr 2002 10:54:08 -0700 (PDT)
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 KAA19383;
	Thu, 25 Apr 2002 10:54:07 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PHs6D18550;
	Thu, 25 Apr 2002 10:54:06 -0700
X-mProtect: <200204251754> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdmiYjbY; Thu, 25 Apr 2002 10:54:04 PDT
Message-ID: <3CC842BD.A42F7D0F@iprg.nokia.com>
Date: Thu, 25 Apr 2002 10:54:05 -0700
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: keiichi@iij.ad.jp
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO
References: <20020425.184505.06470684.keiichi@iij.ad.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

hi Keiichi,

There was a discussion between Erik Normark and myself. I think
we concluded on something similar to the following. (correct me
if missed something, Erik).

HAO is processed if

  - if there is a BCE with CoA = IPv6 src and HoA = HAO content
  - if there is a home registration BCE with HoA = HAO content
  - if packet contains BU and satisfies the security policy
    between MN and HA 
  - if packet contains AH or ESP header and satisfies the security
    policy check between MN and HA.

The last two bullets could be combined into one. And then it 
becomes the IPsec check that Francis is talking about.

Vijay



Keiichi SHIMA / $BEg7D0l(B wrote:
> 
> Hi,
> 
> May I ask a question about processing a HAO?  I think the processing
> is difficult to implement.  I will try to explain why it is difficult.
> 
> The latest discussion concludes that a HAO must not be processed
> without a valid BCE.  Also, the BU/BA for the home registration must
> be protected by the ESP.
> 
> 1. The home registration.
> 
> The BU/BA for home registration must be protected by the ESP.  To do
> this, the HA and the MN must have the SA and the SPD properly.  For
> example,
> 
> On HA:  SA1: HA, MN_HoA, ESP
>         SA2: MN_HoA, HA, ESP
>         SPD: HA -> MN_HoA, MH, ESP
> 
> On MH:  SA1: HA, MN_HoA, ESP
>         SA2: MN_HoA, HA, ESP
>         SPD: MN_HoA -> HA, MH, ESP
> 
> Since we use a MN_HoA as a endpoint of the SA and the SPD, the BU/BA
> for the home registration packet must include a HAO.
> 
> 2. Dropping a packet which contains a HAO without a valid BCE.
> 
> The CN must drop packets which contain a HAO without a valid BCE.  The
> HA is also a CN.  When processing a BU from a MN, a HA first encounts
> a HAO.  Since the HA doesn't have a BCE for the MN, the BU is dropped.
> 
> Conclusion: the home registration never be processed.
> 
> Condideration:
> 
> - Using MN_CoA as an endpoint of the SA/SPD:
> 
> Using MN_CoA makes it possible to remove a HAO from a BU.  But, if we
> use a MN_CoA, the SA entry and the SPD entry must be updated at each
> time when the MN moves.  In addision, it requires some SA
> establishment mechanism because the HA never know the new CoA that the
> MN gets on the newly visited foreign network.  It seems unrealistic.
> 
> - Introduce a flag that indicates 'I saw a HAO'.
> 
> Instead of dorpping the packet which contains a HAO without a valid
> BCE immediately, just set a flag that means this packet has a HAO.
> After all extension headers are processed, check the BCEs.  If we have
> no BCE corresponding to the HAO, we drop the packet.
> 
> This method works except one inappropliate behaviour.  If the packet
> has other exthdr/DOs after a HAO, the exthdr/DOs are processed.
> Obviously, those exthdrs/DOs must not be processed because the packets
> that has a HAO without a valid BCE must be dropped.
> 
> How do you think about this?
> 
> If I am missing something, please correct me.
> 
> ---
> Keiichi SHIMA
> IIJ Research Laboratory 
> KAME Project 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 13:58:57 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29618
	for ; Thu, 25 Apr 2002 13:58:56 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28179;
	Thu, 25 Apr 2002 10:58:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11425;
	Thu, 25 Apr 2002 10:58:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PHvJGs008671
	for ; Thu, 25 Apr 2002 10:57:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PHvJGU008664
	for mobile-ip-dist; Thu, 25 Apr 2002 10:57:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PHvDGs008639
	for ; Thu, 25 Apr 2002 10:57:14 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10429
	for ; Thu, 25 Apr 2002 10:57:13 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29474
	for ; Thu, 25 Apr 2002 11:57:12 -0600 (MDT)
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 KAA19625;
	Thu, 25 Apr 2002 10:57:12 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PHvBj24129;
	Thu, 25 Apr 2002 10:57:11 -0700
X-mProtect: <200204251757> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdzJXhNg; Thu, 25 Apr 2002 10:57:09 PDT
Message-ID: <3CC84375.86815E69@iprg.nokia.com>
Date: Thu, 25 Apr 2002 10:57:09 -0700
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: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO
References: <20020425.184505.06470684.keiichi@iij.ad.jp> <3CC842BD.A42F7D0F@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

And of course, assuming the SPD/SAD uses MN's HoA always.

Vijay

Vijay Devarapalli wrote:
> 
> hi Keiichi,
> 
> There was a discussion between Erik Normark and myself. I think
> we concluded on something similar to the following. (correct me
> if missed something, Erik).
> 
> HAO is processed if
> 
>   - if there is a BCE with CoA = IPv6 src and HoA = HAO content
>   - if there is a home registration BCE with HoA = HAO content
>   - if packet contains BU and satisfies the security policy
>     between MN and HA
>   - if packet contains AH or ESP header and satisfies the security
>     policy check between MN and HA.
> 
> The last two bullets could be combined into one. And then it
> becomes the IPsec check that Francis is talking about.
> 
> Vijay
> 
> Keiichi SHIMA / $BEg7D0l(B wrote:
> >
> > Hi,
> >
> > May I ask a question about processing a HAO?  I think the processing
> > is difficult to implement.  I will try to explain why it is difficult.
> >
> > The latest discussion concludes that a HAO must not be processed
> > without a valid BCE.  Also, the BU/BA for the home registration must
> > be protected by the ESP.
> >
> > 1. The home registration.
> >
> > The BU/BA for home registration must be protected by the ESP.  To do
> > this, the HA and the MN must have the SA and the SPD properly.  For
> > example,
> >
> > On HA:  SA1: HA, MN_HoA, ESP
> >         SA2: MN_HoA, HA, ESP
> >         SPD: HA -> MN_HoA, MH, ESP
> >
> > On MH:  SA1: HA, MN_HoA, ESP
> >         SA2: MN_HoA, HA, ESP
> >         SPD: MN_HoA -> HA, MH, ESP
> >
> > Since we use a MN_HoA as a endpoint of the SA and the SPD, the BU/BA
> > for the home registration packet must include a HAO.
> >
> > 2. Dropping a packet which contains a HAO without a valid BCE.
> >
> > The CN must drop packets which contain a HAO without a valid BCE.  The
> > HA is also a CN.  When processing a BU from a MN, a HA first encounts
> > a HAO.  Since the HA doesn't have a BCE for the MN, the BU is dropped.
> >
> > Conclusion: the home registration never be processed.
> >
> > Condideration:
> >
> > - Using MN_CoA as an endpoint of the SA/SPD:
> >
> > Using MN_CoA makes it possible to remove a HAO from a BU.  But, if we
> > use a MN_CoA, the SA entry and the SPD entry must be updated at each
> > time when the MN moves.  In addision, it requires some SA
> > establishment mechanism because the HA never know the new CoA that the
> > MN gets on the newly visited foreign network.  It seems unrealistic.
> >
> > - Introduce a flag that indicates 'I saw a HAO'.
> >
> > Instead of dorpping the packet which contains a HAO without a valid
> > BCE immediately, just set a flag that means this packet has a HAO.
> > After all extension headers are processed, check the BCEs.  If we have
> > no BCE corresponding to the HAO, we drop the packet.
> >
> > This method works except one inappropliate behaviour.  If the packet
> > has other exthdr/DOs after a HAO, the exthdr/DOs are processed.
> > Obviously, those exthdrs/DOs must not be processed because the packets
> > that has a HAO without a valid BCE must be dropped.
> >
> > How do you think about this?
> >
> > If I am missing something, please correct me.
> >
> > ---
> > Keiichi SHIMA
> > IIJ Research Laboratory 
> > KAME Project 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 14:03:58 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29901
	for ; Thu, 25 Apr 2002 14:03:58 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04203;
	Thu, 25 Apr 2002 12:03:58 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15152;
	Thu, 25 Apr 2002 11:03:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PI30Gs010247
	for ; Thu, 25 Apr 2002 11:03:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PI30fr010240
	for mobile-ip-dist; Thu, 25 Apr 2002 11:03:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PI2tGs010219
	for ; Thu, 25 Apr 2002 11:02:55 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29134
	for ; Thu, 25 Apr 2002 11:02:54 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25892
	for ; Thu, 25 Apr 2002 11:02:54 -0700 (PDT)
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 LAA19967;
	Thu, 25 Apr 2002 11:02:53 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PI2pv01737;
	Thu, 25 Apr 2002 11:02:51 -0700
X-mProtect: <200204251802> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdY11ocD; Thu, 25 Apr 2002 11:02:49 PDT
Message-ID: <3CC844C9.8F05F405@iprg.nokia.com>
Date: Thu, 25 Apr 2002 11:02:49 -0700
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas 
CC: James Kempf ,
        "Alper E. YEGIN" ,
        Manolis Sifalakis ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
References: <3CB5DB1F.90909@lancaster.ac.uk>
		<012801c1e198$1fcb99c0$7e6015ac@T23KEMPF>
		<3CBDBC62.21C19B77@iprg.nokia.com>
		<000001c1e7b6$9288fd80$746015ac@T23KEMPF>
		<3CC0B44C.DB862958@iprg.nokia.com>
		<046701c1e804$7016f330$736015ac@AlperVAIO>
		<3CC58E3C.86B <3CC5CA61.E210D29F@iprg.nokia.com>
		<00c401c1eb69$25179340$b36015ac@T23KEMPF>
		<15558.58813.157282.992826@thomasm-u1.cisco.com>
		<00c101c1ec33$a51c7f40$b36015ac@T23KEMPF> <15559.64857.612244.267865@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:

> James Kempf writes:
>  > Hi Michael,
>  >
>  > Your analysis is correct if the mobile node knows that a handover is
>  > occuring. I probably didn't make this clear enough, but as I mentioned,
>  > IP hosts have always had the option of choosing their default router,
>  > and if they becme aware that this router is changing, they should have
>  > the option of choosing a new one. Security, to the extent it is possible
>  > with currently unsecured protocols such as ND, should of course also
>  > play a role as you describe.
>  >
>  > I was objecting to what I detected  in Rajeev's note that this must
>  > always be the case, even when the mobile did not have any knowledge that
>  > the handover was occuring. In my view, this corresponds to a failure of
>  > a router in the network.
>  >
>  > Which occurs depends on how much informatoin is made available to which
>  > entity by the wireless protocol.
>
>    Yes, I understand where you're coming from, but
>    my gut level feeling is that Rajeev is right to
>    be suspicious because the issues don't seem to be
>    100% parallel. What this seems like to me --
>    and I might be in left field here -- is
>    something more akin to ICMP REDIRECT. That is,
>    I'd like you to move elsewhere because it's a
>    better route. But in the REDIRECT case, the
>    node doesn't have to actually honor it; after a
>    few retries, the router gives up and assumes
>    they won't move. This isn't entirely unlike
>    another scenario where a router has dynamic metrics
>    which for whatever reason it just ignores (say
>    it has a static route too).
>

Interesting analogy. Some more thoughts..

- in the REDIRECT case or more generally the
   network-triggered case, the MN is informed and
   the MN has the option to disregard it as opposed to
   unilaterally deciding the destination for MN's packets.
   This is a crucial point.
- if the knowledge that MN is about to "lose its link"
   resides exclusively at the network, the network can
   _still_ provide such an indication to the MN, e.g., via
   ProxyRtAdv in FMIPv6 or REDIRECT. [coincidentally, we
   used REDIRECT for network-triggered handover
   in our version of the fast handover draft back
   in October 2000]. If such a knowledge resides exclusively
   at the MN, the MN can always solicit a move and then
   authorize it. In either case, the MN _can_ be (and should be)
   given the token to authorize redirection.
- if notification fails (e.g., due to bad terrain), there is
   standard MIP with the possibility of
   siphoning packets from the previous AR.



>
>    Thus to my mind, the nature of these changes
>    are *cooperative* on a hop-by-hop basis. That
>    is, I'd like you to do something and you
>    oblige. Therefore, if it makes sense in this
>

Good point. If the MN does not engage, then it
won't gain and might lose.

>    case -- and I'm not sure because which piqued
>    my interest here was the Internet gestalt -- it
>    does seem that to mimic the current net, the
>    exchange needs to be "may I? yes, please do"
>    which sort of favors Rajeev's contention that
>    it must be authorized by the MN. The reason
>    is because the MN ultimately needs to
>    participate in the move (eg, retune its radio,
>    etc), right?

Right.

Regards,

-Rajeev

ps. BTW, is there a version of Redirect for
      renumbering with an alert option ?


>
>
>                 Mike



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 15:23:23 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02955
	for ; Thu, 25 Apr 2002 15:23:20 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00726;
	Thu, 25 Apr 2002 12:22:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16278;
	Thu, 25 Apr 2002 12:22:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PJLTGs007604
	for ; Thu, 25 Apr 2002 12:21:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PJLTvs007599
	for mobile-ip-dist; Thu, 25 Apr 2002 12:21:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PJLMGs007559
	for ; Thu, 25 Apr 2002 12:21:22 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15764
	for ; Thu, 25 Apr 2002 12:21:22 -0700 (PDT)
Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA15635
	for ; Thu, 25 Apr 2002 13:21:21 -0600 (MDT)
Received: from unknown (HELO EmadQ) (emadaq@217.144.4.164 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Apr 2002 19:21:18 -0000
Reply-To: 
From: "Emad Qadoura" 
To: 
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Thu, 25 Apr 2002 22:20:50 +0200
Message-ID: <000001c1ec96$b5cf8450$a40490d9@EmadQ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <3CC82CA7.78332B19@iprg.nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Charlie,

I have the following Qs:

1) Do you have a link of where I can find such
publications/Simulations/Implementations? Also having them in a
reference like section would be a good idea?

2) In practice, what would be the likely/suggested size of the domain
(the size of the coverage area) for a GFA? an example considering
wireless networks would be helpful?

3) If the coverage area is large, and the home network does provide
personalized content services based on the mobile node's location
requiring a finer location, would you expect this feature to be always
turned off?

4) Did a prior bakeoff include this draft?

Regards,
EQ

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Charles E.
Perkins
Sent: Thursday, April 25, 2002 6:20 PM
To: Madhavi W. Chandra
Cc: Annika Jonsson; mobile-ip@sunroof.eng.sun.com; Eva Gustafsson
Subject: Re: [mobile-ip] WG Last Call:
draft-ietf-mobileip-reg-tunnel-06.txt

Hello Madhavi,

"Madhavi W. Chandra" wrote:

> There is no doubt that your draft is the result of extensive
> research.

In this case, we also have publications, simulations, and
implementations to back up the research.

>             Perhaps if we included a section in the draft
> that outlined the scenarios that would benefit from the
> implementation and added text in the Intro/Abstract to indicate
> clearly that this design is OPTIONAL, it would be more apparent
> that the architecture need not be implemented.  It would also
> be clear under what circumstances one would want to implement
> this design.  I would also suggest a section on synergies
> with Fast Handoffs...to explain the interaction, or separation.

I think this would be great.  I would locate the synergy section
in another Appendix.  I would locate the optionality statement
and scenario description in the first part of the document,
probably within section 3 (perhaps section 3.1).

> We can certainly help you with text.  I think this is
> independent of the draft status...experimental or not.

I hope I am not speaking out of line before consulting my
co-authors, but for myself I would quite appreciate your
help.

Regards,
Charlie P.



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 17:51:40 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07394
	for ; Thu, 25 Apr 2002 17:51:39 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08294;
	Thu, 25 Apr 2002 14:51:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20493;
	Thu, 25 Apr 2002 14:50:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PLnoGs024495
	for ; Thu, 25 Apr 2002 14:49:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PLnnPF024493
	for mobile-ip-dist; Thu, 25 Apr 2002 14:49:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PLneGs024440
	for ; Thu, 25 Apr 2002 14:49:40 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21727
	for ; Thu, 25 Apr 2002 14:49:39 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13268
	for ; Thu, 25 Apr 2002 15:49:38 -0600 (MDT)
Message-ID: <007601c1eca2$d981bce0$8e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Charles E. Perkins" ,
        "Madhavi W. Chandra" 
Cc: "Annika Jonsson" ,
        ,
        "Eva Gustafsson" 
References:  <3CC818C0.1E628F82@iprg.nokia.com> <20020425121142.A7334@cisco.com> <3CC82CA7.78332B19@iprg.nokia.com>
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Thu, 25 Apr 2002 14:47:47 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Charlie,

> > There is no doubt that your draft is the result of extensive
> > research.
> 
> In this case, we also have publications, simulations, and
> implementations to back up the research.
> 

Did your simulations look at what happened if a GFA fails?

            jak




From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 18:29:48 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08167
	for ; Thu, 25 Apr 2002 18:29:48 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29991;
	Thu, 25 Apr 2002 16:29:48 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09194;
	Thu, 25 Apr 2002 15:29:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PMStGs025596
	for ; Thu, 25 Apr 2002 15:28:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PMStLZ025595
	for mobile-ip-dist; Thu, 25 Apr 2002 15:28:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PMSqGs025588
	for ; Thu, 25 Apr 2002 15:28:52 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06866
	for ; Thu, 25 Apr 2002 15:28:52 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29606
	for ; Thu, 25 Apr 2002 16:28:51 -0600 (MDT)
Message-ID: <00c501c1eca8$5368c300$8e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Rajeev Koodli" , "Michael Thomas" 
Cc: 
References: <3CB5DB1F.90909@lancaster.ac.uk>	<012801c1e198$1fcb99c0$7e6015ac@T23KEMPF>	<3CBDBC62.21C19B77@iprg.nokia.com>	<000001c1e7b6$9288fd80$746015ac@T23KEMPF>	<3CC0B44C.DB862958@iprg.nokia.com>	<046701c1e804$7016f330$736015ac@AlperVAIO>	<3CC58E3C.86B <3CC5CA61.E210D29F@iprg.nokia.com>	<00c401c1eb69$25179340$b36015ac@T23KEMPF>	<15558.58813.157282.992826@thomasm-u1.cisco.com>	<00c101c1ec33$a51c7f40$b36015ac@T23KEMPF> <15559.64857.612244.267865@thomasm-u1.cisco.com> <3CC844C9.8F05F405@iprg.nokia.com>
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
Date: Thu, 25 Apr 2002 15:25:11 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Michael/Rajeev,

I understand the desire to get the mobile involved in making the
handover decision, but there really is a problem if you are concerned
about reliable performance improvement. If reliability is not a concern,
then signaling the mobile over the air prior to the handover and letting
it decide is clearly the right way to go.

If you are concerned about reliable performance (such as might be needed
to do VoIP), then there is an issue with any signaling to the mobile
getting cut off prior to the mobile's moving. We've done some simulation
work on the FMIPv4 algorithms, and, together with Motorola, have
implemented them on 802.11b and IS-2000 RAN. The Prereg algorithm
(analogous to the original FMIPv6 algorithm) performs poorly in
comparision to the Postreg algorithm (like BETH) on IS-2000 RAN because
sometimes the initial signaling between the access router and the mobile
node gets cut off, This occurs if the mobile node moves before the
signaling can complete.

If the mobile node has enough time for signaling to complete between the
prehandover trigger informing it that a handover is pending and the time
at which the actual Layer 2 handover occurs, then it can achieve
performance equal to that achieved when the access router simply
switches the routing without consulting the mobile node. However, radio
conditions around handover are always dicey (since, otherwise, the
mobile node wouldn't be handing over) and the mobile node may speed up.
As a result, the actual prehandover trigger time is really a random
variable, and it could end up being too short. In that case, the mobile
node must recover on the new access router by using standard Mobile IP,
during which time its traffic on the old access router is dropped. So,
if a prehandover trigger is available on the access router, reliability
is improved by starting the tunnel, then having the mobile node fix up
things afterwards if it doesn't happen to like the access router on
which it is located.

Another alternative which works about equally as well, if there is no
prehandover trigger available on the access router, but the mobile node
does obtain a trigger on the new link when the link comes up, is for the
mobile to initiate the tunnel itself after the link switch. In this
case, the mobile is involved, but it takes longer.

Smoothing (buffering or bicasting) is also possible, but our experiments
on IS-2000 RAN indicated that an average of between 1 and 2 packets were
dropped if the access router just switched on the tunnel. The traffic
generator we were using was simulating real time traffic. A drop rate of
1 to 2 packets (with 20 ms packet interarrival time) would probably not
be noticed with voice, so it hardly seems worth it to introduce
smoothing, though it might be for other traffic or if no predictive
information was available in the network.

Of course, none of this matters if one is not concerned with reliable
real time performance suitable for replacing current circuit switched
cellular with VoIP (as I am). I can send you some slides with
preliminary measurments. We are continuing measurements on FMIPv4 (I'd
like to do some statistics on the results) and will be attempting the
same kinds of measurements on FMIPv6.

                    jak

----- Original Message -----
From: "Rajeev Koodli" 
To: "Michael Thomas" 
Cc: "James Kempf" ; "Alper E. YEGIN"
; "Manolis Sifalakis"
; 
Sent: Thursday, April 25, 2002 11:02 AM
Subject: Re: [mobile-ip] some questions about
draft-ietf-mobileip-fast-mipv6-04


> Michael Thomas wrote:
>
> > James Kempf writes:
> >  > Hi Michael,
> >  >
> >  > Your analysis is correct if the mobile node knows that a handover
is
> >  > occuring. I probably didn't make this clear enough, but as I
mentioned,
> >  > IP hosts have always had the option of choosing their default
router,
> >  > and if they becme aware that this router is changing, they should
have
> >  > the option of choosing a new one. Security, to the extent it is
possible
> >  > with currently unsecured protocols such as ND, should of course
also
> >  > play a role as you describe.
> >  >
> >  > I was objecting to what I detected  in Rajeev's note that this
must
> >  > always be the case, even when the mobile did not have any
knowledge that
> >  > the handover was occuring. In my view, this corresponds to a
failure of
> >  > a router in the network.
> >  >
> >  > Which occurs depends on how much informatoin is made available to
which
> >  > entity by the wireless protocol.
> >
> >    Yes, I understand where you're coming from, but
> >    my gut level feeling is that Rajeev is right to
> >    be suspicious because the issues don't seem to be
> >    100% parallel. What this seems like to me --
> >    and I might be in left field here -- is
> >    something more akin to ICMP REDIRECT. That is,
> >    I'd like you to move elsewhere because it's a
> >    better route. But in the REDIRECT case, the
> >    node doesn't have to actually honor it; after a
> >    few retries, the router gives up and assumes
> >    they won't move. This isn't entirely unlike
> >    another scenario where a router has dynamic metrics
> >    which for whatever reason it just ignores (say
> >    it has a static route too).
> >
>
> Interesting analogy. Some more thoughts..
>
> - in the REDIRECT case or more generally the
>    network-triggered case, the MN is informed and
>    the MN has the option to disregard it as opposed to
>    unilaterally deciding the destination for MN's packets.
>    This is a crucial point.
> - if the knowledge that MN is about to "lose its link"
>    resides exclusively at the network, the network can
>    _still_ provide such an indication to the MN, e.g., via
>    ProxyRtAdv in FMIPv6 or REDIRECT. [coincidentally, we
>    used REDIRECT for network-triggered handover
>    in our version of the fast handover draft back
>    in October 2000]. If such a knowledge resides exclusively
>    at the MN, the MN can always solicit a move and then
>    authorize it. In either case, the MN _can_ be (and should be)
>    given the token to authorize redirection.
> - if notification fails (e.g., due to bad terrain), there is
>    standard MIP with the possibility of
>    siphoning packets from the previous AR.
>
>
>
> >
> >    Thus to my mind, the nature of these changes
> >    are *cooperative* on a hop-by-hop basis. That
> >    is, I'd like you to do something and you
> >    oblige. Therefore, if it makes sense in this
> >
>
> Good point. If the MN does not engage, then it
> won't gain and might lose.
>
> >    case -- and I'm not sure because which piqued
> >    my interest here was the Internet gestalt -- it
> >    does seem that to mimic the current net, the
> >    exchange needs to be "may I? yes, please do"
> >    which sort of favors Rajeev's contention that
> >    it must be authorized by the MN. The reason
> >    is because the MN ultimately needs to
> >    participate in the move (eg, retune its radio,
> >    etc), right?
>
> Right.
>
> Regards,
>
> -Rajeev
>
> ps. BTW, is there a version of Redirect for
>       renumbering with an alert option ?
>
>
> >
> >
> >                 Mike
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 18:47:01 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08406
	for ; Thu, 25 Apr 2002 18:47:01 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08002;
	Thu, 25 Apr 2002 16:47:03 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17005;
	Thu, 25 Apr 2002 15:46:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PMjvGs025714
	for ; Thu, 25 Apr 2002 15:45:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PMjvLJ025713
	for mobile-ip-dist; Thu, 25 Apr 2002 15:45:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PMjrGs025706
	for ; Thu, 25 Apr 2002 15:45:53 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18114
	for ; Thu, 25 Apr 2002 18:45:48 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA02037
	for mobile-ip@sunroof.eng.sun.com; Thu, 25 Apr 2002 18:46:48 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PIsIGs028239
	for ; Thu, 25 Apr 2002 11:54:18 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03237
	for ; Thu, 25 Apr 2002 11:53:21 -0700 (PDT)
Received: from ext-nj2gw-2.online-age.net (ext-nj2gw-2.online-age.net [216.35.73.164])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27474
	for ; Thu, 25 Apr 2002 11:53:21 -0700 (PDT)
Received: from int-nj2gw-4.online-age.net (int-nj2gw-4 [3.159.236.68])
	by ext-nj2gw-2.online-age.net (8.9.3+Sun/8.9.1/990426-RLH) with ESMTP id OAA15258;
	Thu, 25 Apr 2002 14:53:00 -0400 (EDT)
Received: from crdns.crd.ge.com (localhost [127.0.0.1])
	by int-nj2gw-4.online-age.net (8.9.3+Sun/8.9.1/990426-RLH) with ESMTP id OAA06571;
	Thu, 25 Apr 2002 14:52:38 -0400 (EDT)
Received: from exc01crdge.crd.ge.com (exc01crdge.crd.ge.com [3.1.116.47])
	by crdns.crd.ge.com (8.11.6/8.11.6) with ESMTP id g3PIqaY07327;
	Thu, 25 Apr 2002 14:52:36 -0400 (EDT)
Received: by exc01crdge.crd.ge.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 25 Apr 2002 14:52:36 -0400
Message-ID: 
From: "Bush, Stephen F (Research)" 
To: "'ipgroup@sprintlabs.com'" ,
        "'ippm@advanced.org'" ,
        "'isadsoc@fokus.gmd.de'"
	 ,
        "'iscc2000@infres.enst.fr'"
	 ,
        "'issll@mercury.lcs.mit.edu'"
	 ,
        "'itc@comsoc.org'" , "'itc@ieee.org'" ,
        "'iwqos@comsoc.org'" ,
        "'jajszcz@kt.agh.edu.pl'" ,
        "'jean-pierre.hubaux@epfl.ch'" ,
        "'jros@cs.up.ac.za'" ,
        "'kamoun@ensi.rnrt.tn'"
	 ,
        "'karmouch@elg.uottawa.ca'"
	 ,
        "'kgold@firstconf.com'" ,
        "'klusch@dfki.de'" ,
        "'kuvs-elg@fokus.gmd.de'"
	 ,
        "'labetoul@eurecom.fr'" ,
        "'lists-mbone-eu-op-out@postman.ripe.net'"
	 ,
        "'Mail-distributor@KOM.th-darmstadt.de'"
	 ,
        "'manet@itd.nrl.navy.mil'"
	 ,
        "'mazum@research.bell-labs.com'"
	 ,
        "'mbone-eu-op@ripe.net'"
	 ,
        "'mobile-ip@sunroof.eng.sun.com'"
	 ,
        "'mobile-ip@tadpole.coms'"
	 ,
        "'mobility@anubis.CS.UMBC.EDU'"
	 ,
        "'mobility@media.mit.edu'"
	 ,
        "'modern-heuristics@uk.ac.mailbase'"
	 ,
        "'multicomm@research.panasonic.com'"
	 ,
        "'netnomics@eco.utexas.edu'"
	 ,
        "'news-announce-conferences@uunet.uu.net'"
	 ,
        "'nichains@bxl.dg13.cec.eu.int'" ,
        "'odp@dstc.edu.au'" ,
        "'opensig-announce@comet.columbia.edu'"
	 ,
        "'orctrans@loria.fr'"
	 ,
        "'osimcast@BBN.COM'" ,
        "'owner-int-serv@ISI.EDU'" ,
        "'performance@haven.csm.ornl.gov'" ,
        "'performance@haven.epm.ornl.gov'" ,
        "'personnel.dsc@epfl.ch'" ,
        "'podc@research.telcordia.com'" ,
        "'prosoft@iro.umontreal.ca'" ,
        "'raf@loria.fr'"
	 ,
        "'Ralph.Steinmetz@KOM.tu-darmstadt.de'"
	 ,
        "'rboutaba@bbcr.uwaterloo.ca'"
	 ,
        "'rem-conf@es.net'" ,
        "'request-datacom@comsoc.org'" ,
        "'reres@laas.fr'" , "'RHDM@lip6.fr'" ,
        "'rm@openmash.org'" ,
        "'Roberto.Saracco@cselt.stet.it'"
	 ,
        "'rsvp@ISI.EDU'" ,
        "'salah@rss.dl.nec.com'" ,
        "'seminar@cse.cuhk.edu.hk'" ,
        "'SIGCOMM-MEMBERS@acm.org'" ,
        "'sigmedia@bellcore.com'" ,
        "'sigmetrics-bb@haven.epm.ornl.gov'" ,
        "'SIGMOB@acm.org'" ,
        "'SIGSIM@ACM.ORG'" ,
        "'Simon.Znaty@enst-bretagne.fr'" ,
        "'sousa@comm.utoronto.ca'" ,
        "'spects02@comp.leeds.ac.uk'" ,
        "'stadler@ctr.columbia.edu'" ,
        "'stds-802-jt11-15@ieee.org'" ,
        "'stds-802-wpan@ieee.org'" ,
        "'swim99@silo.csci.unt.edu'" ,
        "'tccc@cosmos.cs.columbia.edu'" ,
        "'tccc@ieee.org'" , "'tcgn@ieee.org'" ,
        "'tci-announce@computer.org'" ,
        "'tcii@ain3.kyungpook.ac.kr'" ,
        "'tcp-impl@lerc.nasa.gov'" ,
        "'tcpsat@lerc.nasa.gov'" ,
        "'tfiw-announce@akalice.research.att.com'"
	 ,
        "'webrepl@cs.utk.edu'"
	 ,
        "'wz@prosun.first.gmd.de'"
	 ,
        "'xtp-relay@cs.concordia.ca'"
	 ,
        "'Yves.Raynaud@irit.fr'"
	 
Subject: [mobile-ip] CFP: Complexity Theory and its Applications to Systems, Networks 
	and Information Assurance
Date: Thu, 25 Apr 2002 14:52:23 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Apologies for multiple copies...

Final Call for Papers - Systemics, Cybernetics and Informatics (SCI) 2002

	COMPLEXITY AND ALGORITHMIC INFORMATION THEORY WITH APPLICATION TO SYSTEMS, NETWORKS, 
						AND INFORMATION ASSURANCE

Amit B. Kulkarni and Stephen F. Bush (General Electric Global Research Center) are organizing 
a special session for SCI-2002 titled "Complexity Theory and its Applications to Systems, 
Networks and Information Assurance".

This session seeks to consolidate research in the areas of modeling, management, and security in
systems and networks with the large and growing body of work in Complexity and Algorithmic
Information 
Theory. The goal of this session is to compare traditional state-of-the-art methods with new advances

incorporating Complexity-based or Algorithmic Information methods and discuss their applications to
the 
health, management, and security of information systems. We invite you to submit papers to the
session 
on topics that can include, but are not limited to, the following:

EXAMPLE OF RELEVANT SESSION TOPICS:

*	Fundamental Relationships between Computation and Communication 
*	Controlled Access of Information, System Vulnerability Detection and Policy Enforcement
*	Quantification and Security Metrics
*	Self-Organization and Composition of System Solutions 
*	Applications of 'Physics Of Information' to Information Systems 
*	Case Studies Involving the Use of Complexity in Information Systems
*	Advances in Estimation and Measurement of Complexity
*	Novel Definitions of Complexity with Emphasis on Implementation Feasibility and Facilitation
	of System Health
*	Quantitative Comparison and Contrast of Complexity Estimators

If you are interested in contributing a paper to the session, please email kulkarni@crd.ge.com
 or bushsf@crd.ge.com  the full paper or 
extended abstract by midnight June 30. [Note: new deadline]

The main conference call for papers follows:

THE 6th WORLD MULTI CONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS SCI 2002

July 14 - 18, 2002

Orlando, Florida, USA
Sheraton World

http://www.iiis.org/sci2002/

Honorary Presidents: Bela Banathy, Stafford Beer and George Klir
Program Committee Chair: William Lesso
General Chair: Nagib Callaos
Organizing Committee Chair: Belkis Sanchez

Stephen F Bush (http://www.crd.ge.com/~bushsf/ftn)


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 19:35:50 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09039
	for ; Thu, 25 Apr 2002 19:35:50 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26134;
	Thu, 25 Apr 2002 17:35:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01780;
	Thu, 25 Apr 2002 16:35:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PNYMGs008355
	for ; Thu, 25 Apr 2002 16:34:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3PNYMpG008354
	for mobile-ip-dist; Thu, 25 Apr 2002 16:34:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3PNYEGs008301
	for ; Thu, 25 Apr 2002 16:34:14 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01179
	for ; Thu, 25 Apr 2002 16:34:15 -0700 (PDT)
Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25346
	for ; Thu, 25 Apr 2002 17:34:13 -0600 (MDT)
Received: from kapow.its.monash.edu.au ([130.194.1.71])
 by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306)
 with ESMTP id <01KH0JGTS8PM8Y57TT@vaxh.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Fri, 26 Apr 2002 09:33:57 +1000
Received: from kapow (unknown [127.0.0.1])	by localhost (Postfix)
 with ESMTP	id CC07A20006; Thu, 25 Apr 2002 23:33:55 +0000 (/etc/localtime)
Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189])
	by kapow.its.monash.edu.au (Postfix) with ESMTP	id 11BB420006; Fri,
 26 Apr 2002 09:33:51 +1000 (EST)
Date: Fri, 26 Apr 2002 09:33:41 +1000
From: Greg Daley 
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality
To: Francis Dupont 
Cc: rene.purnadi@nokia.com, brett.pentland@eng.monash.edu.au,
        kempf@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com
Reply-to: greg.daley@eng.monash.edu.au
Message-id: <3CC89255.2C3CA90A@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <200204241041.g3OAfUT69047@givry.rennes.enst-bretagne.fr>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7BIT

Hi Francis,

Some comments are inline.
(also some reformatting done to clarify comment origin).

Francis Dupont wrote:
> 
>    I know of several systems where the L2
>    Access Point is not an IP device, and therefore
>    cannot participate in L3 connectivity (even if it
>    knows about a new association).
> 
> => this is (with possible very high arrival rate) 
> => the only issue in the scheme I propose. 
> => But there are already some cases where
> => the L2 access point has to participate to
> => L3 stuff:
> => - AAA (insecure networks are not so popular :-)
> => - many xxx handover enhancements (to trigger RA
> =>   sending is in fact the first step of
> =>   possible enhancements).

[GD]: I agree that many L2 Wireless APs today have IP
[GD]: Function (and that AAA may be somewhat important :)
[GD]: but this does not mean that an AP is necessarily
[GD]: deployed as the L3 router for any of their links.
[GD]: Therefore they cannot send the RA on their own
[GD]: behalf (As L2 devices rather than as router function).

>    If there is intelligence in the network to assist
>    with sending RA's, then I'm happy for that effort to
>    be explored,
> 
> => we agree about this, and perhaps we agree too
> => about the superiority of this approach over
> => fast RS/RA one.

[GD]: I'm not sure I'd say that yet, my workmates
[GD]: have been using fast RS/RA here...
[GD]: Certainly there is worth in determining 
[GD]: how the network may speed knowledge of handover
[GD]: especially if there is not prior knowledge from
[GD]: the previous access network.
 
>    but it is not a viable method for some
>    widely deployed technologies.
> 
> => you have to give concrete examples and don't
> => forget that if currentIEEE 802.11 networks
> => have no deployed good AAA the reason is the 
> => lack of available solutions, and this hole
> => is being filled very quickly.
> =>  (for instance if you use LEAP, the radius
> =>  server can trigger the RA, in fact if you
> =>  use address filtering (very common!) the
> =>  radius server is used in order to punch
> =>  holes in filters (messages with the AP for
> =>  MAC filters, with the firewall for IP
> =>  filters, etc). A very easy way to implement
> =>  my proposal is to put the radius server on
> =>  the same link than the AP and the MN and 
> =>  to send a RS from it).

[GD]: I have to admit that the technologies I was
[GD]: most concerned with were 802.X networks
[GD]: (particularly Ethernet and 802.11).
[GD]: It may take a long time to get LEAP/RADIUS into
[GD]: deployed Ethernet networks...
[GD]: Regarding use of LEAP/RADIUS, I cannot see how
[GD]: the RADIUS responses would apply to any other 
[GD]: host than the AP (i.e. the access router), so even
[GD]: if the appropriate filters are set, the AR still 
[GD]: will wait a random delay (under today's standard)
[GD]: before the response RA is sent (multicast or 
[GD]: to the AP?)

[GD]: I think that a router would still have to respond
[GD]: (possibly selectively) to RS's in an expedited way.
[GD]: Erik's viewpoint that there not be special
[GD]: signalling for fast RS/RA could be coupled with a
[GD]: statement that administrators may configure routers
[GD]: to respond to only certain L3/L2 address pairs
[GD]: quickly (perhaps sent with AH).

[GD]: this situation could obviously be collapsed if
[GD]: the AR is the AP, so that when L2 comes up, an RA
[GD]: would be sent immediately.

[GD]: As an aside, I would never advise people to put
[GD]: an AAA server on an access network, if at all
[GD]: possible.

Greg Daley



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 22:04:33 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12194
	for ; Thu, 25 Apr 2002 22:04:32 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02031;
	Thu, 25 Apr 2002 20:04:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17744;
	Thu, 25 Apr 2002 19:04:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q22pGs007868
	for ; Thu, 25 Apr 2002 19:02:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q22oXO007866
	for mobile-ip-dist; Thu, 25 Apr 2002 19:02:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q22fGs007804
	for ; Thu, 25 Apr 2002 19:02:41 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24866
	for ; Thu, 25 Apr 2002 19:02:41 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA01129
	for ; Thu, 25 Apr 2002 20:02:41 -0600 (MDT)
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 TAA16421;
	Thu, 25 Apr 2002 19:02:40 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3Q22cK07971;
	Thu, 25 Apr 2002 19:02:38 -0700
X-mProtect: <200204260202> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpddCMY1J; Thu, 25 Apr 2002 19:02:36 PDT
Message-ID: <3CC8B53C.4F077FB5@iprg.nokia.com>
Date: Thu, 25 Apr 2002 19:02:36 -0700
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: Michael Thomas , mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
References: <3CB5DB1F.90909@lancaster.ac.uk>	<012801c1e198$1fcb99c0$7e6015ac@T23KEMPF>	<3CBDBC62.21C19B77@iprg.nokia.com>	<000001c1e7b6$9288fd80$746015ac@T23KEMPF>	<3CC0B44C.DB862958@iprg.nokia.com>	<046701c1e804$7016f330$736015ac@AlperVAIO>	<3CC58E3C.86B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello again Jim,

performance considerations is relevant. Clearly, fine tuning per
link type is needed. However, I would argue that such a need should
not alter the basic design principle(s). Mechanisms that preserve
the principles and provide the desired performance should be preferred,
at least in IETF work. For instance, if reliability of delivering a
handover
message to the MN is a concern, the previous AR could buffer data packets
and deliver them in case the link does fail to deliver the
handover message to the MN. Sure, there might be jitter (when there
is talkspurt, which BTW is a minority percentage in the ON-OFF
voice behavior), but an application such as VoIP has jitter buffers and
adaptive playout. I would be more inclined towards such an approach since
- not all links behave the same way; actually they hardly do
- not all applications have the same constraints
- a single design principle is applicable regardless of the link
   idiosyncracies and application requirements

I have more comments/questions below :-)

Regards,

-Rajeev


James Kempf wrote:

> Michael/Rajeev,
>
> I understand the desire to get the mobile involved in making the
> handover decision, but there really is a problem if you are concerned
> about reliable performance improvement. If reliability is not a concern,
> then signaling the mobile over the air prior to the handover and letting
> it decide is clearly the right way to go.
>

Reliability is a concern, but the solution to address unreliability is
multi-fold, isn't it ?

>
>
> If the mobile node has enough time for signaling to complete between the
> prehandover trigger informing it that a handover is pending and the time
> at which the actual Layer 2 handover occurs, then it can achieve
> performance equal to that achieved when the access router simply
> switches the routing without consulting the mobile node. However, radio
>

This is to be expected but good to hear empiricial validation.

> conditions around handover are always dicey (since, otherwise, the
> mobile node wouldn't be handing over) and the mobile node may speed up.

I tend to agree, but also would like to mention that MN may be interested
in getting "better" link connectivity from an existing "ok" link.

>
> As a result, the actual prehandover trigger time is really a random
> variable, and it could end up being too short. In that case, the mobile
> node must recover on the new access router by using standard Mobile IP,
> during which time its traffic on the old access router is dropped. So,
>

Alternatively, these packets, when there are any, could be buffered and
delivered once the MN regains connectivity.

> Smoothing (buffering or bicasting) is also possible, but our experiments
> on IS-2000 RAN indicated that an average of between 1 and 2 packets were
> dropped if the access router just switched on the tunnel. The traffic
>

Just curious if you did try the case when the router waited for the MN to
send authorization..

>
> Of course, none of this matters if one is not concerned with reliable
> real time performance suitable for replacing current circuit switched
> cellular with VoIP (as I am). I can send you some slides with
> preliminary measurments. We are continuing measurements on FMIPv4 (I'd
> like to do some statistics on the results) and will be attempting the
> same kinds of measurements on FMIPv6.
>

Good. Hopefully, we can compare notes. I have recently seen
some preliminary results from folks at UCLA on FMIPv6 which
closely match our preliminary tests on FMIPv6 (for WLAN).

>
>                     jak
>
> ----- Original Message -----
> From: "Rajeev Koodli" 
> To: "Michael Thomas" 
> Cc: "James Kempf" ; "Alper E. YEGIN"
> ; "Manolis Sifalakis"
> ; 
> Sent: Thursday, April 25, 2002 11:02 AM
> Subject: Re: [mobile-ip] some questions about
> draft-ietf-mobileip-fast-mipv6-04
>
> > Michael Thomas wrote:
> >
> > > James Kempf writes:
> > >  > Hi Michael,
> > >  >
> > >  > Your analysis is correct if the mobile node knows that a handover
> is
> > >  > occuring. I probably didn't make this clear enough, but as I
> mentioned,
> > >  > IP hosts have always had the option of choosing their default
> router,
> > >  > and if they becme aware that this router is changing, they should
> have
> > >  > the option of choosing a new one. Security, to the extent it is
> possible
> > >  > with currently unsecured protocols such as ND, should of course
> also
> > >  > play a role as you describe.
> > >  >
> > >  > I was objecting to what I detected  in Rajeev's note that this
> must
> > >  > always be the case, even when the mobile did not have any
> knowledge that
> > >  > the handover was occuring. In my view, this corresponds to a
> failure of
> > >  > a router in the network.
> > >  >
> > >  > Which occurs depends on how much informatoin is made available to
> which
> > >  > entity by the wireless protocol.
> > >
> > >    Yes, I understand where you're coming from, but
> > >    my gut level feeling is that Rajeev is right to
> > >    be suspicious because the issues don't seem to be
> > >    100% parallel. What this seems like to me --
> > >    and I might be in left field here -- is
> > >    something more akin to ICMP REDIRECT. That is,
> > >    I'd like you to move elsewhere because it's a
> > >    better route. But in the REDIRECT case, the
> > >    node doesn't have to actually honor it; after a
> > >    few retries, the router gives up and assumes
> > >    they won't move. This isn't entirely unlike
> > >    another scenario where a router has dynamic metrics
> > >    which for whatever reason it just ignores (say
> > >    it has a static route too).
> > >
> >
> > Interesting analogy. Some more thoughts..
> >
> > - in the REDIRECT case or more generally the
> >    network-triggered case, the MN is informed and
> >    the MN has the option to disregard it as opposed to
> >    unilaterally deciding the destination for MN's packets.
> >    This is a crucial point.
> > - if the knowledge that MN is about to "lose its link"
> >    resides exclusively at the network, the network can
> >    _still_ provide such an indication to the MN, e.g., via
> >    ProxyRtAdv in FMIPv6 or REDIRECT. [coincidentally, we
> >    used REDIRECT for network-triggered handover
> >    in our version of the fast handover draft back
> >    in October 2000]. If such a knowledge resides exclusively
> >    at the MN, the MN can always solicit a move and then
> >    authorize it. In either case, the MN _can_ be (and should be)
> >    given the token to authorize redirection.
> > - if notification fails (e.g., due to bad terrain), there is
> >    standard MIP with the possibility of
> >    siphoning packets from the previous AR.
> >
> >
> >
> > >
> > >    Thus to my mind, the nature of these changes
> > >    are *cooperative* on a hop-by-hop basis. That
> > >    is, I'd like you to do something and you
> > >    oblige. Therefore, if it makes sense in this
> > >
> >
> > Good point. If the MN does not engage, then it
> > won't gain and might lose.
> >
> > >    case -- and I'm not sure because which piqued
> > >    my interest here was the Internet gestalt -- it
> > >    does seem that to mimic the current net, the
> > >    exchange needs to be "may I? yes, please do"
> > >    which sort of favors Rajeev's contention that
> > >    it must be authorized by the MN. The reason
> > >    is because the MN ultimately needs to
> > >    participate in the move (eg, retune its radio,
> > >    etc), right?
> >
> > Right.
> >
> > Regards,
> >
> > -Rajeev
> >
> > ps. BTW, is there a version of Redirect for
> >       renumbering with an alert option ?
> >
> >
> > >
> > >
> > >                 Mike
> >
> >



From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 22:36:44 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13681
	for ; Thu, 25 Apr 2002 22:36:43 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12211;
	Thu, 25 Apr 2002 20:36:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01719;
	Thu, 25 Apr 2002 19:36:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q2ZBGs020823
	for ; Thu, 25 Apr 2002 19:35:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q2ZAqW020819
	for mobile-ip-dist; Thu, 25 Apr 2002 19:35:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q2YvGs020746
	for ; Thu, 25 Apr 2002 19:34:57 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01427
	for ; Thu, 25 Apr 2002 19:34:58 -0700 (PDT)
Received: from mail.flarion.com (mail.flarion.com [63.103.94.23])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11616
	for ; Thu, 25 Apr 2002 20:34:57 -0600 (MDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 25 Apr 2002 22:34:57 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3A892@ftmail>
From: "Alan O'Neill" 
To: "Madhavi W. Chandra" ,
        Annika Jonsson
	 ,
        charliep@iprg.nokia.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Thu, 25 Apr 2002 22:34:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Madhavi,

Good point.

In the context of [RegTunMods] I would restate this as follows;

The FA adds the GFAIPext to inform the HA of the CoA, and to enable the HA
to return the GFA address to the MN. The latter is so that next time the MN
can insert the CoA itself in the next RREQ and also enables the MN to
register directly to the GFA with a CCoA.

Now RegTunMods suggests splitting the GFA address into two bits. 

1) The GFAIPext is the address of the GFA from the MN and FAs perspective
and can therefore always appear in a FAA for movement detection unless a
dynamic allocation is to be made by the FA. In this case though, the FA
simply sends to the GFA. The FA then inserts GFAIPext in the RREP to the MN
protected by the FA_MN authext. The problem you raise goes away here.

2) The GFA CoA is the address of the GFA from the perspective of the HA and
therefore should go into a HFAext (not GFAIPext) inserted by the GFA (and
not by the FA) and sent to the HA protected by the GFA-HA auth ext.  This
repeats the general hierarchical HFAext mechanism that can used by the FA to
inform the GFA of a dynamically assigned FA CoA. Once again the problem goes
away. Note that the HFAext does not need to be returned to the MN but must
be returned just to the GFA so it knows that the HA processed the HFAext.

Therefore, in this more general model we can deal with disparate addressing
plans yet still protect all exchanges..

Alan.

-----Original Message-----
From: Madhavi W. Chandra [mailto:mchandra@cisco.com]
Sent: 25 April 2002 23:47
To: Annika Jonsson; charliep@iprg.nokia.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Last Call: Regional Tunneling input


Hi Annika and Charlie,

Putting RFC issues aside for a moment, please clarify a 
technical doubt...

If the MN sets the CoA field to 0.0.0.0, then the
FA assigns a GFA and appends the GFA IPext to the RRQ.  The
HA extracts the GFA CoA from the GFA IPext, and sets up the
tunnel end point to this GFA CoA.  However, it is not mandatory
to protect the GFA IPext with the FHAE.  I'm wondering what
the security implications of this are...since the tunnel
endpoint may be determined by an unprotected extension.  It
seems more susceptible to MN traffic hijacking by a 
man-in-the-middle.  What are your thoughts?

Thanks,
Madhavi



On Mon, Apr 22, 2002 at 04:32:37PM +0200, Annika Jonsson wrote:
> Hi Alan,
> 
> I have read your suggestions, and I have a few comments.
> 
> First, regarding the dynamic allocation of HA: we do support that in the 
> current draft. We assume that it is the GFA that participates in the 
> authentication procedure as AAA client and not the FA (see section 3.1.2).

> The reason for this is that it is the GFA that acts as FA towards the HA, 
> and therfore needs the keys for securing registration messages. So, in
this 
> way, a AAA server can dynamically allocate an HA, and the GFA will be 
> informed about this.
> 
> Second, the problem with how to handle different addressing plans between 
> FA - GFA and GFA - HA. I agree that this should be supported. Let's see if

> I understand your suggestion correctly:
> * The GFA address advertised in the Agent Advertisement should be the 
> "local" address of the GFA, where it can be reached from the FA.
> * A Home registration from a MN should never include any CoA address
> * The FA sends the registration req. on to the GFA "local" address
> * The GFA allocates CoA to the MN
> * The GFA IP extension (forget the name change for now...) should be used 
> to transport the selected CoA to the HA and to carry the selected CoA back

> to the MN, as is already the case in the draft.
> 
> I agree that dynamically allocating the CoA is the best way, and it seems 
> resonable that this is the responsibility of the GFA and not the FA. But, 
> the reason why we didn't specify that all MN:s must use that method is
that 
> we wanted to be backwards compatible wiht HA:s that does'nt specifically 
> support Regional registrations (or rather, the GFA IP extension). If MN:s 
> are allowed to put the CoA in the Registration request, the HA will never 
> need to know that the visited network uses regional registrations, and the

> GFA will look lika a normal FA. I still think this is a good feature.
> 
> To allow this, the FA must advertise a publicly routable GFA (CoA)
address. 
> If the FA and GFA belongs to a private address domain, the FA needs to
have 
> a mapping from the public CoA address to the private GFA address that it 
> should use to send the Registration request to. I think this solves the 
> problem.
> 
> To summarise, I suggest that we:
> * clarify that dynamic allocation of CoA is preferable
> * add that the FA might use another address to communicate with a GFA than

> the CoA advertised, and that it in that case needs a mapping between these

> two addresses
> * change the allocation of CoA and use of the GFA IP address extension, by

> saying that it is the responsibility of the FA to select GFA, but not to 
> include any GFA IP extension, because it is the responsibility of the GFA 
> to allocate CoA, and it will add the GFA IP extension.
> 
> Do you agree that this solves the problems you raised?
> 
> /Annika
> 
> At 22:23 2002-04-15 -0400, Alan O'Neill wrote:
> >Below is the abstract for the draft that makes last call suggestions on
> >Regional tunneling.
> >
> >see
>
>http://search.ietf.org/internet-drafts/draft-oneill-mip-regtun-mods-00.txt
> >
> >Abstract
> >
> >    Regional Registration modifies the normal MIP Registration signalling
> >    back to the HA so that the signalling can traverse an intermediate
> >    Gateway Foreign Agent (GFA). The registered binding is between the
Home
> >    Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent
> >    (HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the
GFA.
> >    Two extensions are defined to support this new Registration
processing
> >    these being the Hierarchical Foreign Agent extension (HFAext) and the
GFA
> >
> >    IP address extension (GFAIPext). The former is used to carry the FA
CoA
> >    to the GFA and the latter is used by the FA to allocate a GFA to the
MN,
> >    and by the FA, GFA, HA to securely return the GFA IP address to the
MN.
> >
> >    The present processing rules for the HA registration enable the FA to
> >    advertise the GFA to the MN in a Foreign Agent Advertisement (FAA)
and
> >    for the MN to include that GFA address into the CoA field of the MIP
home
> >
> >    Registration. This however assumes a number of things about the GFA
> >    address in the FAA and the addressing realms between the FA-GFA and
GFA-
> >    HA.. Specifically, the GFA CoA and the GFA IP address must
potentially be
> >
> >    from two different addressing plans and hence cannot be in the same
FAA.
> >    This draft describes the issues and suggests a solution that requires
> >    slight modifications to the required extensions, that generalises the
> >    Home Registration signalling for arbitrary intermediate MIP nodes,
and
> >    only slightly modifies the processing rules for the MIP Home
> >    Registration. This draft also describes a way to support dynamic HA
> >    allocation along-side Regional Registrations.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 22:36:57 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13699
	for ; Thu, 25 Apr 2002 22:36:57 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03029;
	Thu, 25 Apr 2002 20:36:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01817;
	Thu, 25 Apr 2002 19:36:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q2ZEGs020836
	for ; Thu, 25 Apr 2002 19:35:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q2ZEoR020832
	for mobile-ip-dist; Thu, 25 Apr 2002 19:35:14 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q2Z2Gs020776
	for ; Thu, 25 Apr 2002 19:35:02 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA06121
	for ; Thu, 25 Apr 2002 19:35:03 -0700 (PDT)
Received: from mail.flarion.com (mail.flarion.com [63.103.94.23])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA12929
	for ; Thu, 25 Apr 2002 20:35:01 -0600 (MDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 25 Apr 2002 22:35:00 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3A893@ftmail>
From: "Alan O'Neill" 
To: Annika Jonsson ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Thu, 25 Apr 2002 22:35:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Annika,

You said..
I think that you misunderstood me (or I you). What you say here is more or 
less what I meant. The only difference is that I still think that an FA 
could in most cases advertise a GFA CoA. This should be a public address, 
sort of a "default CoA", that an MN MAY use, e.g. if it's HA doesn't 
support the GFA IP extension. By specifying that an MN SHOULD set the CoA 
field in the Registration request to zero, that method will be used in most 
cases. I agreed that we could change so that the FA only forwards the 
registration to the GFA, and the GFA selects CoA, and adds the GFA IP 
extension. I don't think that this requires the FA to have an extensive
mapping 
knowledge. It needs to know the address to use to send the registration 
request to the GFA, but you can never get away from that.


AWO> I think we will call it a mutual misunderstanding ok :-)

So It is still not quite clear to me what you are suggesting...My logic
which I think is similar would be...

1) That the FA advertises the default GFA in the FAA for movement detection
reasons (but may not)..

2) f present, the MN SHOULD NOT use this as the GFA CoA in the first RREG to
a new HA

3) If the MN detects that the HA does not support GFAIPext then the MN can
try to use the GFA address in the FAA as the CoA.

Is that what you mean and do we differ by the fact that you wish the GFA in
the FAA to be public whilst I am happy for it to be public or private and
then rely on NAT higher in the topology....

Now when applied to RegTunMods, the last line becomes

3) If the GFA detects that the HA does not support HFAext, then it informs
the MN who can try to use.....


Now Ahmads suggestion on how to deal with legacy HAs, by the GFA detecting
if a GFAIPext is not returned, must now be revised as follows..

We are now interested in finding out if the HA pocessed the HFAext which
contained the GFA CoA. Therefore, the HA should return the HFAext to the
GFA, protected by the HA-GFAauthext to indicate this. The GFA then knows
whether or not to return an  error to the MN.

Progress or are the waters muddying ?

Alan


From owner-mobile-ip@sunroof.eng.sun.com  Thu Apr 25 22:37:06 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13713
	for ; Thu, 25 Apr 2002 22:37:05 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18435;
	Thu, 25 Apr 2002 20:37:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01932;
	Thu, 25 Apr 2002 19:36:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q2Z0Gs020764
	for ; Thu, 25 Apr 2002 19:35:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q2YxHm020758
	for mobile-ip-dist; Thu, 25 Apr 2002 19:34:59 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q2YpGs020703
	for ; Thu, 25 Apr 2002 19:34:51 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01363
	for ; Thu, 25 Apr 2002 19:34:51 -0700 (PDT)
Received: from mail.flarion.com (mail.flarion.com [63.103.94.23])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11573
	for ; Thu, 25 Apr 2002 20:34:51 -0600 (MDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 25 Apr 2002 22:34:50 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3A890@ftmail>
From: "Alan O'Neill" 
To: "Dana L. Blair" ,
        Annika Jonsson
	 ,
        "Charles E. Perkins"
	 ,
        "Madhavi W. Chandra" ,
        James Kempf , Basavaraj.Patil@nokia.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t
	xt
Date: Thu, 25 Apr 2002 22:34:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Thanks Dana,

Nice explaination, but I don't see enough justification in this
email for a "regional element".

AWO> There isn't nor was intended to be..

Please be aware that I am open to the idea of a "regional element".
However, there must be specific scenarios which have obvious
improvements over current MN, FA, and HA relationships to warrant
an internet standard.

Also, I would hesitate to suggest modifications to a draft which itself
has questionable merit as a standard.  Maybe you should start from
scratch with what you really need instead of creating various
modification drafts.

AWO> That is also happening but understand that when I started this (pre
last call) that RegTun was already there with unknown future status so
ignoring it would have been somewhat arrogant and unfair to those authors
methinks...

Alan

> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Alan O'Neill
> Sent: Wednesday, April 24, 2002 2:15 AM
> To: Annika Jonsson; Charles E. Perkins; Madhavi W. Chandra; James Kempf;
> Basavaraj.Patil@nokia.com
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] WG Last Call:
> draft-ietf-mobileip-reg-tunnel-06.txt
>
>
> So I thought given the thread I would add some higher layer
> thoughts behind
> Flarions interest in this draft and respond to some of the other comments
> raised. I do so coming from an intial viewpoint of seeing
> absolutely no need
> for regional registration for MIP...so am a slightly converted strong
> sceptic..as you will see below.
>
> Firstly, I agree with many that avoiding additional points of failure and
> the cost/benefit of regional registration makes its usefulness
> debatable...
> I agree that the hand-off aspects of this draft should be split
> out into the
> hand-off work and that additional work is required on the 'home signaling
> via regional node plane' to address some of the technical issues,
> especially
> regarding backwards compatibility and GFA CoA assignment (see my previous
> response to Annika on the latter and Ahmeds excellent analysis on the
> former). Even then, (if I was a neutral), I think I would say
> that we would
> need to see more deployment demand to progress the mechanisms in
> this draft
> on standards track.
>
> However, Flarion has one of the more challenging environments for
> MIPv4 and
> we will deploy something, sometime, somewhere soon (hopefully in huge
> volumes ;-) In reviewing a lot of MIP work in anticipation of that
> deployment, reviews that are still ongoing and for obvious reasons
> commercially sensitive at this time, it is apparent that there are some
> missing bits. We plan to continue to write these up and submit them
> following discussions and agreement with our core router partners and
> customers to then hopefully trigger standards activity where necessary.
> RegTunMods and RevTunMods were the first two such drafts and there will be
> others unrelated to regional tunneling...
>
> One such missing bit appears to be the need to be able to advertise the
> existence of a regional element (the 'I' bit) to the MN, to
> detect when that
> element has changed and to register to a home agent via each new regional
> element. We specifically have little interest in the RFA, in the regional
> element being a GFA and in the regional registration to the GFA itself. My
> analysis of, and feedback on, the RegTun draft in [RegTunMods]
> was motivated
> simply by the desire to be able to re-use the home registration regional
> extensions and hence co-exist with GFAs that might already have been
> deployed. I am open-minded about them getting deployed, but very
> unhappy if
> the general regional element capability is lost or eventually not
> standardised.
>
> I can and will elaborate much further on these points in suitable
> drafts as
> soon as I am able. This will hopefully be a matter of days or at
> worst a few
> weeks. In the absence of that justification and information I would be
> supportive of the draft being revised and taken to experimental. I would
> however recommend that we try to separate out the home signaling via a
> regional element, from the type of regional element and its features, as I
> think (well know :-) they are distinct. A generalised address carrier with
> sub-types can be used to transport addresses up and down that signalling
> plane and be used to trigger address type specific processing..ie
> a GFA CoA
> sub-type means do GFA type things. I think this redesign is a
> good idea even
> just for GFA as who knows what future requirements will come upon us (ours
> aside) and nailing up a general capability is unfortunate. This address
> carrier should maybe be defined in a separate draft.
>
> I also believe that the regional element should be able to be in
> the core or
> at the edge as alluded to by other responders, although ours will
> likely be
> in the core much to the horror of some of you no doubt. I wouldn't do it
> though unless I thought it was absolutely necessary...believe me.
>
> I think we should also finally recognise the extensive and excellent work
> that has gone into RegTun, and await both suitable revisions and then
> vendor/customer interest before committing this to standards track.
>
> Regards,  Alan.
>
>
>
>
>
>
>


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 02:07:10 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25663
	for ; Fri, 26 Apr 2002 02:07:10 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18683;
	Fri, 26 Apr 2002 00:07:09 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA21155;
	Thu, 25 Apr 2002 23:06:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q660Gs017221
	for ; Thu, 25 Apr 2002 23:06:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q660PH017220
	for mobile-ip-dist; Thu, 25 Apr 2002 23:06:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q65sGs017185
	for ; Thu, 25 Apr 2002 23:05:54 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18040
	for ; Thu, 25 Apr 2002 23:05:54 -0700 (PDT)
Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19973
	for ; Fri, 26 Apr 2002 00:05:53 -0600 (MDT)
Received: from ns.iij.ad.jp ([192.168.2.111])
	by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA03391;
	Fri, 26 Apr 2002 15:05:52 +0900 (JST)
Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA04420; Fri, 26 Apr 2002 15:05:51 +0900 (JST)
Date: Fri, 26 Apr 2002 15:05:20 +0900 (JST)
Message-Id: <20020426.150520.32793746.keiichi@iij.ad.jp>
To: vijayd@IPRG.nokia.com, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO
From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= 
In-Reply-To: <3CC842BD.A42F7D0F@iprg.nokia.com>
References: <20020425.184505.06470684.keiichi@iij.ad.jp>
	<3CC842BD.A42F7D0F@iprg.nokia.com>
X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Vijay,

From: Vijay Devarapalli 

>   - if there is a BCE with CoA = IPv6 src and HoA = HAO content

fine.

>   - if there is a home registration BCE with HoA = HAO content

fine.

>   - if packet contains BU and satisfies the security policy
>     between MN and HA 
>   - if packet contains AH or ESP header and satisfies the security
>     policy check between MN and HA.

To check if the packet has a BU or not, we must chase all the exthdrs
before processing a HAO because a BU is included in a MH which is the
last exthdr.  Also, to check if the packet satisfies the security
policy, we must process the ESP header before processing a HAO...
Hmm..

I tend to agree with the Francis's idea to process a HAO if the next
header value of the destination option header which contains a HAO is
ESP.  This makes it simple to implement a HAO processing.

---
Keiichi SHIMA
IIJ Research Laboratory 
KAME Project 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 02:12:22 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25755
	for ; Fri, 26 Apr 2002 02:12:22 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA09865;
	Fri, 26 Apr 2002 00:12:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA23553;
	Thu, 25 Apr 2002 23:12:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q6BSGs019180
	for ; Thu, 25 Apr 2002 23:11:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q6BRjt019179
	for mobile-ip-dist; Thu, 25 Apr 2002 23:11:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q6BLGs019138
	for ; Thu, 25 Apr 2002 23:11:21 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05349
	for ; Thu, 25 Apr 2002 23:11:21 -0700 (PDT)
Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20219
	for ; Fri, 26 Apr 2002 00:11:21 -0600 (MDT)
Received: from ns.iij.ad.jp ([192.168.2.111])
	by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA03566;
	Fri, 26 Apr 2002 15:11:19 +0900 (JST)
Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA05624; Fri, 26 Apr 2002 15:11:18 +0900 (JST)
Date: Fri, 26 Apr 2002 15:10:49 +0900 (JST)
Message-Id: <20020426.151049.122682763.keiichi@iij.ad.jp>
To: Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO 
From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= 
In-Reply-To: <200204251507.g3PF7ET73773@givry.rennes.enst-bretagne.fr>
References: <20020425.184505.06470684.keiichi@iij.ad.jp>
	<200204251507.g3PF7ET73773@givry.rennes.enst-bretagne.fr>
X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Francis,

From: Francis Dupont 

>    The latest discussion concludes that a HAO must not be processed
>    without a valid BCE.
> 
> => I disagree: it must not be processed if it is not verified and
> there are at least two ways to verify a HAO:
>  - BCE check
>  - IPsec (the idea is if the HAO is fake the IPsec processing will
>    reject the whole packet, look at my ID about IPsec and Mobile IPv6).

OK.  I agree with you.

>    Also, the BU/BA for the home registration must be protected by the ESP.
>    
> => so the HAO will be verified and as soon as the next header type is ESP
> the BCE check is no more necessary. Unfortunately the SA pair would be used
> only for the protection of BU/BA exchange: a waste but it *is* secure!
> (this comment is only for the home registration and when the only direct
> traffic between the MN and the HA is the mobility signaling).

This seems simple and effective.

One question.  We should check a framgmenation header (and the nxthdr
value in the fragmentation header) after a destination options header
which contains a HAO, shouldn't we?


---
Keiichi SHIMA
IIJ Research Laboratory 
KAME Project 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 02:14:45 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25799
	for ; Fri, 26 Apr 2002 02:14:45 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10788;
	Fri, 26 Apr 2002 00:14:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24656;
	Thu, 25 Apr 2002 23:14:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q6DtGs020106
	for ; Thu, 25 Apr 2002 23:13:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q6DssS020104
	for mobile-ip-dist; Thu, 25 Apr 2002 23:13:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q6DkGs020051
	for ; Thu, 25 Apr 2002 23:13:47 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24329
	for ; Thu, 25 Apr 2002 23:13:47 -0700 (PDT)
Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25338
	for ; Fri, 26 Apr 2002 00:13:45 -0600 (MDT)
Received: (from msa@localhost)
	by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id JAA17342;
	Fri, 26 Apr 2002 09:13:32 +0300
Date: Fri, 26 Apr 2002 09:13:32 +0300
Message-Id: <200204260613.JAA17342@burp.tkv.asdf.org>
From: Markku Savela 
To: keiichi@iij.ad.jp
CC: vijayd@IPRG.nokia.com, mobile-ip@sunroof.eng.sun.com
In-reply-to: <20020426.150520.32793746.keiichi@iij.ad.jp> (message from	
 Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= on Fri, 26 Apr 2002	
 15:05:20 +0900 (JST))
Subject: Re: [mobile-ip] How to process HAO
References: <20020425.184505.06470684.keiichi@iij.ad.jp>
	<3CC842BD.A42F7D0F@iprg.nokia.com> <20020426.150520.32793746.keiichi@iij.ad.jp>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

> 
> I tend to agree with the Francis's idea to process a HAO if the next
> header value of the destination option header which contains a HAO is
> ESP.  This makes it simple to implement a HAO processing.

Hmm.. just to protect dest option (and HAO) from prying eyes, I would
much more like to put ESP *before* destination options.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 02:42:57 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26148
	for ; Fri, 26 Apr 2002 02:42:56 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22722;
	Thu, 25 Apr 2002 23:42:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA06720;
	Thu, 25 Apr 2002 23:42:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q6f8Gs001406
	for ; Thu, 25 Apr 2002 23:41:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q6f8KH001397
	for mobile-ip-dist; Thu, 25 Apr 2002 23:41:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q6eqGs001283
	for ; Thu, 25 Apr 2002 23:40:53 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13289
	for ; Thu, 25 Apr 2002 23:40:53 -0700 (PDT)
Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05290
	for ; Fri, 26 Apr 2002 00:40:52 -0600 (MDT)
Received: from ns.iij.ad.jp ([192.168.2.111])
	by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA04600;
	Fri, 26 Apr 2002 15:40:50 +0900 (JST)
Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA13358; Fri, 26 Apr 2002 15:40:50 +0900 (JST)
Date: Fri, 26 Apr 2002 15:40:20 +0900 (JST)
Message-Id: <20020426.154020.69257026.keiichi@iij.ad.jp>
To: msa@burp.tkv.asdf.org, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO
From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= 
In-Reply-To: <200204260613.JAA17342@burp.tkv.asdf.org>
References: <3CC842BD.A42F7D0F@iprg.nokia.com>
	<20020426.150520.32793746.keiichi@iij.ad.jp>
	<200204260613.JAA17342@burp.tkv.asdf.org>
X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
From: Markku Savela 
Content-Transfer-Encoding: 7bit

> > I tend to agree with the Francis's idea to process a HAO if the next
> > header value of the destination option header which contains a HAO is
> > ESP.  This makes it simple to implement a HAO processing.
> 
> Hmm.. just to protect dest option (and HAO) from prying eyes, I would
> much more like to put ESP *before* destination options.

I think we cannot put ESP before HAO unless we use a MN_CoA as an
endpoint of the SA between the HA and the MN.  Once the MN encrypts
its MN_HoA, the HA can't decrypt it because it doesn't have a SA
between HA_addr and MN_CoA.

---
Keiichi SHIMA
IIJ Research Laboratory 
KAME Project 




From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 04:08:36 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27000
	for ; Fri, 26 Apr 2002 04:08:35 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00071;
	Fri, 26 Apr 2002 02:08:32 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17177;
	Fri, 26 Apr 2002 01:08:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q86pGs012405
	for ; Fri, 26 Apr 2002 01:06:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q86pk4012403
	for mobile-ip-dist; Fri, 26 Apr 2002 01:06:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q86eGs012332
	for ; Fri, 26 Apr 2002 01:06:40 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07854
	for ; Fri, 26 Apr 2002 01:06:42 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29074
	for ; Fri, 26 Apr 2002 02:06:41 -0600 (MDT)
Message-ID: <004d01c1ecf9$0d5b8cc0$746015ac@T23KEMPF>
From: "James Kempf" 
To: "Rajeev Koodli" 
Cc: "Michael Thomas" , 
References: <3CB5DB1F.90909@lancaster.ac.uk>	<012801c1e198$1fcb99c0$7e6015ac@T23KEMPF>	<3CBDBC62.21C19B77@iprg.nokia.com>	<000001c1e7b6$9288fd80$746015ac@T23KEMPF>	<3CC0B44C.DB862958@iprg.nokia.com>	<046701c1e804$7016f330$736015ac@AlperVAIO>	<3CC58E3C.86B <3CC8B53C.4F077FB5@iprg.nokia.com>
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
Date: Fri, 26 Apr 2002 01:04:09 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Rajeev,

I rather favor some mechanism to inform the MN after the move has
occured. For example, sending the MN an ICMP REDIRECT message after the
access router has changed, as Michael has suggested, would do the trick,
as it would avoid the problem of the signaling getting cut off
prematurely.

Buffering in the context of predictive algorithms that utilize
prehandover over-the-air siginaling (such as FMIPv6) is difficult
because the amount of data to be buffered is not deterministic. It
depends on the speed of the mobile node, the data rate on the channel,
and the Layer 2 handover latency. Calculating the size of the buffer
becomes a major deployment headache. One can set the buffer size to
catch N standard deviations, but what about the N+1st? In particular,
the N+1st could be a rare event where the consequences of not handling
it are severe, like an emergency vehicle that moves much more quickly
than the average traffic.

In contrast, predictive algorithms that utilize network predictive
information to switch the routing without prehandover involvement of the
mobile don't run into this problem. The buffer size is deterministic,
making deployment much easier.

So I favor a statement in the FMIPv6 draft that the new AR SHOULD send
an ICMP REDIRECT message to the mobile node if BETH handover is
utilized.

Specific responses to your questions below.

            jak


> Just curious if you did try the case when the router waited for the MN
to
> send authorization..
>

We did not examine that case. Obviously, it would delay handover even
more. I think there is some work to be done here on context transfer for
speeding authentication. I believe 802.11i is looking at preflooding
authentication to surrounding access points in order to avoid handover
delay, a similar technique or targeted context transfer could be used
for cellular.

> Good. Hopefully, we can compare notes. I have recently seen
> some preliminary results from folks at UCLA on FMIPv6 which
> closely match our preliminary tests on FMIPv6 (for WLAN).
>

I've also seen some results from the EU Moby Dick project on FMIPv6
which match your results. However, I think more work needs to be done to
characterize the behavior of FMIPv6 under load. In particular, the
"hack" of forcing handover by resetting the BSSid effectively makes the
prehandover layer 2 trigger time deterministic, so the experimenter can
optimize this time to avoid having the FMIPv6 signaling cut off. In
reality, this time will be a random variable, just like it is for
cellular, if the 802.11 committee ever manages to define its handover
conditions precisely enough so the NIC manufacuturers can offer a
uniform L2 trigger API.

            jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 04:47:30 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27420
	for ; Fri, 26 Apr 2002 04:47:29 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22722;
	Fri, 26 Apr 2002 02:47:31 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25810;
	Fri, 26 Apr 2002 01:47:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q8kLGs029179
	for ; Fri, 26 Apr 2002 01:46:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q8kLkm029173
	for mobile-ip-dist; Fri, 26 Apr 2002 01:46:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q8k9Gs029087
	for ; Fri, 26 Apr 2002 01:46:09 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20679
	for ; Fri, 26 Apr 2002 01:46:11 -0700 (PDT)
Received: from telecom.samsung.co.kr ([165.213.149.2])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18799
	for ; Fri, 26 Apr 2002 01:46:10 -0700 (PDT)
Received: from junhyuk ([165.213.114.141])
	by telecom.samsung.co.kr (8.11.6/8.11.6) with SMTP id g3Q8jmh05957;
	Fri, 26 Apr 2002 17:45:48 +0900 (KST)
Message-ID: <001f01c1ecfe$ae33c040$8d72d5a5@junhyuk>
From: "Junhyuk Song" 
To: 
Cc: =?utf-8?B?7J2064+Z6riw?= 
Subject: [mobile-ip] New ID: draft-song-dnsext-nai-support-01.txt
Date: Fri, 26 Apr 2002 17:45:12 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001C_01C1ED4A.1DDFBED0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_001C_01C1ED4A.1DDFBED0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQpJIHJlY2VudGx5IHN1Ym1pdGVkICJkcmFmdC1zb25nLWRuc2V4dC1uYWktc3Vw
cG9ydC0wMS50eHQiIHRvIEROU0VYVCB3b3JrZ3JvdXAuDQpJIGJlbGlldmUgaXQgbWF5IGJlIGdv
b2QgaWRlYSB0byBkZWZpbmUgTkFJIFJSIChSZXNvdXJjZSBSZWNvcmQpIGluIGNhc2Ugb2YgTUlQ
djQgRHluYW1pYyBIb21lIEFkZHJlc3MgQWxsb2NhdGlvbi4gIEl0IHdpbGwgZW5hYmxlIENOIHRv
IGxvY2F0ZSBNTiwgd2hlbiBNTiBpcyByZS1hbGxvY2F0ZWQgbmV3IEhvbWUgSVAgYWRkcmVzcy4g
DQoNCkFic3RyYWN0DQogICANCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIHVzZSBvZiB0
aGUgbmV3IEROUyBSUiB0eXBlICJOQUkiIA0KICAgKE5ldHdvcmsgQWNjZXNzIElkZW50aWZpZXIp
IFtSRkMyNDg2XSB0byBzcGVjaWZ5IGR5bmFtaWNhbGx5IGFzc2lnbmVkDQogICBJUCBhZGRyZXNz
Lg0KDQpUaGlzIGRvY3VtZW50IGNhbiBiZSBmb3VuZCBiZWxvdyBVUkw6DQpodHRwOi8vc2VhcmNo
LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zb25nLWRuc2V4dC1uYWktc3VwcG9ydC0w
MS50eHQNCg0KDQpUaGFua3MsDQpKSCBTT05HDQo=

------=_NextPart_000_001C_01C1ED4A.1DDFBED0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u
dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2
LjAwLjI2MDAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC
T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbCw8L0ZPTlQ+PC9E
SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp
emU9Mj5JIHJlY2VudGx5IHN1Ym1pdGVkICJkcmFmdC1zb25nLWRuc2V4dC1uYWktc3VwcG9ydC0w
MS50eHQiIHRvIA0KRE5TRVhUIHdvcmtncm91cC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp
emU9Mj5JIGJlbGlldmUgaXQgbWF5IGJlIGdvb2QgaWRlYSB0byBkZWZpbmUgTkFJIFJSIChSZXNv
dXJjZSANClJlY29yZCkmbmJzcDtpbiBjYXNlIG9mJm5ic3A7TUlQdjQgRHluYW1pYyBIb21lIEFk
ZHJlc3MgQWxsb2NhdGlvbi4mbmJzcDsgSXQgDQp3aWxsIGVuYWJsZSBDTiB0byBsb2NhdGUmbmJz
cDtNTiwgd2hlbiBNTiBpcyByZS1hbGxvY2F0ZWQgbmV3Jm5ic3A7SG9tZSBJUCANCmFkZHJlc3Mu
Jm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW
Pg0KPERJVj48Rk9OVCBzaXplPTI+QWJzdHJhY3Q8QlI+Jm5ic3A7Jm5ic3A7IDxCUj4mbmJzcDsm
bmJzcDsgVGhpcyBkb2N1bWVudCANCnByb3Bvc2VzIHRoZSB1c2Ugb2YgdGhlIG5ldyBETlMgUlIg
dHlwZSAiTkFJIiA8QlI+Jm5ic3A7Jm5ic3A7IChOZXR3b3JrIEFjY2VzcyANCklkZW50aWZpZXIp
IFtSRkMyNDg2XSB0byBzcGVjaWZ5IGR5bmFtaWNhbGx5IGFzc2lnbmVkPEJSPiZuYnNwOyZuYnNw
OyBJUCANCmFkZHJlc3MuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu
YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhpcyBkb2N1bWVudCBjYW4gYmUgZm91bmQg
YmVsb3cgVVJMOjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3qtbTrprwgc2l6ZT0yPjxB
IA0KaHJlZj0iaHR0cDovL3NlYXJjaC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc29u
Zy1kbnNleHQtbmFpLXN1cHBvcnQtMDEudHh0Ij5odHRwOi8vc2VhcmNoLmlldGYub3JnL2ludGVy
bmV0LWRyYWZ0cy9kcmFmdC1zb25nLWRuc2V4dC1uYWktc3VwcG9ydC0wMS50eHQ8L0E+PC9GT05U
PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O
VCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzLDwv
Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkpIIFNPTkc8L0ZPTlQ+PC9ESVY+PC9CT0RZ
PjwvSFRNTD4NCg==

------=_NextPart_000_001C_01C1ED4A.1DDFBED0--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 04:55:03 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27586
	for ; Fri, 26 Apr 2002 04:55:03 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27344;
	Fri, 26 Apr 2002 02:55:05 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29110;
	Fri, 26 Apr 2002 01:54:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q8rwGs002380
	for ; Fri, 26 Apr 2002 01:53:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q8rwMt002369
	for mobile-ip-dist; Fri, 26 Apr 2002 01:53:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q8rgGs002269
	for ; Fri, 26 Apr 2002 01:53:42 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22285
	for ; Fri, 26 Apr 2002 01:53:43 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA25416
	for ; Fri, 26 Apr 2002 02:53:42 -0600 (MDT)
Message-ID: <006401c1ecfe$ddfd7c30$356015ac@AlperVAIO>
From: "Alper E. YEGIN" 
To: "James Kempf" ,
        "Rajeev Koodli" 
Cc: "Manolis Sifalakis" ,
        
References: <3CB5DB1F.90909@lancaster.ac.uk> <012801c1e198$1fcb99c0$7e6015ac@T23KEMPF> <3CBDBC62.21C19B77@iprg.nokia.com> <000001c1e7b6$9288fd80$746015ac@T23KEMPF> <3CC0B44C.DB862958@iprg.nokia.com> <046701c1e804$7016f330$736015ac@AlperVAIO> <3CC58E3C.86B <3CC5CA61.E210D29F@iprg.nokia.com> <00c401c1eb69$25179340$b36015ac@T23KEMPF>
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
Date: Fri, 26 Apr 2002 01:46:29 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

> So I agree that the FBU is the proper signal for starting the tunnel in
> FMIPv6, but I do not agree that it holds as a general principle that a
> MN can determine the routing of its packets, as this would be in direct
> contradiction of basic Internet routing design principles.

These principles are still valid as long as mobile node stays on the same
network. But of course these principles didn't account for the case of
"hosts" going "mobile". In which case, Mobile IP principles should
be applicable: mobile node is in charge of getting its routing fixed. Mobile
node cannot do this on its won, needs support from the network. At least
the home agent, if not the access routers on the access network should
cooperate.



alper



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 05:38:35 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28204
	for ; Fri, 26 Apr 2002 05:38:35 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07623;
	Fri, 26 Apr 2002 02:38:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05446;
	Fri, 26 Apr 2002 02:37:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q9ZkGs020496
	for ; Fri, 26 Apr 2002 02:35:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3Q9ZkIw020495
	for mobile-ip-dist; Fri, 26 Apr 2002 02:35:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3Q9ZgGs020488
	for ; Fri, 26 Apr 2002 02:35:42 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15222
	for ; Fri, 26 Apr 2002 02:35:45 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12252
	for ; Fri, 26 Apr 2002 03:35:44 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3Q9ZUB24216;
	Fri, 26 Apr 2002 11:35:30 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA10402;
	Fri, 26 Apr 2002 11:35:30 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3Q9ZUT76719;
	Fri, 26 Apr 2002 11:35:30 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204260935.g3Q9ZUT76719@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Vijay Devarapalli 
cc: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO 
In-reply-to: Your message of Thu, 25 Apr 2002 10:54:05 PDT.
             <3CC842BD.A42F7D0F@iprg.nokia.com> 
Date: Fri, 26 Apr 2002 11:35:30 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

     - if packet contains BU and satisfies the security policy
       between MN and HA 
     - if packet contains AH or ESP header and satisfies the security
       policy check between MN and HA.
   
   The last two bullets could be combined into one. And then it 
   becomes the IPsec check that Francis is talking about.
   
=> as I have asked at the last IETF meeting, the ID 16 uses the
Charlie Perkins' "verified HOA" term. Unfortunately it is done
only in the section 13.2 and the ID suggests the only way to
verify a HOA is the BCE check. This is one of the many cases
the ID doesn't take IPsec into account, my principal concern
aboit it (with the traditional stupid proposal to unicast a NS
to the HA in order to get its link-layer address).

Regards

Francis.Dupont@enst-bretagne.fr

PS: the verification by a convenient IPsec transform is 100% safe
because it provides a proof of the origin of the packet (by a
secret sharing or, better, by crypto checksum in the case of AH).


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 06:07:22 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28661
	for ; Fri, 26 Apr 2002 06:07:21 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25191;
	Fri, 26 Apr 2002 04:07:21 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA20316;
	Fri, 26 Apr 2002 03:07:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QA5mGs022940
	for ; Fri, 26 Apr 2002 03:05:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QA5mx0022939
	for mobile-ip-dist; Fri, 26 Apr 2002 03:05:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QA5iGs022928
	for ; Fri, 26 Apr 2002 03:05:44 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA10269
	for ; Fri, 26 Apr 2002 03:05:44 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16965
	for ; Fri, 26 Apr 2002 04:05:43 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3QA5QB29449;
	Fri, 26 Apr 2002 12:05:26 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA10942;
	Fri, 26 Apr 2002 12:05:27 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3QA5QT76799;
	Fri, 26 Apr 2002 12:05:26 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204261005.g3QA5QT76799@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Vijay Devarapalli 
cc: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO 
In-reply-to: Your message of Thu, 25 Apr 2002 10:57:09 PDT.
             <3CC84375.86815E69@iprg.nokia.com> 
Date: Fri, 26 Apr 2002 12:05:26 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   And of course, assuming the SPD/SAD uses MN's HoA always.
   
=> there is no choice for the SPD because SPD selector are traffic selectors
for inner addresses.  The SAD case is more complex but as the HOA must
be before the IPsec header so is processed before for incoming packets
only the HoA works. Note tehre are many other reasons to use the HoA
and the only drawback is more complexity in SA establishment for
home registration (again, look at draft-dupont-ipsec-mipv6-00.txt).

I use the occasion to fix the issue of not doing any check for the CoA
when a BU is protected by a convenient IPsec SA:
 - the possible attack (authentified BU with a bad CoA, i.e. an attack
   from the MN itself) uses reflection and doesn't hide the identity
   of the attacker at all
 - IPsec SA establishment checks strong authentication + authorization
   (so the issue doesn't exist for the HoA)
 - verification of the CoA can be impossible for home registration
   (i.e. when the CN is the HA, the only solution I can see is AAA
    with AAA infrastructure as in draft-le-aaa-mipv6-requirements-00.txt)
So I suggest to interpret the term authorization as to trust (or not)
the MN to give its real CoA. So this will become a special case for
the IPsec security policy, as to use a self-signed certificate or
a CGA is enough for mobility but not for all other purposes...
 Fortunately now the mobility signaling is a "protocol" which can
be properly handled in SPD, so this proposal is trivial to implement.
 Note this issue is only for BUs, for a regular packet to an ordinary
CN with a HOA, a convenient IPsec transform is enough and gives back
the triangular routing...

Thanks

Francis.Dupont@enst-bretagne.fr

PS: I use the term convenient because, for instance, an ESP transform
alone with null authentication is not enough for mobility (and in fact
for any) purpose.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 08:03:36 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00417
	for ; Fri, 26 Apr 2002 08:03:36 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20583;
	Fri, 26 Apr 2002 06:03:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02205;
	Fri, 26 Apr 2002 05:03:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QC2YGs011295
	for ; Fri, 26 Apr 2002 05:02:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QC2YAG011294
	for mobile-ip-dist; Fri, 26 Apr 2002 05:02:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QC2VGs011287
	for ; Fri, 26 Apr 2002 05:02:31 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25566
	for ; Fri, 26 Apr 2002 05:02:32 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05560
	for ; Fri, 26 Apr 2002 05:02:31 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3QC2TB15454
	for ; Fri, 26 Apr 2002 14:02:29 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA12811
	for ; Fri, 26 Apr 2002 14:02:29 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3QC2TT77081
	for ; Fri, 26 Apr 2002 14:02:29 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204261202.g3QC2TT77081@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security
Date: Fri, 26 Apr 2002 14:02:29 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

I've just done a comment about NAT/NATPT traversal security
at IPCN and I believe it is useful to discuss about the raised
issue in this list.

The basic problem is the HA has to trust the CoA found from the
source address in the IP header which can be forged by anyone
in the path (note this is different from my "trust the CoA given
by the MN argument" in a previous mail).

I don't know if this is enough to restrict/reject the NAT traversal
proposal but at least the security section should *not* stay empty!

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 08:56:43 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01965
	for ; Fri, 26 Apr 2002 08:56:42 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27799;
	Fri, 26 Apr 2002 05:56:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13966;
	Fri, 26 Apr 2002 05:56:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QCstGs024014
	for ; Fri, 26 Apr 2002 05:54:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QCst05024007
	for mobile-ip-dist; Fri, 26 Apr 2002 05:54:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QCshGs023917
	for ; Fri, 26 Apr 2002 05:54:43 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16796
	for ; Fri, 26 Apr 2002 05:54:45 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27694
	for ; Fri, 26 Apr 2002 06:54:43 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3QCsbB25413;
	Fri, 26 Apr 2002 14:54:38 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA13879;
	Fri, 26 Apr 2002 14:54:37 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3QCsbT77241;
	Fri, 26 Apr 2002 14:54:37 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204261254.g3QCsbT77241@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= 
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO 
In-reply-to: Your message of Fri, 26 Apr 2002 15:10:49 +0900.
             <20020426.151049.122682763.keiichi@iij.ad.jp> 
Date: Fri, 26 Apr 2002 14:54:37 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   This seems simple and effective.
   
=> Thanks!

   One question.  We should check a framgmenation header (and the nxthdr
   value in the fragmentation header) after a destination options header
   which contains a HAO, shouldn't we?
   
=> I agree but with standard header positions it should be enough...

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 09:01:32 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02098
	for ; Fri, 26 Apr 2002 09:01:32 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28608;
	Fri, 26 Apr 2002 07:01:32 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16534;
	Fri, 26 Apr 2002 06:01:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QD0AGs026490
	for ; Fri, 26 Apr 2002 06:00:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QD09lj026487
	for mobile-ip-dist; Fri, 26 Apr 2002 06:00:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QD01Gs026433
	for ; Fri, 26 Apr 2002 06:00:01 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15867
	for ; Fri, 26 Apr 2002 06:00:03 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00207
	for ; Fri, 26 Apr 2002 06:00:02 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3QCxcB26132;
	Fri, 26 Apr 2002 14:59:38 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA13978;
	Fri, 26 Apr 2002 14:59:38 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3QCxYT77264;
	Fri, 26 Apr 2002 14:59:38 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204261259.g3QCxYT77264@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Markku Savela 
cc: keiichi@iij.ad.jp, vijayd@IPRG.nokia.com, mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO 
In-reply-to: Your message of Fri, 26 Apr 2002 09:13:32 +0300.
             <200204260613.JAA17342@burp.tkv.asdf.org> 
Date: Fri, 26 Apr 2002 14:59:34 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   > I tend to agree with the Francis's idea to process a HAO if the next
   > header value of the destination option header which contains a HAO is
   > ESP.  This makes it simple to implement a HAO processing.
   
   Hmm.. just to protect dest option (and HAO) from prying eyes, I would
   much more like to put ESP *before* destination options.

=> for many reasons (some already explained by Keiichi) the HAO MUST
be before the ESP. For instance in order to give back the triangulat
routing when there is a convenient IPsec SA...

Regards

Francis.Dupont@enst-bretagne.fr

PS: by definition, the only thing non-mobility entities
want to know in a correspondent node is the home address!


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 10:12:55 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05101
	for ; Fri, 26 Apr 2002 10:12:54 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07541;
	Fri, 26 Apr 2002 08:12:55 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22011;
	Fri, 26 Apr 2002 07:12:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QEBdGs026892
	for ; Fri, 26 Apr 2002 07:11:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QEBdJV026885
	for mobile-ip-dist; Fri, 26 Apr 2002 07:11:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QEBUGs026831
	for ; Fri, 26 Apr 2002 07:11:30 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08164
	for ; Fri, 26 Apr 2002 07:11:31 -0700 (PDT)
Received: from cisco.com (shako.cisco.com [64.102.17.78])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24379
	for ; Fri, 26 Apr 2002 08:11:30 -0600 (MDT)
Received: (from mchandra@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA18050;
	Fri, 26 Apr 2002 10:11:22 -0400 (EDT)
Date: Fri, 26 Apr 2002 10:11:22 -0400
From: "Madhavi W. Chandra" 
To: Francis Dupont 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security
Message-ID: <20020426101122.E13617@cisco.com>
References: <200204261202.g3QC2TT77081@givry.rennes.enst-bretagne.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200204261202.g3QC2TT77081@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr on Fri, Apr 26, 2002 at 02:02:29PM +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Francis,

Excellent point which we were going to raise as well.
It is the similar situation as in the Regional Registration
draft...the tunnel end point is set up to an CoA, that is
not part of protected data.  (In the Regional Registration
case, when the GFA IPext is protected by FHAE, this is not
an issue.)

Regarding the NAT draft, the basic need is for the HA to 
somehow verify that the IP SRC address is in fact from a
NAT, and not some man-in-the-middle.  However, I'm not sure
that given the current nature of NAT, if this is possible.
I was looking at the STUN draft in midcomm WG as a possible hook,
but I think this approach is also susceptible to man-in-the-middle.

It seems that establishing a MIP tunnel as above opens up greater
risk for MN traffic hijacking.  However, as I'm not a security
expert, I don't know for sure.  Perhaps you and others can shed
some light on this. 

Since NAT/MIP interaction is a real need in MIP deployments, hopefully
we can ensure that we are not opening up any further security
risks than base MIP.

Regards,
Madhavi




On Fri, Apr 26, 2002 at 02:02:29PM +0200, Francis Dupont wrote:
> I've just done a comment about NAT/NATPT traversal security
> at IPCN and I believe it is useful to discuss about the raised
> issue in this list.
> 
> The basic problem is the HA has to trust the CoA found from the
> source address in the IP header which can be forged by anyone
> in the path (note this is different from my "trust the CoA given
> by the MN argument" in a previous mail).
> 
> I don't know if this is enough to restrict/reject the NAT traversal
> proposal but at least the security section should *not* stay empty!
> 
> Regards
> 
> Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 10:36:57 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06081
	for ; Fri, 26 Apr 2002 10:36:57 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01955;
	Fri, 26 Apr 2002 07:36:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04399;
	Fri, 26 Apr 2002 07:36:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QEZ1Gs007762
	for ; Fri, 26 Apr 2002 07:35:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QEZ1CS007755
	for mobile-ip-dist; Fri, 26 Apr 2002 07:35:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QEYhGs007621
	for ; Fri, 26 Apr 2002 07:34:43 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15387
	for ; Fri, 26 Apr 2002 07:34:44 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21844
	for ; Fri, 26 Apr 2002 08:34:43 -0600 (MDT)
Received: from fedex.cisco.com (IDENT:mirapoint@fedex.cisco.com [171.69.17.28])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3QEYYp6013002;
	Fri, 26 Apr 2002 07:34:34 -0700 (PDT)
Received: from cisco.com (rtp-vpn1-375.cisco.com [10.82.225.119])
	by fedex.cisco.com (Mirapoint)
	with ESMTP id ABP02125;
	Fri, 26 Apr 2002 07:32:14 -0700 (PDT)
Message-ID: <3CC967F2.BCEBA47E@cisco.com>
Date: Fri, 26 Apr 2002 07:45:06 -0700
From: Milind Kulkarni 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Madhavi W. Chandra" 
CC: Francis Dupont ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security
References: <200204261202.g3QC2TT77081@givry.rennes.enst-bretagne.fr> <20020426101122.E13617@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis,

I am sure the authors will correct you as well, but the latest
version for this draft is -02.txt (and not 00). Though even in 
that draft, the scheme is susceptible to man-in-the-middle attack.

Milind

"Madhavi W. Chandra" wrote:
> 
> Francis,
> 
> Excellent point which we were going to raise as well.
> It is the similar situation as in the Regional Registration
> draft...the tunnel end point is set up to an CoA, that is
> not part of protected data.  (In the Regional Registration
> case, when the GFA IPext is protected by FHAE, this is not
> an issue.)
> 
> Regarding the NAT draft, the basic need is for the HA to
> somehow verify that the IP SRC address is in fact from a
> NAT, and not some man-in-the-middle.  However, I'm not sure
> that given the current nature of NAT, if this is possible.
> I was looking at the STUN draft in midcomm WG as a possible hook,
> but I think this approach is also susceptible to man-in-the-middle.
> 
> It seems that establishing a MIP tunnel as above opens up greater
> risk for MN traffic hijacking.  However, as I'm not a security
> expert, I don't know for sure.  Perhaps you and others can shed
> some light on this.
> 
> Since NAT/MIP interaction is a real need in MIP deployments, hopefully
> we can ensure that we are not opening up any further security
> risks than base MIP.
> 
> Regards,
> Madhavi
> 
> On Fri, Apr 26, 2002 at 02:02:29PM +0200, Francis Dupont wrote:
> > I've just done a comment about NAT/NATPT traversal security
> > at IPCN and I believe it is useful to discuss about the raised
> > issue in this list.
> >
> > The basic problem is the HA has to trust the CoA found from the
> > source address in the IP header which can be forged by anyone
> > in the path (note this is different from my "trust the CoA given
> > by the MN argument" in a previous mail).
> >
> > I don't know if this is enough to restrict/reject the NAT traversal
> > proposal but at least the security section should *not* stay empty!
> >
> > Regards
> >
> > Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 10:46:56 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06368
	for ; Fri, 26 Apr 2002 10:46:55 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09913;
	Fri, 26 Apr 2002 07:46:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11010;
	Fri, 26 Apr 2002 07:46:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QEivGs012751
	for ; Fri, 26 Apr 2002 07:44:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QEiuEh012742
	for mobile-ip-dist; Fri, 26 Apr 2002 07:44:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QEiYGs012566
	for ; Fri, 26 Apr 2002 07:44:34 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18136
	for ; Fri, 26 Apr 2002 07:44:33 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03352
	for ; Fri, 26 Apr 2002 07:44:32 -0700 (PDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3QEiRB25365;
	Fri, 26 Apr 2002 09:44:28 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 26 Apr 2002 09:44:24 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC53@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'bob@marksmob.com'" ,
        "'Tony Johansson'"
	 
Cc: "'Fredrik Johansson'" ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-
	00.txt
Date: Fri, 26 Apr 2002 09:44:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1ED30.DA710E60"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1ED30.DA710E60
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Bob;
I am resending this email because I am not sure if it made it earlier.

I think the whole idea is to prevent this draft from mandating all Mobile
Nodes to include
AAA NAI extension with subtype 1 "HA" in the following scenarios:

1. When the Mobile Node sends a Registration Request for Re-Authentication:
MN will never be able to send the AAA NAI extension in the Registration 
request unless it recognizes and support that extension. Because, it
received 
it from HAAA through the FAAA and the FA in the Registration Reply message.
Legacy MN does not support any feature which requires this anyway.

2. When the Mobile Node request a static Mobile IP call. "specific IP
address"
ONLY those Mobile Node which again support and recognizes this extension
will be able to send it. Because, legacy Mobile Node are not configured with
AAA NAI extension for the HA anyway. Also, legacy MN does not support 
any feature which requires this to be added to the Registration Request.

However, I agree the proposed text may be very broad.

Tony/Bob,
Do you think the following text would be more specific?
It include all the text I proposed so far.

section 4. should read:
"
   The HA identity uses subtype 1 of the AAA NAI Extension.  It contains
   the NAI of the AAA interface of the HA in the form hostname@realm.
   Together the hostname and realm forms the complete FQDN
   (hostname.realm) of the HA's AAA interface.

   The home agent MUST provide HA identity in every registration reply 
   sent to the mobile node destined through the AAA infrastructure.

   A mobile node which support AAA NAI extension MUST provide HA 
   identity in every registration request sent when re-authenticating, 
   or when requesting a specific IP address at initial authentication.
"

section 5. should read:
"
   The AAAH identity uses subtype 2 of the AAA NAI Extension.  It
   contains the NAI of the home AAA server in the form hostname@realm.
   Together the hostname and realm forms the complete FQDN
   (hostname.realm) of the home AAA servers interface.

   The home agent MUST provide this in every registration reply sent to 
   the mobile node destined through the AAA infrastructure.

   A mobile node which support the AAA NAI extension MUST always 
   save the latest AAAH Identity received in the registration reply message 
   and MUST provide the AAAH Identity in every registration request sent 
    when re-authenticating.

   If the AAAH identity is present, the foreign agent MUST direct an
   authentication request to this home AAA server when authenticating
   the mobile node through the AAA infrastructure by means described in
   [2]
"

This will eliminate the need for the following text:
"The AAA NAI extension MUST only be used with the Diameter Mobile IPv4
application and MUST NOT be used with any other AAA protocol."


Regards; 
Ahmad Muhanna 
****************************************************************************
***************************


Hello Ahmad,
 
I'm still not totally comfortable with this new technique and its impact on
bandwidth-constrained links.
 
For RFC2002, the MN sent only the authentication extensions it knew it
needed. It knew if it had a
security association with the FA, and had to have a security association
with the HA.
 
For RFC3012, the MN could use the presence (or absence) of the Challenge to
determine which
extensions and parameters (like NAI) it included in the Registration
Request.
 
But for this new I-D, the MN does not get any clue at all. Therefore it
needs to include the extension
because it might be needed. This, it seems to me, is not so good for
bandwidth-constrained links.
As Tony pointed out, it seems that the MN must be configured to send or not
to send - I'd rather the
FA provided some clue.
 
Bob
 
-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna
Sent: Monday, April 22, 2002 3:38 PM
To: 'Tony Johansson'; bob@marksmob.com
Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
fredrik@ipunplugged.com
Subject: RE: [mobile-ip] RE: A Question
about:draft-ietf-mobileip-aaa-nai-00.txt


Hi Bob; 
Let me add to what Tony just said. 
I do not think that any MN needs to know anything about the type 
of AAA infrastructure the FA and HA are using to authenticate the MN. 
However, the MN Application is developed with certain standard in mind. 
(certain method of authentication) 
for example: 
1. ONLY RFC2002 Compliant MN: 
It assumes that it has a security association with both the FA and the 
HA. If it visit any FA where it shares a security association with, MN sends

RRQ message with MN-FA Authentication extension and it works just fine. 
2. ONLY RFC2002 & RFC3012 Compliant MN: 
RFC 3012 addressed properly the case of MN in 1 but offered a new 
mechanism for authenticating the MN to the FA using the FA Challenge 
and MN-AAA authentication extension. 
3. Now Latest MN with all of the above (RFC3220) and diameter compliant: 
MN includes AAA NAI extension and those FA which support diameter 
will use process it and those FA which does not support AAA NAI (skippable) 
will continue to use either method in 2 or 1. 


Regards; 
Ahmad Muhanna 


> -----Original Message----- 
> From: Tony Johansson [mailto:tony.johansson@ericsson.com] 
> Sent: Monday, April 22, 2002 4:15 PM 
> To: bob@marksmob.com 
> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Fredrik Johansson'; 
> mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com 
> Subject: Re: [mobile-ip] RE: A Question 
> about:draft-ietf-mobileip-aaa-nai-00.txt 
> 
> 
> Hi Bob, 
> 
> Yes, it's based on MN configuration and FA configuration. Same as e.g 
> the handling of RFC3012/RFC3012bis and the 
> draft-ietf-mobileip-aaa-key-09.txt. 
> 
> The advertisements will not tell you anything reading this. 
> 
> /Tony 
> 
> Robert J Marks wrote: 
> 
> >  Perhaps someone can explain how the MN knows the type of AAA 
> > infrastructure used by the FA nd HA. I don't believe any information 
> > is included in any advertisement. Does this "solution" rely 
> only upon 
> > MN configuration, or am I missing something here? Thanks.Bob 
> > -----Original Message----- 
> > From: owner-mobile-ip@sunroof.eng.sun.com 
> > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad 
> > Muhanna 
> > Sent: Monday, April 22, 2002 1:59 PM 
> > To: 'Tony Johansson' 
> > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> > fredrik@ipunplugged.com 
> > Subject: RE: [mobile-ip] RE: A Question 
> > about:draft-ietf-mobileip-aaa-nai-00.txt 
> > 
> > Hello Tony; 
> > YES; this solves the problem. 
> > 
> > Regards; 
> > Ahmad Muhanna 
> > 
> > > -----Original Message----- 
> > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] 
> > > Sent: Monday, April 22, 2002 2:51 PM 
> > > To: Muhanna, Ahmad [RICH1:2Q20:EXCH] 
> > > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> > > fredrik@ipunplugged.com 
> > > Subject: Re: [mobile-ip] RE: A Question 
> > > about:draft-ietf-mobileip-aaa-nai-00.txt 
> > > 
> > > 
> > > Hello Ahmad, 
> > > 
> > > Ahmad Muhanna wrote: 
> > > 
> > > 
> > > > I do not think that It is the same!! 
> > > > RFC3012 introduced a new way of authenticating the MN to the FA 
> > > > without violating 
> > > > backward compatibility of RFC2002 or later RFC3220. 
> > > > Mobile Node does not know which way or the standard the 
> > > foreign agent 
> > > > uses to 
> > > > authenticate it. It could be through RADIUS, AAA, Diameter 
> > > who knows. 
> > > 
> > > > 
> > > > The point here is that this draft mandates that every 
> Mobile Node 
> > > > include AAA NAI extension 
> > > > with subtype of 1 whenever it requests static Mobile IP 
> or during 
> > > > Inter-FA handoff. 
> > > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile 
> > > Node which 
> > > > exist right now, 
> > > > does not do this. 
> > > > After this draft becomes a standard, according to this 
> > > section, MN is 
> > > > not following the 
> > > > standard by not sending AAA NAI extension in initial 
> Registration 
> > > > Request or during re-authentication.!!! 
> > > > 
> > > > This is not backward compatible!!!! 
> > > 
> > > Okay, so how about adding the following statement to the 
> > introduction: 
> > > 
> > > "The AAA NAI extension MUST only be used with the Diameter Mobile 
> > IPv4 
> > > application and MUST NOT be used with any other AAA protocol." 
> > > 
> > > 
> > > 
> > > /Tony 
> > > 
> > > 
> > > 
> 
> 

------_=_NextPart_001_01C1ED30.DA710E60
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt




Hello Bob;

I am resending this email because I am not sure if it made it earlier.




I think the whole idea is to prevent this draft from mandating all Mobile Nodes to include

AAA NAI extension with subtype 1 "HA" in the following scenarios:




1. When the Mobile Node sends a Registration Request for Re-Authentication:

MN will never be able to send the AAA NAI extension in the Registration 

request unless it recognizes and support that extension. Because, it received 

it from HAAA through the FAAA and the FA in the Registration Reply message.

Legacy MN does not support any feature which requires this anyway.




2. When the Mobile Node request a static Mobile IP call. "specific IP address"

ONLY those Mobile Node which again support and recognizes this extension

will be able to send it. Because, legacy Mobile Node are not configured with

AAA NAI extension for the HA anyway. Also, legacy MN does not support 

any feature which requires this to be added to the Registration Request.




However, I agree the proposed text may be very broad.




Tony/Bob,

Do you think the following text would be more specific?

It include all the text I proposed so far.




section 4. should read:

"

   The HA identity uses subtype 1 of the AAA NAI Extension.  It contains

   the NAI of the AAA interface of the HA in the form hostname@realm.

   Together the hostname and realm forms the complete FQDN

   (hostname.realm) of the HA's AAA interface.




   The home agent MUST provide HA identity in every registration reply 

   sent to the mobile node destined through the AAA infrastructure.




   A mobile node which support AAA NAI extension MUST provide HA 

   identity in every registration request sent when re-authenticating, 

   or when requesting a specific IP address at initial authentication.

"




section 5. should read:

"

   The AAAH identity uses subtype 2 of the AAA NAI Extension.  It

   contains the NAI of the home AAA server in the form hostname@realm.

   Together the hostname and realm forms the complete FQDN

   (hostname.realm) of the home AAA servers interface.




   The home agent MUST provide this in every registration reply sent to 

   the mobile node destined through the AAA infrastructure.




   A mobile node which support the AAA NAI extension MUST always 

   save the latest AAAH Identity received in the registration reply message 

   and MUST provide the AAAH Identity in every registration request sent 

    when re-authenticating.




   If the AAAH identity is present, the foreign agent MUST direct an

   authentication request to this home AAA server when authenticating

   the mobile node through the AAA infrastructure by means described in

   [2]

"




This will eliminate the need for the following text:

"The AAA NAI extension MUST only be used with the Diameter Mobile IPv4

application and MUST NOT be used with any other AAA protocol."






Regards; 

Ahmad Muhanna 

*******************************************************************************************************






Hello Ahmad,

 

I'm still not totally comfortable with this new technique and its impact on bandwidth-constrained links.

 

For RFC2002, the MN sent only the authentication extensions it knew it needed. It knew if it had a

security association with the FA, and had to have a security association with the HA.

 

For RFC3012, the MN could use the presence (or absence) of the Challenge to determine which

extensions and parameters (like NAI) it included in the Registration Request.

 

But for this new I-D, the MN does not get any clue at all. Therefore it needs to include the extension

because it might be needed. This, it seems to me, is not so good for bandwidth-constrained links.

As Tony pointed out, it seems that the MN must be configured to send or not to send - I'd rather the

FA provided some clue.

 

Bob

 

-----Original Message-----

From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna

Sent: Monday, April 22, 2002 3:38 PM

To: 'Tony Johansson'; bob@marksmob.com

Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com

Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt






Hi Bob; 

Let me add to what Tony just said. 

I do not think that any MN needs to know anything about the type 

of AAA infrastructure the FA and HA are using to authenticate the MN. 

However, the MN Application is developed with certain standard in mind. 

(certain method of authentication) 

for example: 

1. ONLY RFC2002 Compliant MN: 

It assumes that it has a security association with both the FA and the 

HA. If it visit any FA where it shares a security association with, MN sends 

RRQ message with MN-FA Authentication extension and it works just fine. 

2. ONLY RFC2002 & RFC3012 Compliant MN: 

RFC 3012 addressed properly the case of MN in 1 but offered a new 

mechanism for authenticating the MN to the FA using the FA Challenge 

and MN-AAA authentication extension. 

3. Now Latest MN with all of the above (RFC3220) and diameter compliant: 

MN includes AAA NAI extension and those FA which support diameter 

will use process it and those FA which does not support AAA NAI (skippable) 

will continue to use either method in 2 or 1. 






Regards; 

Ahmad Muhanna 






> -----Original Message----- 

> From: Tony Johansson [mailto:tony.johansson@ericsson.com] 

> Sent: Monday, April 22, 2002 4:15 PM 

> To: bob@marksmob.com 

> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Fredrik Johansson'; 

> mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com 

> Subject: Re: [mobile-ip] RE: A Question 

> about:draft-ietf-mobileip-aaa-nai-00.txt 

> 

> 

> Hi Bob, 

> 

> Yes, it's based on MN configuration and FA configuration. Same as e.g 

> the handling of RFC3012/RFC3012bis and the 

> draft-ietf-mobileip-aaa-key-09.txt. 

> 

> The advertisements will not tell you anything reading this. 

> 

> /Tony 

> 

> Robert J Marks wrote: 

> 

> >  Perhaps someone can explain how the MN knows the type of AAA 

> > infrastructure used by the FA nd HA. I don't believe any information 

> > is included in any advertisement. Does this "solution" rely 

> only upon 

> > MN configuration, or am I missing something here? Thanks.Bob 

> > -----Original Message----- 

> > From: owner-mobile-ip@sunroof.eng.sun.com 

> > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad 

> > Muhanna 

> > Sent: Monday, April 22, 2002 1:59 PM 

> > To: 'Tony Johansson' 

> > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 

> > fredrik@ipunplugged.com 

> > Subject: RE: [mobile-ip] RE: A Question 

> > about:draft-ietf-mobileip-aaa-nai-00.txt 

> > 

> > Hello Tony; 

> > YES; this solves the problem. 

> > 

> > Regards; 

> > Ahmad Muhanna 

> > 

> > > -----Original Message----- 

> > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] 

> > > Sent: Monday, April 22, 2002 2:51 PM 

> > > To: Muhanna, Ahmad [RICH1:2Q20:EXCH] 

> > > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 

> > > fredrik@ipunplugged.com 

> > > Subject: Re: [mobile-ip] RE: A Question 

> > > about:draft-ietf-mobileip-aaa-nai-00.txt 

> > > 

> > > 

> > > Hello Ahmad, 

> > > 

> > > Ahmad Muhanna wrote: 

> > > 

> > > 

> > > > I do not think that It is the same!! 

> > > > RFC3012 introduced a new way of authenticating the MN to the FA 

> > > > without violating 

> > > > backward compatibility of RFC2002 or later RFC3220. 

> > > > Mobile Node does not know which way or the standard the 

> > > foreign agent 

> > > > uses to 

> > > > authenticate it. It could be through RADIUS, AAA, Diameter 

> > > who knows. 

> > > 

> > > > 

> > > > The point here is that this draft mandates that every 

> Mobile Node 

> > > > include AAA NAI extension 

> > > > with subtype of 1 whenever it requests static Mobile IP 

> or during 

> > > > Inter-FA handoff. 

> > > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile 

> > > Node which 

> > > > exist right now, 

> > > > does not do this. 

> > > > After this draft becomes a standard, according to this 

> > > section, MN is 

> > > > not following the 

> > > > standard by not sending AAA NAI extension in initial 

> Registration 

> > > > Request or during re-authentication.!!! 

> > > > 

> > > > This is not backward compatible!!!! 

> > > 

> > > Okay, so how about adding the following statement to the 

> > introduction: 

> > > 

> > > "The AAA NAI extension MUST only be used with the Diameter Mobile 

> > IPv4 

> > > application and MUST NOT be used with any other AAA protocol." 

> > > 

> > > 

> > > 

> > > /Tony 

> > > 

> > > 

> > > 

> 

> 





------_=_NextPart_001_01C1ED30.DA710E60--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 11:16:47 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07411
	for ; Fri, 26 Apr 2002 11:16:46 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25131;
	Fri, 26 Apr 2002 08:16:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28281;
	Fri, 26 Apr 2002 08:16:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QFE2Gs028133
	for ; Fri, 26 Apr 2002 08:14:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QFE1QQ028120
	for mobile-ip-dist; Fri, 26 Apr 2002 08:14:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QFDhGs027977
	for ; Fri, 26 Apr 2002 08:13:43 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08911
	for ; Fri, 26 Apr 2002 08:13:44 -0700 (PDT)
Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA01314
	for ; Fri, 26 Apr 2002 09:13:43 -0600 (MDT)
Received: from unknown (HELO EmadQ) (emadaq@217.144.4.21 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Apr 2002 15:13:42 -0000
Reply-To: 
From: "Emad Qaddoura" 
To: "'Annika Jonsson'" ,
        
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Fri, 26 Apr 2002 18:13:31 +0200
Message-ID: <001101c1ed3d$51d0c930$150490d9@EmadQ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <5.0.0.25.0.20020425151932.0236f220@era-t.ericsson.se>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Annika,

	My main concern about this draft:

1) Has there been any studies/scenarios about the impact to in-flight
traffic to the MN, while it is performing regional re-registrations? 

2) How does the old FA handle the data that is received while the MN
re-registers with a new FA? 

3) I understand this is not any worse from the normal (in 2002) case
without regional registrations, but the case below can make such delay
longer.

From Section 5.0, 4th paragraph, 
"If the advertised GFA is not the same as the one the mobile node has
   registered as its care-of address, and if the mobile node is still
   within the same domain as it was when it registered that care-of
   address, the mobile node MAY try to perform a regional registration
   with its registered GFA. If the foreign agent cannot support
   regional registration to a GFA, other than advertised, the foreign
   agent denies the regional registration with code UNKNOWN_GFA (see
   section 9.3).  In this case the MN has to do a new home registration
   via the new GFA."

As you see, there is extra registration step here,( if the current GFA
used by the MN is not supported by the FA), adding possible delays to
traffic, would it be reasonable to expect all FAs in the same domain to
handle the regional registration to the different GFAs. Or do I
misunderstand the above paragraph?

With the route optimization draft being optional extensions, we should
be concerned about any additional delays to traffic destined to the MN.

Thanks,
EQ 
 





From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 11:33:37 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07943
	for ; Fri, 26 Apr 2002 11:33:36 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28164;
	Fri, 26 Apr 2002 09:33:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09325;
	Fri, 26 Apr 2002 08:32:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QFVMGs007022
	for ; Fri, 26 Apr 2002 08:31:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QFVKSb007002
	for mobile-ip-dist; Fri, 26 Apr 2002 08:31:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QFUwGs006828
	for ; Fri, 26 Apr 2002 08:30:58 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16050
	for ; Fri, 26 Apr 2002 08:31:00 -0700 (PDT)
Received: from cisco.com (shako.cisco.com [64.102.17.78])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11995
	for ; Fri, 26 Apr 2002 09:30:59 -0600 (MDT)
Received: (from mchandra@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA21942;
	Fri, 26 Apr 2002 11:30:55 -0400 (EDT)
Date: Fri, 26 Apr 2002 11:30:55 -0400
From: "Madhavi W. Chandra" 
To: Emad Qaddoura 
Cc: "'Annika Jonsson'" ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Last Call:  Regional Tunneling input
Message-ID: <20020426113055.D19679@cisco.com>
References: <5.0.0.25.0.20020425151932.0236f220@era-t.ericsson.se> <001101c1ed3d$51d0c930$150490d9@EmadQ>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <001101c1ed3d$51d0c930$150490d9@EmadQ>; from emadaq@yahoo.com on Fri, Apr 26, 2002 at 06:13:31PM +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Annika,

On Fri, Apr 26, 2002 at 06:13:31PM +0200, Emad Qaddoura wrote:
> Annika,
> 
> 	My main concern about this draft:
> 
> 1) Has there been any studies/scenarios about the impact to in-flight
> traffic to the MN, while it is performing regional re-registrations? 
> 
> 2) How does the old FA handle the data that is received while the MN
> re-registers with a new FA? 
> 
> 3) I understand this is not any worse from the normal (in 2002) case
> without regional registrations, but the case below can make such delay
> longer.
> 
> >From Section 5.0, 4th paragraph, 
> "If the advertised GFA is not the same as the one the mobile node has
>    registered as its care-of address, and if the mobile node is still
>    within the same domain as it was when it registered that care-of
>    address, the mobile node MAY try to perform a regional registration
>    with its registered GFA. If the foreign agent cannot support
>    regional registration to a GFA, other than advertised, the foreign
>    agent denies the regional registration with code UNKNOWN_GFA (see
>    section 9.3).  In this case the MN has to do a new home registration
>    via the new GFA."
> 
> As you see, there is extra registration step here,( if the current GFA
> used by the MN is not supported by the FA), adding possible delays to
> traffic, would it be reasonable to expect all FAs in the same domain to
> handle the regional registration to the different GFAs. Or do I
> misunderstand the above paragraph?

This seems to also be the case when the MN sets the CoA=0.0.0.0,
and the HA doesn't support Regional Registrations...two RRQ trips
if the MN attempts to register again with a non-zero CoA.  
Can you please comment on this as well?

Thanks,
Madhavi

> With the route optimization draft being optional extensions, we should
> be concerned about any additional delays to traffic destined to the MN.
> 
> Thanks,
> EQ 
>  
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 12:00:56 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08928
	for ; Fri, 26 Apr 2002 12:00:55 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01155;
	Fri, 26 Apr 2002 10:00:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01720;
	Fri, 26 Apr 2002 09:00:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QFxGGs021300
	for ; Fri, 26 Apr 2002 08:59:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QFxG5J021291
	for mobile-ip-dist; Fri, 26 Apr 2002 08:59:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QFxAGs021246
	for ; Fri, 26 Apr 2002 08:59:11 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27573
	for ; Fri, 26 Apr 2002 11:59:12 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA02245
	for mobile-ip@sunroof.eng.sun.com; Fri, 26 Apr 2002 12:00:12 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QBotGs009634
	for ; Fri, 26 Apr 2002 04:50:55 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28035
	for ; Fri, 26 Apr 2002 04:50:56 -0700 (PDT)
Received: from abssrv1.absnet.no ([217.170.130.7])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05205
	for ; Fri, 26 Apr 2002 05:50:54 -0600 (MDT)
Received: from [217.170.129.11] by abssrv1.absnet.no (NTMail 7.01.0023/NT4162.01.96646795) with ESMTP id qsnqlfaa for mobile-ip@sunroof.eng.sun.com; Fri, 26 Apr 2002 13:41:19 +0200
Message-ID: <003601c1ed18$b8942880$0b81aad9@cube>
Reply-To: =?iso-8859-1?Q?St=E5le_Olsen?= 
From: =?iso-8859-1?Q?St=E5le_Olsen?= 
To: 
References: 
Subject: [mobile-ip] Moobil Node drivers and software
Date: Fri, 26 Apr 2002 13:51:29 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3QBotGs009644
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

I have been trying to get an overview over the different solutions for the MN.

I've found the following:

    1. Cisco points to a Third party vendor called Birdstep.com
    2. Intel seems to be puting something on the market rigth now.
    3. There are several Unix/linux implementations.

Any feedback on where i / we can find a real good MS alternative until they implement it them selfs would be great !!  :)






From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 12:41:23 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10168
	for ; Fri, 26 Apr 2002 12:41:23 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03472;
	Fri, 26 Apr 2002 10:41:23 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28806;
	Fri, 26 Apr 2002 09:41:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QGdpGs011317
	for ; Fri, 26 Apr 2002 09:39:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QGdpRT011315
	for mobile-ip-dist; Fri, 26 Apr 2002 09:39:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QGdmGs011290
	for ; Fri, 26 Apr 2002 09:39:48 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09177
	for ; Fri, 26 Apr 2002 12:39:49 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA02265
	for mobile-ip@sunroof.eng.sun.com; Fri, 26 Apr 2002 12:40:49 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QDtSGs020914
	for ; Fri, 26 Apr 2002 06:55:28 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12947
	for ; Fri, 26 Apr 2002 06:55:28 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27288
	for ; Fri, 26 Apr 2002 07:55:27 -0600 (MDT)
Received: from tom by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian))
	id 1716Bk-0001oy-00; Fri, 26 Apr 2002 16:55:04 +0300
Date: Fri, 26 Apr 2002 16:55:04 +0300
From: Tom K Weckstrom 
To: James Kempf 
Cc: "Charles E. Perkins" ,
        "Madhavi W. Chandra" ,
        Annika Jonsson ,
        mobile-ip@sunroof.eng.sun.com,
        Eva Gustafsson 
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Message-ID: <20020426135504.GT29152@muminmamman.lifix.fi>
References:  <3CC818C0.1E628F82@iprg.nokia.com> <20020425121142.A7334@cisco.com> <3CC82CA7.78332B19@iprg.nokia.com> <007601c1eca2$d981bce0$8e6015ac@T23KEMPF>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <007601c1eca2$d981bce0$8e6015ac@T23KEMPF>
User-Agent: Mutt/1.3.25i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

James,


On Thu, Apr 25, 2002 at 02:47:47PM -0700, James Kempf wrote:
> Hi Charlie,
> 
> > > There is no doubt that your draft is the result of extensive
> > > research.
> > 
> > In this case, we also have publications, simulations, and
> > implementations to back up the research.
> > 
> 
> Did your simulations look at what happened if a GFA fails?
> 
>             jak
---end quoted text---

I think this question is irrelevant. Let me explain with some
additional comments/questions:

- What happens, if a FA serving a single foreign network (without the
  hierarchy) happens to fail?
  --> The users are without the MIP service.

- What do you do, if you suspect that your firewall, VPN GW, high end
  router, or GFA may fail and you do not want the users be affected?
  --> You deploy a High Availability solution. There are solutions out
      there for the above mentioned network elements, probably
      excluding GFA at the moment.

- Should the High Availability solution be somehow bound to this
  standardisation proposal at hand?
  --> Why should it be? That can be handled separately. That can be
      standardized separately, if need be. To me, it looks like High
      Availability solutions would most often be proporietary.


Regards, Tom

-- 
Tom Weckström                   PGP id:  E1DB55E9
Lifix Systems Oy        Mobile:  +358 50 350 5997
Innopoli 2	      Tekniikantie 14	      FIN-02150 Espoo



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 12:41:37 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10181
	for ; Fri, 26 Apr 2002 12:41:32 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11964;
	Fri, 26 Apr 2002 10:41:32 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28978;
	Fri, 26 Apr 2002 09:41:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QGeMGs011373
	for ; Fri, 26 Apr 2002 09:40:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QGeLld011372
	for mobile-ip-dist; Fri, 26 Apr 2002 09:40:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QGeJGs011365
	for ; Fri, 26 Apr 2002 09:40:20 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19226
	for ; Fri, 26 Apr 2002 12:40:21 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA02270
	for mobile-ip@sunroof.eng.sun.com; Fri, 26 Apr 2002 12:41:21 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QET0Gs004831
	for ; Fri, 26 Apr 2002 07:29:00 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19962
	for ; Fri, 26 Apr 2002 07:29:01 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18138
	for ; Fri, 26 Apr 2002 08:29:00 -0600 (MDT)
Received: from tom by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian))
	id 1716iT-0002Zx-00; Fri, 26 Apr 2002 17:28:53 +0300
Date: Fri, 26 Apr 2002 17:28:53 +0300
From: Tom K Weckstrom 
To: mobile-ip@sunroof.eng.sun.com
Cc: "Charles E. Perkins" ,
        Annika Jonsson ,
        Eva Gustafsson 
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Message-ID: <20020426142853.GU29152@muminmamman.lifix.fi>
References: <697DAA22C5004B4596E033803A7CEF44096934@daebe007.NOE.Nokia.com> <20020422223042.GQ12913@muminmamman.lifix.fi> <20020422234829.GT12913@muminmamman.lifix.fi> <20020422235326.GU12913@muminmamman.lifix.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20020422235326.GU12913@muminmamman.lifix.fi>
User-Agent: Mutt/1.3.25i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Hello all.

On Tue, Apr 23, 2002 at 02:53:26AM +0300, Tom K Weckstrom wrote:
> Hello.
> 
> Please, read the attached text file for my comments on
> draft-ietf-mobileip-reg-tunnel-06.txt.
> 
> Please, consider this as a first stage and by no means exhaustive
> "issue list". I'll get back with concrete proposals later this week.
---end quoted text---

My time ran out for sending the concrete proposals I promised
during this week, so here we go. In a nutshell:

- Clarify the draft so that there is one way to implement the solution
  (the MUST features) and then try to clarify the different options
  around the MUST solution. The current -06 version offers sooo many
  possibilities. Also some optional features may be removed
  altogether, e.g. MN registering directly to the GFA.

- I propose a signaling, where upon the handoff, ony one registration
  request is sent and only one reply is sent back. This is how
  Dynamics - HUT Mobile IP works when a hierarchical model is
  deployed. The details of the messages can be left for future
  discussion. The current message design from v. -06 can be used
  mostly. As an addition, the FAs need to learn about their children
  in the tree. The draft can propose manual configuration, or an
  automated registration protocol for FAs. This has also been
  implemented by Dynamics Group, so just copy that working solution to
  the specs. The use of BUs (ala route optim.) as it is done in the
  current rdaft can be allowed, if zero packet loss is of high
  importance, but to me it is an additional plus that itself should
  not be used as an integral part of regional
  tunneling/registrations. I know, why it is used as an integral part
  at the moment, but it does not need to be so, if the FAs know their
  children in the tree.

- Reach for backwards compatibility:
	- Advertise a single care of address (the GFA address)
	- RFC 3220 compliant implementations would benefit from
          regionalised registrations, but GFA would always handle the
          handoff as a crossover FA.
	- If complete transparency is desired, there is an issue with
          nonce based replay protection. We have to work this out.

- Give "candy" for those who implement the necessary extensions to
  their clients:
	- An intelligent client would add a PFAN type extension to
          tell the hierarhcy, the previous FA through which it
          registered. --> Faster handoffs handled lower in the hierarchy.

- Make a list / matrix of conflicting proposals, so that we can see
  where the prolems are. The current discussion about the need of the
  draft, etc. can also be lifted to the next level.

- Specify the way to distribute keys between GFA, the RFAs and the
  FAs. Again, an implementation and specification about this is
  available in http://www.cs.hut.fi/Research/Dynamics/

I hope this gets the discussion further and to a generally acceptable
-07 version of the draft.

I'll be on vacation next week, but I'll check the thread and give
further comments as soon as I return. I'll be happy to help in
defining the next version of the draft.

Best regards, Tom

-- 
Tom Weckström                   PGP id:  E1DB55E9
Lifix Systems Oy        Mobile:  +358 50 350 5997
Innopoli 2	      Tekniikantie 14	      FIN-02150 Espoo



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 12:51:02 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10427
	for ; Fri, 26 Apr 2002 12:51:02 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23707;
	Fri, 26 Apr 2002 09:50:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04446;
	Fri, 26 Apr 2002 09:50:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QGnIGs012688
	for ; Fri, 26 Apr 2002 09:49:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QGnIci012687
	for mobile-ip-dist; Fri, 26 Apr 2002 09:49:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QGnEGs012670
	for ; Fri, 26 Apr 2002 09:49:14 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03987
	for ; Fri, 26 Apr 2002 09:49:16 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17017
	for ; Fri, 26 Apr 2002 10:49:16 -0600 (MDT)
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 JAA16839;
	Fri, 26 Apr 2002 09:49:15 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3QGnEA08244;
	Fri, 26 Apr 2002 09:49:14 -0700
X-mProtect: <200204261649> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdpAKQni; Fri, 26 Apr 2002 09:48:34 PDT
Message-ID: <3CC984E2.30BAF3CF@iprg.nokia.com>
Date: Fri, 26 Apr 2002 09:48:34 -0700
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: Michael Thomas , mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
References: <3CB5DB1F.90909@lancaster.ac.uk>	<012801c1e198$1fcb99c0$7e6015ac@T23KEMPF>	<3CBDBC62.21C19B77@iprg.nokia.com>	<000001c1e7b6$9288fd80$746015ac@T23KEMPF>	<3CC0B44C.DB862958@iprg.nokia.com>	<046701c1e804$7016f330$736015ac@AlperVAIO>	<3CC58E3C.86B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

James Kempf wrote:

> Rajeev,
>
> I rather favor some mechanism to inform the MN after the move has
> occured. For example, sending the MN an ICMP REDIRECT message after the
> access router has changed, as Michael has suggested, would do the trick,
> as it would avoid the problem of the signaling getting cut off
> prematurely.

REDIRECT is not sent _after_ the change of access router, but before
the MN moves. It is a notification for an impending handover, at least
that was my understanding and the basis for our now old proposal.


>
>
> Buffering in the context of predictive algorithms that utilize
> prehandover over-the-air siginaling (such as FMIPv6) is difficult
> because the amount of data to be buffered is not deterministic. It
> depends on the speed of the mobile node, the data rate on the channel,
> and the Layer 2 handover latency. Calculating the size of the buffer
> becomes a major deployment headache. One can set the buffer size to
> catch N standard deviations, but what about the N+1st? In particular,
> the N+1st could be a rare event where the consequences of not handling
> it are severe, like an emergency vehicle that moves much more quickly
> than the average traffic.
>

It could be simpler: handover delay over the expected inter-packet arrival
time.
So, if expected handover delay is 100 ms, with 20 ms inter-packet
separation for
voice, you need room for 5 packets. Charlie has looked into buffering in
greater detail, and we have an implementation as well. We need to study the

performance aspects.

>
> In contrast, predictive algorithms that utilize network predictive
> information to switch the routing without prehandover involvement of the
> mobile don't run into this problem. The buffer size is deterministic,
> making deployment much easier.
>

Ok. This is a design choice. For handover smoothing, which is a related
albeit separate topic, we need to evaluate the available options.

>
> So I favor a statement in the FMIPv6 draft that the new AR SHOULD send
> an ICMP REDIRECT message to the mobile node if BETH handover is
> utilized.
>

Well, I don't believe that was the proposal, but if you wish BETH to have
such a message, we could consider it.

Regards,

-Rajeev


>
> Specific responses to your questions below.
>
>             jak
>
> > Just curious if you did try the case when the router waited for the MN
> to
> > send authorization..
> >
>
> We did not examine that case. Obviously, it would delay handover even
> more. I think there is some work to be done here on context transfer for
> speeding authentication. I believe 802.11i is looking at preflooding
> authentication to surrounding access points in order to avoid handover
> delay, a similar technique or targeted context transfer could be used
> for cellular.
>
> > Good. Hopefully, we can compare notes. I have recently seen
> > some preliminary results from folks at UCLA on FMIPv6 which
> > closely match our preliminary tests on FMIPv6 (for WLAN).
> >
>
> I've also seen some results from the EU Moby Dick project on FMIPv6
> which match your results. However, I think more work needs to be done to
> characterize the behavior of FMIPv6 under load. In particular, the
> "hack" of forcing handover by resetting the BSSid effectively makes the
> prehandover layer 2 trigger time deterministic, so the experimenter can
> optimize this time to avoid having the FMIPv6 signaling cut off. In
> reality, this time will be a random variable, just like it is for
> cellular, if the 802.11 committee ever manages to define its handover
> conditions precisely enough so the NIC manufacuturers can offer a
> uniform L2 trigger API.
>
>             jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 13:08:59 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11013
	for ; Fri, 26 Apr 2002 13:08:54 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26338;
	Fri, 26 Apr 2002 10:08:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12873;
	Fri, 26 Apr 2002 10:08:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QH7FGs013247
	for ; Fri, 26 Apr 2002 10:07:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QH7FsL013246
	for mobile-ip-dist; Fri, 26 Apr 2002 10:07:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QH7BGs013239
	for ; Fri, 26 Apr 2002 10:07:11 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25353
	for ; Fri, 26 Apr 2002 10:07:13 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26734
	for ; Fri, 26 Apr 2002 11:07:13 -0600 (MDT)
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 KAA17913;
	Fri, 26 Apr 2002 10:07:13 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3QH7Bo32670;
	Fri, 26 Apr 2002 10:07:11 -0700
X-mProtect: <200204261707> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdR5nJh7; Fri, 26 Apr 2002 10:07:09 PDT
Message-ID: <3CC9893E.69C5DFA9@iprg.nokia.com>
Date: Fri, 26 Apr 2002 10:07:10 -0700
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: keiichi@iij.ad.jp
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO
References: <20020425.184505.06470684.keiichi@iij.ad.jp>
		<3CC842BD.A42F7D0F@iprg.nokia.com> <20020426.150520.32793746.keiichi@iij.ad.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Keiichi SHIMA / $BEg7D0l(B wrote:

> 
> To check if the packet has a BU or not, we must chase all the exthdrs
> before processing a HAO because a BU is included in a MH which is the
> last exthdr.  Also, to check if the packet satisfies the security
> policy, we must process the ESP header before processing a HAO...
> Hmm..
> 
> I tend to agree with the Francis's idea to process a HAO if the next
> header value of the destination option header which contains a HAO is
> ESP.  This makes it simple to implement a HAO processing.

cool... fine with me.

Vijay


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 13:48:02 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16515
	for ; Fri, 26 Apr 2002 13:48:01 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01330;
	Fri, 26 Apr 2002 11:48:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20711;
	Fri, 26 Apr 2002 10:47:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QHkHGs027254
	for ; Fri, 26 Apr 2002 10:46:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QHkG7q027244
	for mobile-ip-dist; Fri, 26 Apr 2002 10:46:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QHjwGs027104
	for ; Fri, 26 Apr 2002 10:45:58 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19511
	for ; Fri, 26 Apr 2002 10:45:58 -0700 (PDT)
Received: from hosting-network.com (NODE1.HOSTING-NETWORK.COM [66.216.6.1] (may be forged))
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA07595
	for ; Fri, 26 Apr 2002 11:45:57 -0600 (MDT)
Received: (qmail 58653 invoked from network); 26 Apr 2002 17:47:36 -0000
Received: from unknown (HELO dell8100rjm) (12.251.150.156)
  by node-28.hosting-network.com with SMTP; 26 Apr 2002 17:47:36 -0000
Reply-To: 
From: "Robert J Marks" 
To: "'Ahmad Muhanna'" ,
        "'Tony Johansson'" 
Cc: "'Fredrik Johansson'" ,
        
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
Date: Fri, 26 Apr 2002 12:45:31 -0500
Organization: Marks Mobile Consulting, LLC
Message-ID: <008f01c1ed4a$2981cda0$6501a8c0@dell8100rjm>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0090_01C1ED20.40ABC5A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC53@zrc2c013.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_0090_01C1ED20.40ABC5A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Ahmad,
 
I received your previous email correctly, but was still considering my
reply. Please excuse the delay.
 
I'm concerned with the following scenario. If a FA supports both RFC3012
and this I-D, then it will include a Challenge Extension in any Agent
Advertisement it sends. A MN entering an area served by the FA will not
know whether the FA "also" supports this I-D, and so must include the
AAA NAI Extension to cover that possibility. I grant that once the MN
receives a Registration Reply, it will know what to do as long as it
stays in the area serviced by the FA. However, this is Mobile IP, not
Nomadic IP, so I expect the MN to move, often, and to face the exact
same situation with the next FA it encounters.
 
I guess no one wants to use another bit in the advertisement to indicate
the type of AAA infrastructure in use. So is there some other way to
provide a clue to the MN and still support backward compatibility and
still conserve bandwidth?
 
Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna
Sent: Friday, April 26, 2002 8:44 AM
To: 'bob@marksmob.com'; 'Tony Johansson'
Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] RE: A Question
about:draft-ietf-mobileip-aaa-nai-00.txt



Hello Bob; 
I am resending this email because I am not sure if it made it earlier. 

I think the whole idea is to prevent this draft from mandating all
Mobile Nodes to include 
AAA NAI extension with subtype 1 "HA" in the following scenarios: 

1. When the Mobile Node sends a Registration Request for
Re-Authentication: 
MN will never be able to send the AAA NAI extension in the Registration 
request unless it recognizes and support that extension. Because, it
received 
it from HAAA through the FAAA and the FA in the Registration Reply
message. 
Legacy MN does not support any feature which requires this anyway. 

2. When the Mobile Node request a static Mobile IP call. "specific IP
address" 
ONLY those Mobile Node which again support and recognizes this extension

will be able to send it. Because, legacy Mobile Node are not configured
with 
AAA NAI extension for the HA anyway. Also, legacy MN does not support 
any feature which requires this to be added to the Registration Request.


However, I agree the proposed text may be very broad. 

Tony/Bob, 
Do you think the following text would be more specific? 
It include all the text I proposed so far. 

section 4. should read: 
" 
   The HA identity uses subtype 1 of the AAA NAI Extension.  It contains

   the NAI of the AAA interface of the HA in the form hostname@realm. 
   Together the hostname and realm forms the complete FQDN 
   (hostname.realm) of the HA's AAA interface. 

   The home agent MUST provide HA identity in every registration reply 
   sent to the mobile node destined through the AAA infrastructure. 

   A mobile node which support AAA NAI extension MUST provide HA 
   identity in every registration request sent when re-authenticating, 
   or when requesting a specific IP address at initial authentication. 
" 

section 5. should read: 
" 
   The AAAH identity uses subtype 2 of the AAA NAI Extension.  It 
   contains the NAI of the home AAA server in the form hostname@realm. 
   Together the hostname and realm forms the complete FQDN 
   (hostname.realm) of the home AAA servers interface. 

   The home agent MUST provide this in every registration reply sent to 
   the mobile node destined through the AAA infrastructure. 

   A mobile node which support the AAA NAI extension MUST always 
   save the latest AAAH Identity received in the registration reply
message 
   and MUST provide the AAAH Identity in every registration request sent

    when re-authenticating. 

   If the AAAH identity is present, the foreign agent MUST direct an 
   authentication request to this home AAA server when authenticating 
   the mobile node through the AAA infrastructure by means described in 
   [2] 
" 

This will eliminate the need for the following text: 
"The AAA NAI extension MUST only be used with the Diameter Mobile IPv4 
application and MUST NOT be used with any other AAA protocol." 


Regards; 
Ahmad Muhanna 
************************************************************************
******************************* 


Hello Ahmad, 
  
I'm still not totally comfortable with this new technique and its impact
on bandwidth-constrained links. 
  
For RFC2002, the MN sent only the authentication extensions it knew it
needed. It knew if it had a 
security association with the FA, and had to have a security association
with the HA. 
  
For RFC3012, the MN could use the presence (or absence) of the Challenge
to determine which 
extensions and parameters (like NAI) it included in the Registration
Request. 
  
But for this new I-D, the MN does not get any clue at all. Therefore it
needs to include the extension 
because it might be needed. This, it seems to me, is not so good for
bandwidth-constrained links. 
As Tony pointed out, it seems that the MN must be configured to send or
not to send - I'd rather the 
FA provided some clue. 
  
Bob 
  
-----Original Message----- 
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna 
Sent: Monday, April 22, 2002 3:38 PM 
To: 'Tony Johansson'; bob@marksmob.com 
Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com;
fredrik@ipunplugged.com 
Subject: RE: [mobile-ip] RE: A Question
about:draft-ietf-mobileip-aaa-nai-00.txt 


Hi Bob; 
Let me add to what Tony just said. 
I do not think that any MN needs to know anything about the type 
of AAA infrastructure the FA and HA are using to authenticate the MN. 
However, the MN Application is developed with certain standard in mind. 
(certain method of authentication) 
for example: 
1. ONLY RFC2002 Compliant MN: 
It assumes that it has a security association with both the FA and the 
HA. If it visit any FA where it shares a security association with, MN
sends 
RRQ message with MN-FA Authentication extension and it works just fine. 
2. ONLY RFC2002 & RFC3012 Compliant MN: 
RFC 3012 addressed properly the case of MN in 1 but offered a new 
mechanism for authenticating the MN to the FA using the FA Challenge 
and MN-AAA authentication extension. 
3. Now Latest MN with all of the above (RFC3220) and diameter compliant:

MN includes AAA NAI extension and those FA which support diameter 
will use process it and those FA which does not support AAA NAI
(skippable) 
will continue to use either method in 2 or 1. 


Regards; 
Ahmad Muhanna 


> -----Original Message----- 
> From: Tony Johansson [mailto:tony.johansson@ericsson.com] 
> Sent: Monday, April 22, 2002 4:15 PM 
> To: bob@marksmob.com 
> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Fredrik Johansson'; 
> mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com 
> Subject: Re: [mobile-ip] RE: A Question 
> about:draft-ietf-mobileip-aaa-nai-00.txt 
> 
> 
> Hi Bob, 
> 
> Yes, it's based on MN configuration and FA configuration. Same as e.g 
> the handling of RFC3012/RFC3012bis and the 
> draft-ietf-mobileip-aaa-key-09.txt. 
> 
> The advertisements will not tell you anything reading this. 
> 
> /Tony 
> 
> Robert J Marks wrote: 
> 
> >  Perhaps someone can explain how the MN knows the type of AAA 
> > infrastructure used by the FA nd HA. I don't believe any information

> > is included in any advertisement. Does this "solution" rely 
> only upon 
> > MN configuration, or am I missing something here? Thanks.Bob 
> > -----Original Message----- 
> > From: owner-mobile-ip@sunroof.eng.sun.com 
> > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad 
> > Muhanna 
> > Sent: Monday, April 22, 2002 1:59 PM 
> > To: 'Tony Johansson' 
> > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> > fredrik@ipunplugged.com 
> > Subject: RE: [mobile-ip] RE: A Question 
> > about:draft-ietf-mobileip-aaa-nai-00.txt 
> > 
> > Hello Tony; 
> > YES; this solves the problem. 
> > 
> > Regards; 
> > Ahmad Muhanna 
> > 
> > > -----Original Message----- 
> > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] 
> > > Sent: Monday, April 22, 2002 2:51 PM 
> > > To: Muhanna, Ahmad [RICH1:2Q20:EXCH] 
> > > Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> > > fredrik@ipunplugged.com 
> > > Subject: Re: [mobile-ip] RE: A Question 
> > > about:draft-ietf-mobileip-aaa-nai-00.txt 
> > > 
> > > 
> > > Hello Ahmad, 
> > > 
> > > Ahmad Muhanna wrote: 
> > > 
> > > 
> > > > I do not think that It is the same!! 
> > > > RFC3012 introduced a new way of authenticating the MN to the FA 
> > > > without violating 
> > > > backward compatibility of RFC2002 or later RFC3220. 
> > > > Mobile Node does not know which way or the standard the 
> > > foreign agent 
> > > > uses to 
> > > > authenticate it. It could be through RADIUS, AAA, Diameter 
> > > who knows. 
> > > 
> > > > 
> > > > The point here is that this draft mandates that every 
> Mobile Node 
> > > > include AAA NAI extension 
> > > > with subtype of 1 whenever it requests static Mobile IP 
> or during 
> > > > Inter-FA handoff. 
> > > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile 
> > > Node which 
> > > > exist right now, 
> > > > does not do this. 
> > > > After this draft becomes a standard, according to this 
> > > section, MN is 
> > > > not following the 
> > > > standard by not sending AAA NAI extension in initial 
> Registration 
> > > > Request or during re-authentication.!!! 
> > > > 
> > > > This is not backward compatible!!!! 
> > > 
> > > Okay, so how about adding the following statement to the 
> > introduction: 
> > > 
> > > "The AAA NAI extension MUST only be used with the Diameter Mobile 
> > IPv4 
> > > application and MUST NOT be used with any other AAA protocol." 
> > > 
> > > 
> > > 
> > > /Tony 
> > > 
> > > 
> > > 
> 
> 


------=_NextPart_000_0090_01C1ED20.40ABC5A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




Message






Hi=20
Ahmad,


 


I=20
received your previous email correctly, but was still considering my =
reply.=20
Please excuse the delay.


 


I'm=20
concerned with the following scenario. If a FA supports both =
RFC3012 and=20
this I-D, then it will include a Challenge Extension in any Agent =
Advertisement=20
it sends. A MN entering an area served by the FA will not know whether =
the FA=20
"also" supports this I-D, and so must include the AAA NAI Extension to =
cover=20
that possibility. I grant that once the MN receives a Registration =
Reply, it=20
will know what to do as long as it stays in the area serviced by the FA. =

However, this is Mobile IP, not Nomadic IP, so I expect the MN to move, =
often,=20
and to face the exact same situation with the next FA it=20
encounters.


 


I=20
guess no one wants to use another bit in the advertisement to indicate =
the type=20
of AAA infrastructure in use. So is there some other way to provide a =
clue to=20
the MN and still support backward compatibility and still conserve=20
bandwidth?


 


Bob



  

  
-----Original Message-----
From:=20
  owner-mobile-ip@sunroof.eng.sun.com=20
  [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad =

  Muhanna
Sent: Friday, April 26, 2002 8:44 AM
To:=20
  'bob@marksmob.com'; 'Tony Johansson'
Cc: 'Fredrik =
Johansson';=20
  mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] RE: A =

  Question about:draft-ietf-mobileip-aaa-nai-00.txt


  
Hello Bob; 
I am=20
  resending this email because I am not sure if it made it =
earlier. 

  
I think the whole idea is to prevent =
this draft=20
  from mandating all Mobile Nodes to include 
AAA NAI extension with subtype 1 "HA" in the following=20
  scenarios: 

  
1. When the Mobile Node sends a =
Registration=20
  Request for Re-Authentication: 
MN will=20
  never be able to send the AAA NAI extension in the Registration=20
  
request unless it recognizes =
and support=20
  that extension. Because, it received 
it=20
  from HAAA through the FAAA and the FA in the Registration Reply=20
  message. 
Legacy MN does not =
support any=20
  feature which requires this anyway. 

  
2. When the Mobile Node request a =
static Mobile IP=20
  call. "specific IP address" 
ONLY those=20
  Mobile Node which again support and recognizes this extension =

will be able to send it. Because, legacy Mobile =
Node are not=20
  configured with 
AAA NAI =
extension for the=20
  HA anyway. Also, legacy MN does not support 
any feature which requires this to be added to the =
Registration=20
  Request. 

  
However, I agree the proposed text may =
be very=20
  broad. 

  
Tony/Bob, 
Do you=20
  think the following text would be more specific? 
It include all the text I proposed so far. 

  
section 4. should read: =

" 
   The HA =
identity uses=20
  subtype 1 of the AAA NAI Extension.  It contains 
   the NAI of the AAA interface of the =
HA in the=20
  form hostname@realm. 
   Together=20
  the hostname and realm forms the complete FQDN 
   (hostname.realm) of the HA's AAA =
interface. 

  
   The home agent MUST =
provide HA=20
  identity in every registration reply 
   sent to the mobile node destined through the AAA =

  infrastructure. 

  
   A mobile node which =
support AAA NAI=20
  extension MUST provide HA 
  =20
  identity in every registration request sent when re-authenticating,=20
  
   or when requesting =
a specific=20
  IP address at initial authentication. 
" 

  
section 5. should read: =

" 
   The =
AAAH identity=20
  uses subtype 2 of the AAA NAI Extension.  It 
   contains the NAI of the home AAA server in the =
form=20
  hostname@realm. 
   =
Together the=20
  hostname and realm forms the complete FQDN 
   (hostname.realm) of the home AAA servers =
interface.=20
  

  
   The home agent MUST =
provide this in=20
  every registration reply sent to =

  
   the mobile =
node=20
  destined through the AAA infrastructure. 

  
   A mobile node =
which support the AAA NAI extension =
MUST always 
  =20
  save the latest AAAH Identity received in the registration reply =
message=20
  
   and MUST provide =
the AAAH=20
  Identity in every registration request sent 
    when re-authenticating. 

  
   If the AAAH identity is =
present, the=20
  foreign agent MUST direct an 
  =20
  authentication request to this home AAA server when =
authenticating=20
  
   the mobile node through =
the AAA=20
  infrastructure by means described in 
   [2] 
" 

  
This will eliminate the need for the =
following=20
  text: 
"The AAA NAI extension =
MUST only be=20
  used with the Diameter Mobile IPv4 
application and MUST NOT be used with any other AAA =
protocol."=20
  


  
Regards; 
Ahmad=20
  Muhanna 
****************************************************************=
***************************************=20
  


  
Hello Ahmad, 
  
I'm still not =
totally=20
  comfortable with this new technique and its impact on =
bandwidth-constrained=20
  links. 
  
For RFC2002, the MN sent only the authentication extensions =
it knew it=20
  needed. It knew if it had a 
security=20
  association with the FA, and had to have a security association with =
the=20
  HA. 
  
For RFC3012, the MN could use the presence (or absence) of =
the=20
  Challenge to determine which 
extensions and=20
  parameters (like NAI) it included in the Registration Request.=20
  
  
But for=20
  this new I-D, the MN does not get any clue at all. Therefore it needs =
to=20
  include the extension 
because =
it might be=20
  needed. This, it seems to me, is not so good for bandwidth-constrained =

  links. 
As Tony pointed out, it =
seems that=20
  the MN must be configured to send or not to send - I'd rather =
the=20
  
FA provided some clue. =

  
Bob =

  
-----Original=20
  Message----- 
From:=20
  owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-i=
p@sunroof.eng.sun.com]=20
  On Behalf Of Ahmad Muhanna 
Sent: Monday,=20
  April 22, 2002 3:38 PM 
To: =
'Tony=20
  Johansson'; bob@marksmob.com 
Cc: 'Fredrik=20
  Johansson'; mobile-ip@sunroof.eng.sun.com; =
fredrik@ipunplugged.com=20
  
Subject: RE: [mobile-ip] RE: A =
Question=20
  about:draft-ietf-mobileip-aaa-nai-00.txt 


  
Hi Bob; 
Let me=20
  add to what Tony just said. 
I =
do not think=20
  that any MN needs to know anything about the type 
of AAA infrastructure the FA and HA are using to authenticate =
the MN.=20
  
However, the MN Application is =
developed=20
  with certain standard in mind. 
(certain=20
  method of authentication) 
for =
example:=20
  
1. ONLY RFC2002 Compliant MN:=20
  
It assumes that it has a =
security=20
  association with both the FA and the 
HA. If=20
  it visit any FA where it shares a security association with, MN sends=20
  
RRQ message with MN-FA =
Authentication=20
  extension and it works just fine. 
2. ONLY=20
  RFC2002 & RFC3012 Compliant MN: 
RFC=20
  3012 addressed properly the case of MN in 1 but offered a new =

mechanism for authenticating the MN to the FA =
using the FA=20
  Challenge 
and MN-AAA =
authentication=20
  extension. 
3. Now Latest MN =
with all of the=20
  above (RFC3220) and diameter compliant: 
MN=20
  includes AAA NAI extension and those FA which support diameter=20
  
will use process it and those =
FA which does=20
  not support AAA NAI (skippable) 
will=20
  continue to use either method in 2 or 1. 


  
Regards; 
Ahmad=20
  Muhanna 


  
> -----Original Message----- =

> From: Tony Johansson [mailto:tony.johansson@ericsso=
n.com]=20
  
> Sent: Monday, April 22, =
2002 4:15 PM=20
  
> To: bob@marksmob.com =

> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; =
'Fredrik=20
  Johansson'; 
>=20
  mobile-ip@sunroof.eng.sun.com; fredrik@ipunplugged.com =

> Subject: Re: [mobile-ip] RE: A Question=20
  
>=20
  about:draft-ietf-mobileip-aaa-nai-00.txt 
> 
> =

> Hi Bob, 
>=20
  
> Yes, it's based on MN =
configuration=20
  and FA configuration. Same as e.g 
> the=20
  handling of RFC3012/RFC3012bis and the 
>=20
  draft-ietf-mobileip-aaa-key-09.txt. 
>=20
  
> The advertisements will =
not tell you=20
  anything reading this. 
>=20
  
> /Tony 
> 
> Robert J =
Marks wrote:=20
  
> 
> >  Perhaps someone can explain how the MN knows =
the type=20
  of AAA 
> > infrastructure =
used by the=20
  FA nd HA. I don't believe any information 
> > is included in any advertisement. Does this =
"solution" rely=20
  
> only upon 
> > MN configuration, or am I missing something here? =
Thanks.Bob=20
  
> > -----Original =
Message-----=20
  
> > From:=20
  owner-mobile-ip@sunroof.eng.sun.com 
>=20
  > [mailto:owner-mobile-i=
p@sunroof.eng.sun.com]=20
  On Behalf Of Ahmad 
> > =
Muhanna=20
  
> > Sent: Monday, April =
22, 2002 1:59=20
  PM 
> > To: 'Tony =
Johansson'=20
  
> > Cc: 'Fredrik =
Johansson';=20
  mobile-ip@sunroof.eng.sun.com; 
> >=20
  fredrik@ipunplugged.com 
> =
> Subject:=20
  RE: [mobile-ip] RE: A Question 
> >=20
  about:draft-ietf-mobileip-aaa-nai-00.txt 
> > 
> > =
Hello Tony;=20
  
> > YES; this solves the =
problem.=20
  
> > 
> > Regards; 
> > Ahmad=20
  Muhanna 
> > =

> > > -----Original Message----- =

> > > From: Tony Johansson [mailto:tony.johansson@ericsso=
n.com]=20
  
> > > Sent: Monday, =
April 22, 2002=20
  2:51 PM 
> > > To: =
Muhanna, Ahmad=20
  [RICH1:2Q20:EXCH] 
> > =
> Cc:=20
  'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com; 
> > > fredrik@ipunplugged.com =

> > > Subject: Re: [mobile-ip] RE: A =
Question=20
  
> > >=20
  about:draft-ietf-mobileip-aaa-nai-00.txt 
> > > 
> =
> >=20
  
> > > Hello Ahmad,=20
  
> > > 
> > > Ahmad Muhanna wrote: 
> > > 
> =
> >=20
  
> > > > I do not =
think that It=20
  is the same!! 
> > > =
> RFC3012=20
  introduced a new way of authenticating the MN to the FA =

> > > > without violating =

> > > > backward compatibility of =
RFC2002 or=20
  later RFC3220. 
> > > =
> Mobile=20
  Node does not know which way or the standard the 
> > > foreign agent 
>=20
  > > > uses to 
> =
> > >=20
  authenticate it. It could be through RADIUS, AAA, Diameter =

> > > who knows. 
> > > 
> =
> > >=20
  
> > > > The point =
here is that=20
  this draft mandates that every 
> Mobile=20
  Node 
> > > > =
include AAA NAI=20
  extension 
> > > > =
with subtype=20
  of 1 whenever it requests static Mobile IP 
> or during 
> =
> > >=20
  Inter-FA handoff. 
> > =
> > Now:=20
  (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile =

> > > Node which 
> > > > exist right now, 
> > > > does not do this. 
> > > > After this draft becomes a standard, =
according to=20
  this 
> > > section, MN =
is=20
  
> > > > not =
following the=20
  
> > > > standard by =
not sending=20
  AAA NAI extension in initial 
>=20
  Registration 
> > > =
> Request or=20
  during re-authentication.!!! 
> > >=20
  > 
> > > > This =
is not=20
  backward compatible!!!! 
> =
> >=20
  
> > > Okay, so how =
about adding=20
  the following statement to the 
> >=20
  introduction: 
> > >=20
  
> > > "The AAA NAI =
extension MUST=20
  only be used with the Diameter Mobile 
>=20
  > IPv4 
> > > =
application and=20
  MUST NOT be used with any other AAA protocol." 
> > > 
> =
> >=20
  
> > > 
> > > /Tony 
> > >=20
  
> > > 
> > > 
> =

> 


------=_NextPart_000_0090_01C1ED20.40ABC5A0--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 13:56:02 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17615
	for ; Fri, 26 Apr 2002 13:56:01 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12845;
	Fri, 26 Apr 2002 11:56:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26126;
	Fri, 26 Apr 2002 10:55:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QHsPGs001019
	for ; Fri, 26 Apr 2002 10:54:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QHsPR5001011
	for mobile-ip-dist; Fri, 26 Apr 2002 10:54:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QHs6Gs000871
	for ; Fri, 26 Apr 2002 10:54:07 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24938
	for ; Fri, 26 Apr 2002 10:54:07 -0700 (PDT)
Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA24569
	for ; Fri, 26 Apr 2002 10:54:07 -0700 (PDT)
Received: from unknown (HELO EmadQ) (emadaq@217.144.4.43 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Apr 2002 17:54:05 -0000
Reply-To: 
From: "Emad Qaddoura" 
To: 
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Fri, 26 Apr 2002 20:53:53 +0200
Message-ID: <000001c1ed53$b8b8ecc0$2b0490d9@EmadQ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <20020426142853.GU29152@muminmamman.lifix.fi>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3QHs7Gs000876
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Tom,

You stated below " The use of BUs (ala route optim.) as it is done in
the
  current rdaft can be allowed, if zero packet loss is of high
  importance, but to me it is an additional plus that itself should
  not be used as an integral part of regional
  tunneling/registrations. I know, why it is used as an integral part
  at the moment, but it does not need to be so, if the FAs know their
  children in the tree."

Since the regional registration adds more delays to the overall scheme
of MIP registrations, then, in my view, a route optimization should be
an integral part and not optional. MIP as it is in 2002 is not with zero
packet loss, and this draft would make it even with more packet loss.
This may classify MIP as a mobility protocol for NON-REAL time
applications. I have been off the list for sometime, I was not aware if
this has been already the classification for MIP? 

What would be the impact on TCP dependent applications when the delay
prolongs due to regional registrations? May be someone can clarify?

Therefore, this draft or others, should always take into consideration
the impact on packet loss and SHOULD always minimize it.

Thanks,
EQ

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Tom K
Weckstrom
Sent: Friday, April 26, 2002 4:29 PM
To: mobile-ip@sunroof.eng.sun.com
Cc: Charles E. Perkins; Annika Jonsson; Eva Gustafsson
Subject: Re: [mobile-ip] WG Last Call:
draft-ietf-mobileip-reg-tunnel-06.txt

Hello all.

On Tue, Apr 23, 2002 at 02:53:26AM +0300, Tom K Weckstrom wrote:
> Hello.
> 
> Please, read the attached text file for my comments on
> draft-ietf-mobileip-reg-tunnel-06.txt.
> 
> Please, consider this as a first stage and by no means exhaustive
> "issue list". I'll get back with concrete proposals later this week.
---end quoted text---

My time ran out for sending the concrete proposals I promised
during this week, so here we go. In a nutshell:

- Clarify the draft so that there is one way to implement the solution
  (the MUST features) and then try to clarify the different options
  around the MUST solution. The current -06 version offers sooo many
  possibilities. Also some optional features may be removed
  altogether, e.g. MN registering directly to the GFA.

- I propose a signaling, where upon the handoff, ony one registration
  request is sent and only one reply is sent back. This is how
  Dynamics - HUT Mobile IP works when a hierarchical model is
  deployed. The details of the messages can be left for future
  discussion. The current message design from v. -06 can be used
  mostly. As an addition, the FAs need to learn about their children
  in the tree. The draft can propose manual configuration, or an
  automated registration protocol for FAs. This has also been
  implemented by Dynamics Group, so just copy that working solution to
  the specs. The use of BUs (ala route optim.) as it is done in the
  current rdaft can be allowed, if zero packet loss is of high
  importance, but to me it is an additional plus that itself should
  not be used as an integral part of regional
  tunneling/registrations. I know, why it is used as an integral part
  at the moment, but it does not need to be so, if the FAs know their
  children in the tree.

- Reach for backwards compatibility:
	- Advertise a single care of address (the GFA address)
	- RFC 3220 compliant implementations would benefit from
          regionalised registrations, but GFA would always handle the
          handoff as a crossover FA.
	- If complete transparency is desired, there is an issue with
          nonce based replay protection. We have to work this out.

- Give "candy" for those who implement the necessary extensions to
  their clients:
	- An intelligent client would add a PFAN type extension to
          tell the hierarhcy, the previous FA through which it
          registered. --> Faster handoffs handled lower in the
hierarchy.

- Make a list / matrix of conflicting proposals, so that we can see
  where the prolems are. The current discussion about the need of the
  draft, etc. can also be lifted to the next level.

- Specify the way to distribute keys between GFA, the RFAs and the
  FAs. Again, an implementation and specification about this is
  available in http://www.cs.hut.fi/Research/Dynamics/

I hope this gets the discussion further and to a generally acceptable
-07 version of the draft.

I'll be on vacation next week, but I'll check the thread and give
further comments as soon as I return. I'll be happy to help in
defining the next version of the draft.

Best regards, Tom

-- 
Tom Weckström                   PGP id:  E1DB55E9
Lifix Systems Oy        Mobile:  +358 50 350 5997
Innopoli 2	      Tekniikantie 14	      FIN-02150 Espoo




From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 15:21:40 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28596
	for ; Fri, 26 Apr 2002 15:21:39 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13505;
	Fri, 26 Apr 2002 12:21:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10580;
	Fri, 26 Apr 2002 12:20:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QJJQGs012251
	for ; Fri, 26 Apr 2002 12:19:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QJJOrL012231
	for mobile-ip-dist; Fri, 26 Apr 2002 12:19:24 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QJJ9Gs012118
	for ; Fri, 26 Apr 2002 12:19:09 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01620
	for ; Fri, 26 Apr 2002 12:19:07 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16196
	for ; Fri, 26 Apr 2002 13:19:07 -0600 (MDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3QJJ0B19186;
	Fri, 26 Apr 2002 14:19:00 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 26 Apr 2002 14:18:57 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC59@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'bob@marksmob.com'" ,
        "'Tony Johansson'"
	 
Cc: "'Fredrik Johansson'" ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-
	00.txt
Date: Fri, 26 Apr 2002 14:18:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1ED57.332B2DD0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1ED57.332B2DD0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Bob;
You are right.

Once more we find that Backward compatibility presents itself as an
issue which needs a permanent solution before we run out of bits and bytes. 
I am working on a solution and I hope I will be able to submit a draft in
couple of weeks.

Regards; 
Ahmad Muhanna 

++++++++++++++++++++++++++++++++++++++++++++

Hi Ahmad,
 
I received your previous email correctly, but was still considering my
reply. Please excuse the delay.
 
I'm concerned with the following scenario. If a FA supports both RFC3012 and
this I-D, then it will include a Challenge Extension in any Agent
Advertisement it sends. A MN entering an area served by the FA will not know
whether the FA "also" supports this I-D, and so must include the AAA NAI
Extension to cover that possibility. I grant that once the MN receives a
Registration Reply, it will know what to do as long as it stays in the area
serviced by the FA. However, this is Mobile IP, not Nomadic IP, so I expect
the MN to move, often, and to face the exact same situation with the next FA
it encounters.
 
I guess no one wants to use another bit in the advertisement to indicate the
type of AAA infrastructure in use. So is there some other way to provide a
clue to the MN and still support backward compatibility and still conserve
bandwidth?
 
Bob
-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna
Sent: Friday, April 26, 2002 8:44 AM
To: 'bob@marksmob.com'; 'Tony Johansson'
Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] RE: A Question
about:draft-ietf-mobileip-aaa-nai-00.txt


Hello Bob; 
I am resending this email because I am not sure if it made it earlier. 
I think the whole idea is to prevent this draft from mandating all Mobile
Nodes to include 
AAA NAI extension with subtype 1 "HA" in the following scenarios: 
1. When the Mobile Node sends a Registration Request for Re-Authentication: 
MN will never be able to send the AAA NAI extension in the Registration 
request unless it recognizes and support that extension. Because, it
received 
it from HAAA through the FAAA and the FA in the Registration Reply message. 
Legacy MN does not support any feature which requires this anyway. 
2. When the Mobile Node request a static Mobile IP call. "specific IP
address" 
ONLY those Mobile Node which again support and recognizes this extension 
will be able to send it. Because, legacy Mobile Node are not configured with

AAA NAI extension for the HA anyway. Also, legacy MN does not support 
any feature which requires this to be added to the Registration Request. 
However, I agree the proposed text may be very broad. 
Tony/Bob, 
Do you think the following text would be more specific? 
It include all the text I proposed so far. 
section 4. should read: 
" 
   The HA identity uses subtype 1 of the AAA NAI Extension.  It contains 
   the NAI of the AAA interface of the HA in the form hostname@realm. 
   Together the hostname and realm forms the complete FQDN 
   (hostname.realm) of the HA's AAA interface. 
   The home agent MUST provide HA identity in every registration reply 
   sent to the mobile node destined through the AAA infrastructure. 
   A mobile node which support AAA NAI extension MUST provide HA 
   identity in every registration request sent when re-authenticating, 
   or when requesting a specific IP address at initial authentication. 
" 
section 5. should read: 
" 
   The AAAH identity uses subtype 2 of the AAA NAI Extension.  It 
   contains the NAI of the home AAA server in the form hostname@realm. 
   Together the hostname and realm forms the complete FQDN 
   (hostname.realm) of the home AAA servers interface. 
   The home agent MUST provide this in every registration reply sent to 
   the mobile node destined through the AAA infrastructure. 
   A mobile node which support the AAA NAI extension MUST always 
   save the latest AAAH Identity received in the registration reply message 
   and MUST provide the AAAH Identity in every registration request sent 
    when re-authenticating. 
   If the AAAH identity is present, the foreign agent MUST direct an 
   authentication request to this home AAA server when authenticating 
   the mobile node through the AAA infrastructure by means described in 
   [2] 
" 
This will eliminate the need for the following text: 
"The AAA NAI extension MUST only be used with the Diameter Mobile IPv4 
application and MUST NOT be used with any other AAA protocol." 


Regards; 
Ahmad Muhanna 
****************************************************************************
*************************** 


Hello Ahmad, 
  
I'm still not totally comfortable with this new technique and its impact on
bandwidth-constrained links. 
  
For RFC2002, the MN sent only the authentication extensions it knew it
needed. It knew if it had a 
security association with the FA, and had to have a security association
with the HA. 
  
For RFC3012, the MN could use the presence (or absence) of the Challenge to
determine which 
extensions and parameters (like NAI) it included in the Registration
Request. 
  
But for this new I-D, the MN does not get any clue at all. Therefore it
needs to include the extension 
because it might be needed. This, it seems to me, is not so good for
bandwidth-constrained links. 
As Tony pointed out, it seems that the MN must be configured to send or not
to send - I'd rather the 
FA provided some clue. 
  
Bob 
  

------_=_NextPart_001_01C1ED57.332B2DD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [mobile-ip] RE: A Question =
about:draft-ietf-mobileip-aaa-nai-00.txt




Hi Bob;

You are right.




Once more we find that Backward compatibility =
presents itself as an

issue which needs a permanent solution before we run =
out of bits and bytes. 

I am working on a solution and I hope I will be able =
to submit a draft in couple of weeks.




Regards; 

Ahmad Muhanna 




++++++++++++++++++++++++++++++++++++++++++++




Hi Ahmad,

 

I received your previous email correctly, but was =
still considering my reply. Please excuse the delay.

 

I'm concerned with the following scenario. If a FA =
supports both RFC3012 and this I-D, then it will include a Challenge =
Extension in any Agent Advertisement it sends. A MN entering an area =
served by the FA will not know whether the FA "also" supports =
this I-D, and so must include the AAA NAI Extension to cover that =
possibility. I grant that once the MN receives a Registration Reply, it =
will know what to do as long as it stays in the area serviced by the =
FA. However, this is Mobile IP, not Nomadic IP, so I expect the MN to =
move, often, and to face the exact same situation with the next FA it =
encounters.



 

I guess no one wants to use another bit in the =
advertisement to indicate the type of AAA infrastructure in use. So is =
there some other way to provide a clue to the MN and still support =
backward compatibility and still conserve bandwidth?



 

Bob

-----Original Message-----

From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-=
ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna

Sent: Friday, April 26, 2002 8:44 AM

To: 'bob@marksmob.com'; 'Tony Johansson'

Cc: 'Fredrik Johansson'; =
mobile-ip@sunroof.eng.sun.com

Subject: RE: [mobile-ip] RE: A Question =
about:draft-ietf-mobileip-aaa-nai-00.txt






Hello Bob; 

I am resending this email because I am not sure if =
it made it earlier. 

I think the whole idea is to prevent this draft from =
mandating all Mobile Nodes to include 

AAA NAI extension with subtype 1 "HA" in =
the following scenarios: 

1. When the Mobile Node sends a Registration Request =
for Re-Authentication: 

MN will never be able to send the AAA NAI extension =
in the Registration 

request unless it recognizes and support that =
extension. Because, it received 

it from HAAA through the FAAA and the FA in the =
Registration Reply message. 

Legacy MN does not support any feature which =
requires this anyway. 

2. When the Mobile Node request a static Mobile IP =
call. "specific IP address" 

ONLY those Mobile Node which again support and =
recognizes this extension 

will be able to send it. Because, legacy Mobile Node =
are not configured with 

AAA NAI extension for the HA anyway. Also, legacy MN =
does not support 

any feature which requires this to be added to the =
Registration Request. 

However, I agree the proposed text may be very =
broad. 

Tony/Bob, 

Do you think the following text would be more =
specific? 

It include all the text I proposed so far. 

section 4. should read: 

" 

   The HA identity uses subtype 1 of the =
AAA NAI Extension.  It contains 

   the NAI of the AAA interface of the HA =
in the form hostname@realm. 

   Together the hostname and realm forms =
the complete FQDN 

   (hostname.realm) of the HA's AAA =
interface. 

   The home agent MUST provide HA identity =
in every registration reply 

   sent to the mobile node destined =
through the AAA infrastructure. 

   A mobile node which support AAA NAI =
extension MUST provide HA 

   identity in every registration request =
sent when re-authenticating, 

   or when requesting a specific IP =
address at initial authentication. 

" 

section 5. should read: 

" 

   The AAAH identity uses subtype 2 of the =
AAA NAI Extension.  It 

   contains the NAI of the home AAA server =
in the form hostname@realm. 

   Together the hostname and realm forms =
the complete FQDN 

   (hostname.realm) of the home AAA =
servers interface. 

   The home agent MUST provide this in =
every registration reply sent to 

   the mobile node destined through the =
AAA infrastructure. 

   A mobile node which support the AAA NAI =
extension MUST always 

   save the latest AAAH Identity received =
in the registration reply message 

   and MUST provide the AAAH Identity in =
every registration request sent 

    when re-authenticating. 

   If the AAAH identity is present, the =
foreign agent MUST direct an 

   authentication request to this home AAA =
server when authenticating 

   the mobile node through the AAA =
infrastructure by means described in 

   [2] 

" 

This will eliminate the need for the following text: =


"The AAA NAI extension MUST only be used with =
the Diameter Mobile IPv4 

application and MUST NOT be used with any other AAA =
protocol." 






Regards; 

Ahmad Muhanna 

***************************************************************=
**************************************** 






Hello Ahmad, 

  

I'm still not totally comfortable with this new =
technique and its impact on bandwidth-constrained links. 

  

For RFC2002, the MN sent only the authentication =
extensions it knew it needed. It knew if it had a 

security association with the FA, and had to have a =
security association with the HA. 

  

For RFC3012, the MN could use the presence (or =
absence) of the Challenge to determine which 

extensions and parameters (like NAI) it included in =
the Registration Request. 

  

But for this new I-D, the MN does not get any clue =
at all. Therefore it needs to include the extension 

because it might be needed. This, it seems to me, is =
not so good for bandwidth-constrained links. 

As Tony pointed out, it seems that the MN must be =
configured to send or not to send - I'd rather the 

FA provided some clue. 

  

Bob 

  





------_=_NextPart_001_01C1ED57.332B2DD0--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 15:26:53 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29321
	for ; Fri, 26 Apr 2002 15:26:52 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02856;
	Fri, 26 Apr 2002 13:26:53 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13675;
	Fri, 26 Apr 2002 12:26:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QJP5Gs014976
	for ; Fri, 26 Apr 2002 12:25:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QJP4w1014960
	for mobile-ip-dist; Fri, 26 Apr 2002 12:25:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QJOjGs014825
	for ; Fri, 26 Apr 2002 12:24:45 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04930
	for ; Fri, 26 Apr 2002 12:24:47 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19804
	for ; Fri, 26 Apr 2002 13:24:46 -0600 (MDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3QJObB20477;
	Fri, 26 Apr 2002 14:24:37 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 26 Apr 2002 14:24:34 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC5A@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Madhavi W. Chandra'" 
Cc: "'Annika Jonsson'" ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Fri, 26 Apr 2002 14:24:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1ED57.FC87A410"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1ED57.FC87A410
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Madhavi;
I am not one of the authors, BUT I think I can comment on this one.

> 
> Annika,
> 
> 
> 
> This seems to also be the case when the MN sets the CoA=0.0.0.0,
> and the HA doesn't support Regional Registrations...two RRQ trips
> if the MN attempts to register again with a non-zero CoA.  
> Can you please comment on this as well?

The draft mandates that Mobile Node MUST not set this address to
zero except if the MN and its HA support regional registration.

section 4.1. 
" 
    If the mobile node sets the care-of address to zero, the mobile node 
   and its home agent MUST support the GFA IP address extension (see section
8.1).  
" 

Regards,
Ahmad Muhanna
> 
> Thanks,
> Madhavi
> 
> > With the route optimization draft being optional 
> extensions, we should
> > be concerned about any additional delays to traffic 
> destined to the MN.
> > 
> > Thanks,
> > EQ 
> >  
> > 
> > 
> 

------_=_NextPart_001_01C1ED57.FC87A410
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] Last Call:  Regional Tunneling input




Hi Madhavi;

I am not one of the authors, BUT I think I can comment on this one.




> 

> Annika,

> 

> 

> 

> This seems to also be the case when the MN sets the CoA=0.0.0.0,

> and the HA doesn't support Regional Registrations...two RRQ trips

> if the MN attempts to register again with a non-zero CoA.  

> Can you please comment on this as well?




The draft mandates that Mobile Node MUST not set this address to

zero except if the MN and its HA support regional registration.




section 4.1. 

" 

    If the mobile node sets the care-of address to zero, the mobile node 

   and its home agent MUST support the GFA IP address extension (see section 8.1).  

" 




Regards,

Ahmad Muhanna

> 

> Thanks,

> Madhavi

> 

> > With the route optimization draft being optional 

> extensions, we should

> > be concerned about any additional delays to traffic 

> destined to the MN.

> > 

> > Thanks,

> > EQ 

> >  

> > 

> > 

> 





------_=_NextPart_001_01C1ED57.FC87A410--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 15:40:01 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00939
	for ; Fri, 26 Apr 2002 15:39:59 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05928;
	Fri, 26 Apr 2002 13:39:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20612;
	Fri, 26 Apr 2002 12:39:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QJYYGs019391
	for ; Fri, 26 Apr 2002 12:34:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QJYXeZ019382
	for mobile-ip-dist; Fri, 26 Apr 2002 12:34:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QJYQGs019348
	for ; Fri, 26 Apr 2002 12:34:26 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03436
	for ; Fri, 26 Apr 2002 12:34:27 -0700 (PDT)
Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25903
	for ; Fri, 26 Apr 2002 13:34:26 -0600 (MDT)
Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163])
	by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3QJbUCI007438;
	Fri, 26 Apr 2002 21:37:35 +0200
From: "Henrik Levkowetz" 
To: "Francis Dupont" ,
        
Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security
Date: Fri, 26 Apr 2002 21:34:13 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <200204261202.g3QC2TT77081@givry.rennes.enst-bretagne.fr>
X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw)
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis,

	Thanks for pointing this out. You may want to take a look at
the security section of the current draft, which is 
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt

	I believe we have discussed this attack in the security
section of that draft, but if I've mistunderstood or not fully
understood the extent of the attack, I'd be happy to update the
security section or take other action as indicated by input from
the list.

	Best regards,
		Henrik

> 
> I've just done a comment about NAT/NATPT traversal security
> at IPCN and I believe it is useful to discuss about the raised
> issue in this list.
> 
> The basic problem is the HA has to trust the CoA found from the
> source address in the IP header which can be forged by anyone
> in the path (note this is different from my "trust the CoA given
> by the MN argument" in a previous mail).
> 
> I don't know if this is enough to restrict/reject the NAT traversal
> proposal but at least the security section should *not* stay empty!
> 
> Regards
> 
> Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Fri Apr 26 18:53:09 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23727
	for ; Fri, 26 Apr 2002 18:53:09 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20480;
	Fri, 26 Apr 2002 16:53:09 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04995;
	Fri, 26 Apr 2002 15:52:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QMpcGs027518
	for ; Fri, 26 Apr 2002 15:51:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3QMpcnu027515
	for mobile-ip-dist; Fri, 26 Apr 2002 15:51:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3QMpYGs027499
	for ; Fri, 26 Apr 2002 15:51:34 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18080
	for ; Fri, 26 Apr 2002 15:51:35 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27079
	for ; Fri, 26 Apr 2002 16:51:34 -0600 (MDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g3QMpXl13486;
	Fri, 26 Apr 2002 17:51:33 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g3QMpXj29189;
	Fri, 26 Apr 2002 17:51:33 -0500 (CDT)
Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA20615; Fri, 26 Apr 2002 17:51:32 -0500 (CDT)
Received: from ericsson.com ([138.85.159.114])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA10553;
	Fri, 26 Apr 2002 17:51:31 -0500 (CDT)
Message-ID: <3CC9D930.5AE0DFB4@ericsson.com>
Date: Fri, 26 Apr 2002 15:48:16 -0700
From: Tony Johansson 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ahmad Muhanna ,
        "'bob@marksmob.com'" 
CC: "'Fredrik Johansson'" ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
References: <6B49EDFE974BD51197D70002A56079D801AFCC59@zrc2c013.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello Bob and Ahmad,

Thanks a lot for your valuable points here and I agree backward
compatibility is an issue. In the existing deployments of Mobile IP
clients, especially those that will soon be deployed for IS-835 (the
cdma2000 standard) will not have AAA NAI extension support. However, I
don't think we need to change any of the wording that we have agreed on
in the draft-ietf-mobileip-aaa-nai-00.txt draft, instead the changes
should be done in the Diameter Mobile IPv4 application. I rather see
that we let the network side takes care and deal with the consequences
of the possible backward compatibility issues for those legacy clients
that don't have AAA NAI support then adding even more complexity to the
mobile IP client side. I've sent a new issue to the aaa-wg list
regarding this
(http://www.merit.edu/mail.archives/aaa-wg/msg03958.html).

Comments / objections to this?

Regards,

/Tony



Ahmad Muhanna wrote:

>
>
> Hi Bob;
> You are right.
>
> Once more we find that Backward compatibility presents itself as an
> issue which needs a permanent solution before we run out of bits and
> bytes.
> I am working on a solution and I hope I will be able to submit a draft
> in couple of weeks.
>
> Regards;
> Ahmad Muhanna
>
> ++++++++++++++++++++++++++++++++++++++++++++
>
> Hi Ahmad,
>
> I received your previous email correctly, but was still considering my
> reply. Please excuse the delay.
>
> I'm concerned with the following scenario. If a FA supports both
> RFC3012 and this I-D, then it will include a Challenge Extension in
> any Agent Advertisement it sends. A MN entering an area served by the
> FA will not know whether the FA "also" supports this I-D, and so must
> include the AAA NAI Extension to cover that possibility. I grant that
> once the MN receives a Registration Reply, it will know what to do as
> long as it stays in the area serviced by the FA. However, this is
> Mobile IP, not Nomadic IP, so I expect the MN to move, often, and to
> face the exact same situation with the next FA it encounters.
>
>
> I guess no one wants to use another bit in the advertisement to
> indicate the type of AAA infrastructure in use. So is there some other
> way to provide a clue to the MN and still support backward
> compatibility and still conserve bandwidth?
>
>
> Bob
> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad
> Muhanna
> Sent: Friday, April 26, 2002 8:44 AM
> To: 'bob@marksmob.com'; 'Tony Johansson'
> Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] RE: A Question
> about:draft-ietf-mobileip-aaa-nai-00.txt
>
> Hello Bob;
> I am resending this email because I am not sure if it made it earlier.
>
> I think the whole idea is to prevent this draft from mandating all
> Mobile Nodes to include
> AAA NAI extension with subtype 1 "HA" in the following scenarios:
> 1. When the Mobile Node sends a Registration Request for
> Re-Authentication:
> MN will never be able to send the AAA NAI extension in the
> Registration
> request unless it recognizes and support that extension. Because, it
> received
> it from HAAA through the FAAA and the FA in the Registration Reply
> message.
> Legacy MN does not support any feature which requires this anyway.
> 2. When the Mobile Node request a static Mobile IP call. "specific IP
> address"
> ONLY those Mobile Node which again support and recognizes this
> extension
> will be able to send it. Because, legacy Mobile Node are not
> configured with
> AAA NAI extension for the HA anyway. Also, legacy MN does not support
> any feature which requires this to be added to the Registration
> Request.
> However, I agree the proposed text may be very broad.
> Tony/Bob,
> Do you think the following text would be more specific?
> It include all the text I proposed so far.
> section 4. should read:
> "
>    The HA identity uses subtype 1 of the AAA NAI Extension.  It
> contains
>    the NAI of the AAA interface of the HA in the form hostname@realm.
>    Together the hostname and realm forms the complete FQDN
>    (hostname.realm) of the HA's AAA interface.
>    The home agent MUST provide HA identity in every registration reply
>
>    sent to the mobile node destined through the AAA infrastructure.
>    A mobile node which support AAA NAI extension MUST provide HA
>    identity in every registration request sent when re-authenticating,
>
>    or when requesting a specific IP address at initial authentication.
>
> "
> section 5. should read:
> "
>    The AAAH identity uses subtype 2 of the AAA NAI Extension.  It
>    contains the NAI of the home AAA server in the form hostname@realm.
>
>    Together the hostname and realm forms the complete FQDN
>    (hostname.realm) of the home AAA servers interface.
>    The home agent MUST provide this in every registration reply sent
> to
>    the mobile node destined through the AAA infrastructure.
>    A mobile node which support the AAA NAI extension MUST always
>    save the latest AAAH Identity received in the registration reply
> message
>    and MUST provide the AAAH Identity in every registration request
> sent
>     when re-authenticating.
>    If the AAAH identity is present, the foreign agent MUST direct an
>    authentication request to this home AAA server when authenticating
>    the mobile node through the AAA infrastructure by means described
> in
>    [2]
> "
> This will eliminate the need for the following text:
> "The AAA NAI extension MUST only be used with the Diameter Mobile IPv4
>
> application and MUST NOT be used with any other AAA protocol."
>
> Regards;
> Ahmad Muhanna
>
> ******************************************************************************************************
>
> Hello Ahmad,
>
> I'm still not totally comfortable with this new technique and its
> impact on bandwidth-constrained links.
>
> For RFC2002, the MN sent only the authentication extensions it knew it
> needed. It knew if it had a
> security association with the FA, and had to have a security
> association with the HA.
>
> For RFC3012, the MN could use the presence (or absence) of the
> Challenge to determine which
> extensions and parameters (like NAI) it included in the Registration
> Request.
>
> But for this new I-D, the MN does not get any clue at all. Therefore
> it needs to include the extension
> because it might be needed. This, it seems to me, is not so good for
> bandwidth-constrained links.
> As Tony pointed out, it seems that the MN must be configured to send
> or not to send - I'd rather the
> FA provided some clue.
>
> Bob
>



From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 27 02:44:52 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23954
	for ; Sat, 27 Apr 2002 02:44:51 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22363;
	Sat, 27 Apr 2002 00:44:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA17665;
	Fri, 26 Apr 2002 23:44:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3R6hoGs022951
	for ; Fri, 26 Apr 2002 23:43:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3R6horA022948
	for mobile-ip-dist; Fri, 26 Apr 2002 23:43:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3R6hjGs022932
	for ; Fri, 26 Apr 2002 23:43:45 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24334
	for ; Fri, 26 Apr 2002 23:43:44 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA23579
	for ; Sat, 27 Apr 2002 00:43:43 -0600 (MDT)
Message-ID: <002101c1edb6$93b1fa30$4e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Tom K Weckstrom" 
Cc: "Charles E. Perkins" ,
        "Madhavi W. Chandra" ,
        "Annika Jonsson" ,
        ,
        "Eva Gustafsson" 
References:  <3CC818C0.1E628F82@iprg.nokia.com> <20020425121142.A7334@cisco.com> <3CC82CA7.78332B19@iprg.nokia.com> <007601c1eca2$d981bce0$8e6015ac@T23KEMPF> <20020426135504.GT29152@muminmamman.lifix.fi>
Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Fri, 26 Apr 2002 23:41:30 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Tom,

I think this question is quite relevent. We are talking here about
routing, and the original Internet routing design accommodates failure
quite well. Any change should also.

If an FA fails, only the mobile nodes in its subnet are affected. If a
GFA fails, some number of subnets under it are affected, including all
their mobile nodes. I think this is a problem if the design does not
accommodate it.

With regard to high availability, high availability invariably means
high cost. It is much more expensive to design for five 9s reliability
than to design the protocol for redundency, so that low cost, cheaper
elements that are used daily can take over if a single element fails. I
do not think network operators want to see the next generation of mobile
networks based on IP require expensive, high availabiliy equipment like
VLRs if it is possible to provide equivalent functionality with lower
cost, redundant elements such as routers.

            jak

----- Original Message -----
From: "Tom K Weckstrom" 
To: "James Kempf" 
Cc: "Charles E. Perkins" ; "Madhavi W. Chandra"
; "Annika Jonsson" ;
; "Eva Gustafsson"

Sent: Friday, April 26, 2002 6:55 AM
Subject: Re: [mobile-ip] WG Last Call:
draft-ietf-mobileip-reg-tunnel-06.txt


> James,
>
>
> On Thu, Apr 25, 2002 at 02:47:47PM -0700, James Kempf wrote:
> > Hi Charlie,
> >
> > > > There is no doubt that your draft is the result of extensive
> > > > research.
> > >
> > > In this case, we also have publications, simulations, and
> > > implementations to back up the research.
> > >
> >
> > Did your simulations look at what happened if a GFA fails?
> >
> >             jak
> ---end quoted text---
>
> I think this question is irrelevant. Let me explain with some
> additional comments/questions:
>
> - What happens, if a FA serving a single foreign network (without the
>   hierarchy) happens to fail?
>   --> The users are without the MIP service.
>
> - What do you do, if you suspect that your firewall, VPN GW, high end
>   router, or GFA may fail and you do not want the users be affected?
>   --> You deploy a High Availability solution. There are solutions out
>       there for the above mentioned network elements, probably
>       excluding GFA at the moment.
>
> - Should the High Availability solution be somehow bound to this
>   standardisation proposal at hand?
>   --> Why should it be? That can be handled separately. That can be
>       standardized separately, if need be. To me, it looks like High
>       Availability solutions would most often be proporietary.
>
>
> Regards, Tom
>
> --
> Tom Weckström                   PGP id:  E1DB55E9
> Lifix Systems Oy        Mobile:  +358 50 350
5997
> Innopoli 2       Tekniikantie 14       FIN-02150 Espoo
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 27 02:58:24 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25263
	for ; Sat, 27 Apr 2002 02:58:24 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26430;
	Sat, 27 Apr 2002 00:58:25 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00357;
	Fri, 26 Apr 2002 23:58:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3R6vbGs024431
	for ; Fri, 26 Apr 2002 23:57:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3R6vaSa024428
	for mobile-ip-dist; Fri, 26 Apr 2002 23:57:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3R6vXGs024420
	for ; Fri, 26 Apr 2002 23:57:33 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19687
	for ; Fri, 26 Apr 2002 23:57:32 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11522
	for ; Fri, 26 Apr 2002 23:57:32 -0700 (PDT)
Message-ID: <004a01c1edb8$8fd10490$4e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Rajeev Koodli" 
Cc: "Michael Thomas" , 
References: <3CB5DB1F.90909@lancaster.ac.uk>	<012801c1e198$1fcb99c0$7e6015ac@T23KEMPF>	<3CBDBC62.21C19B77@iprg.nokia.com>	<000001c1e7b6$9288fd80$746015ac@T23KEMPF>	<3CC0B44C.DB862958@iprg.nokia.com>	<046701c1e804$7016f330$736015ac@AlperVAIO>	<3CC58E3C.86B <3CC984E2.30BAF3CF@iprg.nokia.com>
Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04
Date: Fri, 26 Apr 2002 23:55:44 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Rajeev,

> REDIRECT is not sent _after_ the change of access router, but before
> the MN moves. It is a notification for an impending handover, at least
> that was my understanding and the basis for our now old proposal.
>

I don't think any signaling should be done over the air prior to
handover, unless it is possible for optimized handover to complete
successfully without it. Otherwise, if the signaling fails, then the MN
must recover using standard Mobile IP at a significant cost. I think the
optmized handover should strive for reliable, deterministic handover
performance.


> It could be simpler: handover delay over the expected inter-packet
arrival
> time.
> So, if expected handover delay is 100 ms, with 20 ms inter-packet
> separation for
> voice, you need room for 5 packets. Charlie has looked into buffering
in
> greater detail, and we have an implementation as well. We need to
study the
>
> performance aspects.
>

Right, so if the expected value of delay is 100 ms but the variance is
400 ms^2, one could get between 4 to 6 packets at one standard
deviation, 3 to 7 at 2, and so forth. If the buffer is sized for 5
packets, then you'd expect to end up dropping about 25% of the time.
That is the point I was trying to make.

On the other hand, if the handover delay is deterministic, or nearly so,
then a buffer for 5 packets should work almost all the time.

> Ok. This is a design choice. For handover smoothing, which is a
related
> albeit separate topic, we need to evaluate the available options.
>

Agreed. I also think we need more study about the various smoothing
algorithms (buffering v.s. bicasting).

> Well, I don't believe that was the proposal, but if you wish BETH to
have
> such a message, we could consider it.
>

I don't think it is a good idea if the message is issued over the air
prior to handover, and I don't think it's a good idea if the handover is
dependent on it. But it may be a good idea to inform the Mobile Node,
without requiring it to change care of address, after handover.

            jak



From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 27 03:39:11 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29654
	for ; Sat, 27 Apr 2002 03:39:11 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25550;
	Sat, 27 Apr 2002 00:38:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06069;
	Sat, 27 Apr 2002 00:37:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3R7YWGs026435
	for ; Sat, 27 Apr 2002 00:34:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3R7YW0F026434
	for mobile-ip-dist; Sat, 27 Apr 2002 00:34:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3R7YRGs026424
	for ; Sat, 27 Apr 2002 00:34:28 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08422
	for ; Sat, 27 Apr 2002 00:34:27 -0700 (PDT)
Received: from rizzo.jerky.net (rizzo.jerky.net [204.57.55.99])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17288
	for ; Sat, 27 Apr 2002 01:34:26 -0600 (MDT)
Received: from hotpop.com (kubrick.hotpop.com [204.57.55.16])
	by rizzo.jerky.net (Postfix) with SMTP id 1A67530120
	for ; Sat, 27 Apr 2002 07:32:21 +0000 (UTC)
Received: from peter (unknown [210.72.13.221])
	by zagnut.hotpop.com (Postfix) with SMTP id 75A485001D
	for ; Sat, 27 Apr 2002 07:32:16 +0000 (UTC)
Message-ID: <01cc01c1edbd$df020d20$dd0d48d2@peter>
From: "MobileIPv6" 
To: 
Subject: [mobile-ip] Hello
Date: Sat, 27 Apr 2002 15:33:45 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01C9_01C1EE00.EAD45840"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-HotPOP: -----------------------------------------------
                   Sent By HotPOP.com FREE Email
             Get your FREE POP email at www.HotPOP.com
          -----------------------------------------------
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_01C9_01C1EE00.EAD45840
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGFzIE1JUHY2IHVzZWQgaW4gbWFya2V0Pw0Kc3VjaCBhcyBQREEgc3VwcG9ydGluZyBNSVB2Nj8N
Cg==

------=_NextPart_000_01C9_01C1EE00.EAD45840
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjUw
LjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC
T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPkhhcyZu
YnNwO01JUHY2IHVzZWQgaW4gbWFya2V0PzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3l
rovkvZMgc2l6ZT0yPnN1Y2ggYXMgUERBIHN1cHBvcnRpbmcgDQpNSVB2Nj88L0ZPTlQ+PC9ESVY+
PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_01C9_01C1EE00.EAD45840--




From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 27 11:35:09 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16817
	for ; Sat, 27 Apr 2002 11:35:09 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01764;
	Sat, 27 Apr 2002 09:35:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14132;
	Sat, 27 Apr 2002 08:34:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3RFY4Gs006617
	for ; Sat, 27 Apr 2002 08:34:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3RFY4qs006616
	for mobile-ip-dist; Sat, 27 Apr 2002 08:34:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3RFXxGs006598
	for ; Sat, 27 Apr 2002 08:33:59 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20781
	for ; Sat, 27 Apr 2002 08:34:00 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19788
	for ; Sat, 27 Apr 2002 09:33:55 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3RFXlB04413;
	Sat, 27 Apr 2002 17:33:47 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA27615;
	Sat, 27 Apr 2002 17:33:48 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3RFXlT91852;
	Sat, 27 Apr 2002 17:33:47 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204271533.g3RFXlT91852@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: "Henrik Levkowetz" 
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
In-reply-to: Your message of Fri, 26 Apr 2002 21:34:13 +0200.
              
Date: Sat, 27 Apr 2002 17:33:47 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   	Thanks for pointing this out. You may want to take a look at
   the security section of the current draft, which is 
    http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt
   
=> I apologize about the draft version (I was at a conference with limited
resources and time) but the basic idea is still the same.

   	I believe we have discussed this attack in the security
   section of that draft, but if I've mistunderstood or not fully
   understood the extent of the attack, I'd be happy to update the
   security section or take other action as indicated by input from
   the list.
   
=> I disagree: the fact the CoA cannot be protected is not described
in the security section. In fact this has nothing to do with the
UDP encapsulation or registration extension (which introduce no new
security vulnerability as you explain) but only with the idea of
NAT traversal.
   
Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Sat Apr 27 12:28:04 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23456
	for ; Sat, 27 Apr 2002 12:28:03 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17436;
	Sat, 27 Apr 2002 10:28:05 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03037;
	Sat, 27 Apr 2002 09:27:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3RGREGs012710
	for ; Sat, 27 Apr 2002 09:27:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3RGRE6K012707
	for mobile-ip-dist; Sat, 27 Apr 2002 09:27:14 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3RGR9Gs012691
	for ; Sat, 27 Apr 2002 09:27:09 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25899
	for ; Sat, 27 Apr 2002 09:27:09 -0700 (PDT)
Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03477
	for ; Sat, 27 Apr 2002 10:27:08 -0600 (MDT)
Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163])
	by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3RGUGfN020138;
	Sat, 27 Apr 2002 18:30:19 +0200
From: "Henrik Levkowetz" 
To: "Francis Dupont" 
Cc: 
Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security
Date: Sat, 27 Apr 2002 18:27:02 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200204271533.g3RFXlT91852@givry.rennes.enst-bretagne.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw)
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis,

	Ah, I see what you are getting at now. Do you happen to have
some text discussing this already? If not, would you consider the
text below a decent discussion of this problem, and a meaningful
conclusion?

	"Although using UDP tunnelling as such does not introduce new
      vulnerablilities, it has to be pointed out that communicating
      across a NAT in fact does change the situation. Without a NAT, the
      care-of address in the registration request will be directly used
      by the home agent to send traffic back to the mobile node, and the
      care-of address is protected by the mobile-home authentication
      extension. When communicating across a NAT, the effective care-of
      address from the home agent point of view is that of the NAT,
      which is not protected by any authentication extension, but
      inferred from the apparent IP source address of received packets.
      This means that by using the mobile IP registration extensions
      described in this document to enable traversal of NATs, one is
      opening oneself up to having the care-of address of a mobile node
      spoofed. The implication is again that it is RECOMMENDED that this
      mechanism for NAT traversal be used together with IPsec or
      equivalent mechanisms to further mutually authenticate the
      communicating parties, and protect the communication."

	Regards,
		Henrik

Francis Dupont wrote:
> 
> 
>    	Thanks for pointing this out. You may want to take a look at
>    the security section of the current draft, which is 
>     http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt
>    
> => I apologize about the draft version (I was at a conference with limited
> resources and time) but the basic idea is still the same.
> 
>    	I believe we have discussed this attack in the security
>    section of that draft, but if I've mistunderstood or not fully
>    understood the extent of the attack, I'd be happy to update the
>    security section or take other action as indicated by input from
>    the list.
>    
> => I disagree: the fact the CoA cannot be protected is not described
> in the security section. In fact this has nothing to do with the
> UDP encapsulation or registration extension (which introduce no new
> security vulnerability as you explain) but only with the idea of
> NAT traversal.
>    
> Regards
> 
> Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Sun Apr 28 09:20:39 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11852
	for ; Sun, 28 Apr 2002 09:20:39 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06676;
	Sun, 28 Apr 2002 07:20:34 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15808;
	Sun, 28 Apr 2002 06:20:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3SDJJrP028488
	for ; Sun, 28 Apr 2002 06:19:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3SDJJNo028487
	for mobile-ip-dist; Sun, 28 Apr 2002 06:19:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3SDJFrP028480
	for ; Sun, 28 Apr 2002 06:19:15 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15737
	for ; Sun, 28 Apr 2002 06:19:17 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06337
	for ; Sun, 28 Apr 2002 07:19:12 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3SDJ5B21260;
	Sun, 28 Apr 2002 15:19:05 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA05140;
	Sun, 28 Apr 2002 15:19:06 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3SDJ5T94356;
	Sun, 28 Apr 2002 15:19:05 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204281319.g3SDJ5T94356@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: "Henrik Levkowetz" 
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
In-reply-to: Your message of Sat, 27 Apr 2002 18:27:02 +0200.
              
Date: Sun, 28 Apr 2002 15:19:05 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   	Ah, I see what you are getting at now. Do you happen to have
   some text discussing this already?

=> no, I raised the issue during a presentation at the IPCN meeting
and it seemed the importance was enough to send a short message
in the list to open a discussion ASAP.

   If not, would you consider the text below a decent discussion of
  this problem, and a meaningful conclusion?
   
   	"Although using UDP tunnelling as such does not introduce new
         vulnerablilities, it has to be pointed out that communicating
         across a NAT in fact does change the situation. Without a NAT, the
         care-of address in the registration request will be directly used
         by the home agent to send traffic back to the mobile node, and the
         care-of address is protected by the mobile-home authentication
         extension. When communicating across a NAT, the effective care-of
         address from the home agent point of view is that of the NAT,
         which is not protected by any authentication extension, but
         inferred from the apparent IP source address of received packets.
         This means that by using the mobile IP registration extensions
         described in this document to enable traversal of NATs, one is
         opening oneself up to having the care-of address of a mobile node
         spoofed. The implication is again that it is RECOMMENDED that this
         mechanism for NAT traversal be used together with IPsec or
         equivalent mechanisms to further mutually authenticate the
         communicating parties, and protect the communication."
   
=> as soon as the problem is explained I am happy.
I am afraid you have to consider the use of forged care-of address in
Denial of Service attacks too (IMHO this is far less critical but
I don't believe nobody won't complain).

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Sun Apr 28 14:04:14 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11498
	for ; Sun, 28 Apr 2002 14:04:13 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29512;
	Sun, 28 Apr 2002 12:04:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16209;
	Sun, 28 Apr 2002 11:04:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3SI34rP028958
	for ; Sun, 28 Apr 2002 11:03:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3SI33vN028957
	for mobile-ip-dist; Sun, 28 Apr 2002 11:03:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3SI2xrP028950
	for ; Sun, 28 Apr 2002 11:02:59 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06203
	for ; Sun, 28 Apr 2002 11:02:54 -0700 (PDT)
Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA18365
	for ; Sun, 28 Apr 2002 12:02:53 -0600 (MDT)
Received: from unknown (HELO EmadQ) (emadaq@217.144.4.252 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Apr 2002 18:02:51 -0000
Reply-To: 
From: "Emad Qaddoura" 
To: "'James Kempf'" ,
        
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Sun, 28 Apr 2002 21:02:33 +0200
Message-ID: <000a01c1eee7$41b56eb0$fc0490d9@EmadQ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <002101c1edb6$93b1fa30$4e6015ac@T23KEMPF>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3SI30rP028951
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

James,

	I agree with you, but I would add even protocol redundancy
should be left to the vendor. A system may provide several protocols
which may all have needs for different reliability aspects. And if one
system has several protocols and each protocol has its own HA or five 9s
requirements, then a vendor would have to end up with many of these
implementations which may be different. Therefore, the protocol design
should stay out of these aspects and leave it up to the vendor’s system
design specifics.

Thx.
EQ
SmartIPNet


> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-
> ip@sunroof.eng.sun.com] On Behalf Of James Kempf
> Sent: Saturday, April 27, 2002 8:42 AM
> To: Tom K Weckstrom
> Cc: Charles E. Perkins; Madhavi W. Chandra; Annika Jonsson; mobile-
> ip@sunroof.eng.sun.com; Eva Gustafsson
> Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-
> 06.txt
> 
> Tom,
> 
> I think this question is quite relevent. We are talking here about
> routing, and the original Internet routing design accommodates failure
> quite well. Any change should also.
> 
> If an FA fails, only the mobile nodes in its subnet are affected. If a
> GFA fails, some number of subnets under it are affected, including all
> their mobile nodes. I think this is a problem if the design does not
> accommodate it.
> 
> With regard to high availability, high availability invariably means
> high cost. It is much more expensive to design for five 9s reliability
> than to design the protocol for redundency, so that low cost, cheaper
> elements that are used daily can take over if a single element fails.
I
> do not think network operators want to see the next generation of
mobile
> networks based on IP require expensive, high availabiliy equipment
like
> VLRs if it is possible to provide equivalent functionality with lower
> cost, redundant elements such as routers.
> 
>             jak
> 
> ----- Original Message -----
> From: "Tom K Weckstrom" 
> To: "James Kempf" 
> Cc: "Charles E. Perkins" ; "Madhavi W.
Chandra"
> ; "Annika Jonsson" ;
> ; "Eva Gustafsson"
> 
> Sent: Friday, April 26, 2002 6:55 AM
> Subject: Re: [mobile-ip] WG Last Call:
> draft-ietf-mobileip-reg-tunnel-06.txt
> 
> 
> > James,
> >
> >
> > On Thu, Apr 25, 2002 at 02:47:47PM -0700, James Kempf wrote:
> > > Hi Charlie,
> > >
> > > > > There is no doubt that your draft is the result of extensive
> > > > > research.
> > > >
> > > > In this case, we also have publications, simulations, and
> > > > implementations to back up the research.
> > > >
> > >
> > > Did your simulations look at what happened if a GFA fails?
> > >
> > >             jak
> > ---end quoted text---
> >
> > I think this question is irrelevant. Let me explain with some
> > additional comments/questions:
> >
> > - What happens, if a FA serving a single foreign network (without
the
> >   hierarchy) happens to fail?
> >   --> The users are without the MIP service.
> >
> > - What do you do, if you suspect that your firewall, VPN GW, high
end
> >   router, or GFA may fail and you do not want the users be affected?
> >   --> You deploy a High Availability solution. There are solutions
out
> >       there for the above mentioned network elements, probably
> >       excluding GFA at the moment.
> >
> > - Should the High Availability solution be somehow bound to this
> >   standardisation proposal at hand?
> >   --> Why should it be? That can be handled separately. That can be
> >       standardized separately, if need be. To me, it looks like High
> >       Availability solutions would most often be proporietary.
> >
> >
> > Regards, Tom
> >
> > --
> > Tom Weckström                   PGP id:  E1DB55E9
> > Lifix Systems Oy        Mobile:  +358 50 350
> 5997
> > Innopoli 2       Tekniikantie 14       FIN-02150 Espoo
> >
> >




From owner-mobile-ip@sunroof.eng.sun.com  Sun Apr 28 14:05:04 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11587
	for ; Sun, 28 Apr 2002 14:05:04 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27923;
	Sun, 28 Apr 2002 11:04:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16230;
	Sun, 28 Apr 2002 11:04:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3SI2qrP028948
	for ; Sun, 28 Apr 2002 11:02:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3SI2qVj028947
	for mobile-ip-dist; Sun, 28 Apr 2002 11:02:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3SI2mrP028940
	for ; Sun, 28 Apr 2002 11:02:48 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23915
	for ; Sun, 28 Apr 2002 11:02:51 -0700 (PDT)
Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA18353
	for ; Sun, 28 Apr 2002 12:02:50 -0600 (MDT)
Received: from unknown (HELO EmadQ) (emadaq@217.144.4.252 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Apr 2002 18:02:41 -0000
Reply-To: 
From: "Emad Qaddoura" 
To: "'Ahmad Muhanna'" ,
        ,
        "'Annika Jonsson'" 
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Sun, 28 Apr 2002 21:02:19 +0200
Message-ID: <000501c1eee7$3bb5a2a0$fc0490d9@EmadQ>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01C1EEF7.FF3E72A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC5A@zrc2c013.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C1EEF7.FF3E72A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,
 
            I agree that in section 4.1 the two RRQ should not exist
with proper implementation. But, in the case as in
 
            However, we should be able to avoid the double RRQ as
presented in my earlier email, below. 
 
            I will leave it up to the authors to respond, just in case I
mis-understood the statement.
 
Thx.
EQ 
 
> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-
> ip@sunroof.eng.sun.com] On Behalf Of Emad Qaddoura
> Sent: Friday, April 26, 2002 6:14 PM
> To: 'Annika Jonsson'; mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Last Call: Regional Tunneling input
> 
> Annika,
> 
>     My main concern about this draft:
> 
> 1) Has there been any studies/scenarios about the impact to in-flight
> traffic to the MN, while it is performing regional re-registrations?
> 
> 2) How does the old FA handle the data that is received while the MN
> re-registers with a new FA?
> 
> 3) I understand this is not any worse from the normal (in 2002) case
> without regional registrations, but the case below can make such delay
> longer.
> 
> From Section 5.0, 4th paragraph,
> "If the advertised GFA is not the same as the one the mobile node has
>    registered as its care-of address, and if the mobile node is still
>    within the same domain as it was when it registered that care-of
>    address, the mobile node MAY try to perform a regional registration
>    with its registered GFA. If the foreign agent cannot support
>    regional registration to a GFA, other than advertised, the foreign
>    agent denies the regional registration with code UNKNOWN_GFA (see
>    section 9.3).  In this case the MN has to do a new home
registration
>    via the new GFA."
> 
> As you see, there is extra registration step here,( if the current GFA
> used by the MN is not supported by the FA), adding possible delays to
> traffic, would it be reasonable to expect all FAs in the same domain
to
> handle the regional registration to the different GFAs. Or do I
> misunderstand the above paragraph?
> 
> With the route optimization draft being optional extensions, we should
> be concerned about any additional delays to traffic destined to the
MN.
> 
> Thanks,
> EQ
> 
> 
 
 
-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad Muhanna
Sent: Friday, April 26, 2002 9:24 PM
To: 'Madhavi W. Chandra'
Cc: 'Annika Jonsson'; mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Last Call: Regional Tunneling input
 
Hi Madhavi; 
I am not one of the authors, BUT I think I can comment on this one. 
> 
> Annika, 
> 
> 
> 
> This seems to also be the case when the MN sets the CoA=0.0.0.0, 
> and the HA doesn't support Regional Registrations...two RRQ trips 
> if the MN attempts to register again with a non-zero CoA.  
> Can you please comment on this as well? 
The draft mandates that Mobile Node MUST not set this address to 
zero except if the MN and its HA support regional registration. 
section 4.1. 
" 
    If the mobile node sets the care-of address to zero, the mobile node

   and its home agent MUST support the GFA IP address extension (see
section 8.1).  
" 
Regards, 
Ahmad Muhanna 
> 
> Thanks, 
> Madhavi 
> 
> > With the route optimization draft being optional 
> extensions, we should 
> > be concerned about any additional delays to traffic 
> destined to the MN. 
> > 
> > Thanks, 
> > EQ 
> >  
> > 
> > 
> 

------=_NextPart_000_0006_01C1EEF7.FF3E72A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable












RE: [mobile-ip] Last Call: Regional Tunneling input












Hi,



 



         =
;   I
agree that in section 4.1 the two RRQ should not exist with proper
implementation. But, in the case as in



 



        =
;    However,
we should be able to avoid the double RRQ as presented in my earlier =
email,
below. 



 



        =
;    I
will leave it up to the authors to respond, just in case I mis-understood
the statement.



 



Thx.



EQ 



 



> -----Original Message-----



> From: owner-mobile-ip@sunroof.eng.sun.com =
[mailto:owner-mobile-



> ip@sunroof.eng.sun.com] On Behalf Of Emad =
Qaddoura



> Sent: Friday, April 26, 2002 6:14 PM



> To: 'Annika Jonsson'; =
mobile-ip@sunroof.eng.sun.com



> Subject: RE: [mobile-ip] Last =
Call:
Regional Tunneling input



> 



> Annika,



> 



>     =
My main
concern about this draft:



> 



> 1) Has there been any studies/scenarios about the impact to
in-flight



> traffic to the MN, while it is performing regional
re-registrations?



> 



> 2) How does the old FA handle the data that is received =
while the
MN



> re-registers with a new FA?



> 



> 3) I understand this is not any worse from the normal (in =
2002)
case



> without regional registrations, but the case below can make =
such
delay



> longer.



> 



> From Section 5.0, 4th =
paragraph,



> "If the advertised GFA is not the same as the one the =
mobile
node has



>    =
registered
as its care-of address, and if the mobile node is =
still



>    =
within the
same domain as it was when it registered that =
care-of



>    =
address,
the mobile node MAY try to perform a regional =
registration



>    =
with its
registered GFA. If the foreign agent cannot =
support



>    =
regional
registration to a GFA, other than advertised, the =
foreign



>    =
agent
denies the regional registration with code UNKNOWN_GFA =
(see



>    =
section
9.3).  In this case the MN =
has to do
a new home registration



>    =
via the
new GFA."



> 



> As you see, there is extra registration step here,( if the =
current
GFA



> used by the MN is not supported by the FA), adding possible =
delays
to



> traffic, would it be reasonable to expect all FAs
in the same domain to



> handle the regional registration to the different GFAs. Or do I



> misunderstand the above =
paragraph?



> 



> With the route optimization draft being optional =
extensions, we
should



> be concerned about any additional delays to traffic =
destined to
the MN.



> 



> Thanks,



> EQ



> 



> 



 



 






-----Original Message-----

From:
owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On
Behalf Of Ahmad Muhanna

Sent: Friday, April 26, =
2002 9:24
PM

To: 'Madhavi W. =
Chandra'

Cc: 'Annika Jonsson';
mobile-ip@sunroof.eng.sun.com

Subject: RE: [mobile-ip] =
Last
Call: Regional Tunneling input



 



Hi
Madhavi; 

I am not one of the =
authors, BUT I
think I can comment on this one. 



> 

> =
Annika, 

> 

> 

> 

> This seems to also =
be the case
when the MN sets the CoA=3D0.0.0.0, 

> and the HA doesn't =
support
Regional Registrations...two RRQ trips 

> if the MN attempts =
to register
again with a non-zero CoA.  

> Can you please =
comment on this
as well? 



The draft
mandates that Mobile Node MUST not set this address to =


zero except if the MN =
and its HA
support regional registration. 



section
4.1. 

" =


    If =
the mobile
node sets the care-of address to zero, the mobile node =


   and its =
home agent
MUST support the GFA IP address extension (see section 8.1).  =


" =




Regards,


Ahmad =
Muhanna 

> 

> =
Thanks, 

> =
Madhavi 

> 

> > With the route
optimization draft being optional 

> extensions, we =
should


> > be concerned =
about any
additional delays to traffic 

> destined to the =
MN.


> > =


> > =
Thanks, 

> > EQ =


> >  =


> > =


> > =


> =













------=_NextPart_000_0006_01C1EEF7.FF3E72A0--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 03:25:09 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06418
	for ; Mon, 29 Apr 2002 03:25:08 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16235;
	Mon, 29 Apr 2002 01:25:02 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18691;
	Mon, 29 Apr 2002 00:24:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3T7NprP029800
	for ; Mon, 29 Apr 2002 00:23:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3T7NogS029799
	for mobile-ip-dist; Mon, 29 Apr 2002 00:23:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3T7NlrP029792
	for ; Mon, 29 Apr 2002 00:23:47 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18487
	for ; Mon, 29 Apr 2002 00:23:49 -0700 (PDT)
Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16353
	for ; Mon, 29 Apr 2002 00:23:48 -0700 (PDT)
Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54])
	by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g3T7QmfN016876;
	Mon, 29 Apr 2002 09:26:49 +0200
From: "Fredrik Johansson" 
To: "Tony Johansson" ,
        "Ahmad Muhanna" , 
Cc: 
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt
Date: Mon, 29 Apr 2002 09:23:29 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <3CC9D930.5AE0DFB4@ericsson.com>
Importance: Normal
X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw)
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi,

I agree that we need to be backward compatible, however as Tony points out,
I don't believe that we should put the complexity in the client. If the
client supports AAA NAI it will send it as stated in the draft today, it's
then up to the access network to decide what's needed, if the extensions are
not understood by the access network they are simply dropped and no harm is
done (except for a few extra bytes over the air). On the other hand, if the
extensions are required by the access network I agree with Tony that it
should be handled in the Diameter Mobile IPv4 application. My guess is that
"old" mobile ip clients can receive a limited set of the services provided,
e.g. only have a home agent assigned in the home network, etc. In this way,
this draft is not doing anything different than rfc3012

/Fredrik

>-----Original Message-----
>From: Tony Johansson [mailto:tony.johansson@ericsson.com]
>Sent: den 27 april 2002 00:48
>To: Ahmad Muhanna; 'bob@marksmob.com'
>Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com
>Subject: Re: [mobile-ip] RE: A Question
>about:draft-ietf-mobileip-aaa-nai-00.txt
>
>
>Hello Bob and Ahmad,
>
>Thanks a lot for your valuable points here and I agree backward
>compatibility is an issue. In the existing deployments of Mobile IP
>clients, especially those that will soon be deployed for IS-835 (the
>cdma2000 standard) will not have AAA NAI extension support. However, I
>don't think we need to change any of the wording that we have agreed on
>in the draft-ietf-mobileip-aaa-nai-00.txt draft, instead the changes
>should be done in the Diameter Mobile IPv4 application. I rather see
>that we let the network side takes care and deal with the consequences
>of the possible backward compatibility issues for those legacy clients
>that don't have AAA NAI support then adding even more complexity to the
>mobile IP client side. I've sent a new issue to the aaa-wg list
>regarding this
>(http://www.merit.edu/mail.archives/aaa-wg/msg03958.html).
>
>Comments / objections to this?
>
>Regards,
>
>/Tony
>
>
>
>Ahmad Muhanna wrote:
>
>>
>>
>> Hi Bob;
>> You are right.
>>
>> Once more we find that Backward compatibility presents itself as an
>> issue which needs a permanent solution before we run out of bits and
>> bytes.
>> I am working on a solution and I hope I will be able to submit a draft
>> in couple of weeks.
>>
>> Regards;
>> Ahmad Muhanna
>>
>> ++++++++++++++++++++++++++++++++++++++++++++
>>
>> Hi Ahmad,
>>
>> I received your previous email correctly, but was still considering my
>> reply. Please excuse the delay.
>>
>> I'm concerned with the following scenario. If a FA supports both
>> RFC3012 and this I-D, then it will include a Challenge Extension in
>> any Agent Advertisement it sends. A MN entering an area served by the
>> FA will not know whether the FA "also" supports this I-D, and so must
>> include the AAA NAI Extension to cover that possibility. I grant that
>> once the MN receives a Registration Reply, it will know what to do as
>> long as it stays in the area serviced by the FA. However, this is
>> Mobile IP, not Nomadic IP, so I expect the MN to move, often, and to
>> face the exact same situation with the next FA it encounters.
>>
>>
>> I guess no one wants to use another bit in the advertisement to
>> indicate the type of AAA infrastructure in use. So is there some other
>> way to provide a clue to the MN and still support backward
>> compatibility and still conserve bandwidth?
>>
>>
>> Bob
>> -----Original Message-----
>> From: owner-mobile-ip@sunroof.eng.sun.com
>> [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Ahmad
>> Muhanna
>> Sent: Friday, April 26, 2002 8:44 AM
>> To: 'bob@marksmob.com'; 'Tony Johansson'
>> Cc: 'Fredrik Johansson'; mobile-ip@sunroof.eng.sun.com
>> Subject: RE: [mobile-ip] RE: A Question
>> about:draft-ietf-mobileip-aaa-nai-00.txt
>>
>> Hello Bob;
>> I am resending this email because I am not sure if it made it earlier.
>>
>> I think the whole idea is to prevent this draft from mandating all
>> Mobile Nodes to include
>> AAA NAI extension with subtype 1 "HA" in the following scenarios:
>> 1. When the Mobile Node sends a Registration Request for
>> Re-Authentication:
>> MN will never be able to send the AAA NAI extension in the
>> Registration
>> request unless it recognizes and support that extension. Because, it
>> received
>> it from HAAA through the FAAA and the FA in the Registration Reply
>> message.
>> Legacy MN does not support any feature which requires this anyway.
>> 2. When the Mobile Node request a static Mobile IP call. "specific IP
>> address"
>> ONLY those Mobile Node which again support and recognizes this
>> extension
>> will be able to send it. Because, legacy Mobile Node are not
>> configured with
>> AAA NAI extension for the HA anyway. Also, legacy MN does not support
>> any feature which requires this to be added to the Registration
>> Request.
>> However, I agree the proposed text may be very broad.
>> Tony/Bob,
>> Do you think the following text would be more specific?
>> It include all the text I proposed so far.
>> section 4. should read:
>> "
>>    The HA identity uses subtype 1 of the AAA NAI Extension.  It
>> contains
>>    the NAI of the AAA interface of the HA in the form hostname@realm.
>>    Together the hostname and realm forms the complete FQDN
>>    (hostname.realm) of the HA's AAA interface.
>>    The home agent MUST provide HA identity in every registration reply
>>
>>    sent to the mobile node destined through the AAA infrastructure.
>>    A mobile node which support AAA NAI extension MUST provide HA
>>    identity in every registration request sent when re-authenticating,
>>
>>    or when requesting a specific IP address at initial authentication.
>>
>> "
>> section 5. should read:
>> "
>>    The AAAH identity uses subtype 2 of the AAA NAI Extension.  It
>>    contains the NAI of the home AAA server in the form hostname@realm.
>>
>>    Together the hostname and realm forms the complete FQDN
>>    (hostname.realm) of the home AAA servers interface.
>>    The home agent MUST provide this in every registration reply sent
>> to
>>    the mobile node destined through the AAA infrastructure.
>>    A mobile node which support the AAA NAI extension MUST always
>>    save the latest AAAH Identity received in the registration reply
>> message
>>    and MUST provide the AAAH Identity in every registration request
>> sent
>>     when re-authenticating.
>>    If the AAAH identity is present, the foreign agent MUST direct an
>>    authentication request to this home AAA server when authenticating
>>    the mobile node through the AAA infrastructure by means described
>> in
>>    [2]
>> "
>> This will eliminate the need for the following text:
>> "The AAA NAI extension MUST only be used with the Diameter Mobile IPv4
>>
>> application and MUST NOT be used with any other AAA protocol."
>>
>> Regards;
>> Ahmad Muhanna
>>
>>
>*******************************************************************
>***********************************
>>
>> Hello Ahmad,
>>
>> I'm still not totally comfortable with this new technique and its
>> impact on bandwidth-constrained links.
>>
>> For RFC2002, the MN sent only the authentication extensions it knew it
>> needed. It knew if it had a
>> security association with the FA, and had to have a security
>> association with the HA.
>>
>> For RFC3012, the MN could use the presence (or absence) of the
>> Challenge to determine which
>> extensions and parameters (like NAI) it included in the Registration
>> Request.
>>
>> But for this new I-D, the MN does not get any clue at all. Therefore
>> it needs to include the extension
>> because it might be needed. This, it seems to me, is not so good for
>> bandwidth-constrained links.
>> As Tony pointed out, it seems that the MN must be configured to send
>> or not to send - I'd rather the
>> FA provided some clue.
>>
>> Bob
>>



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 05:29:16 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15713
	for ; Mon, 29 Apr 2002 05:29:16 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26241;
	Mon, 29 Apr 2002 02:28:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22998;
	Mon, 29 Apr 2002 02:28:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3T9RlrP000052
	for ; Mon, 29 Apr 2002 02:27:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3T9Rkb4000051
	for mobile-ip-dist; Mon, 29 Apr 2002 02:27:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3T9RhrP000042
	for ; Mon, 29 Apr 2002 02:27:43 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07349
	for ; Mon, 29 Apr 2002 02:27:45 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20387
	for ; Mon, 29 Apr 2002 03:27:37 -0600 (MDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3T9RXs7022735
	for ; Mon, 29 Apr 2002 11:27:33 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Apr 29 11:29:34 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBTZQZ3>; Mon, 29 Apr 2002 11:27:32 +0200
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACD1@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'James Kempf'" ,
        "'Rajeev Koodli'"
	 
Cc: "'Michael Thomas'" ,
        "'mobile-ip@sunroof.eng.sun.com'"
	 
Subject: RE: [mobile-ip] some questions about draft-ietf-mobileip-fast-mip
	v6-04
Date: Mon, 29 Apr 2002 11:27:30 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

James,

I rather favor some mechanism to inform the MN after 
the move has occured. For example, sending the MN an 
ICMP REDIRECT message after the access router has changed, 
as Michael has suggested, would do the trick,
as it would avoid the problem of the signaling getting cut off
prematurely.
 
=> A side note, this is not the way redirects are used. 
If there is an indication after the MN moves, then 
we should keep it simple and stick to the original
MIPv6 design. However, I agree with Rajeev's analysis
and suggestions to use the indication before movement.
Also, in the MIPv4 draft, we did add a combined method
for failure modes where the oFA sends the indication
before the MN moves, and if no registration is received
till the MN disconnects, the traffic is forwarded to
the new FA.
This is clearly valid for the case where the network
(FA) is aware of the connection/disconnection state
of the MN.

 Hesham
 


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 09:00:05 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01937
	for ; Mon, 29 Apr 2002 09:00:04 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04502;
	Mon, 29 Apr 2002 07:00:03 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11183;
	Mon, 29 Apr 2002 05:59:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TCx2rP000546
	for ; Mon, 29 Apr 2002 05:59:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TCx2D9000545
	for mobile-ip-dist; Mon, 29 Apr 2002 05:59:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TCwxrP000538
	for ; Mon, 29 Apr 2002 05:58:59 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10937
	for ; Mon, 29 Apr 2002 05:59:00 -0700 (PDT)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00092
	for ; Mon, 29 Apr 2002 05:59:00 -0700 (PDT)
Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 29 Apr 2002 08:56:05 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] Working Group Last Call: draft-ietf-mobileip-nat-traversal-02.txt
Date: Mon, 29 Apr 2002 08:56:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 


This is Mobile IP working group last call for moving the following draft to
Proposed Std:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt
.

Please post last call comments to the mailing list before Friday, May 17.

Phil


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 09:19:04 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04156
	for ; Mon, 29 Apr 2002 09:19:04 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28980;
	Mon, 29 Apr 2002 07:19:03 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15973;
	Mon, 29 Apr 2002 06:18:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TDHsrP000644
	for ; Mon, 29 Apr 2002 06:17:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TDHrnB000643
	for mobile-ip-dist; Mon, 29 Apr 2002 06:17:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TDHorP000636
	for ; Mon, 29 Apr 2002 06:17:50 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15601
	for ; Mon, 29 Apr 2002 06:17:52 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28427
	for ; Mon, 29 Apr 2002 07:17:51 -0600 (MDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3TDHpk10195;
	Mon, 29 Apr 2002 08:17:51 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 29 Apr 2002 08:17:57 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC60@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Fredrik Johansson'" ,
        Tony Johansson , bob@marksmob.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-
	00.txt
Date: Mon, 29 Apr 2002 08:17:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EF80.44B8AB10"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1EF80.44B8AB10
Content-Type: text/plain;
	charset="iso-8859-1"

Hello all;

YES, I agree as long as we change the mandates from MUST to SHOULD.
On the other hand, we agreed to change the following in section 5 which is
not related
to the Mobile Node Client:

In section 5. It reads: 
"The home agent MUST provide this in every registration reply if using 
   the AAA server ." 

"The home agent MUST provide this in every registration reply sent to 
  the mobile node destined through the AAA infrastructure." 
  
I hope that you do not mind.


Regards;
Ahmad Muhanna

> 
> 
> Hi,
> 
> I agree that we need to be backward compatible, however as 
> Tony points out,
> I don't believe that we should put the complexity in the 
> client. If the
> client supports AAA NAI it will send it as stated in the 
> draft today, it's
> then up to the access network to decide what's needed, if the 
> extensions are
> not understood by the access network they are simply dropped 
> and no harm is
> done (except for a few extra bytes over the air). On the 
> other hand, if the
> extensions are required by the access network I agree with 
> Tony that it
> should be handled in the Diameter Mobile IPv4 application. My 
> guess is that
> "old" mobile ip clients can receive a limited set of the 
> services provided,
> e.g. only have a home agent assigned in the home network, 
> etc. In this way,
> this draft is not doing anything different than rfc3012
> 
> /Fredrik
> >
> >
> >Hello Bob and Ahmad,
> >
> >Thanks a lot for your valuable points here and I agree backward
> >compatibility is an issue. In the existing deployments of Mobile IP
> >clients, especially those that will soon be deployed for IS-835 (the
> >cdma2000 standard) will not have AAA NAI extension support. 
> However, I
> >don't think we need to change any of the wording that we 
> have agreed on
> >in the draft-ietf-mobileip-aaa-nai-00.txt draft, instead the changes
> >should be done in the Diameter Mobile IPv4 application. I rather see
> >that we let the network side takes care and deal with the 
> consequences
> >of the possible backward compatibility issues for those 
> legacy clients
> >that don't have AAA NAI support then adding even more 
> complexity to the
> >mobile IP client side. I've sent a new issue to the aaa-wg list
> >regarding this
> >(http://www.merit.edu/mail.archives/aaa-wg/msg03958.html).
> >
> >Comments / objections to this?
> >
> >Regards,
> >
> >/Tony
> >
> 

------_=_NextPart_001_01C1EF80.44B8AB10
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai-00.txt




Hello all;




YES, I agree as long as we change the mandates from MUST to SHOULD.

On the other hand, we agreed to change the following in section 5 which is not related

to the Mobile Node Client:




In section 5. It reads: 

"The home agent MUST provide this in every registration reply if using 

   the AAA server ." 




"The home agent MUST provide this in every registration reply sent to 

  the mobile node destined through the AAA infrastructure." 

  

I hope that you do not mind.






Regards;

Ahmad Muhanna




> 

> 

> Hi,

> 

> I agree that we need to be backward compatible, however as 

> Tony points out,

> I don't believe that we should put the complexity in the 

> client. If the

> client supports AAA NAI it will send it as stated in the 

> draft today, it's

> then up to the access network to decide what's needed, if the 

> extensions are

> not understood by the access network they are simply dropped 

> and no harm is

> done (except for a few extra bytes over the air). On the 

> other hand, if the

> extensions are required by the access network I agree with 

> Tony that it

> should be handled in the Diameter Mobile IPv4 application. My 

> guess is that

> "old" mobile ip clients can receive a limited set of the 

> services provided,

> e.g. only have a home agent assigned in the home network, 

> etc. In this way,

> this draft is not doing anything different than rfc3012

> 

> /Fredrik

> >

> >

> >Hello Bob and Ahmad,

> >

> >Thanks a lot for your valuable points here and I agree backward

> >compatibility is an issue. In the existing deployments of Mobile IP

> >clients, especially those that will soon be deployed for IS-835 (the

> >cdma2000 standard) will not have AAA NAI extension support. 

> However, I

> >don't think we need to change any of the wording that we 

> have agreed on

> >in the draft-ietf-mobileip-aaa-nai-00.txt draft, instead the changes

> >should be done in the Diameter Mobile IPv4 application. I rather see

> >that we let the network side takes care and deal with the 

> consequences

> >of the possible backward compatibility issues for those 

> legacy clients

> >that don't have AAA NAI support then adding even more 

> complexity to the

> >mobile IP client side. I've sent a new issue to the aaa-wg list

> >regarding this

> >(http://www.merit.edu/mail.archives/aaa-wg/msg03958.html).

> >

> >Comments / objections to this?

> >

> >Regards,

> >

> >/Tony

> >

> 





------_=_NextPart_001_01C1EF80.44B8AB10--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 09:19:16 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04197
	for ; Mon, 29 Apr 2002 09:19:15 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29143;
	Mon, 29 Apr 2002 07:19:16 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16023;
	Mon, 29 Apr 2002 06:19:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TDIPrP000675
	for ; Mon, 29 Apr 2002 06:18:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TDIPRE000668
	for mobile-ip-dist; Mon, 29 Apr 2002 06:18:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TDIIrP000658
	for ; Mon, 29 Apr 2002 06:18:18 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14282
	for ; Mon, 29 Apr 2002 06:18:20 -0700 (PDT)
Received: from chardonnay.levkowetz.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10812
	for ; Mon, 29 Apr 2002 06:18:19 -0700 (PDT)
Received: from [127.0.0.1] (helo=chardonnay)
	by chardonnay.levkowetz.com with smtp (Exim 4.02)
	id GVBZMG-00029K-00; Mon, 29 Apr 2002 15:18:16 +0200
From: "Henrik Levkowetz" 
To: ,
        "Henrik Levkowetz" 
Cc: 
Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
Date: Mon, 29 Apr 2002 15:18:16 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
Importance: Normal
In-Reply-To: <200204281319.g3SDJ5T94356@givry.rennes.enst-bretagne.fr>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis wrote:
......
>    
> => as soon as the problem is explained I am happy.

Ok. I'll make sure some text on this is included. 

> I am afraid you have to consider the use of forged care-of address in
> Denial of Service attacks too (IMHO this is far less critical but
> I don't believe nobody won't complain).

Mmm, I don't see that there's a difference in this case at all - a forged
care-of address only exists at the time where a registration request has
been decoded and validated, and a valid UDP tunnel request extension found.
But in a DoS attack, (as opposed to an attack with a cryptographically broken
security association) the attacker will be sending invalid reg. requests to
the HA, to force it to spend time handling them. They will never come as
far as to being validated, and thus there cannot be an issue of a forged
care-of address. As far as I can see, this plays out exactly as in current
MIPv4 - no difference at all.

	Best regards,
		Henrik





From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 09:45:47 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07406
	for ; Mon, 29 Apr 2002 09:45:46 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26108;
	Mon, 29 Apr 2002 06:45:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22753;
	Mon, 29 Apr 2002 06:44:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TDhHrP000876
	for ; Mon, 29 Apr 2002 06:43:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TDhHfA000875
	for mobile-ip-dist; Mon, 29 Apr 2002 06:43:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TDhErP000868
	for ; Mon, 29 Apr 2002 06:43:14 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21078
	for ; Mon, 29 Apr 2002 06:43:16 -0700 (PDT)
Received: from cisco.com (shako.cisco.com [64.102.17.78])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11789
	for ; Mon, 29 Apr 2002 07:43:15 -0600 (MDT)
Received: (from mchandra@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA27204;
	Mon, 29 Apr 2002 09:42:12 -0400 (EDT)
Date: Mon, 29 Apr 2002 09:42:12 -0400
From: "Madhavi W. Chandra" 
To: Ahmad Muhanna 
Cc: "'Madhavi W. Chandra'" ,
        "'Annika Jonsson'" ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Last Call:  Regional Tunneling input
Message-ID: <20020429094211.A11950@cisco.com>
References: <6B49EDFE974BD51197D70002A56079D801AFCC5A@zrc2c013.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCC5A@zrc2c013.us.nortel.com>; from amuhanna@nortelnetworks.com on Fri, Apr 26, 2002 at 02:24:29PM -0500
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

HI Ahmad,

On Fri, Apr 26, 2002 at 02:24:29PM -0500, Ahmad Muhanna wrote:
> Hi Madhavi;
> I am not one of the authors, BUT I think I can comment on this one.
> > 
> > Annika,
> > 
> > This seems to also be the case when the MN sets the CoA=0.0.0.0,
> > and the HA doesn't support Regional Registrations...two RRQ trips
> > if the MN attempts to register again with a non-zero CoA.  
> > Can you please comment on this as well?
> 
> The draft mandates that Mobile Node MUST not set this address to
> zero except if the MN and its HA support regional registration.
> 
> section 4.1. 
> " 
>     If the mobile node sets the care-of address to zero, the mobile node 
>    and its home agent MUST support the GFA IP address extension (see section
> 8.1).  
> " 

OK...thanks for pointing this out.  I was looking for such a 
statement, but somehow missed it.

Regards,
Madhavi

> 
> Regards,
> Ahmad Muhanna
> > 
> > Thanks,
> > Madhavi
> > 
> > > With the route optimization draft being optional 
> > extensions, we should
> > > be concerned about any additional delays to traffic 
> > destined to the MN.
> > > 
> > > Thanks,
> > > EQ 
> > >  
> > > 
> > > 
> > 


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 10:22:33 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11588
	for ; Mon, 29 Apr 2002 10:22:33 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04577;
	Mon, 29 Apr 2002 08:22:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01249;
	Mon, 29 Apr 2002 07:22:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TELTrP001072
	for ; Mon, 29 Apr 2002 07:21:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TELTKa001071
	for mobile-ip-dist; Mon, 29 Apr 2002 07:21:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TELQrP001064
	for ; Mon, 29 Apr 2002 07:21:26 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13353
	for ; Mon, 29 Apr 2002 07:21:28 -0700 (PDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22610
	for ; Mon, 29 Apr 2002 08:21:27 -0600 (MDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3TELN426310;
	Mon, 29 Apr 2002 09:21:23 -0500 (CDT)
Message-ID: <3CCD56FA.3070005@alcatel.com>
Date: Mon, 29 Apr 2002 09:21:46 -0500
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Phil Roberts 
CC: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: Re: [mobile-ip] Working Group Last Call: draft-ietf-mobileip-nat-traversal-02.txt
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Phil,
  This draft is being revised now, so should we wait until the revision 
is over for the last call?

Regards,

Phil Roberts wrote:

>This is Mobile IP working group last call for moving the following draft to
>Proposed Std:
>http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt
>.
>
>Please post last call comments to the mailing list before Friday, May 17.
>
>Phil
>

-- 
Behcet 





From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 10:24:09 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11807
	for ; Mon, 29 Apr 2002 10:24:09 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24888;
	Mon, 29 Apr 2002 08:24:08 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01715;
	Mon, 29 Apr 2002 07:23:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TEN4rP001115
	for ; Mon, 29 Apr 2002 07:23:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TEN4Gr001114
	for mobile-ip-dist; Mon, 29 Apr 2002 07:23:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TEN0rP001107
	for ; Mon, 29 Apr 2002 07:23:00 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01409
	for ; Mon, 29 Apr 2002 07:22:55 -0700 (PDT)
Received: from chardonnay.levkowetz.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21668
	for ; Mon, 29 Apr 2002 08:22:50 -0600 (MDT)
Received: from [127.0.0.1] (helo=chardonnay)
	by chardonnay.levkowetz.com with smtp (Exim 4.02)
	id GVC2M0-0002C8-00; Mon, 29 Apr 2002 16:22:48 +0200
From: "Henrik Levkowetz" 
To: "Francis Dupont" 
Cc: 
Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security
Date: Mon, 29 Apr 2002 16:22:47 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
Importance: Normal
In-Reply-To: <200204281319.g3SDJ5T94356@givry.rennes.enst-bretagne.fr>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis,

Actually, I've been thinking some more about this, and I believe that
the problem is less serious than I first thought.  What can be done by
somebody on the path between MN and HA is to spoof the source address of
the registration request, which will later be used as the care-of
address, i.e.  the destination address of the forward tunnel from the HA
point of view. This will not influence the reverse tunnel, which will
remain unaffected. So the attacker will have to remain on the path in
order to do harm, and then we are back to a situation which is pretty
equivalent to what we have with MIPv4 without NAT traversal, I believe.
Have I missed something here?

	Regards,
		Henrik


Francis Dupont wrote:
> 
>    	Ah, I see what you are getting at now. Do you happen to have
>    some text discussing this already?
> 
> => no, I raised the issue during a presentation at the IPCN meeting
> and it seemed the importance was enough to send a short message
> in the list to open a discussion ASAP.
> 
>    If not, would you consider the text below a decent discussion of
>   this problem, and a meaningful conclusion?
>    
>    	"Although using UDP tunnelling as such does not introduce new
>          vulnerablilities, it has to be pointed out that communicating
>          across a NAT in fact does change the situation. Without a NAT, the
>          care-of address in the registration request will be directly used
>          by the home agent to send traffic back to the mobile node, and the
>          care-of address is protected by the mobile-home authentication
>          extension. When communicating across a NAT, the effective care-of
>          address from the home agent point of view is that of the NAT,
>          which is not protected by any authentication extension, but
>          inferred from the apparent IP source address of received packets.
>          This means that by using the mobile IP registration extensions
>          described in this document to enable traversal of NATs, one is
>          opening oneself up to having the care-of address of a mobile node
>          spoofed. The implication is again that it is RECOMMENDED that this
>          mechanism for NAT traversal be used together with IPsec or
>          equivalent mechanisms to further mutually authenticate the
>          communicating parties, and protect the communication."
>    
> => as soon as the problem is explained I am happy.
> I am afraid you have to consider the use of forged care-of address in
> Denial of Service attacks too (IMHO this is far less critical but
> I don't believe nobody won't complain).
> 
> Thanks
> 
> Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 10:34:36 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13090
	for ; Mon, 29 Apr 2002 10:34:35 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02190;
	Mon, 29 Apr 2002 08:34:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08443;
	Mon, 29 Apr 2002 07:34:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TEXZrP001278
	for ; Mon, 29 Apr 2002 07:33:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TEXZ12001277
	for mobile-ip-dist; Mon, 29 Apr 2002 07:33:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TEXVrP001270
	for ; Mon, 29 Apr 2002 07:33:31 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08061
	for ; Mon, 29 Apr 2002 07:33:34 -0700 (PDT)
Received: from chardonnay.levkowetz.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10343
	for ; Mon, 29 Apr 2002 07:33:33 -0700 (PDT)
Received: from [127.0.0.1] (helo=chardonnay)
	by chardonnay.levkowetz.com with smtp (Exim 4.02)
	id GVC33I-00021W-00; Mon, 29 Apr 2002 16:33:18 +0200
From: "Henrik Levkowetz" 
To: "Behcet Sarikaya" ,
        "Phil Roberts" 
Cc: 
Subject: RE: [mobile-ip] Working Group Last Call:     draft-ietf-mobileip-nat-traversal-02.txt
Date: Mon, 29 Apr 2002 16:33:18 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
Importance: Normal
In-Reply-To: <3CCD56FA.3070005@alcatel.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

?? 

Bechet,

	We had not planned to issue another revision before last call. 

	There has been a few comments, I expected to handle those at the same 
time as other comments resulting from last call, and then if necessary have 
a new last call.

	Regards,
		Henrik

> 
> Hi Phil,
>   This draft is being revised now, so should we wait until the revision 
> is over for the last call?
> 
> Regards,
> 
> Phil Roberts wrote:
> 
> >This is Mobile IP working group last call for moving the following draft to
> >Proposed Std:
> >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt
> >.
> >
> >Please post last call comments to the mailing list before Friday, May 17.
> >
> >Phil
> >
> 
> -- 
> Behcet 
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 11:35:18 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18868
	for ; Mon, 29 Apr 2002 11:35:17 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22473;
	Mon, 29 Apr 2002 09:35:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04210;
	Mon, 29 Apr 2002 08:35:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TFYMrP001640
	for ; Mon, 29 Apr 2002 08:34:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TFYMOx001639
	for mobile-ip-dist; Mon, 29 Apr 2002 08:34:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TFYJrP001632
	for ; Mon, 29 Apr 2002 08:34:19 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20952
	for ; Mon, 29 Apr 2002 08:34:22 -0700 (PDT)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21761
	for ; Mon, 29 Apr 2002 09:34:21 -0600 (MDT)
Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 29 Apr 2002 11:31:26 -0400
Message-ID: 
From: Phil Roberts 
To: "'Behcet Sarikaya'" ,
        Phil Roberts
	 
Cc: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Working Group Last Call: draft-ietf-mobileip-nat-
	traversal-02.txt
Date: Mon, 29 Apr 2002 11:31:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

No, why?  The current discussion can be folded in with other last
call comments.


> -----Original Message-----
> From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] 
> Sent: Monday, April 29, 2002 10:22 AM
> To: Phil Roberts
> Cc: 'mobile-ip@sunroof.eng.sun.com'
> Subject: Re: [mobile-ip] Working Group Last Call: 
> draft-ietf-mobileip-nat-traversal-02.txt
> 
> 
> Hi Phil,
>   This draft is being revised now, so should we wait until 
> the revision 
> is over for the last call?
> 
> Regards,
> 
> Phil Roberts wrote:
> 
> >This is Mobile IP working group last call for moving the following 
> >draft to Proposed Std: 
> >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-t
raversal-0
>2.txt
>.
>
>Please post last call comments to the mailing list before Friday, May 
>17.
>
>Phil
>

-- 
Behcet 




From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 11:57:58 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20828
	for ; Mon, 29 Apr 2002 11:57:57 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27795;
	Mon, 29 Apr 2002 08:57:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13398;
	Mon, 29 Apr 2002 08:57:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TFuYrP001777
	for ; Mon, 29 Apr 2002 08:56:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TFuYr2001776
	for mobile-ip-dist; Mon, 29 Apr 2002 08:56:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TFuUrP001769
	for ; Mon, 29 Apr 2002 08:56:31 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13057
	for ; Mon, 29 Apr 2002 08:56:34 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16849
	for ; Mon, 29 Apr 2002 09:56:33 -0600 (MDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3TFuWs7001693
	for ; Mon, 29 Apr 2002 17:56:32 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Apr 29 17:55:33 2002 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 29 Apr 2002 17:44:54 +0200
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACEA@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'emadaq@yahoo.com'" ,
        "'Annika Jonsson'"
	 ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Mon, 29 Apr 2002 17:55:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Emad,

  > Annika,
  > 
  > 	My main concern about this draft:
  > 
  > 1) Has there been any studies/scenarios about the impact to 
  > in-flight
  > traffic to the MN, while it is performing regional 
  > re-registrations? 
  > 
  > 2) How does the old FA handle the data that is received while the MN
  > re-registers with a new FA? 

=> Isn't this the same for a HA registration?
Why should we expect this draft to handle all the 
handover problems?
The low latency draft handles the problems you
mention, and it includes a section on how to 
co-exist with this draft.

Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 14:54:20 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11187
	for ; Mon, 29 Apr 2002 14:54:19 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06376;
	Mon, 29 Apr 2002 11:53:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01014;
	Mon, 29 Apr 2002 11:53:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TIqerP002299
	for ; Mon, 29 Apr 2002 11:52:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TIqeEd002298
	for mobile-ip-dist; Mon, 29 Apr 2002 11:52:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TIqbrP002291
	for ; Mon, 29 Apr 2002 11:52:37 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00676
	for ; Mon, 29 Apr 2002 11:52:40 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05161
	for ; Mon, 29 Apr 2002 12:52:39 -0600 (MDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3TIqcs7000722
	for ; Mon, 29 Apr 2002 20:52:38 +0200 (MEST)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon Apr 29 20:52:37 2002 +0200
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <2281ZW67>; Mon, 29 Apr 2002 20:52:39 +0200
Message-ID: 
From: "Karen E Nielsen (TED)" 
To: "'Vijay Devarapalli'" 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] How to process HAO
Date: Mon, 29 Apr 2002 20:52:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Vijay,

> HAO is processed if
> 
>   - if there is a BCE with CoA = IPv6 src and HoA = HAO content
Fine
>   - if there is a home registration BCE with HoA = HAO content

I am probably missing something obvious here - but - why is it that the CoA not 
need to be verified with a home registration BCE ?

>   - if packet contains BU and satisfies the security policy
>     between MN and HA 
Fine - 
>   - if packet contains AH or ESP header and satisfies the security
>     policy check between MN and HA.
Fine
> 

Karen


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 16:06:48 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17729
	for ; Mon, 29 Apr 2002 16:06:43 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18579;
	Mon, 29 Apr 2002 14:06:42 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27769;
	Mon, 29 Apr 2002 13:06:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TK5CrP002579
	for ; Mon, 29 Apr 2002 13:05:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TK5CF3002578
	for mobile-ip-dist; Mon, 29 Apr 2002 13:05:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TK57rP002571
	for ; Mon, 29 Apr 2002 13:05:07 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26900
	for ; Mon, 29 Apr 2002 13:05:07 -0700 (PDT)
Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA14623
	for ; Mon, 29 Apr 2002 13:05:00 -0700 (PDT)
Received: from unknown (HELO EmadQ) (emadaq@217.144.4.171 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Apr 2002 20:04:57 -0000
Reply-To: 
From: "Emad Qaddoura" 
To: "'Hesham Soliman \(ERA\)'" ,
        "'Annika Jonsson'" ,
        
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Mon, 29 Apr 2002 23:04:32 +0200
Message-ID: <000001c1efc1$79fec1b0$ab0490d9@EmadQ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6ACEA@Esealnt861.al.sw.ericsson.se>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham,

	Yes it is not different from the HA registration, but, we are
adding additional level(s) for processing registrations. Therefore, the
ultimate timing might be impacted depending on the scenario. I really
wish to see the studies/(bakeoff results if any) for this draft to
understand the overall impact to MIP.

	What is the status of the low latency draft? How many vendors
have adopted the low latency draft already and have it in their
products? Is it required or optional when addition the regional
registration scheme? Please don't consider this as a negative view of
the low latency draft, but until these drafts become adopted and widely
implemented, it would be preferable to make new MIP design/enhancements
with the least impact to through traffic. Otherwise, MIP would be more
of non-real time oriented mobility protocol.

Thx.
EQ
	 

> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-
> ip@sunroof.eng.sun.com] On Behalf Of Hesham Soliman (ERA)
> Sent: Monday, April 29, 2002 5:55 PM
> To: 'emadaq@yahoo.com'; 'Annika Jonsson';
mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Last Call: Regional Tunneling input
> 
> Emad,
> 
>   > Annika,
>   >
>   > 	My main concern about this draft:
>   >
>   > 1) Has there been any studies/scenarios about the impact to
>   > in-flight
>   > traffic to the MN, while it is performing regional
>   > re-registrations?
>   >
>   > 2) How does the old FA handle the data that is received while the
MN
>   > re-registers with a new FA?
> 
> => Isn't this the same for a HA registration?
> Why should we expect this draft to handle all the
> handover problems?
> The low latency draft handles the problems you
> mention, and it includes a section on how to
> co-exist with this draft.
> 
> Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 16:07:26 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17750
	for ; Mon, 29 Apr 2002 16:07:21 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15810;
	Mon, 29 Apr 2002 13:06:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27792;
	Mon, 29 Apr 2002 13:06:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TK4srP002559
	for ; Mon, 29 Apr 2002 13:04:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TK4smL002558
	for mobile-ip-dist; Mon, 29 Apr 2002 13:04:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TK4hrP002543
	for ; Mon, 29 Apr 2002 13:04:43 -0700 (PDT)
Received: from patan.sun.com ([129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26718
	for ; Mon, 29 Apr 2002 13:04:45 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00552
	for ; Mon, 29 Apr 2002 14:04:45 -0600 (MDT)
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 NAA06163;
	Mon, 29 Apr 2002 13:04:44 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3TK4hC24668;
	Mon, 29 Apr 2002 13:04:43 -0700
X-mProtect: <200204292004> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd59UXYU; Mon, 29 Apr 2002 13:04:41 PDT
Message-ID: <3CCDA75A.80214A9A@iprg.nokia.com>
Date: Mon, 29 Apr 2002 13:04:42 -0700
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: "Karen E Nielsen (TED)" 
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] How to process HAO
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

"Karen E Nielsen (TED)" wrote:
> 
> Hi Vijay,
> 
> > HAO is processed if
> >
> >   - if there is a BCE with CoA = IPv6 src and HoA = HAO content
> Fine
> >   - if there is a home registration BCE with HoA = HAO content
> 
> I am probably missing something obvious here - but - why is it that the CoA not
> need to be verified with a home registration BCE ?

When the MN moves and send a home registration BU, the source
address would be the newCoA (whereas the current BCE at the
home agent has the oldCoA). 

The HA has to just update the existing BCE with the newCoA. 

Vijay

> 
> >   - if packet contains BU and satisfies the security policy
> >     between MN and HA
> Fine -
> >   - if packet contains AH or ESP header and satisfies the security
> >     policy check between MN and HA.
> Fine
> >
> 
> Karen


From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 16:30:15 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18727
	for ; Mon, 29 Apr 2002 16:30:15 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08016;
	Mon, 29 Apr 2002 13:29:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06378;
	Mon, 29 Apr 2002 13:29:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TKSUrP002863
	for ; Mon, 29 Apr 2002 13:28:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TKSTmn002862
	for mobile-ip-dist; Mon, 29 Apr 2002 13:28:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TKSQrP002855
	for ; Mon, 29 Apr 2002 13:28:26 -0700 (PDT)
Received: from patan.sun.com ([129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06032
	for ; Mon, 29 Apr 2002 13:28:28 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16987
	for ; Mon, 29 Apr 2002 14:28:27 -0600 (MDT)
Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3TKRd8M018664;
	Mon, 29 Apr 2002 13:27:39 -0700 (PDT)
Received: from DBLAIRW2K (newyork2-dhcp-89.cisco.com [171.68.49.89])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id ACT78837;
	Mon, 29 Apr 2002 13:27:33 -0700 (PDT)
From: "Dana L. Blair" 
To: "James Kempf" , "Tom K Weckstrom" 
Cc: "Charles E. Perkins" ,
        "Madhavi W. Chandra" ,
        "Annika Jonsson" ,
        ,
        "Eva Gustafsson" 
Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.txt
Date: Mon, 29 Apr 2002 16:27:33 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <002101c1edb6$93b1fa30$4e6015ac@T23KEMPF>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of James Kempf
> Sent: Saturday, April 27, 2002 2:42 AM
> To: Tom K Weckstrom
> Cc: Charles E. Perkins; Madhavi W. Chandra; Annika Jonsson;
> mobile-ip@sunroof.eng.sun.com; Eva Gustafsson
> Subject: Re: [mobile-ip] WG Last Call:
> draft-ietf-mobileip-reg-tunnel-06.txt
>
>
> Tom,
>
> I think this question is quite relevent. We are talking here about
> routing, and the original Internet routing design accommodates failure
> quite well. Any change should also.
>
> If an FA fails, only the mobile nodes in its subnet are affected. If a
> GFA fails, some number of subnets under it are affected, including all
> their mobile nodes. I think this is a problem if the design does not
> accommodate it.

Actually a well designed Wireless Access network would have more
than one FA per IP Subnet.  Therefore, if one FA fails, then
MNs could re-register through the other FA quite simply.

thanks,
Dana

>
> With regard to high availability, high availability invariably means
> high cost. It is much more expensive to design for five 9s reliability
> than to design the protocol for redundency, so that low cost, cheaper
> elements that are used daily can take over if a single element fails. I
> do not think network operators want to see the next generation of mobile
> networks based on IP require expensive, high availabiliy equipment like
> VLRs if it is possible to provide equivalent functionality with lower
> cost, redundant elements such as routers.
>
>             jak
>
> ----- Original Message -----
> From: "Tom K Weckstrom" 
> To: "James Kempf" 
> Cc: "Charles E. Perkins" ; "Madhavi W. Chandra"
> ; "Annika Jonsson" ;
> ; "Eva Gustafsson"
> 
> Sent: Friday, April 26, 2002 6:55 AM
> Subject: Re: [mobile-ip] WG Last Call:
> draft-ietf-mobileip-reg-tunnel-06.txt
>
>
> > James,
> >
> >
> > On Thu, Apr 25, 2002 at 02:47:47PM -0700, James Kempf wrote:
> > > Hi Charlie,
> > >
> > > > > There is no doubt that your draft is the result of extensive
> > > > > research.
> > > >
> > > > In this case, we also have publications, simulations, and
> > > > implementations to back up the research.
> > > >
> > >
> > > Did your simulations look at what happened if a GFA fails?
> > >
> > >             jak
> > ---end quoted text---
> >
> > I think this question is irrelevant. Let me explain with some
> > additional comments/questions:
> >
> > - What happens, if a FA serving a single foreign network (without the
> >   hierarchy) happens to fail?
> >   --> The users are without the MIP service.
> >
> > - What do you do, if you suspect that your firewall, VPN GW, high end
> >   router, or GFA may fail and you do not want the users be affected?
> >   --> You deploy a High Availability solution. There are solutions out
> >       there for the above mentioned network elements, probably
> >       excluding GFA at the moment.
> >
> > - Should the High Availability solution be somehow bound to this
> >   standardisation proposal at hand?
> >   --> Why should it be? That can be handled separately. That can be
> >       standardized separately, if need be. To me, it looks like High
> >       Availability solutions would most often be proporietary.
> >
> >
> > Regards, Tom
> >
> > --
> > Tom Weckström                   PGP id:  E1DB55E9
> > Lifix Systems Oy        Mobile:  +358 50 350
> 5997
> > Innopoli 2       Tekniikantie 14       FIN-02150 Espoo
> >
> >
>



From owner-mobile-ip@sunroof.eng.sun.com  Mon Apr 29 17:57:43 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21226
	for ; Mon, 29 Apr 2002 17:57:43 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03035;
	Mon, 29 Apr 2002 14:57:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13319;
	Mon, 29 Apr 2002 14:57:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TLuFrP003184
	for ; Mon, 29 Apr 2002 14:56:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3TLuFes003183
	for mobile-ip-dist; Mon, 29 Apr 2002 14:56:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3TLuCrP003176
	for ; Mon, 29 Apr 2002 14:56:12 -0700 (PDT)
Received: from pheriche.sun.com ([129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07426
	for ; Mon, 29 Apr 2002 14:56:15 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01801
	for ; Mon, 29 Apr 2002 15:56:14 -0600 (MDT)
Message-ID: <020e01c1efc8$6ffbb8b0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: ,
        "'Hesham Soliman \(ERA\)'" ,
        "'Annika Jonsson'" ,
        
References: <000001c1efc1$79fec1b0$ab0490d9@EmadQ>
Subject: Re: [mobile-ip] Last Call:  Regional Tunneling input
Date: Mon, 29 Apr 2002 14:54:28 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

EQ,

Excuse me for butting in, but here's my take on your questions.

> What is the status of the low latency draft?

It is considered by the authors to be complete, there is still the
question of updating based on implementation
experience and what track to put it on (experimental v.s. standard).

>How many vendors
> have adopted the low latency draft already and have it in their
> products?

None, and the prospect is not good for any in the near future. There is
currently one experimental implementation, done by Jon Wood on Solaris
MIP. Jon is also working on another implementation on Linux. There are
no other implementations nor implementation efforts of which I am aware.
Vendors interested in Mobile IPv4 would most likely be implementing the
3GPP2 standard, and they already define a mechanism based on PPP for
fast IP handover.

>Is it required or optional when addition the regional
> registration scheme?

It is not required, but there is some discussion in the low latency
draft about how to utilize regional registration if it is available for
the Prereg technique. For Postreg, it is unnecessary, because the Mobile
Node can continue to use its Care of Address until Home Agent
Registration would not pose a latency burden.

>Please don't consider this as a negative view of
> the low latency draft, but until these drafts become adopted and
widely
> implemented, it would be preferable to make new MIP
design/enhancements
> with the least impact to through traffic. Otherwise, MIP would be more
> of non-real time oriented mobility protocol.
>

Well, it currently is a non-realtime oriented mobility protocol, with
the exception of Layer 2 specific fast handover techniques such as 3GPP2
uses.

            jak



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 00:46:25 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29843
	for ; Tue, 30 Apr 2002 00:46:25 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA10201;
	Mon, 29 Apr 2002 22:45:48 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA00361;
	Mon, 29 Apr 2002 21:45:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U4inrP003799
	for ; Mon, 29 Apr 2002 21:44:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3U4infn003798
	for mobile-ip-dist; Mon, 29 Apr 2002 21:44:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U4ikrP003791
	for ; Mon, 29 Apr 2002 21:44:46 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA15112
	for ; Mon, 29 Apr 2002 21:44:49 -0700 (PDT)
Received: from smtp.cs.nthu.edu.tw (smtp.cs.nthu.edu.tw [140.114.87.30])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01519
	for ; Mon, 29 Apr 2002 21:44:44 -0700 (PDT)
Received: from scarab (scarab.cs.nthu.edu.tw [140.114.79.99])
	by smtp.cs.nthu.edu.tw (8.9.3/8.9.3) with SMTP id MAA00766;
	Tue, 30 Apr 2002 12:44:42 +0800 (CST)
Message-ID: <003401c1f001$bcea4db0$634f728c@cs.nthu.edu.tw>
From: "mrbig" 
To: , 
References: <01cc01c1edbd$df020d20$dd0d48d2@peter>
Subject: [mobile-ip] CFP
Date: Tue, 30 Apr 2002 12:44:32 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
      CALL FOR PAPERS
Content-Transfer-Encoding: 7bit

  The Third IEEE Pacific-Rim Conference on Multimedia
   Special Session on "Wireless Multimedia Networks"

     National Tsing Hua University, Hsinchu, Taiwan
         December 16 -- 18, 2002
 

Theme of Special Session
------------------------

As technologies  evolve, high-speed  transmission now is  possible for
both indoor and outdoor wireless  systems. It is envisioned that novel
services  and  applications  such  as graphic  email,  multimedia  web
browsing, video conferencing, etc.  will become prevalent in our daily
life anytime and anywhere. This session, as a constituent of PCM 2002,
serves  as  a  forum  for  academic  and  industrial  researchers  and
practitioners  to  discuss  the  technologies of  wireless  multimedia
systems.  The organizer  seeks  contributions of  high quality  papers
addressing  various  aspects  of  state-of-art  research  in  wireless
multimedia systems and networks for presentation at the conference and
publication in  the proceedings. We solicit papers  covering a variety
of topics including, but not limited to:

  o Systems and Architecture
  o Access Protocols
  o Resource Management
  o Mobility Management
  o Power Control and Management
  o QoS Provisioning
  o Security
  o Mobile Computing
  o Mobile VoIP
  o Video over wireless Internet 
  o Network Performance Analysis
  o Internetworking
  o System Integration

Paper Submissions
-----------------
   Papers must be written in English. Please prepare your paper according 
   to the guideline of PCM 2002. All accepted papers will be published in
   the PCM 2002 proceedings. Send your paper for the special session to:

     Professor Jyh-Cheng Chen
     Department of Computer Science, and
     Institute of Communications Engineering
     National Tsing Hua University
     101, Sec.2, Kuang Fu Rd.
     Hsinchu, Taiwan 300, R.O.C.

     e-mail: jcchen@cs.nthu.edu.tw
     fax:    + 886 3 572 3694
     phone:  + 886 3 574 2961
  
Important Dates
---------------
   Paper submission due: May 30, 2002
   Notification of Acceptance: July 15, 2002
   Camera-ready version due: Aug. 15, 2002  

FOR MORE INFORMATION:
---------------------

Please visit the conference web site at http://www.ee.nthu.edu.tw/~PCM2002/
or send email to PCM2002@ee.nthu.edu.tw for any questions or for more 
information about the conference.




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 02:35:45 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09359
	for ; Tue, 30 Apr 2002 02:35:44 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22052;
	Tue, 30 Apr 2002 00:35:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04801;
	Mon, 29 Apr 2002 23:34:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U6Y3rP003950
	for ; Mon, 29 Apr 2002 23:34:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3U6Y3Jw003949
	for mobile-ip-dist; Mon, 29 Apr 2002 23:34:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U6Y0rP003942
	for ; Mon, 29 Apr 2002 23:34:00 -0700 (PDT)
Received: from pheriche.sun.com ([129.147.5.34])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04676
	for ; Mon, 29 Apr 2002 23:33:59 -0700 (PDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21456
	for ; Tue, 30 Apr 2002 00:33:54 -0600 (MDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3U6Xn0E027650
	for ; Tue, 30 Apr 2002 08:33:49 +0200 (MEST)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 30 08:33:49 2002 +0200
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 30 Apr 2002 08:33:50 +0200
Message-ID: 
From: "Karen E Nielsen (TED)" 
To: "'Vijay Devarapalli'" 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] How to process HAO
Date: Tue, 30 Apr 2002 08:29:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Vijay,

> > > HAO is processed if
> > >
> > >   - if there is a BCE with CoA = IPv6 src and HoA = HAO content
> > Fine
> > >   - if there is a home registration BCE with HoA = HAO content
> > 
> > I am probably missing something obvious here - but - why is 
> it that the CoA not
> > need to be verified with a home registration BCE ?
> 
> When the MN moves and send a home registration BU, the source
> address would be the newCoA (whereas the current BCE at the
> home agent has the oldCoA). 
> 
> The HA has to just update the existing BCE with the newCoA. 
> 

Thanks ! ..... but isn't this case included under the item below (the first one) - I mean
the BU still needs to be properly authenticated - right ? 
I understand the term security policy below to be broader than the term _IPSEC_ security policy -
meaning any security policy that the MN and the HA share with respect to BU authentication - 
could be IPSEC could be something else, e.g.
authentication sub option ala draft 15.

> > >   - if packet contains BU and satisfies the security policy
> > >     between MN and HA
> > Fine -
> > >   - if packet contains AH or ESP header and satisfies the security
> > >     policy check between MN and HA.
> > Fine
> > >
> > 

Karen


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 03:31:58 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09957
	for ; Tue, 30 Apr 2002 03:31:58 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15210;
	Tue, 30 Apr 2002 01:31:04 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13889;
	Tue, 30 Apr 2002 00:30:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U7TorP004098
	for ; Tue, 30 Apr 2002 00:29:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3U7ToRl004097
	for mobile-ip-dist; Tue, 30 Apr 2002 00:29:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U7TlrP004090
	for ; Tue, 30 Apr 2002 00:29:47 -0700 (PDT)
Received: from lukla.Sun.COM ([129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13594
	for ; Tue, 30 Apr 2002 00:29:46 -0700 (PDT)
Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA18761
	for ; Tue, 30 Apr 2002 01:29:44 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Tue, 30 Apr 2002 10:29:42 +0300
Message-ID: 
Thread-Topic: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
Thread-Index: AcHut8LsBs79TLBLQJ+HrwnD82OypABXXjmw
From: "Sami Vaarala" 
To: "Francis Dupont" ,
        "Henrik Levkowetz" 
Cc: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3U7TlrP004091
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Francis,

As NATs are entities "out of control", attackers and NATs
cannot really be distinguished (in a sense, a NAT is an
attacker).  Since we have to blindly trust the NATted
source address of a RRQ, the current draft therefore allows
an attacker on the route between the MN and the HA to divert
the mobility binding to a bogus address.

I think the only countermeasure would be in the spirit of
IPv6 RR, i.e., a four-message registration request where
the routability of the NATted source address of the RRQ
is ensured.  This would only defeat attackers that cannot
receive packets destinated to the bogus address they are
using.

I personally think the best alternative is to use the draft
as is.  We should add a more verbose description about the
change in Mobile IPv4 security as a result.  We could also
add a note that short mobility binding lifetimes alleviate
the attack;  unless the attacker is constantly active, the
attack causes only temporary disruption.

I don't think IPsec alleviates the problem, though.  IPsec
can prevent redirected traffic from being read, but that is
a service that Mobile IPv4 does not provide anyway.  IPsec
does nothing to authenticate the NATted source address.

-Sami

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: 28 April 2002 16:19
> To: Henrik Levkowetz
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt
> security
> 
>    	Ah, I see what you are getting at now. Do you happen to have
>    some text discussing this already?
> 
> => no, I raised the issue during a presentation at the IPCN meeting
> and it seemed the importance was enough to send a short message
> in the list to open a discussion ASAP.
> 
>    If not, would you consider the text below a decent discussion of
>   this problem, and a meaningful conclusion?
> 
>    	"Although using UDP tunnelling as such does not introduce new
>          vulnerablilities, it has to be pointed out that communicating
>          across a NAT in fact does change the situation. Without a
NAT,
> the
>          care-of address in the registration request will be directly
used
>          by the home agent to send traffic back to the mobile node,
and
> the
>          care-of address is protected by the mobile-home
authentication
>          extension. When communicating across a NAT, the effective
care-of
>          address from the home agent point of view is that of the NAT,
>          which is not protected by any authentication extension, but
>          inferred from the apparent IP source address of received
packets.
>          This means that by using the mobile IP registration
extensions
>          described in this document to enable traversal of NATs, one
is
>          opening oneself up to having the care-of address of a mobile
node
>          spoofed. The implication is again that it is RECOMMENDED that
> this
>          mechanism for NAT traversal be used together with IPsec or
>          equivalent mechanisms to further mutually authenticate the
>          communicating parties, and protect the communication."
> 
> => as soon as the problem is explained I am happy.
> I am afraid you have to consider the use of forged care-of address in
> Denial of Service attacks too (IMHO this is far less critical but
> I don't believe nobody won't complain).
> 
> Thanks
> 
> Francis.Dupont@enst-bretagne.fr



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 04:52:48 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10961
	for ; Tue, 30 Apr 2002 04:52:47 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23202;
	Tue, 30 Apr 2002 02:52:08 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26732;
	Tue, 30 Apr 2002 01:51:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U8pGrP004373
	for ; Tue, 30 Apr 2002 01:51:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3U8pGQe004372
	for mobile-ip-dist; Tue, 30 Apr 2002 01:51:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U8pDrP004365
	for ; Tue, 30 Apr 2002 01:51:13 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25086
	for ; Tue, 30 Apr 2002 01:51:09 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22669
	for ; Tue, 30 Apr 2002 01:51:08 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3U8ouB32351;
	Tue, 30 Apr 2002 10:50:56 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA20665;
	Tue, 30 Apr 2002 10:50:56 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3U8olT00120;
	Tue, 30 Apr 2002 10:50:56 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204300850.g3U8olT00120@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: "Henrik Levkowetz" 
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
In-reply-to: Your message of Mon, 29 Apr 2002 15:18:16 +0200.
              
Date: Tue, 30 Apr 2002 10:50:47 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   > I am afraid you have to consider the use of forged care-of address in
   > Denial of Service attacks too (IMHO this is far less critical but
   > I don't believe nobody won't complain).
   
   Mmm, I don't see that there's a difference in this case at all

=> I disagree: a lot of traffic can be redirected with only one packet.

   But in a DoS attack...

=> the man DoS attack is not against the HA but against the real owner
of the forged CoA.

   As far as I can see, this plays out exactly as in current MIPv4.
   
=> in the current MIPv4, only the MN can launch the attack and it is
supposed to be trustable (and its identity is revealed in any packet).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 04:57:04 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11061
	for ; Tue, 30 Apr 2002 04:57:03 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25598;
	Tue, 30 Apr 2002 02:56:39 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27757;
	Tue, 30 Apr 2002 01:56:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U8tvrP004432
	for ; Tue, 30 Apr 2002 01:55:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3U8tvk5004431
	for mobile-ip-dist; Tue, 30 Apr 2002 01:55:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U8tsrP004424
	for ; Tue, 30 Apr 2002 01:55:54 -0700 (PDT)
Received: from patan.sun.com ([129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27639
	for ; Tue, 30 Apr 2002 01:55:55 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18488
	for ; Tue, 30 Apr 2002 02:55:54 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3U8tHB00521;
	Tue, 30 Apr 2002 10:55:17 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA20727;
	Tue, 30 Apr 2002 10:55:17 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3U8tDT00148;
	Tue, 30 Apr 2002 10:55:17 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204300855.g3U8tDT00148@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: "Henrik Levkowetz" 
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
In-reply-to: Your message of Mon, 29 Apr 2002 16:22:47 +0200.
              
Date: Tue, 30 Apr 2002 10:55:13 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   Actually, I've been thinking some more about this, and I believe that
   the problem is less serious than I first thought.  What can be done by
   somebody on the path between MN and HA is to spoof the source address of
   the registration request, which will later be used as the care-of
   address, i.e.  the destination address of the forward tunnel from the HA
   point of view. This will not influence the reverse tunnel, which will
   remain unaffected. So the attacker will have to remain on the path in
   order to do harm, and then we are back to a situation which is pretty
   equivalent to what we have with MIPv4 without NAT traversal, I believe.
   Have I missed something here?
   
=> I agree that if the attacker gets the traffic and the traffic is
protected the only bad effect for the MN is this traffic is lost.
But the DoS side is still annoying because with one packet the bad guy
can redirect a lot of traffic to its victim as I explained in a previous
mail.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 05:20:11 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11308
	for ; Tue, 30 Apr 2002 05:20:10 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06126;
	Tue, 30 Apr 2002 02:17:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00640;
	Tue, 30 Apr 2002 02:17:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U9HArP004508
	for ; Tue, 30 Apr 2002 02:17:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3U9H9Es004507
	for mobile-ip-dist; Tue, 30 Apr 2002 02:17:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U9H6rP004500
	for ; Tue, 30 Apr 2002 02:17:06 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29264
	for ; Tue, 30 Apr 2002 02:17:08 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05788
	for ; Tue, 30 Apr 2002 02:17:06 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3U9GuB04976;
	Tue, 30 Apr 2002 11:16:56 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA21058;
	Tue, 30 Apr 2002 11:16:56 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3U9GtT00247;
	Tue, 30 Apr 2002 11:16:55 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204300916.g3U9GtT00247@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: "Sami Vaarala" 
cc: "Henrik Levkowetz" , mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
In-reply-to: Your message of Tue, 30 Apr 2002 10:29:42 +0300.
              
Date: Tue, 30 Apr 2002 11:16:55 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   As NATs are entities "out of control", attackers and NATs
   cannot really be distinguished (in a sense, a NAT is an
   attacker).

=> I agree: NATs are evil!

   Since we have to blindly trust the NATted

=> we have to: we should not but we have no choice, is it what it means?

   source address of a RRQ, the current draft therefore allows
   an attacker on the route between the MN and the HA to divert
   the mobility binding to a bogus address.
   
   I think the only countermeasure would be in the spirit of
   IPv6 RR, i.e., a four-message registration request where
   the routability of the NATted source address of the RRQ
   is ensured.  This would only defeat attackers that cannot
   receive packets destinated to the bogus address they are
   using.
   
=> this introduces a lot of complexity for a weak result.

   I personally think the best alternative is to use the draft
   as is.  We should add a more verbose description about the
   change in Mobile IPv4 security as a result.  We could also
   add a note that short mobility binding lifetimes alleviate
   the attack;  unless the attacker is constantly active, the
   attack causes only temporary disruption.
   
=> IMHO this is better.

   I don't think IPsec alleviates the problem, though.  IPsec
   can prevent redirected traffic from being read, but that is
   a service that Mobile IPv4 does not provide anyway.  IPsec
   does nothing to authenticate the NATted source address.
   
=> I agree: IPsec is efficient only against a part of the threat.
This is why I am afraid the other part (DoS) will be a real concern...

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 05:50:20 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11754
	for ; Tue, 30 Apr 2002 05:50:19 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10679;
	Tue, 30 Apr 2002 03:49:31 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05729;
	Tue, 30 Apr 2002 02:49:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U9mbrP004579
	for ; Tue, 30 Apr 2002 02:48:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3U9ma9x004578
	for mobile-ip-dist; Tue, 30 Apr 2002 02:48:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U9mXrP004571
	for ; Tue, 30 Apr 2002 02:48:33 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00481
	for ; Tue, 30 Apr 2002 02:48:35 -0700 (PDT)
Received: from chardonnay.levkowetz.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20585
	for ; Tue, 30 Apr 2002 02:48:33 -0700 (PDT)
Received: from [127.0.0.1] (helo=chardonnay)
	by chardonnay.levkowetz.com with smtp (Exim 4.02)
	id GVDKKS-00031C-00; Tue, 30 Apr 2002 11:48:28 +0200
From: "Henrik Levkowetz" 
To: ,
        "Sami Vaarala" 
Cc: 
Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
Date: Tue, 30 Apr 2002 11:48:28 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
Importance: Normal
In-Reply-To: <200204300916.g3U9GtT00247@givry.rennes.enst-bretagne.fr>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Francis and Sami,

	Ok, so we need to add:

	1. A paragraph that describes the mechanism - part of the
text I proposed a couple of mails back might do that if the part
about IPsec is removed

	2. Further text to point out how this can be used for DoS
attacks on a third party, if you are in the path between a MN and
a HA

	3. A recommendation that a short mobility binding lifetime be
used, to alleviate the problem.

	Anything else?

	Regards,
		Henrik
	

Francis Dupont wrote:
> 
> 
>  In your previous mail you wrote:
> 
>    As NATs are entities "out of control", attackers and NATs
>    cannot really be distinguished (in a sense, a NAT is an
>    attacker).
> 
> => I agree: NATs are evil!
> 
>    Since we have to blindly trust the NATted
> 
> => we have to: we should not but we have no choice, is it what it means?
> 
>    source address of a RRQ, the current draft therefore allows
>    an attacker on the route between the MN and the HA to divert
>    the mobility binding to a bogus address.
>    
>    I think the only countermeasure would be in the spirit of
>    IPv6 RR, i.e., a four-message registration request where
>    the routability of the NATted source address of the RRQ
>    is ensured.  This would only defeat attackers that cannot
>    receive packets destinated to the bogus address they are
>    using.
>    
> => this introduces a lot of complexity for a weak result.
> 
>    I personally think the best alternative is to use the draft
>    as is.  We should add a more verbose description about the
>    change in Mobile IPv4 security as a result.  We could also
>    add a note that short mobility binding lifetimes alleviate
>    the attack;  unless the attacker is constantly active, the
>    attack causes only temporary disruption.
>    
> => IMHO this is better.
> 
>    I don't think IPsec alleviates the problem, though.  IPsec
>    can prevent redirected traffic from being read, but that is
>    a service that Mobile IPv4 does not provide anyway.  IPsec
>    does nothing to authenticate the NATted source address.
>    
> => I agree: IPsec is efficient only against a part of the threat.
> This is why I am afraid the other part (DoS) will be a real concern...
> 
> Regards
> 
> Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 06:33:26 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12209
	for ; Tue, 30 Apr 2002 06:33:25 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06289;
	Tue, 30 Apr 2002 04:32:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12177;
	Tue, 30 Apr 2002 03:32:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UAVjrP004690
	for ; Tue, 30 Apr 2002 03:31:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UAVjxi004689
	for mobile-ip-dist; Tue, 30 Apr 2002 03:31:45 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UAVfrP004682
	for ; Tue, 30 Apr 2002 03:31:42 -0700 (PDT)
Received: from lukla.Sun.COM ([129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA10677
	for ; Tue, 30 Apr 2002 03:31:42 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08827
	for ; Tue, 30 Apr 2002 04:31:37 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3UAUxB16730;
	Tue, 30 Apr 2002 12:30:59 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA22079;
	Tue, 30 Apr 2002 12:30:59 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3UAUxT00442;
	Tue, 30 Apr 2002 12:30:59 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204301030.g3UAUxT00442@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: "Henrik Levkowetz" 
cc: "Sami Vaarala" , mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
In-reply-to: Your message of Tue, 30 Apr 2002 11:48:28 +0200.
              
Date: Tue, 30 Apr 2002 12:30:59 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   	1. A paragraph that describes the mechanism - part of the
   text I proposed a couple of mails back might do that if the part
   about IPsec is removed
   
=> I don't understand the part about IPsec: we have to explain
that without IPsec an attacker can get the traffic and read it.
(I believe you'd like to do the right thing but you ask explicitely
my opinion).

   	2. Further text to point out how this can be used for DoS
   attacks on a third party, if you are in the path between a MN and
   a HA
   
   	3. A recommendation that a short mobility binding lifetime be
   used, to alleviate the problem.
   
=> fine!

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 07:35:53 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14416
	for ; Tue, 30 Apr 2002 07:35:52 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10520;
	Tue, 30 Apr 2002 04:33:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24338;
	Tue, 30 Apr 2002 04:33:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UBWmrP004822
	for ; Tue, 30 Apr 2002 04:32:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UBWm8L004821
	for mobile-ip-dist; Tue, 30 Apr 2002 04:32:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UBWjrP004814
	for ; Tue, 30 Apr 2002 04:32:45 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20207
	for ; Tue, 30 Apr 2002 04:32:46 -0700 (PDT)
Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10091
	for ; Tue, 30 Apr 2002 04:32:45 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Tue, 30 Apr 2002 14:32:43 +0300
Message-ID: 
Thread-Topic: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
Thread-Index: AcHwMjR0o4j5ej8wRGqRKrT0v55KKwACEyBA
From: "Sami Vaarala" 
To: "Francis Dupont" ,
        "Henrik Levkowetz" 
Cc: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3UBWjrP004815
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Hi Francis,

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: 30 April 2002 13:31
> To: Henrik Levkowetz
> Cc: Sami Vaarala; mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt
> security
> 
>  In your previous mail you wrote:
> 
>    	1. A paragraph that describes the mechanism - part of the
>    text I proposed a couple of mails back might do that if the part
>    about IPsec is removed
> 
> => I don't understand the part about IPsec: we have to explain
> that without IPsec an attacker can get the traffic and read it.

In order to hijack the mobility binding, the attacker must reside
on the path between the MN and the HA, and would thus be able to
read the traffic (regardless of NAT traversal).  I.e., the attack on
confidentiality is not NAT traversal specific?  Or did you have
some other concern?

Best regards,

-Sami




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 08:00:16 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15045
	for ; Tue, 30 Apr 2002 08:00:16 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11909;
	Tue, 30 Apr 2002 05:59:40 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01227;
	Tue, 30 Apr 2002 04:59:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UBwprP004932
	for ; Tue, 30 Apr 2002 04:58:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UBwpMo004931
	for mobile-ip-dist; Tue, 30 Apr 2002 04:58:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UBwlrP004924
	for ; Tue, 30 Apr 2002 04:58:47 -0700 (PDT)
Received: from pheriche.sun.com ([129.147.5.34])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01080
	for ; Tue, 30 Apr 2002 04:58:49 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16027
	for ; Tue, 30 Apr 2002 05:58:48 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g3UBwEB30065;
	Tue, 30 Apr 2002 13:58:14 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA23246;
	Tue, 30 Apr 2002 13:58:14 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g3UBwDT00651;
	Tue, 30 Apr 2002 13:58:13 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200204301158.g3UBwDT00651@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: "Sami Vaarala" 
cc: "Henrik Levkowetz" , mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
In-reply-to: Your message of Tue, 30 Apr 2002 14:32:43 +0300.
              
Date: Tue, 30 Apr 2002 13:58:13 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
 In your previous mail you wrote:

   In order to hijack the mobility binding, the attacker must reside
   on the path between the MN and the HA, and would thus be able to
   read the traffic (regardless of NAT traversal).  I.e., the attack on
   confidentiality is not NAT traversal specific?  Or did you have
   some other concern?
   
=> now I can see your argument. I still believe mobility introduces
a difference because in order to redirect the traffic an attacker needs
only to hijack the BU. For instance it doesn't need to stay on the path
(where it could get everything with and without mobility).
 So I am still in favor to keep a short statement about IPsec in order
to encourage this counter-measure to this part of the threat.

Regards

Francis.Dupont@enst-bretagne.fr

PS: if they are clear enough, I am nothing at all against long &
detailed security considerations.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 08:33:23 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16554
	for ; Tue, 30 Apr 2002 08:33:19 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09020;
	Tue, 30 Apr 2002 05:31:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29780;
	Tue, 30 Apr 2002 05:30:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UCUErP005078
	for ; Tue, 30 Apr 2002 05:30:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UCUDXj005077
	for mobile-ip-dist; Tue, 30 Apr 2002 05:30:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UCUArP005070
	for ; Tue, 30 Apr 2002 05:30:10 -0700 (PDT)
Received: from patan.sun.com ([129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29664
	for ; Tue, 30 Apr 2002 05:30:12 -0700 (PDT)
Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02096
	for ; Tue, 30 Apr 2002 06:30:11 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Tue, 30 Apr 2002 15:30:09 +0300
Message-ID: 
Thread-Topic: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security 
Thread-Index: AcHwPlANC/n3/83xRha0vkF/B53N0wAAhSxA
From: "Sami Vaarala" 
To: "Francis Dupont" 
Cc: "Henrik Levkowetz" , 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g3UCUBrP005071
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit

Francis,

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: 30 April 2002 14:58
> To: Sami Vaarala
> Cc: Henrik Levkowetz; mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt
> security
> 
>  In your previous mail you wrote:
> 
>    In order to hijack the mobility binding, the attacker must reside
>    on the path between the MN and the HA, and would thus be able to
>    read the traffic (regardless of NAT traversal).  I.e., the attack
on
>    confidentiality is not NAT traversal specific?  Or did you have
>    some other concern?
> 
> => now I can see your argument. I still believe mobility introduces
> a difference because in order to redirect the traffic an attacker
needs
> only to hijack the BU. For instance it doesn't need to stay on the
path
> (where it could get everything with and without mobility).
>  So I am still in favor to keep a short statement about IPsec in order
> to encourage this counter-measure to this part of the threat.

Yes, I understand what you mean.  So we should say that keeping the
mobility binding lifetime short limits the impact of the hijack attack
when the attacker leaves the link after spoofing the RRQ.  Similarly,
use of IPsec provides confidentiality in the same situation.

Best regards,

-Sami 



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 09:23:07 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19215
	for ; Tue, 30 Apr 2002 09:23:06 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07094;
	Tue, 30 Apr 2002 06:20:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11739;
	Tue, 30 Apr 2002 06:20:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UDJprP005176
	for ; Tue, 30 Apr 2002 06:19:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UDJpit005175
	for mobile-ip-dist; Tue, 30 Apr 2002 06:19:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UDJmrP005168
	for ; Tue, 30 Apr 2002 06:19:48 -0700 (PDT)
Received: from patan.sun.com ([129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21065
	for ; Tue, 30 Apr 2002 06:19:50 -0700 (PDT)
Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27449
	for ; Tue, 30 Apr 2002 07:19:49 -0600 (MDT)
Received: from ipunplugged.com (rdmsr.local.ipunplugged.com [213.88.134.211])
	by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with ESMTP id g3UDMofN021200;
	Tue, 30 Apr 2002 15:22:50 +0200
Message-ID: <3CCE99A5.80808@ipunplugged.com>
Date: Tue, 30 Apr 2002 15:18:29 +0200
From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sami Vaarala 
CC: Francis Dupont ,
        Henrik Levkowetz
 ,
        mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security
References: 
Content-Type: multipart/alternative;
 boundary="------------030901040002080905070505"
X-RAVMilter-Version: 8.3.1(snapshot 20020108) (mailgw)
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

--------------030901040002080905070505
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sami Vaarala wrote:

>Francis,
>
>  
>
>>-----Original Message-----
>>From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
>>Sent: 30 April 2002 14:58
>>To: Sami Vaarala
>>Cc: Henrik Levkowetz; mobile-ip@sunroof.eng.sun.com
>>Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt
>>security
>>
>> In your previous mail you wrote:
>>
>>   In order to hijack the mobility binding, the attacker must reside
>>   on the path between the MN and the HA, and would thus be able to
>>   read the traffic (regardless of NAT traversal).  I.e., the attack
>>    
>>
>on
>  
>
>>   confidentiality is not NAT traversal specific?  Or did you have
>>   some other concern?
>>
>>=> now I can see your argument. I still believe mobility introduces
>>a difference because in order to redirect the traffic an attacker
>>    
>>
>needs
>  
>
>>only to hijack the BU. For instance it doesn't need to stay on the
>>    
>>
>path
>  
>
>>(where it could get everything with and without mobility).
>> So I am still in favor to keep a short statement about IPsec in order
>>to encourage this counter-measure to this part of the threat.
>>    
>>
>
>Yes, I understand what you mean.  So we should say that keeping the
>mobility binding lifetime short limits the impact of the hijack attack
>when the attacker leaves the link after spoofing the RRQ.  Similarly,
>use of IPsec provides confidentiality in the same situation.
>
>Best regards,
>
>-Sami 
>
What the attacker acheives is an eavesdrop in one direction for the 
duration of the registration. Because the redirect is only valid for the 
traffic going from the HA to the MN, the traffic from HA to MN is 
unaffected.

For this he has to actively change the source address of the RRQ in an 
intermediate node to an address which most probably is topologically 
incorrect and risk to have the packets dropped. This instead of just 
passively listening from the position he has, in the path, adn get both 
directions.

given this and the fact that it's a given and well known fact that 
mobile ip doens't supply you with integrety I think that it will rather 
confuse than enlight people to start recommending ipsec becuase of these 
extensions. It will just raise new issues adn new questions. Is it the 
control messages that should be ipseced ? what ipsec, AH? Is it related 
to port 443 ?

So yes, inform people of the new threats but I don't think we should 
recomend ipsec as some kind of saviour. Because it's not. He could 
eavesdrop before and he could do it now. So ipsec is equally applicable 
to pure mobile ip and has very little to do with nat traversal 
extensions. And the dos case ipsec doesn't help at all.

Regards
/// Hasse

--------------030901040002080905070505
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Sami Vaarala wrote:



  
Francis,

  

  

    
-----Original Message-----
From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
Sent: 30 April 2002 14:58
To: Sami Vaarala
Cc: Henrik Levkowetz; mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt
security

 In your previous mail you wrote:

   In order to hijack the mobility binding, the attacker must reside
   on the path between the MN and the HA, and would thus be able to
   read the traffic (regardless of NAT traversal).  I.e., the attack
    

  

  
on
  

  

    
   confidentiality is not NAT traversal specific?  Or did you have
   some other concern?

=> now I can see your argument. I still believe mobility introduces
a difference because in order to redirect the traffic an attacker
    

  

  
needs
  

  

    
only to hijack the BU. For instance it doesn't need to stay on the
    

  

  
path
  

  

    
(where it could get everything with and without mobility).
 So I am still in favor to keep a short statement about IPsec in order
to encourage this counter-measure to this part of the threat.
    

  

  

Yes, I understand what you mean.  So we should say that keeping the
mobility binding lifetime short limits the impact of the hijack attack
when the attacker leaves the link after spoofing the RRQ.  Similarly,
use of IPsec provides confidentiality in the same situation.

Best regards,

-Sami 



What the attacker acheives is an eavesdrop in one direction for the duration
of the registration. Because the redirect is only valid for the traffic going
from the HA to the MN, the traffic from HA to MN is unaffected. 



For this he has to actively change the source address of the RRQ in an intermediate
node to an address which most probably is topologically incorrect and risk
to have the packets dropped. This instead of just passively listening from
the position he has, in the path, adn get both directions. 



given this and the fact that it's a given and well known fact that mobile
ip doens't supply you with integrety I think that it will rather confuse
than enlight people to start recommending ipsec becuase of these extensions.
It will just raise new issues adn new questions. Is it the control messages
that should be ipseced ? what ipsec, AH? Is it related to port 443 ? 



So yes, inform people of the new threats but I don't think we should recomend
ipsec as some kind of saviour. Because it's not. He could eavesdrop before
and he could do it now. So ipsec is equally applicable to pure mobile ip
and has very little to do with nat traversal extensions. And the dos case
ipsec doesn't help at all.



Regards

/// Hasse




--------------030901040002080905070505--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 10:08:23 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21005
	for ; Tue, 30 Apr 2002 10:08:23 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23424;
	Tue, 30 Apr 2002 08:07:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05344;
	Tue, 30 Apr 2002 07:07:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UE61rP005335
	for ; Tue, 30 Apr 2002 07:06:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UE615C005334
	for mobile-ip-dist; Tue, 30 Apr 2002 07:06:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UE5vrP005327
	for ; Tue, 30 Apr 2002 07:05:57 -0700 (PDT)
Received: from patan.sun.com ([129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04663
	for ; Tue, 30 Apr 2002 07:05:57 -0700 (PDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24296
	for ; Tue, 30 Apr 2002 08:05:56 -0600 (MDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3UE5t0E028949
	for ; Tue, 30 Apr 2002 16:05:55 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 30 16:05:42 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JBT6MS0>; Tue, 30 Apr 2002 16:05:42 +0200
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AD07@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'emadaq@yahoo.com'" ,
        "Hesham Soliman (ERA)"
	 ,
        "'Annika Jonsson'"
	 ,
        mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Tue, 30 Apr 2002 16:05:34 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Emad, 

  > 	Yes it is not different from the HA registration, but, we are
  > adding additional level(s) for processing registrations. 
  > Therefore, the
  > ultimate timing might be impacted depending on the 
  > scenario. I really
  > wish to see the studies/(bakeoff results if any) for this draft to
  > understand the overall impact to MIP.

=> Just so I understand you, do you mean that it is
like to be worse in terms of performance than standard
MIP?

  > 
  > 	What is the status of the low latency draft? How many vendors
  > have adopted the low latency draft already and have it in their
  > products? Is it required or optional when addition the regional
  > registration scheme? Please don't consider this as a 
  > negative view of
  > the low latency draft, but until these drafts become 
  > adopted and widely
  > implemented, it would be preferable to make new MIP 
  > design/enhancements

=> It's not a negative view but it's certainly inconsistent
with IETF rules. Whether I think that this draft is 
a good one or not, I would strongly suggest that 
we follow one standard process when dealing with
drafts being proposed for standards. 

We had the same argument for the low latency draft
and I'm afraid that requiring vendors to present 
their product plans to IETF to justify whether 
a draft should become an RFC makes no sense at all. 
Does prototyping a solution mean that it will be
in a product? 
What about prototypes by universities are they 
accepatable enough?

  > with the least impact to through traffic. Otherwise, MIP 
  > would be more
  > of non-real time oriented mobility protocol.

=> I hope you're not suggesting that RFC 2002 or 3122
is good for real time.

Hesham

  > 
  > Thx.
  > EQ
  > 	 
  > 
  > > -----Original Message-----
  > > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-
  > > ip@sunroof.eng.sun.com] On Behalf Of Hesham Soliman (ERA)
  > > Sent: Monday, April 29, 2002 5:55 PM
  > > To: 'emadaq@yahoo.com'; 'Annika Jonsson';
  > mobile-ip@sunroof.eng.sun.com
  > > Subject: RE: [mobile-ip] Last Call: Regional Tunneling input
  > > 
  > > Emad,
  > > 
  > >   > Annika,
  > >   >
  > >   > 	My main concern about this draft:
  > >   >
  > >   > 1) Has there been any studies/scenarios about the impact to
  > >   > in-flight
  > >   > traffic to the MN, while it is performing regional
  > >   > re-registrations?
  > >   >
  > >   > 2) How does the old FA handle the data that is 
  > received while the
  > MN
  > >   > re-registers with a new FA?
  > > 
  > > => Isn't this the same for a HA registration?
  > > Why should we expect this draft to handle all the
  > > handover problems?
  > > The low latency draft handles the problems you
  > > mention, and it includes a section on how to
  > > co-exist with this draft.
  > > 
  > > Hesham
  > 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 10:56:30 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23627
	for ; Tue, 30 Apr 2002 10:56:25 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26630;
	Tue, 30 Apr 2002 08:55:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20761;
	Tue, 30 Apr 2002 07:55:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UEsirP005634
	for ; Tue, 30 Apr 2002 07:54:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UEshjN005633
	for mobile-ip-dist; Tue, 30 Apr 2002 07:54:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UEserP005626
	for ; Tue, 30 Apr 2002 07:54:40 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04958
	for ; Tue, 30 Apr 2002 07:54:41 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04923
	for ; Tue, 30 Apr 2002 07:54:41 -0700 (PDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3UEonN00048;
	Tue, 30 Apr 2002 09:50:49 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 30 Apr 2002 09:50:42 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCC71@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna"
To: "'Annika Jonsson'" ,
        "'Charles E. Perkins'"
	 
Cc: mobile-ip@sunroof.eng.sun.com,
        "'A.ONeill@flarion.com'"
	 
Subject: RE: [mobile-ip] RE: [mobile-imp] WG Last Call:  draft-ietf-mobile
	 ip-reg-tunnel-06. txt
Date: Tue, 30 Apr 2002 09:50:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1F056.657E8A50"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F056.657E8A50
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Annika;

In section 4.1 the third paragraph it talks about Mobile Nodes
with co-located care-of address and the way it uses
Regional Registration. This section is under Home Registration.
This means that it does not talk about the Regional Registration mechanism
YET. Because that has a separate section No. 5.

Now in the third paragraph section 4.1 as shown below, it talks about the 
Mobile Node adding a Hierarchical Foreign Agent extension and to be placed
after the MN-HA authentication extension in Registration Request message. 
Also, to be protected by the MN-GFA authentication extension. It also
continues 
to say using the mobility security association which has been established
with 
GFA according to section 3.1.2.

" ........... 
   In this case, the mobile node MUST add a
   Hierarchical Foreign Agent extension 8.2, including its co-located
   care-of address, to the Registration Request before sending it.  The
   Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA
   authentication extension.  It SHOULD be authenticated by using the
   MN-GFA authentication extension (see Section 10).  The authentication
   data SHOULD be calculated using a mobility security association
   that has been established with the GFA (Section 3.1.2). ...........
"

I am really confused here for the following points: 
1. We are talking about Home registration. Which I understand is the initial
registration with the Mobile Node Home Agent or when it changes GFA.
However,
the text talk about the initial registration request here.
2. Now at this point of time, there is no established mobility security
association
between the mobile Node and GFA.
3. section 3.1.2, talks about using the mobility security association, which
has been 
established during the initial (Home Registration), in Regional Registration
NOT Home
Registration.
4. In other words, Mobile Node does not have a mobility security association
with the
GFA at the time of initial or Home registration that paragraph 3 talks
about.


Am I correct or I am missing something. 
Please let me know.

Regards;
Ahmad Muhanna

------_=_NextPart_001_01C1F056.657E8A50
Content-Type: text/html;
	charset="iso-8859-1"






RE: [mobile-ip] RE: [mobile-imp] WG Last Call:  draft-ietf-mobile ip-reg-tunnel-06. txt




Hello Annika;




In section 4.1 the third paragraph it talks about Mobile Nodes

with co-located care-of address and the way it uses

Regional Registration. This section is under Home Registration.

This means that it does not talk about the Regional Registration mechanism

YET. Because that has a separate section No. 5.




Now in the third paragraph section 4.1 as shown below, it talks about the 

Mobile Node adding a Hierarchical Foreign Agent extension and to be placed

after the MN-HA authentication extension in Registration Request message. 

Also, to be protected by the MN-GFA authentication extension. It also continues 

to say using the mobility security association which has been established with 

GFA according to section 3.1.2.




" ........... 

   In this case, the mobile node MUST add a

   Hierarchical Foreign Agent extension 8.2, including its co-located

   care-of address, to the Registration Request before sending it.  The

   Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA

   authentication extension.  It SHOULD be authenticated by using the

   MN-GFA authentication extension (see Section 10).  The authentication

   data SHOULD be calculated using a mobility security association

   that has been established with the GFA (Section 3.1.2). ...........

"




I am really confused here for the following points: 

1. We are talking about Home registration. Which I understand is the initial

registration with the Mobile Node Home Agent or when it changes GFA. However,

the text talk about the initial registration request here.

2. Now at this point of time, there is no established mobility security association

between the mobile Node and GFA.

3. section 3.1.2, talks about using the mobility security association, which has been 

established during the initial (Home Registration), in Regional Registration NOT Home

Registration.

4. In other words, Mobile Node does not have a mobility security association with the

GFA at the time of initial or Home registration that paragraph 3 talks about.






Am I correct or I am missing something. 

Please let me know.




Regards;

Ahmad Muhanna





------_=_NextPart_001_01C1F056.657E8A50--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 11:02:18 2002
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24099
	for ; Tue, 30 Apr 2002 11:02:17 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28105;
	Tue, 30 Apr 2002 09:01:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23538;
	Tue, 30 Apr 2002 08:01:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UF0arP005689
	for ; Tue, 30 Apr 2002 08:00:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UF0aw6005688
	for mobile-ip-dist; Tue, 30 Apr 2002 08:00:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UF0XrP005681
	for ; Tue, 30 Apr 2002 08:00:33 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23336
	for ; Tue, 30 Apr 2002 08:00:34 -0700 (PDT)
Received: from mail.flarion.com (mail.flarion.com [63.103.94.23])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08969
	for ; Tue, 30 Apr 2002 08:00:33 -0700 (PDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 30 Apr 2002 11:00:32 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABD8A@ftmail>
From: George Tsirtsis 
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Question on RFC3220
Date: Tue, 30 Apr 2002 11:00:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi all,

This is probably a stupid question but here it is anyway:
The Registration Request header in MIPv4 have the following flags:


   +-+-+-+-+-+-+-+-+-+-+-+-+
    ...|S|B|D|M|G|r|T|x|    ...
   +-+-+-+-+-+-+-+-+-+-+-+-+

of which:

      r        Sent as zero; ignored on reception.  SHOULD NOT be
               allocated for any other uses.

Can anyone tell me why this SHOULD NOT be allocated in the future?? Is there
any logic behind this or it is just an arbitrary act of fate?

Thanks
George


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 11:08:28 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24247
	for ; Tue, 30 Apr 2002 11:08:27 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04750;
	Tue, 30 Apr 2002 09:07:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25786;
	Tue, 30 Apr 2002 08:07:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UF71rP005742
	for ; Tue, 30 Apr 2002 08:07:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UF71M6005741
	for mobile-ip-dist; Tue, 30 Apr 2002 08:07:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UF6vrP005734
	for ; Tue, 30 Apr 2002 08:06:58 -0700 (PDT)
Received: from lukla.Sun.COM ([129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02641
	for ; Tue, 30 Apr 2002 08:06:59 -0700 (PDT)
Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA02073
	for ; Tue, 30 Apr 2002 09:06:53 -0600 (MDT)
Received: from unknown (HELO EmadQ) (emadaq@217.144.4.51 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 Apr 2002 15:06:47 -0000
Reply-To: 
From: "Emad Qaddoura" 
To: "'Hesham Soliman \(ERA\)'" ,
        "'Annika Jonsson'" ,
        
Subject: RE: [mobile-ip] Last Call:  Regional Tunneling input
Date: Tue, 30 Apr 2002 18:06:22 +0200
Message-ID: <000001c1f060$fcc5e980$330490d9@EmadQ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AD07@Esealnt861.al.sw.ericsson.se>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hi Hesham,



> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
> Sent: Tuesday, April 30, 2002 4:06 PM
> To: 'emadaq@yahoo.com'; Hesham Soliman (ERA); 'Annika Jonsson';
mobile-
> ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Last Call: Regional Tunneling input
> 
> Emad,
> 
>   > 	Yes it is not different from the HA registration, but, we are
>   > adding additional level(s) for processing registrations.
>   > Therefore, the
>   > ultimate timing might be impacted depending on the
>   > scenario. I really
>   > wish to see the studies/(bakeoff results if any) for this draft to
>   > understand the overall impact to MIP.
> 
> => Just so I understand you, do you mean that it is
> like to be worse in terms of performance than standard
> MIP?
[<<>>] 
[<<>>] Since the regional registration adds more processing, it
would mean longer registration time, due to the hierarchy of
registrations and the different cases that need to be handled.

> 
>   >
>   > 	What is the status of the low latency draft? How many vendors
>   > have adopted the low latency draft already and have it in their
>   > products? Is it required or optional when addition the regional
>   > registration scheme? Please don't consider this as a
>   > negative view of
>   > the low latency draft, but until these drafts become
>   > adopted and widely
>   > implemented, it would be preferable to make new MIP
>   > design/enhancements
> 
> => It's not a negative view but it's certainly inconsistent
> with IETF rules. Whether I think that this draft is
> a good one or not, I would strongly suggest that
> we follow one standard process when dealing with
> drafts being proposed for standards.
[<<>>] 
[<<>>] I don't disagree. I have been involved with the IETF for many
years.

> We had the same argument for the low latency draft
> and I'm afraid that requiring vendors to present
> their product plans to IETF to justify whether
> a draft should become an RFC makes no sense at all.
> Does prototyping a solution mean that it will be
> in a product?
> What about prototypes by universities are they
> accepatable enough?
[<<>>] 
[<<>>] Well the question is not requiring vendors to present their
product plans or not. The issue is until such drafts become to the
standard level to where they are adopted, we have to be careful in all
additions to the MIP in terms of not introducing more delays whenever
possible.

> 
>   > with the least impact to through traffic. Otherwise, MIP
>   > would be more
>   > of non-real time oriented mobility protocol.
> 
> => I hope you're not suggesting that RFC 2002 or 3122
> is good for real time.
[<<>>] 
[<<>>] We are on the same lines, No I am not suggesting so.

> 
> Hesham
> 
>   >
>   > Thx.
>   > EQ
>   >
>   >
>   > > -----Original Message-----
>   > > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-
>   > > ip@sunroof.eng.sun.com] On Behalf Of Hesham Soliman (ERA)
>   > > Sent: Monday, April 29, 2002 5:55 PM
>   > > To: 'emadaq@yahoo.com'; 'Annika Jonsson';
>   > mobile-ip@sunroof.eng.sun.com
>   > > Subject: RE: [mobile-ip] Last Call: Regional Tunneling input
>   > >
>   > > Emad,
>   > >
>   > >   > Annika,
>   > >   >
>   > >   > 	My main concern about this draft:
>   > >   >
>   > >   > 1) Has there been any studies/scenarios about the impact to
>   > >   > in-flight
>   > >   > traffic to the MN, while it is performing regional
>   > >   > re-registrations?
>   > >   >
>   > >   > 2) How does the old FA handle the data that is
>   > received while the
>   > MN
>   > >   > re-registers with a new FA?
>   > >
>   > > => Isn't this the same for a HA registration?
>   > > Why should we expect this draft to handle all the
>   > > handover problems?
>   > > The low latency draft handles the problems you
>   > > mention, and it includes a section on how to
>   > > co-exist with this draft.
>   > >
>   > > Hesham
>   >



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 11:24:16 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24894
	for ; Tue, 30 Apr 2002 11:24:16 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24466;
	Tue, 30 Apr 2002 08:22:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01301;
	Tue, 30 Apr 2002 08:21:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFL8rP005843
	for ; Tue, 30 Apr 2002 08:21:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UFL8GU005842
	for mobile-ip-dist; Tue, 30 Apr 2002 08:21:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFL5rP005835
	for ; Tue, 30 Apr 2002 08:21:05 -0700 (PDT)
Received: from patan.sun.com ([129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11864
	for ; Tue, 30 Apr 2002 08:21:06 -0700 (PDT)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14318
	for ; Tue, 30 Apr 2002 09:21:06 -0600 (MDT)
Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 30 Apr 2002 11:18:09 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] 3220 reissue
Date: Tue, 30 Apr 2002 11:18:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

We've asked Charlie to resubmit RFC 3220 for now just to include the fix for
the editing
glitch in the publication of RFC 3220.

A bis version is already under construction to include a number of
clarifications.  This will
continue independent of the fix to 3220.

Phil


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 11:30:33 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25133
	for ; Tue, 30 Apr 2002 11:30:33 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19916;
	Tue, 30 Apr 2002 09:29:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04198;
	Tue, 30 Apr 2002 08:29:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFTArP005892
	for ; Tue, 30 Apr 2002 08:29:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UFT9Fd005891
	for mobile-ip-dist; Tue, 30 Apr 2002 08:29:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFT6rP005884
	for ; Tue, 30 Apr 2002 08:29:06 -0700 (PDT)
Received: from lukla.Sun.COM ([129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13979
	for ; Tue, 30 Apr 2002 08:29:08 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11199
	for ; Tue, 30 Apr 2002 09:23:49 -0600 (MDT)
Message-ID: <008f01c1f05a$c81644b0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        , "'Annika Jonsson'" ,
        
References: <4DA6EA82906FD511BE2F00508BCF053802C6AD07@Esealnt861.al.sw.ericsson.se>
Subject: Re: [mobile-ip] Last Call:  Regional Tunneling input
Date: Tue, 30 Apr 2002 08:22:03 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hesham,

The problem with the low latency draft is that not even universities are
intending to implement it, as far as I can see. So it is not a question
of whether anybody does products or not, but rather whether anybody
wants to implement it at all. I might be wrong, of course, but so far, I
haven't seen any interest.

It is, of course, different with the FMIPv6 draft.

            jak

----- Original Message -----
From: "Hesham Soliman (ERA)" 
To: ; "Hesham Soliman (ERA)"
; "'Annika Jonsson'"
; 
Sent: Tuesday, April 30, 2002 7:05 AM
Subject: RE: [mobile-ip] Last Call: Regional Tunneling input


> Emad,
>
>   > Yes it is not different from the HA registration, but, we are
>   > adding additional level(s) for processing registrations.
>   > Therefore, the
>   > ultimate timing might be impacted depending on the
>   > scenario. I really
>   > wish to see the studies/(bakeoff results if any) for this draft to
>   > understand the overall impact to MIP.
>
> => Just so I understand you, do you mean that it is
> like to be worse in terms of performance than standard
> MIP?
>
>   >
>   > What is the status of the low latency draft? How many vendors
>   > have adopted the low latency draft already and have it in their
>   > products? Is it required or optional when addition the regional
>   > registration scheme? Please don't consider this as a
>   > negative view of
>   > the low latency draft, but until these drafts become
>   > adopted and widely
>   > implemented, it would be preferable to make new MIP
>   > design/enhancements
>
> => It's not a negative view but it's certainly inconsistent
> with IETF rules. Whether I think that this draft is
> a good one or not, I would strongly suggest that
> we follow one standard process when dealing with
> drafts being proposed for standards.
>
> We had the same argument for the low latency draft
> and I'm afraid that requiring vendors to present
> their product plans to IETF to justify whether
> a draft should become an RFC makes no sense at all.
> Does prototyping a solution mean that it will be
> in a product?
> What about prototypes by universities are they
> accepatable enough?
>
>   > with the least impact to through traffic. Otherwise, MIP
>   > would be more
>   > of non-real time oriented mobility protocol.
>
> => I hope you're not suggesting that RFC 2002 or 3122
> is good for real time.
>
> Hesham
>
>   >
>   > Thx.
>   > EQ
>   >
>   >
>   > > -----Original Message-----
>   > > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-
>   > > ip@sunroof.eng.sun.com] On Behalf Of Hesham Soliman (ERA)
>   > > Sent: Monday, April 29, 2002 5:55 PM
>   > > To: 'emadaq@yahoo.com'; 'Annika Jonsson';
>   > mobile-ip@sunroof.eng.sun.com
>   > > Subject: RE: [mobile-ip] Last Call: Regional Tunneling input
>   > >
>   > > Emad,
>   > >
>   > >   > Annika,
>   > >   >
>   > >   > My main concern about this draft:
>   > >   >
>   > >   > 1) Has there been any studies/scenarios about the impact to
>   > >   > in-flight
>   > >   > traffic to the MN, while it is performing regional
>   > >   > re-registrations?
>   > >   >
>   > >   > 2) How does the old FA handle the data that is
>   > received while the
>   > MN
>   > >   > re-registers with a new FA?
>   > >
>   > > => Isn't this the same for a HA registration?
>   > > Why should we expect this draft to handle all the
>   > > handover problems?
>   > > The low latency draft handles the problems you
>   > > mention, and it includes a section on how to
>   > > co-exist with this draft.
>   > >
>   > > Hesham
>   >
>



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 11:33:57 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25292
	for ; Tue, 30 Apr 2002 11:33:56 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17782;
	Tue, 30 Apr 2002 09:33:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06044;
	Tue, 30 Apr 2002 08:33:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFWHrP005947
	for ; Tue, 30 Apr 2002 08:32:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UFWGN1005946
	for mobile-ip-dist; Tue, 30 Apr 2002 08:32:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFWDrP005939
	for ; Tue, 30 Apr 2002 08:32:13 -0700 (PDT)
Received: from kathmandu.sun.com ([129.147.5.36])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05754
	for ; Tue, 30 Apr 2002 08:32:15 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18708
	for ; Tue, 30 Apr 2002 09:32:14 -0600 (MDT)
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 IAA23423;
	Tue, 30 Apr 2002 08:32:13 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3UFWDd28127;
	Tue, 30 Apr 2002 08:32:13 -0700
X-mProtect: <200204301532> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdfyQpSp; Tue, 30 Apr 2002 08:32:11 PDT
Message-ID: <3CCEB8F7.429DA26C@iprg.nokia.com>
Date: Tue, 30 Apr 2002 08:32:07 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: George Tsirtsis 
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Question on RFC3220
References: <8C92E23A3E87FB479988285F9E22BE465ABD8A@ftmail>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Hello George,

That's a SHOULD NOT, not a MUST NOT.

The reason for NOT allocating it, would be to avoid damage
to legacy implementations that used the bit for its previous
meaning.

The reason for allocating it, would be to satisfy working
group demand for some other need.

Regards,
Charlie P.


George Tsirtsis wrote:

> Hi all,
>
> This is probably a stupid question but here it is anyway:
> The Registration Request header in MIPv4 have the following flags:
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+
>     ...|S|B|D|M|G|r|T|x|    ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+
>
> of which:
>
>       r        Sent as zero; ignored on reception.  SHOULD NOT be
>                allocated for any other uses.
>
> Can anyone tell me why this SHOULD NOT be allocated in the future?? Is there
> any logic behind this or it is just an arbitrary act of fate?
>
> Thanks
> George



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 11:45:43 2002
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25844
	for ; Tue, 30 Apr 2002 11:45:42 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03381;
	Tue, 30 Apr 2002 08:43:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09817;
	Tue, 30 Apr 2002 08:43:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFgcrP006032
	for ; Tue, 30 Apr 2002 08:42:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UFgcdC006031
	for mobile-ip-dist; Tue, 30 Apr 2002 08:42:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UFgZrP006024
	for ; Tue, 30 Apr 2002 08:42:35 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18267
	for ; Tue, 30 Apr 2002 08:42:37 -0700 (PDT)
Received: from mail.flarion.com (mail.flarion.com [63.103.94.23])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07712
	for ; Tue, 30 Apr 2002 08:42:36 -0700 (PDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 30 Apr 2002 11:42:35 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABD8E@ftmail>
From: George Tsirtsis 
To: "'Charlie Perkins'" 
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Question on RFC3220
Date: Tue, 30 Apr 2002 11:42:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

I guess I do not remember what the old meaning was....could you remind me?

Thanks
George

-----Original Message-----
From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
Sent: Tuesday, April 30, 2002 4:32 PM
To: George Tsirtsis
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Question on RFC3220



Hello George,

That's a SHOULD NOT, not a MUST NOT.

The reason for NOT allocating it, would be to avoid damage
to legacy implementations that used the bit for its previous
meaning.

The reason for allocating it, would be to satisfy working
group demand for some other need.

Regards,
Charlie P.


George Tsirtsis wrote:

> Hi all,
>
> This is probably a stupid question but here it is anyway:
> The Registration Request header in MIPv4 have the following flags:
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+
>     ...|S|B|D|M|G|r|T|x|    ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+
>
> of which:
>
>       r        Sent as zero; ignored on reception.  SHOULD NOT be
>                allocated for any other uses.
>
> Can anyone tell me why this SHOULD NOT be allocated in the future?? Is
there
> any logic behind this or it is just an arbitrary act of fate?
>
> Thanks
> George


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 13:27:36 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29882
	for ; Tue, 30 Apr 2002 13:27:36 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22558;
	Tue, 30 Apr 2002 10:25:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23151;
	Tue, 30 Apr 2002 10:25:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UHOJrP006411
	for ; Tue, 30 Apr 2002 10:24:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UHOJtb006410
	for mobile-ip-dist; Tue, 30 Apr 2002 10:24:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UHOHrP006403
	for ; Tue, 30 Apr 2002 10:24:17 -0700 (PDT)
Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08037
	for ; Tue, 30 Apr 2002 13:24:17 -0400 (EDT)
Received: from onion.East.Sun.COM (localhost [IPv6:::1])
	by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g3UHOFqp004533
	for ; Tue, 30 Apr 2002 13:24:15 -0400 (EDT)
Received: (from glass@localhost)
	by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g3UHOFwW004532
	for mobile-ip@sunroof.eng.sun.com; Tue, 30 Apr 2002 13:24:15 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3U6f7rP004012
	for ; Mon, 29 Apr 2002 23:41:07 -0700 (PDT)
Received: from lukla.Sun.COM ([129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27328
	for ; Mon, 29 Apr 2002 23:41:07 -0700 (PDT)
Received: from ex.harpak.tsk.mil.tr ([193.255.158.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25234
	for ; Tue, 30 Apr 2002 00:41:03 -0600 (MDT)
Received: from MUHMODISLTSBMD ([192.168.10.85]) by ex.harpak.tsk.mil.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JHXD8G1S; Tue, 30 Apr 2002 08:52:12 +0300
Message-ID: <002b01c1f196$56c230c0$550aa8c0@muhmodisltsbmd>
From: "Erdal CAYIRCI" 
To: 
Subject: [mobile-ip] CFP for Special Issue Computer Networks (Elsevier) on Wireless Sensor Networks
Date: Thu, 2 May 2002 08:00:54 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0028_01C1F1AF.7BFCF230"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C1F1AF.7BFCF230
Content-Type: text/plain;
	charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable

Dear Colleague,

Enclosed below please find the Call for Papers for the Special Issue =
Computer Networks (Elsevier) on Wireless Sensor networks. We apologize =
if you received multiple copies of this Call for Papers. Please feel =
free to distribute it.

Best regards,

Erdal Cayirci
GaTech

Ramesh Govindan
ICSI

Taieb Znati
NSF

Mani Srivastava
UCLA

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

CALL FOR PAPERS
Special Issue Computer Networks (Elsevier) on "Wireless Sensor Networks"

Recent advances in digital electronics, embedded systems and wireless
communications are leading the way to a new class of distributed =
wireless
sensor networks. These networks have a wide range of potential =
applications,
including security and surveillance, control, actuation and maintenance =
of
complex systems, and fine-grain monitoring of indoor and outdoor
environments.

Sensor networks differ from conventional network systems in many =
aspects.
They usually involve a large number of spatially distributed,
energy-constrained, self-configuring and self-aware nodes. Furthermore, =
they
tend to be autonomous and require a high degree of cooperation and
adaptation to perform the desired coordinated tasks and networking
functionalities. As such, they bring about new challenges and design
considerations, which go much beyond conventional network systems.

This special issue of Computer Networks is intended to foster the
dissemination of high quality research in communication protocols, data
management and access techniques, and applications of wireless sensor
networks. We hope that the resulting issue will significantly advance =
our
understanding of this nascent area of research.

Only technical papers describing previously unpublished, original,
state-of-art research, and not currently under review by another =
conference
or journal, will be considered. We solicit papers covering a variety of
topics related to wireless sensor networks including, but not limited =
to:

- Novel applications of sensor networks for surveillance, fine-grain
instrumentation, and actuation
- New sensor network communication architectures
- Software platforms and tools for sensor network application =
development
- Energy-efficient media access, error control, and traffic management
- Energy-efficient systems services such as localization and time
synchronization
- Scalable, and energy-efficient, data-dissemination schemes
- Robust distributed algorithms for collaborative processing
- Mechanisms for authenticated, secure communication
- Modeling and performance evaluation of large-scale sensor network
algorithms
- Application specific network and systems services, including =
data-centric
routing, attribute-based addressing, and location management

Authors should follow the Computer Networks (Elsevier) manuscript format
described at http://www.elsevier.nl/locate/compnw. Prospective authors
should submit a PDF version of their complete manuscript according to =
the
following timetable to: sensornet@cs.itu.edu.tr

Manuscript Due: October 15, 2002
Acceptance Notification: January 14, 2003
Final Manuscript Due: March 11, 2003
Publication Date: August 2003

Erdal Cayirci
BWN Lab.
Sch. of Elec.&Comp. Eng.
Georgia Inst. of Tech.
Atlanta, GA 30332
erdal@ece.gatech.edu

Ramesh Govindan
International Comp. Sci. Inst.
Berkeley, CA 94704-1198
ramesh@ICSI.Berkeley.EDU

Taieb Znati
Div. of Adv. Net. Inf. & Res.
The Nat. Science Foundation
Arlington, VA 22230
tznati@nsf.gov

Mani Srivastava
Elec. Eng. Department
UCLA
Los Angeles, CA 90095-1594
mbs@ee.ucla.edu






------=_NextPart_000_0028_01C1F1AF.7BFCF230
Content-Type: text/html;
	charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable









Dear Colleague,

Enclosed =
below please=20
find the Call for Papers for the Special Issue Computer Networks =
(Elsevier) on=20
Wireless Sensor networks. We apologize if you received multiple copies =
of this=20
Call for Papers. Please feel free to distribute it.

Best=20
regards,

Erdal Cayirci
GaTech

Ramesh=20
Govindan
ICSI

Taieb Znati
NSF

Mani=20
Srivastava
UCLA

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CALL=20
FOR PAPERS
Special Issue Computer Networks (Elsevier) on "Wireless =
Sensor=20
Networks"

Recent advances in digital electronics, embedded =
systems and=20
wireless
communications are leading the way to a new class of =
distributed=20
wireless
sensor networks. These networks have a wide range of =
potential=20
applications,
including security and surveillance, control, actuation =
and=20
maintenance of
complex systems, and fine-grain monitoring of indoor =
and=20
outdoor
environments.

Sensor networks differ from conventional =
network=20
systems in many aspects.
They usually involve a large number of =
spatially=20
distributed,
energy-constrained, self-configuring and self-aware =
nodes.=20
Furthermore, they
tend to be autonomous and require a high degree of=20
cooperation and
adaptation to perform the desired coordinated tasks =
and=20
networking
functionalities. As such, they bring about new challenges =
and=20
design
considerations, which go much beyond conventional network=20
systems.

This special issue of Computer Networks is intended to =
foster=20
the
dissemination of high quality research in communication =
protocols,=20
data
management and access techniques, and applications of wireless=20
sensor
networks. We hope that the resulting issue will significantly =
advance=20
our
understanding of this nascent area of research.

Only =
technical=20
papers describing previously unpublished, original,
state-of-art =
research,=20
and not currently under review by another conference
or journal, will =
be=20
considered. We solicit papers covering a variety of
topics related to =

wireless sensor networks including, but not limited to:

- Novel=20
applications of sensor networks for surveillance, =
fine-grain
instrumentation,=20
and actuation
- New sensor network communication architectures
- =
Software=20
platforms and tools for sensor network application development
-=20
Energy-efficient media access, error control, and traffic =
management
-=20
Energy-efficient systems services such as localization and=20
time
synchronization
- Scalable, and energy-efficient, =
data-dissemination=20
schemes
- Robust distributed algorithms for collaborative =
processing
-=20
Mechanisms for authenticated, secure communication
- Modeling and =
performance=20
evaluation of large-scale sensor network
algorithms
- Application =
specific=20
network and systems services, including data-centric
routing, =
attribute-based=20
addressing, and location management

Authors should follow the =
Computer=20
Networks (Elsevier) manuscript format
described at http://www.elsevier.nl/loca=
te/compnw.=20
Prospective authors
should submit a PDF version of their complete =
manuscript=20
according to the
following timetable to: sensornet@cs.itu.edu.tr
Manuscript=20
Due: October 15, 2002
Acceptance Notification: January 14, =
2003
Final=20
Manuscript Due: March 11, 2003
Publication Date: August =
2003

Erdal=20
Cayirci
BWN Lab.
Sch. of Elec.&Comp. Eng.
Georgia Inst. of=20
Tech.
Atlanta, GA 30332
erdal@ece.gatech.edu

Rame=
sh=20
Govindan
International Comp. Sci. Inst.
Berkeley, CA =
94704-1198
ramesh@ICSI.Berkeley.EDU
=

Taieb=20
Znati
Div. of Adv. Net. Inf. & Res.
The Nat. Science=20
Foundation
Arlington, VA 22230
tznati@nsf.gov

Mani =
Srivastava
Elec.=20
Eng. Department
UCLA
Los Angeles, CA 90095-1594
mbs@ee.ucla.edu






------=_NextPart_000_0028_01C1F1AF.7BFCF230--




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 13:48:48 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00908
	for ; Tue, 30 Apr 2002 13:48:48 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28960;
	Tue, 30 Apr 2002 11:48:08 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03783;
	Tue, 30 Apr 2002 10:47:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UHktrP006613
	for ; Tue, 30 Apr 2002 10:46:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UHktJh006612
	for mobile-ip-dist; Tue, 30 Apr 2002 10:46:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UHkqrP006605
	for ; Tue, 30 Apr 2002 10:46:52 -0700 (PDT)
Received: from lukla.Sun.COM ([129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13742
	for ; Tue, 30 Apr 2002 10:46:53 -0700 (PDT)
Received: from mail.flarion.com (mail.flarion.com [63.103.94.23])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00414
	for ; Tue, 30 Apr 2002 11:46:52 -0600 (MDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 30 Apr 2002 13:46:50 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABD97@ftmail>
From: George Tsirtsis 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Question on RFC3220
Date: Tue, 30 Apr 2002 13:46:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

A good man responded.
Thanks Bob.

George

-----Original Message-----
From: Robert J Marks [mailto:bob@marksmob.com]
Sent: Tuesday, April 30, 2002 6:19 PM
To: 'George Tsirtsis'
Subject: RE: [mobile-ip] Question on RFC3220


V - Van Jacobson compression.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Registration Lifetime      |R|B|H|F|M|G|V|    reserved     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V        Van Jacobson header compression.  This agent supports use
         of Van Jacobson header compression [10] over the link
         with any registered mobile node.
Bob

> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com 
> [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of 
> George Tsirtsis
> Sent: Tuesday, April 30, 2002 9:42 AM
> To: 'Charlie Perkins'
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Question on RFC3220
> 
> 
> I guess I do not remember what the old meaning was....could 
> you remind me?
> 
> Thanks
> George
> 
> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Tuesday, April 30, 2002 4:32 PM
> To: George Tsirtsis
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Question on RFC3220
> 
> 
> 
> Hello George,
> 
> That's a SHOULD NOT, not a MUST NOT.
> 
> The reason for NOT allocating it, would be to avoid damage
> to legacy implementations that used the bit for its previous
> meaning.
> 
> The reason for allocating it, would be to satisfy working
> group demand for some other need.
> 
> Regards,
> Charlie P.
> 
> 
> George Tsirtsis wrote:
> 
> > Hi all,
> >
> > This is probably a stupid question but here it is anyway:
> > The Registration Request header in MIPv4 have the following flags:
> >
> >    +-+-+-+-+-+-+-+-+-+-+-+-+
> >     ...|S|B|D|M|G|r|T|x|    ...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > of which:
> >
> >       r        Sent as zero; ignored on reception.  SHOULD NOT be
> >                allocated for any other uses.
> >
> > Can anyone tell me why this SHOULD NOT be allocated in the 
> future?? Is
> there
> > any logic behind this or it is just an arbitrary act of fate?
> >
> > Thanks
> > George
> 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 16:44:04 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08359
	for ; Tue, 30 Apr 2002 16:44:04 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11602;
	Tue, 30 Apr 2002 14:43:29 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22951;
	Tue, 30 Apr 2002 13:43:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UKgGrP006978
	for ; Tue, 30 Apr 2002 13:42:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UKgGE1006977
	for mobile-ip-dist; Tue, 30 Apr 2002 13:42:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UKgDrP006970
	for ; Tue, 30 Apr 2002 13:42:13 -0700 (PDT)
Received: from patan.sun.com ([129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28676
	for ; Tue, 30 Apr 2002 13:42:16 -0700 (PDT)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24081
	for ; Tue, 30 Apr 2002 14:42:15 -0600 (MDT)
Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 30 Apr 2002 16:39:17 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: [mobile-ip] Status of draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt
Date: Tue, 30 Apr 2002 16:39:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

In going through the last call comments on regional registrations there were
some posts about the status of this draft and to what extent it had been
discussed in the working group.  

Raj and I had talked about it and I'd proposed that we not advance this
document
based on the perceived lack of interest in it in terms of real
implementation, in
fact to remove it completely from the WG's agenda.  Since some work has been
done
on it, perhaps the correct thing to do would be to keep it and publish it as
an experimental RFC.  I can't say that I'm in favor of the latter but
tentatively
agree to do so.  When the WG started the effort there was tremendous
interest in it
but that interest has dropped nearly to zilch.  If starting today it's not
clear
there is enough constituency to add it as a working group item.  Hence my
preference to drop it altogether.  Neither of us thought that taking it onto
the standards track as proposed was appropriate.

We should have kept the WG up-to-date on our thinking and appreciate hearing
feedback on this.

Phil



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 17:16:35 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09216
	for ; Tue, 30 Apr 2002 17:16:34 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29521;
	Tue, 30 Apr 2002 14:14:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05190;
	Tue, 30 Apr 2002 14:14:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ULDFrP007139
	for ; Tue, 30 Apr 2002 14:13:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ULDF6a007138
	for mobile-ip-dist; Tue, 30 Apr 2002 14:13:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ULDCrP007131
	for ; Tue, 30 Apr 2002 14:13:12 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04738
	for ; Tue, 30 Apr 2002 14:13:13 -0700 (PDT)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22133
	for ; Tue, 30 Apr 2002 14:13:12 -0700 (PDT)
Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 30 Apr 2002 17:10:15 -0400
Message-ID: 
From: Phil Roberts 
To: "'mobile-ip@sunroof.eng.sun.com'" 
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-lowlatency-handoffs
	-v4-03.txt
Date: Tue, 30 Apr 2002 17:10:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

This is about the low latency doc - I happened to be reminded of
it while reading about reg. registrations, but I'm talking about
low latency.  I can see how what I posted would be misleading.  Sorry
about that.

> -----Original Message-----
> From: Phil Roberts [mailto:PRoberts@MEGISTO.com] 
> Sent: Tuesday, April 30, 2002 4:39 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: [mobile-ip] Status of 
> draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt
> 
> 
> In going through the last call comments on regional 
> registrations there were some posts about the status of this 
> draft and to what extent it had been discussed in the working group.  
> 
> Raj and I had talked about it and I'd proposed that we not 
> advance this document based on the perceived lack of interest 
> in it in terms of real implementation, in fact to remove it 
> completely from the WG's agenda.  Since some work has been 
> done on it, perhaps the correct thing to do would be to keep 
> it and publish it as an experimental RFC.  I can't say that 
> I'm in favor of the latter but tentatively agree to do so.  
> When the WG started the effort there was tremendous interest 
> in it but that interest has dropped nearly to zilch.  If 
> starting today it's not clear there is enough constituency to 
> add it as a working group item.  Hence my preference to drop 
> it altogether.  Neither of us thought that taking it onto the 
> standards track as proposed was appropriate.
> 
> We should have kept the WG up-to-date on our thinking and 
> appreciate hearing feedback on this.
> 
> Phil
> 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 17:19:54 2002
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09296
	for ; Tue, 30 Apr 2002 17:19:53 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17333;
	Tue, 30 Apr 2002 15:19:17 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06905;
	Tue, 30 Apr 2002 14:19:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ULIJrP007176
	for ; Tue, 30 Apr 2002 14:18:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ULII7m007175
	for mobile-ip-dist; Tue, 30 Apr 2002 14:18:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ULIFrP007168
	for ; Tue, 30 Apr 2002 14:18:15 -0700 (PDT)
Received: from onion (onion [129.148.174.110])
	by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g3ULIGg23776
	for ; Tue, 30 Apr 2002 17:18:16 -0400 (EDT)
Date: Tue, 30 Apr 2002 17:18:14 -0400 (EDT)
From: "Steven M. Glass" 
Reply-To: "Steven M. Glass" 
Subject: RE: [mobile-ip] Issue with IPdst in FA reply when MN home address  is 0.0.0.0
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

    The five opinions I've seen all agree with this - is that concensus?

                              Cheers,
                                  Steve

>     This is my concern (that and I like to see things more consistent across
> related cases, and for easier implementation reasons).  I do NOT want to see
> a bit in the registration request to indicate "please broadcast my
> registration reply with an address assignment back to me".   My guess is the
> reason secion 3.7.2.3 is worded the way it is may have something to do with
> the misnomer that broadcast@L3 means you broadcast@L2.  You can broadcast@L3
> with a unicast L2 (and thereby also not force your MN to support pomiscuity
> at L3).  One key reason to not broadcast L2 is that it wakes sleeping
> clients (not nice if your battery powered, smart radio management issues
> aside).
> 
>     Anyway, I'd like to see this changed so that the FA *always* sends
> registration replies to 255.255.255.255 in response to registration requests
> with IPsrc = 0.0.0.0.
> 
>     Does anyone else have any thoughts?
> 
>                               Cheers,
>                                   Steve
> 
> 
> > Snip from RFC 2131, section 4.1 "Constructing and Sending DHCP messages":
> > 
> > "Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER,
> > DHCPACK and DHCPNAK messages directly to the client using uicast delivery.
> > The IP destination address (in the IP header) is set to the DHCP 'yiaddr'
> > address and the link-layer destination address is set to the DHCP 'chaddr'
> > address."
> > 
> > As you can see, DHCP will actually try to send replies unicast to the
> > address that is being assigned, exactly how MIP is designed.  However, if
> > you read a little further in RFC 2131 (DHCP), it describes that some hosts
> > may not have the ability to receive IP packets sent to addresses they don't
> > yet have.  Therefore, they have built in a flag in the DHCPDISCOVER message
> > which requests that the server broadcast the replies back.
> > 
> > I don't really know if such hosts exist, but if so I guess they will not
> > work with MIP address assignment??
> > 
> > matt
> 
> 
> 
> 
> > > -----Original Message-----
> > > From: Steven M. Glass [mailto:Steven.Glass@Sun.COM]
> > > Sent: Thursday, April 04, 2002 8:37 PM
> > > To: mobile-ip@sunroof.eng.sun.com
> > > Subject: [mobile-ip] Issue with IPdst in FA reply when MN home address
> > > is 0.0.0.0
> > > 
> > > 
> > >     As long as we're republishing 3220 anyway...
> > > 
> > >     The scenario in question is limited to a non-colocated MN 
> > > registering with
> > > a home address of 0.0.0.0 via a foreign agent.  In question 
> > > is the address the
> > > FA uses when sending a registration reply to said MN.
> > > 
> > >     My understanding of section 3.7.2.3 (and 3.7.3.2 which 
> > > refers to using the
> > > same rules as section 3.7.2.3) is:
> > > 
> > >         1) - FA rejecting the registration request ->
> > >             the registration reply is sent to 255.255.255.255
> > > 
> > >         2) - FA forwarding a registration reply from the HA ->
> > >             a) - if the registration reply contains a non-0 Home addr
> > >                  the FA forwards the reply to the [assigned] home addr
> > > 
> > >             b) - if the registration reply contains a home addr of
> > >                  0.0.0.0, the FA forwards the reply to 255.255.255.255
> > > 
> > >      If that's the correct understanding to have, then my 
> > > question is directed
> > > at 2a above:
> > > 
> > >      Why doesn't this behave like bootP, DHCP, etc, and 
> > > ALWAYS send the reply
> > > to 255.255.255.255?  Since in all cases the MN doesn't know 
> > > what address to
> > > listen for, making it consistent seems to me to be the right 
> > > thing to do.  I
> > > confess to having to read the section something like 3 times 
> > > to not mis-read
> > > it - so what am I missing?
> > > 
> > >                               Cheers,
> > >                                   Steve
> > > 
> 
> 




From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 17:59:50 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10385
	for ; Tue, 30 Apr 2002 17:59:50 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24492;
	Tue, 30 Apr 2002 14:57:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21587;
	Tue, 30 Apr 2002 14:57:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ULuhrP007327
	for ; Tue, 30 Apr 2002 14:56:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3ULuhgT007326
	for mobile-ip-dist; Tue, 30 Apr 2002 14:56:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged))
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3ULuerP007319
	for ; Tue, 30 Apr 2002 14:56:40 -0700 (PDT)
Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207])
	by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g3ULufJe015588;
	Tue, 30 Apr 2002 14:56:41 -0700 (PDT)
Message-Id: <200204302156.g3ULufJe015588@jurassic.eng.sun.com>
Date: Tue, 30 Apr 2002 14:59:02 -0700 (PDT)
From: Samita Chakrabarti 
Reply-To: Samita Chakrabarti 
Subject: RE: [mobile-ip] Issue with IPdst in FA reply when MN home address  is 0.0.0.0
To: Steven.Glass@Sun.COM
Cc: mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Q2PwmUoSgFE3W9AEicPgcw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Hi Steve,


> 
>     The five opinions I've seen all agree with this - is that concensus?
> 
>                               Cheers,
>                                   Steve
> 

I have suggested  the following text for 3.7.2.3 to fix the problems 
in the RFC3220, as per Charlie's request. Did not hear any objection
to it so far. So, I believe, we can use this text.


     IP Destination Address

               If the Registration Reply is generated by the Foreign
               Agent in order to reject a mobile node's Registration
               Request, and the Registration Request contains a source 
               Address which is not 0.0.0.0, then the IP Destination
               Address is copied from the IP source address field of the
               Registration Request.  If the Registration
               Reply is received from the Home Agent, and the corresponding
            Registration Request contains a non-zero source address, then theIP
               Destination Address is copied from the source address field
               of the Registration Request.  Otherwise, when the source address
               of the Registration request is 0.0.0.0 the IP Destination
               Address of the Registration Reply is set to be 255.255.255.255.


The above text should cover the following scenarios:

1. When MN has home-addr as it's configured IP-addr
2. When MN has Co-located care-of-addr.
3. When MN has configured with home-addr, but the HA replied with
   a home-addr which is not equal to the currently configured one.
4. When MN does not have any IP address configured and uses 0.0.0.0
   as it's source address of the registration request.
5. When MN does not have a home-addr, but acquires a temporary address
   in the local network and requests a homeaddr from homeagent (If
   we allow this case, actually this case is useful to prevent broadcast
   regReply, even though the L2addr could be the unicast one, but don't
   know if there is any security threat behind this). 


Also, in my previous email, I had requested to revisit the 'MUST' requirement

for IP Source address in 3.6.1.1 section as per previous email discussions
in the list:

   IP Source Address (as per current definition in RFC3220):

      -  When registering on a foreign network with a co-located care-of
         address, the IP source address MUST be the care-of address.

      -  Otherwise, if the mobile node does not have a home address, the
         IP source address MUST be 0.0.0.0.

      -  In all other circumstances, the IP source address MUST be the
         mobile node's home address.
-Samita

> >     This is my concern (that and I like to see things more consistent across
> > related cases, and for easier implementation reasons).  I do NOT want to see
> > a bit in the registration request to indicate "please broadcast my
> > registration reply with an address assignment back to me".   My guess is the
> > reason secion 3.7.2.3 is worded the way it is may have something to do with
> > the misnomer that broadcast@L3 means you broadcast@L2.  You can broadcast@L3
> > with a unicast L2 (and thereby also not force your MN to support pomiscuity
> > at L3).  One key reason to not broadcast L2 is that it wakes sleeping
> > clients (not nice if your battery powered, smart radio management issues
> > aside).
> > 
> >     Anyway, I'd like to see this changed so that the FA *always* sends
> > registration replies to 255.255.255.255 in response to registration requests
> > with IPsrc = 0.0.0.0.
> > 
> >     Does anyone else have any thoughts?
> > 
> >                               Cheers,
> >                                   Steve
> > 
> > 
> > > Snip from RFC 2131, section 4.1 "Constructing and Sending DHCP messages":
> > > 
> > > "Normally, DHCP servers and BOOTP relay agents attempt to deliver 
DHCPOFFER,
> > > DHCPACK and DHCPNAK messages directly to the client using uicast delivery.
> > > The IP destination address (in the IP header) is set to the DHCP 'yiaddr'
> > > address and the link-layer destination address is set to the DHCP 'chaddr'
> > > address."
> > > 
> > > As you can see, DHCP will actually try to send replies unicast to the
> > > address that is being assigned, exactly how MIP is designed.  However, if
> > > you read a little further in RFC 2131 (DHCP), it describes that some hosts
> > > may not have the ability to receive IP packets sent to addresses they 
don't
> > > yet have.  Therefore, they have built in a flag in the DHCPDISCOVER 
message
> > > which requests that the server broadcast the replies back.
> > > 
> > > I don't really know if such hosts exist, but if so I guess they will not
> > > work with MIP address assignment??
> > > 
> > > matt
> > 
> > 
> > 
> > 
> > > > -----Original Message-----
> > > > From: Steven M. Glass [mailto:Steven.Glass@Sun.COM]
> > > > Sent: Thursday, April 04, 2002 8:37 PM
> > > > To: mobile-ip@sunroof.eng.sun.com
> > > > Subject: [mobile-ip] Issue with IPdst in FA reply when MN home address
> > > > is 0.0.0.0
> > > > 
> > > > 
> > > >     As long as we're republishing 3220 anyway...
> > > > 
> > > >     The scenario in question is limited to a non-colocated MN 
> > > > registering with
> > > > a home address of 0.0.0.0 via a foreign agent.  In question 
> > > > is the address the
> > > > FA uses when sending a registration reply to said MN.
> > > > 
> > > >     My understanding of section 3.7.2.3 (and 3.7.3.2 which 
> > > > refers to using the
> > > > same rules as section 3.7.2.3) is:
> > > > 
> > > >         1) - FA rejecting the registration request ->
> > > >             the registration reply is sent to 255.255.255.255
> > > > 
> > > >         2) - FA forwarding a registration reply from the HA ->
> > > >             a) - if the registration reply contains a non-0 Home addr
> > > >                  the FA forwards the reply to the [assigned] home addr
> > > > 
> > > >             b) - if the registration reply contains a home addr of
> > > >                  0.0.0.0, the FA forwards the reply to 255.255.255.255
> > > > 
> > > >      If that's the correct understanding to have, then my 
> > > > question is directed
> > > > at 2a above:
> > > > 
> > > >      Why doesn't this behave like bootP, DHCP, etc, and 
> > > > ALWAYS send the reply
> > > > to 255.255.255.255?  Since in all cases the MN doesn't know 
> > > > what address to
> > > > listen for, making it consistent seems to me to be the right 
> > > > thing to do.  I
> > > > confess to having to read the section something like 3 times 
> > > > to not mis-read
> > > > it - so what am I missing?
> > > > 
> > > >                               Cheers,
> > > >                                   Steve
> > > > 
> > 
> > 
> 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 18:13:40 2002
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10768
	for ; Tue, 30 Apr 2002 18:13:40 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02258;
	Tue, 30 Apr 2002 16:13:02 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28548;
	Tue, 30 Apr 2002 15:11:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UMAprP007384
	for ; Tue, 30 Apr 2002 15:10:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UMApNG007383
	for mobile-ip-dist; Tue, 30 Apr 2002 15:10:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UMAmrP007376
	for ; Tue, 30 Apr 2002 15:10:48 -0700 (PDT)
Received: from lukla.Sun.COM ([129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28187
	for ; Tue, 30 Apr 2002 15:10:50 -0700 (PDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28011
	for ; Tue, 30 Apr 2002 16:10:48 -0600 (MDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA15203 for ; Tue, 30 Apr 2002 15:10:47 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA03984 for ; Tue, 30 Apr 2002 15:10:47 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id <2NG92AJV>; Tue, 30 Apr 2002 17:10:47 -0500
Message-ID: 
From: Singh Ajoy-ASINGH1 
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-lowlatency-handoffs
	-v4-03.txt
Date: Tue, 30 Apr 2002 17:10:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 

Phil/Raj,
We have implemented low latency handoff draft. Our observation 
is that fast handoff performs far better than standard 
Mobile/IP. I do see value in publishing this
document as RFC. Probably it is okay to publish this as 
experimental RFC if not standard track.
regards,
ajoy

-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Tuesday, April 30, 2002 3:39 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Status of
draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt


In going through the last call comments on regional registrations there were
some posts about the status of this draft and to what extent it had been
discussed in the working group.  

Raj and I had talked about it and I'd proposed that we not advance this
document
based on the perceived lack of interest in it in terms of real
implementation, in
fact to remove it completely from the WG's agenda.  Since some work has been
done
on it, perhaps the correct thing to do would be to keep it and publish it as
an experimental RFC.  I can't say that I'm in favor of the latter but
tentatively
agree to do so.  When the WG started the effort there was tremendous
interest in it
but that interest has dropped nearly to zilch.  If starting today it's not
clear
there is enough constituency to add it as a working group item.  Hence my
preference to drop it altogether.  Neither of us thought that taking it onto
the standards track as proposed was appropriate.

We should have kept the WG up-to-date on our thinking and appreciate hearing
feedback on this.

Phil


From owner-mobile-ip@sunroof.eng.sun.com  Tue Apr 30 18:46:07 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11516
	for ; Tue, 30 Apr 2002 18:46:06 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20118;
	Tue, 30 Apr 2002 15:43:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14003;
	Tue, 30 Apr 2002 15:43:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UMgnrP007503
	for ; Tue, 30 Apr 2002 15:42:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g3UMgm0p007502
	for mobile-ip-dist; Tue, 30 Apr 2002 15:42:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g3UMgjrP007495
	for ; Tue, 30 Apr 2002 15:42:45 -0700 (PDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13713
	for ; Tue, 30 Apr 2002 15:42:47 -0700 (PDT)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14509
	for ; Tue, 30 Apr 2002 15:42:47 -0700 (PDT)
Message-ID: <017901c1f098$1d7b2730$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Phil Roberts" , 
References: 
Subject: Re: [mobile-ip] Status of draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt
Date: Tue, 30 Apr 2002 15:41:06 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
List-Archive: 
List-Owner: 
List-Subscribe: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

Phil,

In general, as Hesham has pointed out, commercial interest hasn't
typically been the decisive criterion in the past about how to dispose
of IETF specs. That may be changing, but I believe there is value in
this work despite the fact that nobody is interested in implementing it
commercially. From a research standpoint, Motorola and DoCoMo have done
a fairly extensive amount of work to implement the protocols described
in this spec, and we have performed fairly extensive measurements on the
performance of the protocols over a simulator and two radio protocols.
We have not had the opportunity to make the results of this work
available at the IETF,  because typically such studies are not the kind
of material that gets presented in IETF meetings, and the need for
detailed graphs makes writing drafts in ASCII on the material
cumbersome. Also, the working group has been fairly consumed with
discussing MIPv6 security for the last year to the exclusion of other
topics. However, we are planning on publishing the results in other
venues and we can make references to the material available if people
are interested. Perhaps, in the final version of the draft, we can embed
the references.

It is, of course, disappointing that nobody else is interested in
implementing these protocols for research purposes, but I believe that
the amount of research work done on the protocols already justifies an
Experimental classification. There is has certainly been more work done
on these protocols, both from the design standpoint and in the
implementation and measurement, than another Experimental RFC (RFC 3082)
with which I was associated.

Therefore, I believe we should advance the draft to WG last call for
Experimental.

            jak

----- Original Message -----
From: "Phil Roberts" 
To: 
Sent: Tuesday, April 30, 2002 1:39 PM
Subject: [mobile-ip] Status of
draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt


> In going through the last call comments on regional registrations
there were
> some posts about the status of this draft and to what extent it had
been
> discussed in the working group.
>
> Raj and I had talked about it and I'd proposed that we not advance
this
> document
> based on the perceived lack of interest in it in terms of real
> implementation, in
> fact to remove it completely from the WG's agenda.  Since some work
has been
> done
> on it, perhaps the correct thing to do would be to keep it and publish
it as
> an experimental RFC.  I can't say that I'm in favor of the latter but
> tentatively
> agree to do so.  When the WG started the effort there was tremendous
> interest in it
> but that interest has dropped nearly to zilch.  If starting today it's
not
> clear
> there is enough constituency to add it as a working group item.  Hence
my
> preference to drop it altogether.  Neither of us thought that taking
it onto
> the standards track as proposed was appropriate.
>
> We should have kept the WG up-to-date on our thinking and appreciate
hearing
> feedback on this.
>
> Phil
>
>